Skip to content


Why Open Source Companies Need to Give Up Control

October 20, 2009

Posted by: Glyn Moody


I've always regarded the passionate discussions that take place within the free software world as a sign of health: it indicates people care, and that they are thinking hard about the issues.

Against that background, a sudden efflorescence of posts about open source companies – what that means, how they work, and their future – is something that I've observed with a certain satisfaction. But sitting and watching isn't really my kind of thing, so I feel it's time for me to wade in with a few thoughts of my own.

In one sense, this discussion is a continuation of the long-running argument about the larger relationship between free software and open source.

But there are also aspects that are unique to the business world – not least because money is involved. For example, here's a post that suggests “the romantic open source narrative is failing”, and the “open source community” is “selling out”:

Big software vendors and VCs throwing money around is not particularly interesting – that’s just the nature of the beast. But the fact that there are so many members of the “open source community” ready to sell out – now that’s interesting.

Well, actually, it’s interesting only to the extent you still believe the romantic narrative that commonly circulates around Open Source. That story involves bands of fiercely independent geek-heroes. Armed only with an Eclipse IDE, a weekend’s supply of Jolt Cola for energy and a poster of Jean-Luc Picard for inspiration, they set out to usurp the big software companies in their attempt to control the software universe.

Who would have thought such esprit de corps would be so easily bought. Not cheaply…just easily.

So, are members of the open source community selling out? I don't think so: it's the people who set up open source companies who are taking the money – and that's hardly surprising, since money was presumably one of the main reasons why they entered business in the first place. Open source was a means to that end, and if someone is prepared to offer them plenty of money to sell, there's no reason they should refuse.

The open source *community*, by contrast, is not in it for the money, but the software – that's how it's defined: by its interest and involvement in a piece of code. When that code is sold, the community gains nothing, and might even suffer if the new owner is buying an open software project for the wrong reasons – to remove a threat to its own closed-source offerings, for example.

That fact underlines the community's subservient nature in these cases: it doesn't really have any say in whether the code is sold, for example. And the reason for that is simple: open source companies generally own the copyright to all the code. Indeed, one of the distinguishing characteristics of businesses based around open source code is that they typically demand outside contributors to assign copyright to them.

As well as giving them overall control of the project, owning the copyright also allows them to sell the code under commercial, non-open licences – something only the copyright holder can do if the free licence is the GNU GPL, as is generally the case.

This introduces an asymmetry into the collaborative development process: although the copyright owner can take external contributions and offer them under a commercial licence, it is not possible for anyone else to do the same.

That's handy for open source companies, but breaks the underlying contract of mutual benefit with companies and people that contribute code. And without the reciprocity, I think the urge to contribute is bound to diminish, because there is likely to be an underlying feeling that external contributors are being unfairly exploited – not least when a company decides to “sell out”.

If this analysis is correct, open source companies will find it harder to encourage external contributions to their products. Indeed, I often get the impression when talking to open source companies that already most of the coding is done in-house, with only minor, relatively inconsequential input from outsiders.

There's nothing wrong with that, and some companies may be happy with that model. But it throws away many of the advantages of open source over closed source approaches, notably in terms of people finding and reporting bugs and maybe even fixing them. More seriously, perhaps, it also diminishes the role of the community, something whose importance and power is increasingly recognised (hello, Facebook.)

Jump to page : [ 1 ] [ 2 ]

Follow highlights from ComputerworldUK on Twitter
Sign up for our Daily Newsletter
The UK IT News widget Get it for your site!

<<newer entry | back to blogs indexolder entry>>

Advert

close

Email this article to a friend or colleague:




PLEASE NOTE: Your name is used only to let the recipient know who sent the story, and in case of transmission error. Both your name and the recipient's name and address will not be used for any other purpose.

close
  • This article is now being printed.
close

What are your views on this subject? Use the form below to post a comment on this article up to 1000 characters.


Characters remaining:

close

Click below to add 'Why Open Source Companies Need to Give Up Control' to your blog.



If you do not have a ComputerworldUK Account and would like to use this feature, please Register.

If you are a registered, logged-in user, this will post the title and first paragraph of this story to your blog to share with your readers.

What is this?

Comments received

Ian Skerrett said on Tuesday, 20 October 2009

Glyn,

Not surprising I agree with the conclusion that Foundations provide a vendor-neutral environment that allows a community to thrive in the long-term. I think Eclipse, Apache and even Linux are great examples.

However, I'd like point out that the contributors to Eclipse project do not assign copyright to the Foundation. They actually keep copyright ownership but it is the diversity of the contributions that create a shared commons.

Another important thing to consider is the ownership of trademarks that identify a project, ex MySQL, Linux, Eclipse, JBoss. The Eclipse project names are trademarks of the Eclipse Foundation, so although an organizaiton retains copyright of their code the 'brand' is a community shared asset.

Glyn Moody said on Tuesday, 20 October 2009

@Ian: thanks for those. Another major difference, of course, is that you don't use the GNU GPL...

I'm not trying to be prescriptive here, just pointing out some successful models.

And yes, trademarks are yet another can of worms that has to be addressed...

William Chambers said on Sunday, 17 January 2010

You...totally missed the entire point of the GPL. It's a licence. Just because someone else can use it for commercial purposes, doesn't defeat the point of the license, nor does it mean it's no longer open-source. The program can still survive just fine without the ability to go commercial and so forth.

Before you write another article, do some research.

Advert

WHITE PAPERS

  • Legal risks: Employee use of the internet and email
    Exploring the challenges facing IT Mangers today and vital steps to ensure safe internet an email use by employees.
  • Phishing for victims
    This White Paper examines the phenomenon of phishing. It explains the potentially catastrophic threat it presents to all kinds of organisation. Exploding some widespread myths, it lights up the murky waters where phishing first emerged and where it continues to evolve. But it also highlights what your business can do to blunt the threat.
  • Challenges and opportunities of PCI
    The control framework implicit in the Payment Card Industry Data Security Standard (PCI DSS) provides an enterprise structure for improving operational, security, and audit performance.
  • Social CRM comes of age
    Who is this “social customer”? What strategies and tools does the new breed of CRM provide to do something about this?
  • Risk Management: Protect and Maximize Stakeholder Value
    What has held organisations back from a broader adoption of risk management programs?
*