"OK - so just let me get this right, you want us to develop this piece of software and then give it away for nothing. Yeah well that makes a lot of sense!"
This note discusses the nature of Open Source development and its use as a software or system development technique.
Open source is not for everyone or for every project - perhaps because of the nature of the project (100% proprietary projects are doomed from the start) or perhaps because of the style of management (peer developers tend to have ideas and react badly to rigid and externally imposed control structures).
But it is a technique used today by some of the major companies in the software and systems business - among them are the smaller guys such as IBM, SUN, HP and INTEL. It is part of the arsenal of development techniques that companies and organisations must consider when looking at systems development OR to make viable what was hitherto impossible.
Here are some all too common scenarios:
We got a great idea for this system that would revolutionize the way we do business (let us take over the world, reduce our costs, deliver better service - or whatever). Minor problem: It is going to take 100 man years of effort and we've got 5 folks to spare.
Our budgets have just been cut back (again) and we cannot afford to finish this development that everyone is screaming for.
We got this piece of software that we need because all our competitors have got it - but it costs a fortune to maintain, enhance etc. It really adds no value to our product is just a gotta have for our market.
This system we are critically dependent upon does not have a feature we want urgently (has had its maintenance costs increased, suspect the vendor may withdraw it or go out of business - or whatever).
The normal reaction to the above scenarios is a shrug of shoulders, blind panic or some combination.
Can we create an Open Source project or can we use an Open Source project to solve our little local difficulty.
If you are going to use an Open Source project as the basis of your development then you need to consider these points:
Is there a good functional fit with an existing project. If you change your strategy a little can you use it as is or does it need a major shift in direction.
If you have to modify an existing Open Source project to provide some functionality that you want to keep private does the license allow you to do it? Can I protect my own IPRs. The Open Source Initiative has lots of information about the many licenses in current use and what they mean.
If you become dependent upon the project what resources should you put into it to ensure its survival and prosperity. Money, effort, hosting, servers, PCs etc.
The feel-good factor. Does the project feel right or if you get heavily involved will there be a culture clash. Get onto the mailing lists and see how the project conducts and organises itself, can we work with these guys harmoniously and for the good of everyone?
There are excellent reasons to start new projects, but you need to think through a number of issues:
Is the whole project going to be Open Source, do we want to keep something private? Is the project still viable if we keep our piece private. Can we design it in a modular way to allow us to snap-in a module for our own use. Will it bother us if competitors do the same and beat us to market!
Can we get a lot of other folks involved. Essentially this means realistically looking at the project from the other person's perspective giving them reasons to buy-in:
What license regime shall we use to protect our interests while ensuring we continue to provide motivation for others to get involved? The Open Source Initiative provides a central resource to help you through this minefield.
Do we understand the culture well enough to organise and manage the project in a sufficiently co-operative way to ensure success.
What resourcing levels are we going to commit to this project? People, money, skill levels (which may need to include marketing and PR resources). If you are in - you gotta be all in.
Are the coding standards, organisation and other essential of multi-person projects in place or would there be resentment (or relief) if you put the grunt effort in to make them happen.
Open Source development is in essence a collaborative and co-operative effort between peers - with a modest but gentle control hierarchy thrown in to make it all work.
Now that's not too different from a classic internal development project.
OK you may never actually meet many of the people involved, they may be spread all over the world and you cannot control them in the classic sense and they may have ideas of their own they wish to contribute. If you are wise you will welcome this input with open arms. If you are wedded to a classic hierarchical organization and like using the whip occasionally - best forget it and get out the check book.
Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.
If you are happy it's OK - but your browser is giving a less than optimal experience on our site. You could, at no charge, upgrade to a W3C standards compliant browser such as Firefox