What Goes Into a Decision To Take Software From Proprietary To Open Source
Lemeowski writes: It's not often that you get to glimpse behind the curtain and see what led a proprietary software company to open source its software. Last year, the networking software company Midokura made a strategic decision to open source its network virtualization platform MidoNet, to address fragmentation in the networking industry. In this interview, Midokura CEO and CTO Dan Mihai Dumitriu explains the company's decision to give away fours years of engineering to the open source community, how it changed the way its engineers worked, and the lessons learned along the way. Among the challenges was helping engineers overcome the culture change of broadcasting their work to a broader community.
/thread
Normally products are released Open Source as that they are not part of their business model.
If your business model is based on consulting, then for the most part it makes sense for most of your products that you make to be Open Source as you are not expecting to make money selling software, but consulting services.
Even if your model is selling software, particular tools that you make are outside of your sales area. Say if you make Electronic Health Records as your core business, your Web Framework that you made, or tools that you use for searching data etc... You might want to Open Source.
There is some advantages in Opening Source such systems.
1. You might get some support outside the company to fix bugs, make improvements etc...
2. Your company will get some good will for releasing the free tool.
3. Your code may create a workforce trained in your system, so there is less training for new hires.
4. You may be able to become the standard, vs trying to deal with a large sets of different methods all closed and expensive. You could kill your competition from you pet project.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
The best things to open source in this scenario are the things that you would buy from a third party, if you trusted the supplier enough. For proprietary software, a second source is almost always impossible. For hardware, it's often quite difficult, depending on the component. Switching from Intel to AMD is quite easy in a lot of cases, switching from a Qualcomm SoC to a Samsung one is more effort. Switching other components can be very hard. Service companies are a lot easier (switching from one law or accounting firm to another is much easier than retooling a production line).
Apple's involvement with LLVM is quite a good example here. Their ecosystem absolutely depends on high-quality compilers existing for OS X and iOS. With Classic MacOS and early versions of OS X, they outsourced this to Metrowerks, who produced quite a competent IDE and set of tools. Then Metrowerks, their sole supplier, was bought by Freescale and development on the Mac versions basically disappeared. They had some involvement in GCC development inherited from NeXT, but GCC was problematic for IDE integration (the parser is designed in such a way that it's impossible to use for syntax highlighting, for example - it does constant folding very early so you can't differentiate 4 and 2+2 in the source). They decided that they needed to bring compiler development in-house, but it was a lot cheaper to do so as part of an open source ecosystem. Apple now contributes something like 40% of the code to LLVM and that vast majority of what other people do directly benefits them, so they're effectively halving their costs. And, of course, giving away the IDE and compiler tools for free (rather than charging, as Metrowerks did) makes people more likely to start developing for Apple platforms.
I am TheRaven on Soylent News