Why would a software company choose to change its product from proprietary to open source? It turns out there are many good reasons, says Dan Mihai Dumitriu, CEO and CTO of networking software company Midokura. In this interview with The Enterprisers Project, Dumitriu explains the benefits.
The Enterprisers Project (TEP): Tell us a little bit about your company.
Dumitriu: Previously, the founders of MidoNet built distributed systems for large e-commerce and websites like Amazon and Google. Conventional networking and operations were simply not efficient or scalable enough to handle the likes of Amazon, so we built our own. It became apparent to us that web-scaled companies and enterprises across the board demand the same level of agility from their infrastructure and shared a similar pain. We decided to build a company to tackle the network performance issues for all companies out there.
TEP: How did you come to decide to take your software open source?
Dumitriu: We saw a movement toward open sourcing infrastructure technology such as Infrastructure as a Service (IaaS) with OpenStack and Eucalyptus. The IaaS cloud software is the first time we see open source lead the category over the proprietary solutions. For example, in the operating system category, the adoption of Linux followed Microsoft. To us, this was an indicator that a sea of change was happening.
With the adoption of open IaaS cloud, we also saw Ceph gaining user traction and users showing a strong preference for open source storage solutions over proprietary in block storage. We took a step back to consider our own market and saw a gap for an open source networking solution. So we took the leap by open sourcing the code behind MidoNet so that open source MidoNet can take the lead in the virtual networking category, much as OpenStack and also Ceph are doing.
TEP: What drawbacks did you have to consider in your decision to go open-source?
Dumitriu: Being proprietary was a barrier to adoption. Users could not evaluate the software without a legal agreement and speaking with a sales rep. With cutting edge technology, users have an expectation to try the software and to understand how things work under it. They are also generally reluctant about bringing new technologies with unknown security risks into their environment. While all software has known vulnerabilities, with open source software, users can review the source code, run security audits, assess the exposure for themselves, and then decide.
TEP: Once you'd decided to go open source, how was that communicated to your team?
Dumitriu: The decision to go open source was a culmination of several years of deliberation and deep involvement with our engineers. Engineers at all levels took part in our business, marketing and technical discussions. We ensured that the final decision was not a surprise to anyone as the entire company was involved in all aspects.
TEP: How did that decision change how your engineers do their work?
Dumitriu: From a technical standpoint, engineers work pretty much the same as before, given that we modeled our software development processes similarly to OpenStack. Prior to our decision to open source, we had already adopted tools commonly favored by the open source community because they were helpful for managing our globally distributed team. We were already making use of chat clients and message list for threaded conversations, and Gerrit for code reviews. The only change was going from a centralized private Github to a public Github.
However, the change was more of a cultural shift than a technical one. Our engineers generally worked in silos or in small teams and kept to themselves. Having to broadcast their work to the broader community was a new thing for them.
We got over the culture change by identifying community champions within engineering. These champions weren't necessarily in management, but often peers. Having our engineers nudging others with a little peer pressure gradually shifted our engineering culture to become more and more open, where key features were discussed in an open forum. The change was gradual but took less time than we expected.
TEP: Any lessons learned along the way?
Dumitriu: One of the lessons we quickly learned was to implement geographically distributed teams. Splitting the work between multiple locations became a forcing function for the engineers to learn how to communicate with other teams. Left to their devices, our engineers would easily have preferred water cooler conversations within one central office, but it would have meant that those working remotely would miss out on these critical conversations.
A side benefit of having a distributed team was better overall documentation and engineers writing more readable code. Better documented code made it easier for new people joining the project to understand and see where they could make improvements. There's less incentive for engineers to do this when working on a proprietary, monolithic code base as there are fewer people reviewing their code.
Another lesson learned is to hire a strong technical community manager from the beginning. Unlike proprietary technology vendors who filter out who they choose to partner with and sell to, an open source community has the goal of broad adoption. It is important for a community manager to foster community involvement through forums and community channels. It is equally important for the community manager to represent the viewpoint of the broader community rather than that of a selected vocal few. Being more inclusive and transparent engendered trust, loyalty and active involvement by the community.
TEP: What advice would you pass along to other CTOs about going open source?
Dumitriu: CTO to CTO: Get ready for things to slow down when you engage the community, but if you're willing to forgo the immediate returns and see the big picture, with an active community, you will be far more successful in five years than if you go it alone.
ALSO READ
- 5 questions to determine if open source is a good fit for a software project
- Open source as a path to innovation
Dan Mihai Dumitriu is CEO, CTO & co-founder of Midokura. He is responsible for the technical innovation and development of designing, building and operating Midokura technology. Prior to founding Midokura, Dan served as Chief Architect at Ballista Securities, a New York City ATS offering an electronic block trading system for options. Dan has also served as Senior Researcher at NGI Group, Technical Lead at Amazon.com, Researcher at Ecole Polytechnique Federale de Lausanne, Senior Researcher at Sony Electronics, and Technical Lead at Reliable Network Solutions. Dan holds a Master of Engineering and a Bachelor of Arts, both in Computer Science, from Cornell University. He is a co-author of numerous research papers, holds several patents in the field of distributed computing, and is an expert in cloud computing technology.
