Tuesday, September 16. 2014

Today marks the 3rd anniversary of my Dad's death. People say you'll never understand how it feels until you go through it, and they are correct. I never truly understood the emptiness that remains.

My most vivid memory of that time is standing there, at my Dad's side in the hospital, as he was breathing his last breaths.; watching the EKG go from a slow but steady beat, to a weak and chaotic wave and then, like a bad soap opera or medical show, to a simple flat line. And he was gone.

I looked at my Dad and all he really *was*, was gone. All that remained was the shell that carried the real Joe Jagielski. He was here, but he really wasn't. I looked at Dad and he was, but he wasn't, my Dad.

We all are aware of our mortality, but it never feels real to us. But when someone close to you dies, especially when you are right there when it happens, it brings it home like a bombshell. I can truly say that, for better or worse, my awareness of death and mortality is never that much below the surface. We all die, and before that happens, we should spend our lives with as much joy and fulfillment as possible.

This realization has somehow made me more, and yet also, less patient. I try not to let little things bother me, and try to see the good in people. I'm more sensitive to people, or, at least, I try to be. Yet, on the other hand, I find that I have little to no patience with two-faced or selfish people who are only there for you if it's "convenient"; Life is too short, and I don't have the time to waste. None of us do.

Dad, I miss you, and I always will. I love you.


Wednesday, December 26. 2012

Now that Christmas Day itself is over, but not the Season, I'm taking some time to reflect on the lessons detailed in Dickens' "A Christmas Carol." And upon reflection, I've decided that the most important character in the story is not Scrooge himself, but instead his deceased partner, Jacob Marley.

Dickens himself suggests so, by starting the novel ensuring his readers that Marley was most certainly dead. He realizes that the story itself has no depth, unless the scene between Scrooge and Marley actually, truly happened. Unless Marley was dead, and unless what he conveys to Scrooge is Truth, then Scrooge's change lacks the power that it deserves.

But even more so, to me, unless Marley is seen (and for the purposes of this blog post, portrayed) as this immensely tragic and woeful creature, the danger that Scrooge is exposing himself to and the dismal eternal future of those who waste their lives here on Earth, then "nothing wonderful" can come from the tale. And so, even more so (if possible) than the words of Marley, the pitiful nature of Marley provides the fuel for the entire story. Again, Dickens' emphasizes this, since Marley is constantly noted as raising a "frightful cry", or shaking his chains in woe. Marley is completely and totally miserable.

So when I watch the various incarnations of "A Christmas Carol," it's the portrayal of Marley which tells me just how well the director (and the entire crew) "gets" the story. So when I watched Disney's version, with Jim Carrey, I thought that it was an OK version until  the arrival of Marley. In this version, Marley is almost comic relief! And then they made the worst mistake ever. Scrooge tries to comfort Marley by explaining this his old partner was always a good man of business, and Marley summarizes the whole of the moral of the story in the most powerful sentences of literary history:

Business! Mankind was my business. The common welfare was my business; charity, mercy, forbearance, and benevolence, were, all, my business. The dealings of my trade were but a drop of water in the comprehensive ocean of my business!

And yet, in Disney's version, he does so with his lower jaw being "comically" manipulated up-and-down by Scrooge (if you've seen the movie, you know what I mean). Unforgivable.

For me, the best version is the 1984 version with George C. Scott. Frank Finlay is, imo, spot on, and I can't but help be moved when he says the above lines. The power, the emotion, the pure and deep misery Marley feels is there, and the audience, and Scrooge, cannot help but be moved by it, and act on it.

May we all remember the lessons of Marley, and for all of us, may mankind be our business. 

The Case for a Universal Web Server Load Value

Monday, November 12. 2012

The reverse proxy feature of Apache httpd is an area which I like to particularly hack on. It's always been, imo, one of the killer features of httpd, but it is especially useful in the Cloud. Being able to dynamically allocate, enable/disable and load balance between back-ends is a MAJOR capability lacking in almost all other "generic" (and even "special-purpose") web servers. And the functionality of the reverse proxy in Apache 2.4 is pretty much state-of-the-art.

But there's a problem, which is not unique to Apache itself. In general, load balancers such as Apache do their load balancing determination based on values it calculates on the back-ends. Sure, Apache has a pretty nice set of load-balancing algorithms, but it still implies that the front-end (the reverse proxy) is responsible for predicting the load on the back-end. This is certainly not optimal.

Red Hat's mod_cluster works around this by creating a "unique" communication channel between Apache and JBoss, which allows JBoss to tell Apache some basic and useful loading parameters on the JBoss server itself. This is great, but limited (and hardly universal). What we really need, imo, is a general, universally agreed-upon method of the back-end sending server load data to the front-end. Something that all back-ends can easily generate (and enable/disable, of course) and something all reverse-proxies can easily parse and use. In other words, we need some sort of unofficial standard (which could eventually become a de-facto standard).

Using the assumption that starting simple is best, what I've been looking at is adding a simple HTTP Response header to Apache (via mod_header) which returns some subset of load parameters, the idea being that when the back-end sends the actual response, part of the meta-data it returns is some measure of its health and/or load. The front-end can then tuck that data away and use it in its load-balancing determination (while, of course, ensuring that the header is not forwarded to the client). Currently, in the trunk version of httpd (but hoping to backport it to 2.4), I have traditional Unix-type load-average and the percentage of how "idle" and "busy" the web-server is. But is that enough info? Or is that too much? How much data should the front-end want or need? Maybe a single agreed-upon value (ala "load average") is best... maybe not. These are the kinds of questions to answer.

Knowing that Apache httpd powers between 57% and 89% of the web (based on which surveys you use and/or trust), it seems logical to discuss this, and work out the particulars, on the Apache httpd development mailing list. I think the time for something like this "universal web-server load" value is long overdue. If interested, join the fun on

Why Open Source Needs Non Profits

Monday, January 30. 2012

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"

The silent drum-beat

Monday, November 28. 2011

There are some topics which are just too expansive for a simple tweet. This is one of them.

Lately, there have been quite a few posts extolling the assumed decrease in the viability and "reason" for the Apache Software Foundation. It's always fashionable to lump all FOSS foundations, and related entities (such as Github), into one combined group and pick out the "winners" and "losers" and those whose stars are rising and those whose glory days are fading away. With the hubbub around DVCS and git/Github, people look at the ASF, and our measured approach to incorporating git into our workflow policies, and declare that since we have not drank the Kool-Aid, the ASF's days are done.

But all this misses the point about what the ASF is, and who we are, and why we are. I hope this blog post will clarify some things.

Continue reading "The silent drum-beat"

I join OSI

Thursday, March 17. 2011
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.

Apache httpd 2.4 - one step closer!

Monday, March 7. 2011
Today we released the first public beta of the next-gen version of Apache httpd, version 2.4.

This release is officially called Apache httpd-2.3.11-beta, since we use odd/even numbering (for the minor version number) to signify alpha/beta vs. stable releases.

Most work has been done in improving performance and stability, but as well as adding lots of useful features, especially as we see the demands placed on web servers by cloud environments. This means that the (reverse) proxy module had gotten a lot of special care and attention. But there are also modules to help with more fine-grained control over timeouts and even a basic bandwidth limiting module bundled in.

With this release and the coming of Apache httpd 2.4 GA, you'll see the popularity and usage of Apache increase even more, as it becomes the web server for the cloud, bar none.


The Trouble with the JCP EC

Friday, December 10. 2010
Just a reminder: The below reflects my opinions and my point of view, personally, as myself.

It is a shame that some parties have described the FOU TCK issue as a battle between Oracle and Apache. It is actually between Oracle and the non-aligned Java community, as represented by the ASF. So when people say that the ASF "loses Java showdown", it isn't the ASF which "lost" (although standing up for principles and the letter of law is never losing), but instead it's the Java community as well as the FOSS community as well.

Recall that at the core of the issue is that Apache simply wanted Oracle to abide by the JSPA and allow access to the TCK without the resulting certified released being encumbered by any FOU restrictions. It is the restrictions on the release which makes it incompatible with not only the Apache License but any open source license.

The acronym JCP stands for the Java Community Process, and it was supposed to be the way in which the entire Java ecosystem would be involved in the development and future of Java. The key word in there is "Community." It wasn't supposed to be a corporate controlled group, carving out areas of Java for their own revenue producing purposes, but, as we will see, that is exactly what is has become. With the ASF leaving, there is no longer any entity within the EC which is fully and completely beholden to what is good for the community at large. That is a serious claim to make, but I think I can back it up.

First of all, let's look at the votes and, just as important, the comments with those votes. The breakdown is
  • Those that voted NO
  • Those that voted YES, but with comments expressing their disappointment with the FOU restrictions
  • Those that voted YES and provided no comments at all

Lets look at the 2nd group first (group #1 needs no explanation, I hope). But before we do that, just remember one thing. At an EC face-to-face meeting, Oracle made it perfectly clear that no matter what the outcome of the vote, they were going to move ahead with Java7 and Java8. So no matter what, no matter what people voted, Java7 and 8 would not be "held back".

Ok now, so almost without fail, the vendors in group #2 derive a significant part of their revenue on Java. Their bottom line depends on it and, for the most part, they have shareholders to worry about. They have a fiduciary duty to make money.

Now I have no doubt that Oracle used everything within their power to "convince" them to vote YES. As mentioned, since these companies depend on Java, and since the sole-source of Java is Oracle, Oracle was able to provide incentives to EC members to see things Oracle's way, in the form of significantly reduced license fees for Java, for example, promises of more control and direction within Java (which in and of itself clearly indicates that Java as a community-involved process is a sham, but I digress), and the like. At a point, these become simply too large to ignore and too significant to the bottom line to disregard.

At the same time, these entities know that if they vote NO, that they will be portrayed, by all the marketing muscle that Oracle can bring to bear, as "stopping Java" or "holding Java back" or some such FUD, even though, as we saw above, Oracle was going ahead with Java no matter what. All you have to do is look at how Oracle has responded to the ASF leaving as clear indication. It's all about "moving Java forward" with the implication that if you don't agree with Oracle, you are "hurting" Java, whereas Oracle, of course, is doing all it can to protect it.

Again, companies which derive revenue from Java cannot afford to be painted as "anti-Java", especially when a direct competitor can portray itself as the savior of Java. And so once again, there is no real option for them. As public companies, their hands are tied. (BTW: with all this in mind, how in the world the Sun acquisition got through the EU and US anti-trust laws is mind-boggling). They simply cannot afford to vote NO.

And so the YES votes are disappointing, yes, but not unexpected. And despite any indications to the contrary, I do applaud those who took the only real avenue available to them and expressed their unhappiness with Oracle and the FOU restrictions in their comments. I personally feel that they wanted to vote NO, wish they could vote NO, but simply can't.

Now regarding group #3 I have very little to say except that I am quite surprised and disappointed that one entity in particular didn't even comment on the FOU restriction. This entity is purportedly pro-Open Source and pro-community and even is directly involved in a large open-source but not open-community "seasonal" (ahem) codebase (the representative was the original coder), and yet they didn't even bother to express any support for Apache or the community at all. So whether their "we love open source" characterization is real or feigned (for pure commercial value) is, I guess, up for grabs. Maybe they had a good reason to be silent; I don't know.

So the impact of the ASF (and Tim and Doug as well) leaving the EC is more than just some disgruntled people not "getting their way" and leaving. It is, in fact, verification that there is no real balance, no real community power within the JCP. Oracle holds all the cards and can gain the system to do whatever it wants, even ignoring contractual agreements. Other EC members can fight, but they will only be allowed what Oracle lets them do. And they will have to simply sit down and take it.

The JCP is no longer about "community" in the sense of "the Java community". It no longer can serve as a process to drive Java towards what is best for all, because one single entity can overrule anything. If what "the community" wants to do aligns with Oracle's business, then Oracle will allow it to happen. If not, then it will be stopped dead in its tracks.

Sure, maybe I could be wrong. Maybe Oracle will actually let the community drive Java, be a true, actual part of the process. Maybe one day Oracle will see the open source community as an entity to be nurtured and helped, rather than a resource to be plundered. Maybe one day all that will happen, and I'll have to eat crow.

And when it does, I'll do so happily. Hell, I'll even have seconds.

But I sincerely doubt if there will ever come a day when I'm picking black feathers out of my teeth...

The JCP Is Dead

Thursday, December 9. 2010
... and Oracle killed it.

By this time, most people know that the ASF has resigned from the JCP EC.

What was posted was our final version of the notice, but I'd also like to share with the community an earlier, rougher and more "emotional" version. It says the same, but in a more face-to-face conversational way. I feel that both versions represent the disappointment, anger and sadness over this whole issue, which has been fostering since 2006. The below just captures it from a different point of view:

The Apache Software Foundation is resigning from the Java Community Process (JCP) Executive Committee (EC).

On December 7, 2010, by a vote of 12 YES and 3 NO votes, the EC approved the Java 7 and Java 8 JSRs and TCKs under license terms which are fundamentally incompatible with open source. The results of the Java7/8 JSR votes from yesterday mean that the EC has just approved a major fundamental JCP specification which, along with its TCK license, makes distribution of a tested, compatible implementation impossible under any open source license by anyone other than Oracle. The EC, by voting in favor of the Java 7/8 JSRs, have given Oracle, who openly ignored the letter of the law as well as the repeatedly stated intent of the community, tacit approval to willfully ignore its contractual obligations, despite any "protests" within their "YES" vote comments. This approval was at the direct expense of a fellow EC member as well as the Java community at large.

Yesterday's vote is the final straw in an issue which has been ongoing since August 2006 and as described in our Open Letter dated April 10, 2007. The withholding of an acceptable, FOU-free TCK by Sun, and now Oracle, is against both the spirit and the letter of the JSPA.

What is not new is that Oracle continues to violate and not honor the JSPA agreements, which are a foundation of the JCP. What is new is that the EC, by fact of their vote, has allowed them to do it. It is obvious that the JCP is not a standards forum, nor a community process at all, but rather a cabal to control the Java ecosystem. The ASF can no longer justify its continued involvement within this entity.

As such, the ASF is removing all official representatives from any and all JSRs. In addition, we will refuse any renewal of our JCP membership and, of course, our EC position.

The ASF is saddened to have to make this move, but we feel that the JCP is completely broken and makes a mockery of the term "community," a concept which has great value to Apache.

Of course, we had hoped that our previous blog post would have spun up more support, but being the pragmatists that we are, we also knew that the other EC members were being seriously pressured by Oracle to vote YES, and so we held out little hope. We also hoped for a better response from Oracle, but what we got was basically self-serving lip-service with what is most likely the funniest and yet most inaccurate line yet in the whole ordeal:

"Oracle provides TCK licenses under fair, reasonable, and non-discriminatory terms consistent with its obligations under the JSPA."

If that little nugget doesn't show that Accuracy and Oracle don't mix, I don't know what will. The JSPA says, in 5.C.III, that a spec lead can't:

"impose any contractual condition or covenant that would limit or restrict the right of any licensee to create or distribute such Independent Implementations"

and, of course, the FOU restriction does exactly that. And as far as "non-discriminatory", well, Oracle has deemed that OpenJDK (*their* distribution) not have any FOU restrictions on the TCK, but that the ASF's (Harmony) will. And that isn't discrimination?

And so, the JCP is dead... All that remains is a zombie, walking the streets of the Java ecosystem, looking for brains...

But maybe, from this death, a new, true community process might arise somewhere, with a different collection of people, one with no entity "more equal than others". That is something I think the ASF would be quite interested in seeing.

Upset, angry and totally disappointed

Saturday, November 6. 2010
I feel the need, for many reasons, to post about what happened to Noirin. I doubt if I will be able to draft something as honest and "on the mark" as what Paul wrote, but I'll try.

First of all, I, like Paul and a few others, were at the bar in question but had no idea what happened. We did seem to all rush out quickly, but I just figured that, well, it was getting late. It is fortunate that I had not been aware of what had happened because, quite honestly, I don't think I could have held myself back.

I know Noirin. In addition to us being both members and directors of the ASF, we are also friends. Noirin is one of those rare persons who have an honest and deep love of life. She enjoys life, she enjoys her friends, she enjoys work. Even when down or depressed, Noirin is still one of the most vivacious people I know.

To have someone take advantage of that, to "mistake" her friendliness as anything more than that, and to act in such a baseless way is appalling. Why don't some guys get that? Are some male of the species so clueless that they really think that any sort of friendly interaction is an offer or invitation for something else? And why do some scum, when something like this happens, blame the girl?

Noirin has every right in the world to be happy, to be free and to feel safe. Something like this happening affects all 3. My greatest fear is that events like this would cause such a light in this world as Noirin to "dim" herself, to shy away, to fade into the background, because of incredibly wrong and poor decisions by people.

And we would all be the worse for it.

Language diversity

Tuesday, September 21. 2010
If you look at the projects within the ASF, you'll notice right off the bat that the vast majority are Java. We do have a handful of other projects based on other languages but, for better or worse, most of 'em are Java.

But if you look at the code that powers the ASF you'll notice a big difference. For one thing, for the most part, we do not run anything that requires a JVM (well, we prefer not to). Also, we prefer all of our sites be as static as possible, which makes mirroring them easier. But the biggest surprise might be just how much we use scripting languages for all the tasks/applications/tools that we need. We use a suite of Perl, Python and Ruby, with Perl being the clear frontrunner (mostly since JoeS is such a Perl monger).

What I think is so useful about all this is that it gives a true, clear perspective on how real infrastructure is architectured (my word). People tend to focus, unjustly, on the applications themselves, and give little thought or credence on the infra required to truly support and implement all that. And this skewed perspective can easily result in bad, dangerous mistakes when making the transition from one architectural design to another, because it ignores a big, big part of the puzzle.

As people look at, investigate and migrate into the cloud, this will become even more of an issue. And a concern.

Apache HTTP Server 2.3.8-alpha

Tuesday, August 31. 2010
Today, I (as Release Manager for the project) released the latest, and what is expected to be the last, alpha version of the NextGen release of Apache httpd.

This is pretty exciting news because for now on we'll be focusing on pushing out beta releases in anticipation of a quick trip to 2.4.0-GA.

Certainly, Apache httpd 2.4.0 has been a long time coming, but it will be well worth the wait. The new features, especially related to MPMS, Authn/Authz and the Proxy module, will continue to be the reference standards for web servers. I'm really excited by all the mod_proxy improvements because that's an area which I, and others, have been giving special attention to. You combine that with the various async changes, the Event and (for the time-being still experimental) Simple MPMs and you have a killer server.

So download and try it out and give us your feedback.


So what's next...

Wednesday, August 25. 2010
Yes, the rumors are true. As anyone who follows me on twitter knows following my tweet, I will be leaving VMware.

The experience has been incredible, and being with VMware was the end of a journey started about 10 years ago when I first joined Covalent. Following some "interesting" events within that company, Covalent emerged as a premier FOSS-related business and as CTO I was able to continue working with Mark and Ryan to grow the company. We were so successful that SpringSource took notice of our products, or business plan and our customer base and decided they wanted in, and so they bought the company. At SpringSource I was, in addition to other tasks, the tech lead and developer for a project that became one of the most significant (if not the most significant) products for the company. And after around 2 years, SpringSource was so successful that VMware took notice and bought us.

Now after a year, it is time to move on.

I'm ready for new challenges and new opportunities. I'm looking for a place that can benefit from my talents, experience and expertise as much as Covalent/SpringSource/VMware has.

I'm ready to make a difference and an impact... Know of any places that might be interested? Let me know.


ASF Voting System Rocks

Wednesday, July 14. 2010
The ASF uses an ssh-based voting tool, mostly developed by Roy, to handle the new member and new director voting process. New members are elected in using a simple yes/no/abstain whereas directors are voted in using the STV system. The tool is great, but it had the requirement of actually having to ssh into a specific machine to cast your votes.

Well, after some discussions on the members mailing list, our illustrious SysAdmin Joe (with some patches from others) created this exceptional GUI front-end for the tool, which makes casting votes even easier. Hopefully, with this front-end, the voter tool will be used for a bunch of other things...

As far as setting up the voter tool, well, I just use a bunch of scripts I hacked together years ago... Not fully automated, but good enough.

Side project Telaen

Wednesday, May 19. 2010
In addition to the stuff I do for $WORK and the ASF, there are also some coding side-projects that I like spending some time (and my limited talents) on. One of these is a PHP-based webmail system called Telaen. It started off when I wanted a nice webmail system to use with jaguNET and found Uebimiau. But the code in Uebimiau was a mess and seemed to be abandon-ware, so I hacked away at it and provided the so-called jimjag patches which many users found useful. After awhile though, it just seemed better to fork it and so a few of us created Telaen.

Anyway, as it always is when you do stuff on the side, Real Life has this nasty habit of intervening, causing development on Telaen to slow down. Well, I've since rebooted the project (who needs sleep??) and have a beta of the latest version (Telaen 1.3.0) available... Check it out.