My experience with open source has taught me a few things about partnerships. I have observed the basic rule that partnerships require give and take. The give and take do not happen in regular intervals, so you need to trust the relationship will cycle back and deliver.
I have a deeper observation about source based businesses. There is a bit of sheek lately to state your code is open source. Typical businesses would see this as a hit to the bottom line. The lost licensing fees means support fees have to pick up the slack. What most people fail to see is that this is huge innovation and long lasting partnership opportunity. With your code in the open you will pick up some contributors to your open source project, but what you really want is your customer’s innovation energy and ideas.
Here is my thinking. What is the first thing most people do when they use a product? No matter how amazing it is, we look to the faults. That Bugatti does 250 MPH, but where’s the cup holder? So when a customer of software looks to its faults, they normally have the support call or the account manager to deal with. When the software is open sourced, who is in the best position to work the problem other than the customer? I know this is not the typical software customer role, but it is a common conversation had over OpenStack software. Coming up with innovative solutions to common problems is what the open source community does best. I would mine 10-20% of your customer base as potential development partners.
Do you want your customers as software development partners? I say yes, for two reasons. First a customer will be invested in certain features that they want to exploit. How better to drive innovation than to make them part of the team. Second is that the customer investment in development will translate into a long term relationship with the software. Your development partners are very likely to incorporate the code into production as their own.
So how do you turn a customers into software development partners? It’s easy and hard at the same time. You need to train the interested customer developers to be part of your team of developers. Easy concept, hard to implement. You will need to have solid training tools. Mentors at the ready. Your code (CI) pipeline will need to be reliable and provide code quality feedback. Your mentors will need to do time on the review side of the pipeline. Once you make the switch, your extended team will need the CI pipeline to have reliable operations coverage. We practice much of this right now with OpenStack. We are in the process of creating the training and mentoring that will sustain the projects.
Summarizing the ideas from above, building long term relationships should always be a goal of any project. Innovation happens with the right mix of people, tools, and ideas. Long term innovation equals happy long term customers. In conclusion, open source business done right, broadens the team and makes everyone stronger.