You Won’t Get Fired for Using Apache

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Git, Svn and CVS Usage on Debian

In March of 2010, I sat on a panel with Justin Erenkrantz (Apache), Mårten Mickos (Eucalyptus), and Jason van Zyl (Maven/Sonatype) at the Eclipse Conference debating the future of open source [coverage]. The audience asked questions on licensing, development models and the direction of open source generally. One of the questions concerned the role of foundations like Eclipse, and whether they represented the future or if that would be written instead by commercial producers of open source.

My answer to that question was simple: neither. GitHub, instead, is the shape of things to come.

Mikeal Rogers came to a similar conclusion in Apache Considered Harmful. His arguments copncerning the importance of GitHub are compelling, as the evidence in favor of decentralized version control generally and Git/GitHub specifically is overwhelming. Quantitatively, virtually all of the metrics available to us reflect trajectories similar to those reflecting the relative popularity amongst Debian installations depicted above. As Chris Aniszczyk documents, legacy centralized tools reflect volume usage but Git’s massive growth has it poised to eclipse them. Git based services, meanwhile, are both profiting from and fueling said growth; an analysis of first half commit data for four major forges collected by Black Duck indicates that GitHub has in three years become the most popular open source repository.

Qualititatively, the benefits to decentralized development have been apparent to us since at least 2007. What GitHub calls “social coding” is the ability of decentralized version control tools like Git or Mercurial to inject collaborative development into a previously individual practice. The byproduct of which is the parellelization of development; like bacteria, GitHub developers may now evolve by swapping material directly to and from one another as required coverage. Which means, in turn, that forking is no longer a bad word but the way development should be done.

In the face of GitHub’s ascendance, the implications for open source foundations are unclear. In Apache Considered Harmful, Rogers’ argues that Apache specifically has essentially outlived its usefulness.

The problem here is less about git and more about the chasm between Apache and the new culture of open source. There is a growing community of young new open source developers that Apache continues to distance itself from and as the ASF plants itself firmly in this position the growing community drifts farther away.

But while I also subscribe to Clay Shirky’s maxim that “Institutions will try to preserve the problem to which they are the solution,” it is far from clear that it applies in this case. For disclosure purposes, I’ll note here that we count both GitHub and open source foundations like Apache and Eclipse as clients.

The argument that foundations have become vestigial in a post-GitHub world necessarily focuses on functional overlaps. Historically, project hosting has been one of the services offered by foundations. The data suggests that foundations who reject decentralized version control systems will fall behind, which is why structures like Eclipse are implementing Git. Even assuming a given foundation is able to transition from centralized to decentralized mechanisms, however, there is no guarantee that this will be sufficient. Iit’s unrealistic expect any foundation to compete with GitHub on functionality or community size, given the respective areas of focus.

The value of foundations, however, has never been principally hosting. They are, rather, the manifestation of a particular mission. The Free Software Foundation, the Apache Software Foundation, the Eclipse Foundation: all serve as the focal point for a group of developers. It is possible that their respective purposes have been fulfilled by GitHub, but the surging code repository seems likely to make foundations more relevant, rather than less.

As Rogers states:

Apache was founded about 12 years ago, a time when companies were still very afraid of open source and many people in the open source community were very afraid of companies. The world hasn’t changed that tremendously, big companies still use an open source stamp as a marketing tool, commonly referred to as “open washing”, and some in the enterprise are still wary about open source, particularly when it comes to certain kinds of licensing.

But, you would be hard pressed to find a single company that didn’t use some amount of open source software nowadays.

The obvious implication is that as acceptance of mainstream open source increases the importance and relevance of Apache’s mission decreases. I believe this to be incorrect. Aside from the many important non-infrastructure services offered by foundations – including IP management, project governance, legal counsel, event planning, and predictable release schedules – foundations have value as brands.

As the volume of open source assets grows, the paradox of choice presents itself to users. This problem in part already sustains a sizable marketplace of commercial products from vendors such as Black Duck, Open Logic, Palamida, and Sonatype. With GitHub and similar tools reducing the friction associated with development, we are likely to see selection problems get worse rather than better; as the volume of open source rises, fueled in part by GitHub’s success, so too does the difficulty of making a choice.

Which is one reason foundations are important. Much as McKinsey advantages Baker and Rhodes scholars in their hiring process, certain audiences will prefer to leverage open source software associated with a known brand such as Apache or Eclipse.

We have long argued that developers are the new kingmakers. As developers begin to make more choices within the enterprises they populate, they will inevitably face the same dilemma that their management predecessors did, which is the burden of choice. GitHub is a center of gravity with respect to development, but it is by design intensely non-prescriptive and inclusive, and thus home to projects of varying degrees of quality, maturity and seriousness. Consider the following:

GitHub, Inc. (“GitHub”) supports the protection of intellectual property and asks the users of the website GitHub.com to do the same. It is the policy of GitHub to respond to all notices of alleged copyright infringement.

Notice is specifically given that GitHub is not responsible for the content on other websites that any user may find or access when using GitHub.com.

GitHub, in other words, disavows responsibility for the projects hosted on the site. Foundations, conversely, explicitly assume it, hence their typically strict IP policies. These exclusive models offer a filter to volume inclusive models such as GitHub’s.

If your continued employment depends not just on the quality of the software you employ, then, but perceptions of the quality of the software you employ, the halo effect offered by foundations that actively triage their assets is likely to be of benefit. For better or for worse. If you’re choosing between one project of indeterminate pedigree hosted at GitHub and an equivalent maintained by a foundation like Apache, the brand is likely to be a feature. Managers used to say “you won’t get fired for buying IBM.” The developers making the decisions in the future may well have their own version: “you won’t get fired for using Apache.”

Rogers appears to have legitimate concerns concerning Apache’s acceptance of Git, and I concur that it’s a GitHub world and we’re all living in it. But I find it difficult to build the case that foundations more broadly won’t have a role to play in it.


  1. More and more, the “Apache brand” is one that serves as a warning label for me, not a safe harbor.  Quality runs the gamut across Apache-managed projects, from the sublime to the shoddy.  Insofar as Apache seems to be the dumping ground for all sorts of projects (how many web frameworks need to be under its umbrella? Which bits has Adobe sloughed off to Apache this week?), any connotations of quality that may have applied in the past is fundamentally behind us IMO.

    The old saying about CA, “where software goes to die”, could be applied to Apache in many instances…”where open source software goes to die”.

  2. @sogrady, I think it’s the perception of IP cleanliness, not quality that’s important. While many individual developers are comfortable easily sharing software using FOSS licenses as social contracts, most corporate organizations live in a [rightly] more conservative legal climate and need the assurances of a well documented and understood IP process before they will assume the risk of use and participation. 

  3. […] You Won’t Get Fired for Using Apache In March of 2010, I sat on a panel with Justin Erenkrantz (Apache), Mårten Mickos (Eucalyptus), and Jason van Zyl (Maven/Sonatype) at the Eclipse Conference debating the future of open source [coverage]. The audience asked questions on licensing, development models and the direction of open source generally. One of the questions concerned the role of foundations like Eclipse, and whether they represented the future or if that would be written instead by commercial producers of open source. […]

  4. Okay.  I said a whole lot more about this in a discussion on the foundations email list, and then turned it into a blog post: http://www.networkworld.com/community/blog/role-foss-foundations

  5. […] the Git era prompted significant discussion, from Mike Milinkovich, Bradley M. Kuhn, Stephen Walli, Stephen O’Grady, and the ASF’s Jim […]

  6. It’s a truism to describe git as decentralized, but I think that’s too simple. I suspect that most organizations use git in a way that is pretty centralized, and it seems that github tends to facilitate this usage pattern, even if the github service is technically agnostic on this question…

    As an aside the git project itself is a member of the Software Freedom Conservancy, which provides a function much like the Apache Foundation to a collection of projects.

  7. […] used the GPL), and “no one ever gets fired for using Apache,” as Redmonk analyst Stephen O’Grady opined. Apache was the safe […]

  8. Great post. To me, it sounds remarkably parallel to Communism. The idea works until a specific group takes charge and decides it knows what is best for the people, which inevitably leads to self-serving decisions. However while I agree that forking is healthy, I also believe it is anathema to standardization. So to achieve standardization and avoid the exact problems you talk about with Android (http://redmonk.com/sogrady/2011/11/02/android-concerns/), I believe some type of governance is needed. I wonder if the model will eventually migrate to a democratic model (one where developers vote in a governing body).

  9. […] used the GPL), and “no one ever gets fired for using Apache,” as Redmonk analyst Stephen O’Grady opined. Apache was the safe […]

  10. Apache has a Maven plugin called RAT. It’s one purpose is to detect files without an Apache license and to fail the build if any are detected. Apache has a review board, where patches’ ownership is supposed to be handed over to Apache.

    It used to be that this kind of institutional ownership was used to try to make corporations feel more comfortable about using open source software, that the Apache pennon indicated certainty & confidence and that businesses craved this.

    This has changed, the need for this reassurance. The decentralized model indeed sprung up from that weakening, but what prompted that attitude change?

    I’d put forth four items,

    For one, open source is everywhere and we no longer regard it as alien. I’d wager 98% of people who have written code at least three times in their life have used some kind of open source code or development tool, and that 98% of software companies have at least one open source component they rely on directly or indirectly. Organizations have to opt out of open-source, and that’s much harder to do than it used to be.

    The FUD (fear uncertainty and doubt) has somewhat cleared. The biggest danger seems to using software that’s not ready yet, and the possibility that it gets abandoned, all of which can be guarded against by downloading the source and fixing it yourself. What the past decade and a half havent shown is security risks and lawsuits for picking up OSS (unless you happen to make phones.)

    Three, the programmers run the show. Not only is open source just a part of making software, but there are less business managers telling programmers how to code and what tools they need to use to do it. There are a lot more libraries than there were a decade ago, and the businesses have gotten further removed from deciding how to pick.

    Four, everyone feel like IP is a primeval jungle out there, one where full and new moons have frenzied lawyers gripping knives between their teeth running through the jungle attacking at random. It’s all arbitrary, so why bother fretting over the face that there is no LICENSE file for the github code you’re staring at: of all the threads, joe and his weekend project are probably not gonna be the ones bringing out the elite IP attack squad to make that jungle a nightmare for you.

    Decentralized seems somewhat synonymous with zero friction do-what-thou-wilt practice. It’s the realization of this liberty that makes brands important, to provide guidance across an increasingly expanding and potentiated space. That’s not just so you the programmer don’t get fired, that’s so you the programmer don’t have to expend a sizable fraction of your life constantly evaluating the ever changing technical ecosystem: the brand will percolate ideas up to you.

    Little last word on this, if Apache does want to maintain a presence as a reliable base for developers, quite a few Apache project wikis need a lot more authoritative and prescriptive content on building and running Apache powered systems. Apache has more commercial contributions than it used to and the danger is Apache allowing commercial entities to sell Apache-ified code while keeping the project structure and support out of Apache. Apache the brand needs a lot more than just code to serve needy app developers.

Leave a Reply

Your email address will not be published. Required fields are marked *