How to Manage the Collaboration with an Open Source Provider or Project?

This article looks at managing the relationship with an open source provider in order to maximize the value for the customer. The article proposes a classification of open source software providers (vendors, projects or communities) based on the term "collaboration intensity" and recommends specific action depending on the business environment.

Before starting the discussion please ask yourself the following questions:

1. What is the monetary and non-monetary value of the open source software for your company?
   How much money do you save, and how do you value flexibility, transparency, security and other aspects of open source?
2. What is the strategic value of the open source software for your company?
   Can your company change faster if it is easy to modify the software? Can you distinguish yourself from your competition?
3. What is the time horizon of using the software?
   Are you going to use the software for months, years or decades? How short-lived are commercial vendors? How fast is innovation progressing inside and outside the open source world?
4. What are the switching costs to change the software later?
5. How strong are your in-house development capabilities?

"Collaboration Intensity"

In order to structure the discussion I propose the term "collaboration intensity" to capture the heart of open source and the customer's involvement with it. It proposes several levels of involvement with the open source product development process of the open source community in general:

• Inspect the source code of the product?
  This should always be the case with open source software.
• Modify the product?
  This is usually not the case with SaaS hosting and applies more to on-premise installations.
• Participate in the development of new features?
  Apart from paid support, is there an open community that is friendly to new members? Is there a developer guide? How easy is it to get bug fixes integrated into the product?
• Become part of the community?
  Can you push customizations into the product? Can you influence decision processes and future releases?

Desired Collaboration Intensity

A customer may not always want to collaborate intensively with an open source community. However the possibility to engage at a later moment may provide extra value, because it opens up new business options and reduces vendor lock-in. If the value of the collaboration is low, customers will prefer low involvement, focus on getting the software running and maybe perform a security audit.

Undesired Collaboration Intensity

Some open source products have a tool-kit character and require configuration to create a finished solution. Other open source products are just unfinished or buggy, so the customer needs to collaborate more than desired.

Make or Buy Applied to Open Source Vendors

Here is a proposal for a decision matrix similar to the famous "make or buy" provider segmentation matrix from supply chain management. The decisive factors are the skill level of your in-house team and the value of the open source software for your company.

Switching costs and a short time horizon may have a modulating effect. High switching cost will basically add to the "value" of the software and push you towards higher desired collaboration intensity. A long time horizon will have a similar effect, while a short time horizon (innovation happening outside of the open source world, new open source products appearing frequently) limits investments into specific products.

Collaboration Intensity with Closed Source Vendors

Collaboration is not limited to open source vendors, obviously. Vendors provide training, support, bug-fixing and sometimes even contact with product managers. SAP and Oracle run "user groups" in order to structure customer's communication with the vendor. Also, some closed-source vendors provide large customers with the right to audit the source code. However, this collaboration is usually limited and not the focus of the vendor.

About the Author

I am Frank Bergmann , the founder and CEO of ]project-open[. I have spent the last 20 years implementing (mostly) open source business software in more than 300 medium to large organizations. You can contact me directly at [frank.bergmann@project-open.com]. I would be happy to hear your opinion about this article, and about your experience implementing open source in general.