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:
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:
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.
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.
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 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.
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.
Calle Aprestadora 19, 12o-2a
08902 Hospitalet de Llobregat (Barcelona)
Spain
Tel Europe: +34 609 953 751
Tel US: +1 415 200 2465
Mail: info@project-open.com