There are many different ways and reasons for companies to develop their software as open source. Here's some brief commentary on the main approaches you'll encounter in practice.
0. Closed source
Well, closed source is obviously not open, but I should mention it as not all software can or should be open. The main benefit of closed source software is that you can sell it. If you are working for profit, then you should only consider open sourcing your software if the benefits of doing so outweigh the lost license revenue.
1. Open releases
Also known as code drops. You develop the software internally, but you make your release available as open source to everyone who's interested. Allows you to play the "open source" card in marketing, and makes for a great loss leader for a "pro" or "enterprise" version with a higher price tag. And no changes are needed from more traditional closed source development processes. Unfortunately your users don't have much of an incentive to get involved in the development unless they decide to fork your codebase, which usually isn't what you'd want.
2. Open development
Making it easy for your users to get truly involved in your project requires changes in the way you approach development. You'll need to open up your source repositories, issue trackers and other tools, and make it easy for people to interact directly with your developers instead of going through levels support personnel. Do that, and you'll start receiving all sorts of contributions like bug reports, patches, new ideas, documentation, support, advocacy and sales leads for free. You can even allow trusted contributors to commit their changes directly to your codebase without losing control of the project.
3. Open community
Control, or the illusion of it, is a double-edged sword. If you're the "owner" the project, why should others invest heavily in developing or supporting "your" code? To avoid this inherent limitation and to unlock the full potential of the open source community, you'll need to let go of the idea of the project being yours. Instead you're just as much a user and a contributor to the project as everyone else, with no special privileges. The more you contribute, the more you get to influence the direction of the project. This is the secret sauce of most truly successful and sustainable open source projects, and it's also a key ingredient of the Apache Way.
So what's the right way?
There's no single best way to do open (or closed) source, and the right model for your project depends on many factors like your business strategy and environment. The right model can even vary between different codebases within the same company. For example in the "open core" model you increase the level of innovation in and adoption of your core technologies by open sourcing them (or using existing open source components), but you make money and maintain your competitive edge through closed source add-ons or full layers on top of the open core. This is the model we've been using quite successfully at Day (now a part of Adobe).
If you've decided to go open source and you don't have a strong need to maintain absolute control over your codebase (like I suppose Oracle now has over the OpenJDK!), I would recommend going all the way to the open community model. It can be a tough cultural change and often requires changes in your existing development processes and practices, but the payback can be huge. In military terms the community can act as a force multiplier not just for your developers, but also for the QA and support personnel and often even your sales and marketing teams!
If you're interested in pursuing the open community model as described above, the Apache Incubator is a great place to start!
Hey Jukka, great classification. I made a similar one a few weeks ago at the NASA Earth Science Data Systems Working Group meetings in New Orleans, LA. Here are the slides: http://bit.ly/cI0WwJ. In it I classify FOSS models as "Help Desk" based (i.e. your #2 above), versus "Open Community" (i.e. your #3 above). And yes, I agree with your point about there not being one "best" model in all situations.
ReplyDeleteNice categorization.
ReplyDeleteAdding to it:
0.5: Available Source.
When talking to vendors, I often ask "And I get the source with that?". Generally they look surprised, take a while to parse the question and then say "No". Some vendors however will give me the source and are happy to work with a world in which I might do some work myself instead of having to rely on their slow product cycle and/or uninspired consultancy.
1.0: Open releases.
Important to note here that there is still an issue tracker; but it's a one way bug reporting mechanism. It's probably harder to manage, and nobody knows when the item will be fixed or what the thought is on it.
---
My biggest concern in Open Source is that model #2 will prove to be the sweet spot for corporate development (possibly with some improvements). In fact....
2.5: Open development with invitation
Maintain control over the project, but invite specific individuals in. Obtain an NDA/contract and let them inside the ivory towers while keeping them independent and community oriented.
Hen, I couldn't agree more with your biggest concern. I've seen it even in Apache projects :(
ReplyDeleteGood points, thanks! The boundaries between these (and other) models are necessarily fuzzy as there are a lot of variables in how you can set up and run an open source project.
ReplyDeleteAbout the sweet spot; the question for a for-profit company is often how much of their source code they can open up without undermining their sales efforts. Model #2 works great for cases like MySQL, and I see Oracle moving to assert similar control also over projects like OpenSolaris, OpenOffice and OpenJDK they acquired through Sun. Model #3 is more often seen with open core scenarios where you have a mix of open and closed source software, so it's not necessarily a net win for external people.
[...] those beliefs and we hope it will strengthen Nooku’s growth towards growing a truly open community [...]
ReplyDelete[...] Agreement. Both changes are forming the cornerstones on which we are growing Nooku as a truly open community of [...]
ReplyDelete