Think free speech, not free beer?

OSS project models, management and "do nots"

When, why and what could happen?

Jan-Erik Luukkonen Janne Arola

30.11.2010

MIT0SY

Index

Why should I go open source Project models Project management What can go wrong?

Example

Why should I go open source?

• •Research laboratories have adopted the Open Source model because the sharing of information is essential to the scientific method, and Open Source allows software to be shared easily.

• •Businesses are adopting the Open Source model because it allows groups of companies to collaborate in solving a problem without the threat of an anti-trust lawsuit, and because of the leverage they gain when the computer-programming public contributes free improvements to their software.

• • Some large corporations have adopted Open Source as a strategy to combat Microsoft and to assure that another Microsoft does not come to dominate the computer industry • The need of open source and model to apply can vary in different codebases within the same company • If you want to do service business around your software, you should consider OSS

Why should I go open source? Cont'd...

• • • Before going blindly to open source, a project should consider their motivation and needs. There are several levels of open source models to choose from.

• Before the project is initiated you need to consider lots of things: what is the budget, how much internal resources do you have, how much control do you need, are there any time constraints etc. Based on these evaluations you can choose your model.

• Cost savings is one major criteria for going open source, in best case you get a "free of charge" R&D team • There is usually no single "right" way to approach this, the right way depends on your company's business strategy and environment. The general models are however described in the following slides.

Project models 0: Closed source

• This is obviously not open source, not all SW is meant to be that. • If the SW asset is the major contributor to your company's revenue stream, and you get most of your money from selling licenses to software, you should be careful in sharing the code. • If however your business comes from the support rather than sales, then you should really consider opening the source.

Project models 1: Open releases

• This model is a.k.a 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.

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

Project models 2: Open development

• • Requires changes in the way you approach development to get your users truly involved in your project • •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 online support • •You’ll start receiving all sorts of contributions like bug reports, patches, new ideas, documentation, support, advocacy and sales leads for free. • • Trusted contributors can be allowed to commit their changes directly to your codebase without losing control of the project.

Project models 3: Open community

• •In this model you’ll need to let go of the idea that the project is 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 • Setting up the community the right way might be one of the most challenging tasks • •Key ingredient of the Apache Way. As well Linux kernel works this way.

Organization

Organization of an OSS project

• There are a few main roles: the initiator, core developers, co developers, release coordinator and the initiator. On top of this comes the user groups, active and passive • Core developers take care of roughly 80% of the new code o This team is usually rather small. If it grows above ~15 people, o you need to set up strict code ownership Many times if the core grows significantly, you move towards several core teams instead of one comprehensive group • Co-developers give new ideas, bug solutions, improvements, test resources etc. • The release coordinator takes care of scheduling the releases. This role is many times the authority in an OSS setup • The initiator is the person who initiated the project. • It is important to have many active users to get bug reports, usability evaluations etc.

Project management

• Biggest OSS systems are built by potentially large numbers (i.e. hundreds or even thousands) of volunteers.

• Work is not assigned; people undertake the work they choose to undertake. But then again, if the core team grows too big, you need to assign ownerships to certain people • There is no explicit system-level design, or even detailed design, except if someone in the project takes the documentation duty • There is no project plan, schedule, or list of deliverables. Only way to make sure these are in shape is to pay people to contribute into the open source community. And yet, you can not tell the rest of the community what to do. • The release coordinator is the closest thing to release manager and scheduler – of course the initiator is many times someone who gives greater visions and guidelines for the future.

•

What can go wrong and why?

Democracy in projects do not work o Need for project leader or leader group?

• Projects compete for developers (and user attention) o Both are finite natural resources • Lack of passion. This is not work, this is supposed to be fun. Nobody holds a gun and tells you to do something. If you want to create a web browser but you hardly browse the web, forget it right away. Think twice: even if you are flamed and criticized, are you still going to love your new baby or not?

• Starting with over precise plan o you will end up with filing the drivers even before you know what it will be. e.g. making a music player -> you do not have to start with support for oracle DB or lastfm integration: start with capability to play mp3 and decent UI?

o Focus on building the application, not all the nitpicky details which can be improved with time.

• Underestimate the maintenance. Just check SF, how many projects did become orphaned in the last years? You can create two dozens open-source projects if you want, but if you think you won't be able to maintain them, then think about it again. Most of the time, we always hope that someone will take over the maintenance, but only a handful projects manage this. I assume, partly because maintaining something is not the fun part of the game.

•

Example of failure: case Xara

Xara was a proprietary SW company that open sourced its vector graphics engine in March 2006. Well, most of it anyway.

• Xara's central failing: they did not understand how to engage the development community on the community's term, rather than Xara's own terms.

• Xara released "the majority of the Xara Xtreme source code" -> 90% of the core code, but not the CDraw rendering engine.

• So does this mean that commercial companies need to open source all of their code to get contributions?

• The proprietary code can be a useful extension to the code, but it shouldn't be its central reason for existence.

• The crippled code is just one of Xara's problems.

o Perhaps even more fundamental problem was its refusal to pay attention to its community.

o Xara wanted to be in control of its community • There was a really nice :-) discussion going on mailing list with FOSS developers and Xara's SW management people. Here is a example peak to it: http://www.xaraxtreme.org/maillists/archive/dev/dev_022007/msg00052.html

References

• • • • • Our open minds http://www.linux.com/archive/feature/119790 Why most open source development projects do not succeed? Evangelos Katsamakas and Nicholas Georgantzas

Graduate School of Business, Fordham University, NY Plone_A_Model_of_a_Mature_Open_Source_Project.pdf, London School of Economics http://jukkaz.wordpress.com/2010/11/08/models-of corporate-open-source/