Feeds

Events, dear boy... a view from Apache

Who better to comment on open source quality issues?

Combat fraud and increase customer satisfaction

Comment After last month's somewhat lightweight piece, I had in mind a solid programmer article for March. But like Harold Macmillan, I'm not just going to ignore events. So here instead is something topical.

Open source advocates have been getting very worked up about an article in The Economist entitled Open source business. Open, but not as usual. The journalist is, as usual, wrong, misinformed, spreading FUD. Sigh. Dear Editor, ...

Do the slashdotters and groklawyers have a point? Yes, certainly. But do they make it? Not really: it's quite hard to find the valid criticisms amid the noise. And who do they speak for? A proportion (probably rather small) of the open source community (whatever that is). And, not least, am I misrepresenting them? Guilty: of course I'm generalising!

Much of the criticism focuses on some "conventional wisdom" about open source: it's chaotic, uncontrolled, unaccountable. Another point that attracted fury was the apparent credibility given to the SCO lawsuits (why do articles like this never mention, for example, Timeline's successful multi-million lawsuits against Windows end-users)? But these criticisms are, in my view, misplaced: in fact the article proceeds to explain why this conventional wisdom isn't true of the significant open source projects such as Apache. Some genuine - and indeed fundamental - factual errors such as equating open source with the GPL have largely been missed, and are in any case peripheral to the article. This is certainly an advance on the days when an article in the mainstream press could be expected to confuse Free Software with the crap on a typical magazine cover disc.

In my view, a stronger criticism is the characterisation of Wikipedia's troubles as a failure of open source. It cannot be that, because it's not an open source project in the first place (open contents?). Alas, it's hard to give the article benefit of any doubt there. But then again, the article's very thesis is that concepts originating with open source software are being adopted in other fields of human activity. Wikipedia is indeed an example of the perils of inadequately thought through adoption of something that looks beguilingly like open source and Eric Raymond's "bazaar".

The Economist is usually well-informed, but at the level of the boardroom executive, not the backroom geek. The most interesting thing about the article is that it appeared at all: this is far more testament to the success of open source than any sound and fury from Microsoft and SCO, or from slashdot and groklaw.

So, how does Apache work in reality to ensure quality and accountability?

Well, any technology company will tell you its greatest asset is its people. Apache is no different, though the brand is worth something too! It has a major advantage over commercial companies: it's not scrabbling for vaguely-competent developers in a competitive marketplace. It's under no pressure to recruit, and it can afford to restrict itself to people with a proven track record of contributions. And its pool of prospective developers is worldwide, limited only when a developer - or his/her employer - is unwilling or unable to sign the relevant Contributor License Agreement (CLA), the document that guarantees Apache and its users the legal right to use the intellectual property in the developer's contributions.

So, Apache has the talent. How does it make best use of it?

Formally, the project is managed by the Project Management Committee (PMC), which reports to the ASF board. But although the PMC has a private mailing list and ultimate responsibility, all technical discussion happens openly and in public, with the possible exception of security issues. The primary resources are the subversion (formerly CVS) repository, and the developer mailinglist. Other important “fora” include the Bugzilla database, IRC chat, and the ApacheCon conference - the latter being the only time significant numbers of developers are likely to meet face-to-face.

The subversion repository is Apache's codebase, and encompasses all ASF projects - not just the webserver and associated APR library (which I, rather loosely, describe as "Apache"). The codebase comprises several parallel versions:

  • Trunk is the current development branch, containing all the latest developments. This is designated as Commit-Then-Review, so new ideas can get tested without bureaucracy and hassle.
  • Release branches (2.2, 2.0, 1.3) are designated stable, and are subject to much stricter rules. Any change to a stable branch must be reviewed and approved by at least three developers, and both source and binary back-compatibility is mandatory. This is coordinated through a file called STATUS in each branch, documenting proposed changes and developer comments. Normally patches to stable branches are tried in trunk first and backported.
  • Experimental branches may be created ad-hoc, to develop new ideas likely to cause significant disruption. A recent example is fully asynchronous client I/O. A successful experiment will be merged into trunk when it's stabilised.

A developer may also veto a proposed change. However, a veto must be accompanied by a detailed explanation and/or an alternative proposal. This then stimulates a discussion on the mailing list to resolve the issues. This works a good deal better than traditional management to impose checks and balances.

Apache's bugzilla database is also fully public and unmoderated, and can be chaotic. It combines real bugs, enhancement and feature requests with non-bugs entered by users, a few of whom refuse to let their pet 'bug' be closed. Some bugs may also be left permanently open to document features and provide patches, where some users may have specific needs that would not be appropriate to the standard Apache.

Intellectual Property is of course highly topical. Apache has robust measures in place to protect itself and its users from incorporating third-party IP, based on holding written consent from both individual and corporate contributors, and rejecting contributions where adequate guarantees are not available.

In summary, Apache's success is backed by strong organisation and effective processes. It is indeed disorganised in the sense that individual developers have much more freedom than in a commercial environment. That's nothing but good: a free developer is a motivated and productive developer, and peer review provides ample checks and balances - even leaving time for the tedious bits such as bugfixes! The bottom line - three times the market share of its nearest competitor. Next time you hear the argument that a market leader will be the product to suffer security exploits, just cite Apache's track record!

High performance access to file storage

More from The Register

next story
Android engineer: We DIDN'T copy Apple OR follow Samsung's orders
Veep testifies for Samsung during Apple patent trial
This time it's 'Personal': new Office 365 sub covers just two devices
Redmond also brings Office into Google's back yard
Batten down the hatches, Ubuntu 14.04 LTS due in TWO DAYS
Admins dab straining server brows in advance of Trusty Tahr's long-term support landing
Microsoft lobs pre-release Windows Phone 8.1 at devs who dare
App makers can load it before anyone else, but if they do they're stuck with it
Half of Twitter's 'active users' are SILENT STALKERS
Nearly 50% have NEVER tweeted a word
Internet-of-stuff startup dumps NoSQL for ... SQL?
NoSQL taste great at first but lacks proper nutrients, says startup cloud whiz
Windows 8.1, which you probably haven't upgraded to yet, ALREADY OBSOLETE
Pre-Update versions of new Windows version will no longer support patches
Microsoft TIER SMEAR changes app prices whether devs ask or not
Some go up, some go down, Redmond goes silent
Red Hat to ship RHEL 7 release candidate with a taste of container tech
Grab 'near-final' version of next Enterprise Linux next week
Ditch the sync, paddle in the Streem: Upstart offers syncless sharing
Upload, delete and carry on sharing afterwards?
prev story

Whitepapers

Designing a defence for mobile apps
In this whitepaper learn the various considerations for defending mobile applications; from the mobile application architecture itself to the myriad testing technologies needed to properly assess mobile applications risk.
3 Big data security analytics techniques
Applying these Big Data security analytics techniques can help you make your business safer by detecting attacks early, before significant damage is done.
Five 3D headsets to be won!
We were so impressed by the Durovis Dive headset we’ve asked the company to give some away to Reg readers.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Securing web applications made simple and scalable
In this whitepaper learn how automated security testing can provide a simple and scalable way to protect your web applications.