IMO - Open Source

My 2017-2018 Introspections

nospam@example.com (Jim Jagielski) — Thu, 04 Jan 2018 10:10:00 -0500

As the old year falls away and the new year boots up, it is traditional for people to write "old year retrospectives" as well as "new year predictions." Heck, I originally envisioned this entry as a duet of 2 separate blogs. But as much as I tried, it was just too difficult to keep them distinct and self-contained. There was simply too much overlap and as much as I expect "new things" in 2018, I think 2018 will mostly be a solidification of events and issues ramped up from 2017.

So with all that in mind, I present my 2017-2018 Introspections... in no particular order:

Continue reading "My 2017-2018 Introspections"

The Path to Apache OpenOffice 4.2.0

nospam@example.com (Jim Jagielski) — Mon, 04 Dec 2017 07:57:45 -0500

It is no secret that, for awhile at least, Apache OpenOffice had lost its groove.

Partly it was due to external issues. Mostly that the project and the committers were spending a lot of their time and energies battling and correcting the FUD associated around the project. Nary a week would go by without the common refrain "OpenOffice is Dead. Kill it already!" and constant (clueless) rehashes of the history between OpenOffice and LibreOffice. With all that, it is easy and understandable to see why morale within the AOO community would have been low. Which would then reflect and affect development on the project itself.

So more so than anything, what the project needed was a good ol' shot of adrenaline in the arm and some encouragement to keep the flame alive. Over the last few months this has succeeded beyond our dreams. After an admittedly way-too-long period, we finally released AOO 4.1.4. And we are actively working on not only a 4.1.5 release but also preparing plans for our 4.2.0 release.

And it's there that you can help.

Part of what AOO really wants to be is a simple, easy-to-user, streamlined office suite for the largest population of people possible. This includes supporting old and long deprecated OSs. For example, our goal is to continue to support Apple OSX 10.7 (Lion) with our 4.2.0 release. However, there is one platform which we are simply unsure about what to do, and how to handle it. And what makes it even more interesting is that it's our reference build system for AOO 4.1.x: CentOS5

Starting with AOO 4.2.0, we are defaulting to GIO instead of Gnome VFS. The problem is that CentOS5 doesn't support GIO, which means that if we continue with CentOS5 as our reference build platform for our community builds, then all Linux users who use and depend on those community builds will be "stuck" with Gnome VFS instead of GIO. If instead we start using CentOS6 as our community build server. we leave CentOS5 users in a lurch (NOTE: CentOS5 users would still be able to build AOO 4.2.0 on their own, it's just that the binaries that the AOO project supplies won't work). So we are looking at 3 options:

We stick w/ CentOS5 as our ref build system for 4.2.0 but force Gnome VFS.
We move to CentOS6, accept the default of GIO but understand that this moves CentOS5 as a non-supported OS for our community builds.
Just as we offer Linux 32 and 64bit builds, starting w/ 4.2.0 we offer CentOS5 community builds (w/ Gnome VFS) IN ADDITION TO CentOS6 builds (w/ GIO). (i.e.: 32bit-Gnome VFS, 64bit-Gnome VFS, 32bit-GIO, 64bit-GIO).

Which one makes the most sense? Join the conversation and the discussion on the AOO dev mailing list!

The brave, new post open source world disaster

nospam@example.com (Jim Jagielski) — Fri, 29 Jan 2016 08:48:11 -0500

Ahhh... The post open source, hipster development world. All is light and unicorns. People have rejected the ideas of governance and licenses; just shove it on Github and share, share, share. "This is the way Open Source should be", it is declared in Vape shops whilst listening to vinyl on their turntables, pork-pie hat skewed so ironically. "Rulz just get in the way, I just wanna do my own thing".

All Hail the fork; meh the merge and the pull. Don't lurk on a mailing list (A mailing list! Get with the times!), ask drive by questions on Stack Overflow. Don't use open tools and collaboration s/w, use cool proprietary systems and software (lock in? what's that?)

Yeah, I'm a greybeard, and I've been part of the open source movement for awhile, having at least some small part in its success. "Wasn't the whole idea of the open source movement, in some way, to make it the default, to move software and software development to align with the goals and ideals of Open Source? Wasn't it, after all, to make Open Source a success?" people will say. "Well it is! So what are you complaining about?"

I am not complaining about the success of Open Source. What I am complaining about, what I am worried about, is redirection of the movement in a way which destroys the successes by ignoring the history of the movement. What I am worried about are people ignoring the lessons learned, and the wisdom obtained during the decades within the movement, by people who don't understand it, but think they do. What I fear is the increasing "influence" of so-called open source experts today, who dismiss what Open Source is, because it is "old" and "outdated" and "that's not how we do things anymore". And I'm angry at people taking a dump on such concepts as community, collaboration and consensus because "that's just too much work".

I'll be honest. IMO, if the prevailing attitudes and "understanding" of Open Source today were around at the beginning of the Open Source movement, then Open Source would never have gained traction. Look at the things that made Open Source popular and successful. It was a keen awareness that code needed to be explicly licensed so people could use it. It was a deep understanding that working together, on a single project, was important, instead of numerous side-projects recreating the wheel. It was a core tenent that people worked on this project because they were personally invested in it, it was important to them, it was personal to them, they volunteered their time and energy on it. It was the balance that communities governed the projects, and companies worked with the communities instead of over them.

Look at all those points, and look at how today, in many ways, they are no longer "important" or "a big deal" to many self-proclaimed next generation open source experts.

You don't honor a movement, you don't carry the torch, you don't keep the dream alive, by ignoring and dimissing the core of what made that movement, that dream, special. Don't turn the Brave, New, Post Open Source world into the Weird Bizarro Open Source World, where it's a funhouse mirror-image of what it could, and should, be.

Apache httpd Reverse Proxy

nospam@example.com (Jim Jagielski) — Tue, 26 Jan 2016 08:23:01 -0500

I've always considered the reverse proxy capability of Apache httpd as one of the real (hidden) gems of the web server. Of course, httpd has a lot of gems: multiple MPMs; a plethora of content creation and rewriting capabilities; dynamic loadable modules; performance and concurrency easily matching its peers; in-depth Lua, Perl and PHP support; and, of course, the vast number of external, 3rd party modules out there. But, for me, the reverse proxy has always been one of its crowning achievements.

So even though Apache httpd excels at delivering both static and dynamic content, an extremely common use-case is for httpd to be used as a "simple" reverse proxy (aka: "gateway"). In this scenario, httpd acts basically like a switch, accepting requests but handing those requests off to servers on the backend. Those backend servers ("origin servers") are where the content really lives, or is created, but the outside never sees them; never even knows they exists. As far as the Web is concerned, that front end gateway is sole server.

The advantages of this setup are numerous and obvious; The implementation provides for high-availability, load balancing, failover, reliability, etc... but only if the gateway web server, the reverse proxy itself, has that capability. Fortunately, Apache httpd does. It has all that and more.

Because it is such a common use-case, and because this capability to so vital to the design and architecture of enterprise web infrastructure, including Cloud setups, I've focused a lot of adding features and improvements to httpd's reverse proxy. Along with the other committers on the httpd project, not only has load balancing been added (and has been for quite awhile), but there are various load balancing methods included, with the ability to add your own implementation very easily. With the balancer-manager, the devops admin gets not only a view into the current state of the reverse proxy, but can also dynamically change various reverse proxy parameters on-the-fly, with these changes surviving a server restart. The reverse proxy supports not only HTTP, but also FastCGI, Websockets, AJP and others. And just recently, I finished work on something that has been on my TODO list for awhile, and something people have wanted for awhile as well: Dynamic Health Checking.

In the normal situations, before httpd sends a request to the backend origin server, it checks to see if it is still "alive" and able to handle the request. Now this is great but it would be even better if, in parallel, httpd was also checking if those backend servers were alive or not independent of requests being passed to them. In other words, not only static health checks but also dynamic checks as well.

Well, now Apache httpd can do exactly that.

Right now this capability exists just on the trunk branch of the server, but I anticipate it being fast-tracked backported to the 2.4.x branch. There are also some addition features I'd like to add in, such as better interaction with the balancer-manager before it is backported. But before too long, the Apache httpd reverse proxy will have this capability and be even better than it is now, and continuing to be even better than its peers, whether they are Open Core or commericial or truly Open Source.

Try it out! And if you are interested in helping develop Apache httpd, jump in and join the fun. Unlike other web server projects, contributor and commit privs can obtained by anyone, not just specially picked people, like "employees" or stuff.

Open Source Has Won The Battle; Let's Not Lose The War

nospam@example.com (Jim Jagielski) — Fri, 17 Apr 2015 10:47:46 -0400

The below is an abstract for a talk...

Open Source Has Won The Battle; Let's Not Lose The War

20 years ago, a bunch of us got together and created Apache, and then 5 years later went ahead and created The Apache Software Foundation. The idea of Open Source back then was weird, and wild, and suspect. But due to the power and capability of the Apache Web Server, in combination with Linux, Open Source gained traction, acceptance and now ubiquity.

Looking around at the IT landscape nowadays, Open Source is found everywhere. Software is eating the world, and Open Source is the utensil of choice. Corporations once critical of Open Source, now embrace it; Open Source is now both strategic and mandatory. In many ways, one could assume that Open Source has won.

Well, maybe it has won, but it's just won the battle; the war is still there, and our success in winning the battle is threatening to cause our loss of the war.

"It's on Github, so of course it's Open Source, right?" Wrong.

"It's got an OSI license, so nothing else is needed, right?" Wrong.

"There's nothing wrong with paid developers/contributors, right?" Well... maybe yes and maybe no.

"What is really the matter with pay-to-play Open Source foundations?" Give me 30 minutes or so, and I'll tell you what the risks are.

There's an old saying that in Open Source, developers/contributors scratch their own itches. But what about today? Do they still? Can they still? And what is the ultimate harm if they can't. And as more and more Open Source gets funded, directly, by corporations, where does that leave the true volunteer contributor? And finally, who really has the ultimate control over a project's destiny?

This presentation will give a short history of the Open Source movement, and why the most critical forces behind its success in being an innovation engine may be at risk.

Open Source and Trademarks

nospam@example.com (Jim Jagielski) — Tue, 11 Nov 2014 09:00:00 -0500

In any area of business and activity related to business, the idea behind, and protection of, trademarks is critical. But what some people don't understand is that in the Open Source/Free Software world, trademarks are, in many ways, the only real asset that a FOSS project has.

Think about this: in most normal areas of software development, the software itself (the code) is intellectual property. It is itself an asset, with value. But in an open source world, the code is free and open to all. "Having" the code isn't any sort of asset, since anyone can also have it as well; in fact, it is encouraged to share that code with as many people as possible. So whereas in other circumstances, the resulting work behind the effort of coding is an "asset", and, in many ways, the most valuable asset, with FOSS projects it is the least valuable.

So what is the main asset of a FOSS project?

The trademark. The brand and goodwill associated with that project. And for many projects, it's the only asset, and it's the main reason why people contributed to, and use, the code. For example, one significant reason why projects enter the Apache Software Foundation is that they want to leverage and benefit from the Apache brand. Being an Apache project automatically gives a project a sense of credibility, as well as a promise on how it will be governed and managed, and how code provenance will be done. It is a reputation obtained from years and years of doing things the right way; The Apache name means something. It has become a brand.

With this in mind, it should be somewhat obvious why FOSS projects walk that fine line between wanting (and needing) to protect their trademarks (and brand) yet, at the same time, allowing people to use those marks in as unrestricted ways as possible. On one hand, you want to use that brand to encourage even wider sharing and usage of the code, yet on the other hand, you must protect those marks from usage which would damage the brand, or confuse people. And so most FOSS projects or foundations create trademark policies that describe acceptable and unacceptable usage.

So I was shocked and extremely disappointed to hear that GNOME is having to battle Groupon over Groupon's unacceptable use of the GNOME mark. There are only 2 possible ways this could have come about:

Those at Groupon tasked with this effort are so incompetent and clueless that they never heard of GNOME
That Groupon is simply thumbing their noses at GNOME and, by extension, the entire FOSS community as well.

This is totally unacceptable, and is, IMO, an attack on all FOSS projects and foundations. When well-funded corporate entities, especially those who directly benefit from FOSS, go ahead and simply decide they can steam-roller over the FOSS community, it is time for all of us to take a stand. Help GNOME defend their mark!

Open Source and Trademarks

nospam@example.com (Jim Jagielski) — Tue, 11 Nov 2014 09:00:00 -0500

So what is the main asset of a FOSS project?

Those at Groupon tasked with this effort are so incompetent and clueless that they never heard of GNOME
That Groupon is simply thumbing their noses at GNOME and, by extension, the entire FOSS community as well.

Shellshock: No, it IS a bash bug

nospam@example.com (Jim Jagielski) — Mon, 29 Sep 2014 12:32:41 -0400

Reading over http://paste.lisp.org/display/143864, I am surprised just how wrong the entire post is.

The gist of the post is that the Shellshock bug is not bash's fault, but rather, in this argument, the fault of Apache and other facing programs in not "sanitizing" the environment before it gets into bash's hands.

Sweet Sassy Molassy! What kind of horse-sh*t is that?

As "proof" of this argument, pjb uses the tired old excuse: "It's not a bug, it's a feature", noting that bash's execution of commands "hidden" in environment variables is documented; But then we get the best line of all:

The implementation detail of using an environment variable whose value starts with "() {" and which may contain further commands after the function definition is not documented, but could still be considered a feature

As far as outlandish statements, this one takes the cake. Somehow, Apache and other programs should sanitize magical, undocumented features and their failure to do so is the problem, not that this magic is undocumented as well as fraught with issues in and of itself.

Let's recall that if any other Bourne-type shell, or, in fact, any real POSIX-compliant shell (which bash claims to be), were being used in the exact situation that bash was being used, there would be no vulnerability. None. Nada. Zero. Replace with ksh, zsh, dash, ... and you'd be perfectly fine. No vulnerability and CGI would work just fine. And also let's recall, again focusing on Apache (and all web servers, in fact; It's not just Apache is affected by this vulnerability but any web server, such as nginx, etc...), the CGI specification specifically makes it clear that environment variables are exactly where the parameters of the client's request lives.

Also, let's consider this: A shell is where the unwashed public interfaces with the OS. If there is ANY place where you don't want undocumented magic, especially in executing random code in an undocumented fashion, it AIN'T the shell. And finally, the default shell is also run by the start-up scripts themselves, again meaning that you want that shell to have as few undocumented bugs... *cough* *cough*, sorry "features" as possible, and certainly not one's that could possible run things behind your back.

Yes, this bug, this vulnerability is certainly bash's, no doubt at all. But it also goes without saying that if bash was not the default shell (/bin/sh) on Linux and OSX, that this would have been a weaker vulnerability. Maybe that was, and is, the main takeaway here. Maybe it is time for the default shell on Linux to "return" to the old Bourne shell or, at least, dash.

Why Open Source Needs Non Profits

nospam@example.com (Jim Jagielski) — Mon, 30 Jan 2012 18:45:16 -0500

It's expected that pretty soon we all will hear about the next big "tech" IPO, which will create a mass of instant millionaires and billionaires. And these newly rich will have made their fortunes, at least partly, by leveraging Open Source and the efforts of unpaid volunteers.

I'm often asked, "Doesn't that bother you?" Ignoring the implication that somehow I "deserve" something due to my involvement when there are, of course, multitudes of people more deserving than I, I can honest answer, "No, not really."

Continue reading "Why Open Source Needs Non Profits"

I join OSI

nospam@example.com (Jim Jagielski) — Thu, 17 Mar 2011 09:05:00 -0400

Yesterday I learned that, along with Karl Fogel and Mike Godwin, I was elected to serve on the Board of Directors (BoD) of the Open Source Initiative (OSI). I consider this a great honor, joining the ranks of the great FOSS luminaries of this esteemed organization. I am also very excited by the changes and the challenges that the coming year holds for OSI, as they... we move to a member, representational model. This is, of course, the logical outcome from OSI moving from being the stewards of the Open Source Definition, to being, for lack of a better term, stewards of Open Source itself. There are, after all, quite a number of open source foundations out there, including the ASF (which I'm also on the BoD of, as well as President), the FSF and Outercurve (which I am on the BoD as well). But just as all these FOSS entities share a common license type, there are also other shared concepts which are core and central to the whole milieu of Open Source, a sort of common ground. And OSI is ideally suited to serve as the focal point for that common ground, a "United Nations" kind of entity. As successful as Open Source has been, it is clear that there is still much to be done... much FUD to be cleared away, much more "evangelism" to be done, and fostering the continued use of FOSS methodologies outside of the traditional "software development" space. And I'm proud to be part of an organization which is wholeheartedly behind all those efforts, and more. Exciting times ahead indeed.