Feeds

When open source is not enough

The case for open development

Boost IT visibility and business value

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. ®

Boost IT visibility and business value

More from The Register

next story
NO MORE ALL CAPS and other pleasures of Visual Studio 14
Unpicking a packed preview that breaks down ASP.NET
KDE releases ice-cream coloured Plasma 5 just in time for summer
Melty but refreshing - popular rival to Mint's Cinnamon's still a work in progress
Leaked Windows Phone 8.1 Update specs tease details of Nokia's next mobes
New screen sizes, dual SIMs, voice over LTE, and more
Put down that Oracle database patch: It could cost $23,000 per CPU
On-by-default INMEMORY tech a boon for developers ... as long as they can afford it
Secure microkernel that uses maths to be 'bug free' goes open source
Hacker-repelling, drone-protecting code will soon be yours to tweak as you see fit
Mozilla keeps its Beard, hopes anti-gay marriage troubles are now over
Plenty on new CEO's todo list – starting with Firefox's slipping grasp
Apple: We'll unleash OS X Yosemite beta on the MASSES on 24 July
Starting today, regular fanbois will be guinea pigs, it tells Reg
prev story

Whitepapers

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.
Consolidation: The Foundation for IT Business Transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.
Backing up Big Data
Solving backup challenges and “protect everything from everywhere,” as we move into the era of big data management and the adoption of BYOD.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Why and how to choose the right cloud vendor
The benefits of cloud-based storage in your processes. Eliminate onsite, disk-based backup and archiving in favor of cloud-based data protection.