I’ve been reflecting on the various companies I’ve worked for and the styles of software development that they used. I’ve experienced everything from hardcore Kanban to hardcore SCRUM to waterfall (but we called it SCRUM). But these categories only scratch the surface of the myriad of dimensions to a software team development model. One of the newer, and more controversial, dimensions you can add to your software development process is your approach to open-source. Meaning, your code. Do you open-source your code? In whole in or part?
Operations like Canonical (makers of Ubuntu Linux) and SuSE (makers of, well, SuSE Linux) pioneered the fully-open-source model. Your code is right out there in public. But, people still pay you! They pay for support when it’s 2AM and the server is on fire. You’re basically the Ghostbusters (but for misconfigured servers).
Also, a number of new database companies have thrown their hat into the ring over the past 20 years, offering fully open-source database software. But, people also pay them (for managed hosting). These companies have been in panic mode lately, trying to claw back their open-source status, because their open-source gambit is being destroyed by cloud hosting providers who can do almost the same thing, cheaper. Ouch.
But the real contriversial part of corporate open-source is the so-called “Open Core” model. This is a model where you build a generic version of your software, the “core”, and you keep your customizations proprietary. A good example is Docker, which provides the core Docker runtime for free, but their proprietary, paid-only GUI is their major selling point.
People tend to look at the open-core model from a competitive risk standpoint. I.E. do the benefits of being “open core” outweigh the risk that someone will come along and use your core and provide their own implementation of your value-add, and steal customers? People spend a lot of time worrying about the risks, so they don’t properly assess the benefits.
One of those benefits, which was a revelation to me when I realized it, is the ability to nearly completely decouple your software development organization from your business. If your “core” is 50% of your developers, and the other 50% of your developers are working on customizing that core into the final product you offer to customers, then 50% of your software developers can essentially be treated like a supplier. They don’t need access to production servers (especially useful if you’re working in the health care, payment, or government sectors). You don’t need to impose draconian software/hardware policies (as everything on their development machines is intended for public release anyway). People can BYO hardware/software environments without IT approval. Hiring conractors is easier. Heck, if you do it right, an ecosystem of mini-projects will spawn around your core open-source project, and you can encourage that ecosystem through donations. You can sponsor students to work on your project through GSOC.
Is open-source or open-core right for you? Obviously, the development model requires buy-in from some hefty stakeholders who may be afraid of the downsides. I hesitate to say that every org would benefit from using it, but I think that it’s something every company should experiment with.