Feeds

When open source is not enough

The case for open development

Internet Security Threat Report 2014

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

Choosing a cloud hosting partner with confidence

More from The Register

next story
Be real, Apple: In-app goodie grab games AREN'T FREE – EU
Cupertino stands down after Euro legal threats
Download alert: Nearly ALL top 100 Android, iOS paid apps hacked
Attack of the Clones? Yeah, but much, much scarier – report
Microsoft: Your Linux Docker containers are now OURS to command
New tool lets admins wrangle Linux apps from Windows
Bada-Bing! Mozilla flips Firefox to YAHOO! for search
Microsoft system will be the default for browser in US until 2020
Facebook, working on Facebook at Work, works on Facebook. At Work
You don't want your cat or drunk pics at the office
Soz, web devs: Google snatches its Wallet off the table
Killing off web service in 3 months... but app-happy bonkers are fine
prev story

Whitepapers

Choosing cloud Backup services
Demystify how you can address your data protection needs in your small- to medium-sized business and select the best online backup service to meet your needs.
A strategic approach to identity relationship management
ForgeRock commissioned Forrester to evaluate companies’ IAM practices and requirements when it comes to customer-facing scenarios versus employee-facing ones.
10 threats to successful enterprise endpoint backup
10 threats to a successful backup including issues with BYOD, slow backups and ineffective security.
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.
Getting ahead of the compliance curve
Learn about new services that make it easy to discover and manage certificates across the enterprise and how to get ahead of the compliance curve.