In defense of Apache

Apache is great for many things, not so for others. Its proponents misunderstand its weaknesses, and its detractors misunderstand its strengths

Page 2 of 4

Apache works, mostly

Much of the time the Apache system works. You have interested people who start a project, get some code working, then propose it to Apache. One of these meritorious members shepherds it into the organization and helps build a community of developers. The "committers" on the project do their own stunts -- the bulk of the marketing and evangelizing.

The Apache name carries a lot of weight and is helpful. There was a brief time when another project had temporarily surpassed POI in capabilities on Excel. This could have been fatal. While POI's scope was broader and included Word and other file formats -- arguably why we fell behind -- Excel was always the most important. The Apache name kept us afloat until we surpassed the other project. It is mostly dead now, and POI continues to be the default in reading/writing Office files from Java.

If you don't care about making a profit and want to attract contributors and users, Apache can be helpful. But Apache is also a big weight on any project. The Apache system for making decisions takes a lot of time, and it encourages the kinds of fights that probably don't need to happen. Projects need leaders, but Apache robs leaders of the semiautocratic power sometimes helpful to keep projects on track. Instead, the leader must become more of a community organizer. Some software developers are good at becoming community organizers, but most ... not so much.

This is not to say that any open source project leader, even outside Apache, can truly be autocratic. Open source allows people to "vote with their feet" -- to leave a project and start their own. Apache's system doesn't make it any less likely they will do so; it just makes it harder for leaders to herd cats.

Board action tends to fail to produce community

The worst Apache projects are those where the board takes action, often in private, and simply announces its decision, sometimes embargoing members from talking about it. Generally these projects were donated by a single company, consisting mainly of that company's developers and possibly allies or business partners. These projects tend to eventually fail.

There are successes as well. Generally, where IBM or others have used Apache to establish a standard, these projects have succeeded. Ironically, I don't think they've usually been successful from a "community" standpoint, but at establishing a standard. You can see successes in the myriad XML and Web services libraries.

The clearest example of failure is Apache Harmony. When IBM pulled out, the project folded. There are earlier examples. Apache Beehive was entirely a BEA project. It really ended up being not much more than a dump and run. Geronimo, for example, was reportedly taken directly under board control because of its lack of diversity. Geronimo also has a declining number of releases per year, and if you look at the LinkedIn profiles of people, you'll realize it is directly based on employment at IBM.

| 1 2 3 4 Page 2
From CIO: 8 Free Online Courses to Grow Your Tech Skills
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies