Still Linux Kernel developers have succeeded in developing a very large and complex software with minimal overhead. Most of the development is done by mixed set of individuals who rarely physically meet each other. Their work is pulled together by similarly distributed individuals called maintainers and eventually by Linus himself.
Very successful open source software (OSS) development has been done with an even simpler setup: someone just sets up a (D)VCS repository (GitHub etc) and starts publicly developing software. Random people get interested in the project and start contributing by sending the original author patches or even pushing changes directly to the repository. In many cases all that is needed to coordinate the work is a common (D)VCS, few emails and/or chat sessions - and of course the source code itself.
If distributed development works this well, could and should it then be used to do non-OSS software? Here the term "non-OSS" refers to the organization and the nature of the project, not to the license of the software. So hire the best professionals from around the globe and offer them good compensation. Create common repositories for code. Have product owners, architects and managers feed the developers with specifications and requirements so that they deliver something that has business value. Set up bug tracking systems and continuous integration machinery to solve the quality problems. Create custom development and testing tools so that developers can maximize their output. Open Source Development on steroids, right?
Unfortunately, no.
The motivation to do Open Source Software development is very different from the non-OSS development. The magic that makes OSS development successful can only happen in a true open source project. Open Source Software development works without management, process and co-location because OSS developers are interested in the project they work for. As Daniel Pink pointed out in (http://www.ted.com/talks/dan_pink_on_motivation.html) no amount of money can beat this.
Pretty much everything else that is the OSS magic comes from this single fact:
OSS developers work on items which they themselves feel are the most valuable and interesting things to do right then. If somebody disagrees about the priorities then either they get into a consensus or the task is just dropped and a better one picked. No one is working on a task they do not believe in.
OSS developers know that anyone can and potentially could review their code or design. Ever noticed the manic urge to clean up your house when visitors are expected? Public review gets the better half of you going.
OSS developers know that unless they themselves communicate and synchronize between the other involved people they will be screwed and most likely people you value will know about it.
OSS developers pick development tools that work best for them. And if they are not happy with the best available tools they will make their own.
The same applies for other aspects of open source software development: have bunch of motivated people with same goals in life work together and the magic will start to happen. In a project where somebody else decides what should be done or who should do what you most likely will not see similar benefits. You will see unmotivated people creating stuff they do not believe in, people not communicating with each other and all kinds of quality and schedule problems.
My recommendation is obvious: if you want to do software in an OSS style then let the people decide what to do and how to do it. If you want to control the content or output of the project then apply other methods. I would start with having all the people co-located but that is another story, then ;)
Orange Lantern, Espoo, Finland
Ei kommentteja:
Lähetä kommentti