My 2017-2018 Introspections
Posted by Jim Jagielski on Thursday, January 4. 2018 in Open Source, Personal, Technology, Work
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:
The Path to Apache OpenOffice 4.2.0
Posted by Jim Jagielski on Monday, December 4. 2017 in ASF, Open Source
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
Posted by Jim Jagielski on Friday, January 29. 2016 in Open Source, Personal
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
Posted by Jim Jagielski on Tuesday, January 26. 2016 in ASF, Open Source, Programming
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
Posted by Jim Jagielski on Friday, April 17. 2015 in Open Source
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.
Page 5 of 5, totaling 23 entries