I’ve worked for several New England startups that used open source software to jump-start their product development. What are some of the tradeoffs? I’m interested in open source software integrated into a product; there are different issues when the company exists to extend an open source project, or when open source software is used as part of the company’s IT infrastructure.
The classic case of this usage is embedding the Linux kernel in the product. Linux is mature, actively-developed, and very modular – these are all attractive attributes. It’s also free, as in royalty-free, and the source code is similarly freely-available. The competition – embeddable kernels, often with a real-time flavor – is also mature, several options are actively-developed, but you pay for using the code, and presumably receive better support in your development. (The technical fit will depend on your application, I won’t address that here.)
Other classic examples include using gcc in your product, or building a web-based service around the Apache web server, or even using common tools such as Perl and PHP. Each one of these software packages is mature and actively-developed, and has competitive commercial products (depending on your application) that are also mature and actively-developed, but require payment.
One company I helped start made the decision (free or not free) several times during our lifetime, and changed the direction we went. Initially, we licensed a commercial embedded real-time operating system, bought a commercial suite of compilers, and used them to develop the first products. Later, in our 3rd-generation products, we switched to a Linux base. (We revised the physical designs at the same time, moving to a more off-the-shelf approach.) Our server application team made different decisions, building in more open source software from the beginning. All of these decisions had an impact on the business years later, and some of them led to last-minute rewriting of non-trivial parts of the product.
The problems we faced – and bigger problems that have been faced by much larger companies – evolved from that word “free”. When I described Linux and other open source projects as “free”, that was sloppy thinking, and in the case of this company it led to some sloppy management practices. (I was part of these practices, I share the responsibility.)
The Linux kernel is copyrighted, and that copyright is released under a license. In this way it is no different from the commercial products I called “competitors”. gcc is also copyrighted, and so are all other open source projects. (If there’s no copyright, we call the software public domain, and the rules are different.)
You wouldn’t found a startup – or start a new project – by saying “I’m going to steal this software and use it to build our next-gen best-seller.” No, you would say “we need to license this software package, and that will cost us X dollars up front with a per-unit royalty of $Y” (or whatever the vendor’s terms are). But, because the industry often calls open source projects “free”, we as software managers often forget to account for the licenses that control them.
Open source software is licensed. The choice to accept those licenses, and abide by their terms, is a business decision that needs to be made by the business managers. Just as you wouldn’t make an individual engineer responsible for counting the units-shipped of a commercial component, and paying the vendor’s royalty, you shouldn’t leave open source licensing decisions to engineers either. These are business decisions that need to be made by technically-savvy business managers.