Can open source engineering work in a commercial project?
Today, in a discussion with some engineers, we wondered if it is possible to replicate some of the attributes that make some open source projects so incredibly powerful in a more commercial setting. We’re not talking about making money off of open source; instead, we’re interested in cataloguing what can be learnt from the open source engineering approach and seeing how it could be leveraged for businesses that have a commercial R&D function.
Successful open source projects:
- Produce very high quality software
- Have generally very motivated developers
- Get some of the best talent in the world
- Are highly distributed, enabling individuals who participate the ultimate in lifestyle flexibility. You live where you want, you work however much you want, whenever you want.
Some of their observations were:
- All successful open source projects have a benevolent dictator in charge. Companies are afraid to confer so much power to one person and instead tend to decide by committe
- The lack of commercial pressure allows engineers to progress towards goals at their own pace, many open source projects produce “progress” very slowly.
- The natural selection among open source projects is brutal. For every successful project with the right idea, the right people, the right market, there are hundreds which fail, either because of the wrong dictator, the wrong idea or the wrong timing
Some of my counters:
- Companies, especially startups, should excel at empowering one individual to steer a project. A company can eliminate all barriers for one individual to lead without having to worry about perception, mundane tasks, or financial worries.
- Product companies, especially those that are targetting thousands of users, have to progress very slowly anyways, giving a lot of consideration to quality, operations, code health, etc.
- The natural slection of commercial endeavours is just as brutal. But if you just could get top notch software out of an engineering team in a reliably manner, then you’ve eliminated one more source of risk.
Wondering what other people’s experiences are in building highly distributed software engineering teams made of highly talented, highly motivated engineers. My gut feeling is that this kind of approach hinges on the quality of the process. The distributed approach forces a degree of formality that correlates with good engineering practices. This raises two interesting questions: a) is it really the process that makes the success, or is there something inherently different when you take money out of the equation that makes it possible for these open source projects to succeed (to me, open source looks like an aberration, it shouldn’t work yet it works beautifully sometimes) b) if it is the process, what comes first, the distribution forcing the practices or developers who wouldn’t work any other way self-organizing around those practices?
In any case, I don’t think that the central motivation of pursuing open source engineering approaches in commercial settings should be the lowering of R&D costs. It makes more sense if the goal is the raising of engineering standards and what that can enable for a certain kind of business.

Recent Comments