Three years ago, the thought of EMC offering up code to open source projects for the world to freely access would have been heresy. The old idea was that we’d produce proprietary source code and over our dead body would we share it.
Almost three years ago, we recognized that winning in the cloud native world would require a wholesale change in attitude towards open source. Why? First, because success as a vendor in this space is about the community rallying around what you’re doing. Second, open source will enable us to move faster through community-based development. And third, we want to eliminate concerns around lock-in. That shift has taken a couple of years to manifest, but our open source engines have kicked into high gear. We made our first contribution in the form of the CoprHD software-defined storage controller. We’ve since followed up with RackHD, a complete hardware M&O layer, UniK to enable use of unikernals, and libStorage, a storage provisioning framework for container platforms.
In making these contributions, we’ve learned a few things about participating in the world of Open Source that are worth sharing.
When you feel like you’re almost ready to go, you’re ready to go
Traditionally, when we think of a product release, we think “we’ve got to get it perfect – we’ve got to solve everything before we put it out there.” But with open source it’s far less important to get things perfect initially, and far more important to get it out into the public domain so the community can work with it. What we learned in releasing CoprHD and RackHD is that you get more credibility by putting software out there and being up front about the condition it’s in rather than pretending everything’s perfect and treating it like a finished product release.
You don’t need a community to get started, but you need your own commitment
You might think that if you open-source something, you’ve got to have 50 partners lined up – actually, you don’t. I used to think you did. The key to driving an open source effort is showing commitment to developing a top quality project. If there’s value, the community will line up behind the project.
Your community self selects
You don’t necessarily get to choose who partners with you – the community self-selects. Intel is one of our big partners on CoprHD, which makes quite a bit of sense logically. But I certainly didn’t anticipate the major contributions that Oregon State University would be making. Yet here we are a year later and OSU is using CoprHD’s southbound SDK to develop a new EMC ScaleIO plug-in. Why might OSU have gotten involved? Because participation in open source projects are a great way for students to get their capabilities and names out for all to see.
All open source licenses are not alike
There are many open source licenses you can release software under. The differences between the licenses are critically important to understand, because they can affect the community’s contribution. Whereas one might ensure all code developed as a result of the project remains open source, the other might drive greater interest around the project itself. With CoprHD we put it out initially under the Mozilla public license, but ultimately switched it to the Apache License 2.0, because that’s what we felt would better enable the community.
Where do we go from here? I think much of software development, and indeed our own will go the route of open source. Seeing precisely what that results in is simple, since much of the open source work we originate is posted to our EMC{code} community. So check it out, tell us what you think, or better yet contribute code. Your feedback will help us learn to be a better member of the open source community, and your code will make for better software for everyone.
