Feeds

When open source is not enough

The case for open development

The essential guide to IT transformation

There was some interesting buzz about the state of open source going around ApacheCon in Dublin.

On one hand, Apache is - and is widely seen as - a moderate, pragmatic voice in the FOSS world: the Apache license is explicitly business-friendly, and the conference was very happy to welcome the arch-enemy of more dogmatic FOSS advocates, Microsoft, among us.

Yet on the other hand, there are voices within Apache saying that open source is not enough, and that we should promote open development.

And from the advocacy/PR gurus comes the suggestion that we currently have an open source bubble, some of which may burst in a couple of years when companies who have adopted OS without an adequate strategy come unstuck. Failing to plan is planning to fail!

Does that mean people cannot agree? Of course, there's always a debate going on, but Apache does not and will not focus so singlemindedly on Freedom as the FSF.

The Apache philosophy is that it's in everyone's interests for projects to be successful, and that that depends on far more than freedom alone. If we are to move software away from the constant reinvention of the same wheels in thousands of jealously-guarded ghettos, and towards a meaningful software commons, then open source is necessary but not sufficient!

Consider for a moment a company with a software product. We can assume a familiar cast of characters, starting with a pointy-haired boss:

Manager: Hmm, our product is going nowhere. If we open source it, maybe we can generate interest and start getting consultancy work. And some good PR for free!

Yep. The PHB has heard and half-understood the open source message, as many are now doing. He might make it work, but that's by no means a foregone conclusion. Open sourcing the product might be the core of a great strategy, but it's no more a magic bullet for our PHB than for any spotty youth hacking away in a bedroom. Some companies in this scenario are going to get disillusioned, and may make a scapegoat of open source.

Anyway, what do our PHB's colleagues think? Let's posit an engineer with a personal stake in the project, and who is not quite as devious as El Reg's BOFH:

Engineer: Great! I'll need a public-facing web and svn server and mailinglist, and quite a lot of man hours to be budgeted. When can I announce it in my favourite public forum?

Yea! There's the enthusiasm that is one vital ingredient of a successful open source project. It's something to build on.

Engineer: Yeah, fine. Just leave me out of it, OK.

Not so good. But not necessarily a dead loss, until the engineer is seen reading the jobs pages with grim determination. On the one hand, if your own engineers, who presumably know the product better than anyone else, aren't motivated, why should anyone else be? You're going to have a hard job building a community.

On the other hand, if the engineer didn't turn pale with horror at the prospect of his work being seen by his peers, then there may be something to work with. There are many, many software products out there whose developers would simply be too embarrassed at the prospect of their work being exposed to public scrutiny. If open sourcing it is to work, there has to be something people want and can work with.

Engineer: [stunned silence; turns pale green]

Maybe it's time to abandon inhouse software development?

Of course, in UK PLC the engineer is more likely to be told what to do only after the important decisions have been taken. The lawyer, on the other hand, may have a veto on it. The lawyer will rightly insist that applicable third-party rights are protected, non-disclosure agreements honoured, etc. A lazy lawyer might take a SCO-inspired view that all code is infected just because something was licensed on commercially confidential terms. Does that leave a viable project?

The Apache Way

Apache has come a long way since it was just about the web server. It is now the Apache Software Foundation, and has about 200 members, with a far greater number of contributors ranging from committers (people entrusted with write access to some part of the code), down to casual users who provide occasional feedback.

Apache is responsible for about 30 self-governing "top-level" projects which, at a technical level, may have nothing in common. Some have grown from scratch as open source, while others are former commercial products that have been donated and opened up. What they have in common is a way of working, sometimes known as "The Apache Way", and a thriving community.

The Incubator

Many Apache projects started life as commercial, closed source projects, whose developers saw the value of open source and the Apache brand. In fact, the ASF not only gets offers of code donations, it turns many of them down, when they are not considered suitable. No project is just accepted unconditionally: instead, any donation first goes into the incubator, where it is mentored into the Apache Way.

Only when it is clear that there is indeed a thriving community, one that is free of cliques and welcoming to outsiders, does it become eligible to graduate to a full project, and use the Apache name. By this time, the community has grown beyond the original donor, who can reasonably expect to be influential but not dominant.

Because the incubator receives donations, it also gets exposed to proposals that have no realistic expectation of successful incubation. Moribund projects which no one is really interested in, whose owners are looking for a magic bullet. Half-baked or even vapourware project ideas looking for free help. And projects that could be realistic candidates, but whose owners aren't prepared to relinquish control.

So, what is the state of open source? It's dominant on the server, a small but rising force on the desktop, and a major player in the fastest-growing area of embedded devices. It's also caught the corporate imagination and started to spark expectations, not all of which are realistic. This last is where the danger lies: where expectations are not fulfilled, there will be a backlash!

The quack's verdict: healthy, but at risk of overindulgence. Your scribe admits a similar condition as he sips his wine and regards his paunch. ®

Secure remote control for conventional and virtual desktops

More from The Register

next story
Munich considers dumping Linux for ... GULP ... Windows!
Give a penguinista a hug, the Outlook's not good for open source's poster child
The Return of BSOD: Does ANYONE trust Microsoft patches?
Sysadmins, you're either fighting fires or seen as incompetents now
Microsoft cries UNINSTALL in the wake of Blue Screens of Death™
Cache crash causes contained choloric calamity
Time to move away from Windows 7 ... whoa, whoa, who said anything about Windows 8?
Start migrating now to avoid another XPocalypse – Gartner
You'll find Yoda at the back of every IT conference
The piss always taking is he. Bastard the.
HANA has SAP cuddling up to 'smaller partners'
Wanted: algorithm wranglers, not systems giants
prev story

Whitepapers

Endpoint data privacy in the cloud is easier than you think
Innovations in encryption and storage resolve issues of data privacy and key requirements for companies to look for in a solution.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Top 8 considerations to enable and simplify mobility
In this whitepaper learn how to successfully add mobile capabilities simply and cost effectively.
Solving today's distributed Big Data backup challenges
Enable IT efficiency and allow a firm to access and reuse corporate information for competitive advantage, ultimately changing business outcomes.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.