After I produced this post about the nature of providing support and services for open source software last week, I spoke with Kim Weins and Stormy Peters from the OpenLogic team to gain a better understanding of the company's perspective on the issue. I should probably mention that OpenLogic reached out to me with an offer to round the story out, and that I was impressed by their independent initiative. Especially considering OpenLogic isn't a paying customer nor are we a household name by any stretch of the imagination. As a matter of fact, if you really want to Get Smart on Open Source don't bother reading me, since even Microsoft is a better source (pun intended).
Nonetheless, both Kim and Stormy made time to schedule a quick chat and I appreciated not only the gesture but also the information I took from it. Neither seized the occasion to "defend" the OpenLogic business model and as a result the talk unfolded like a real conversation instead of some sort of vendor countermeasure or slap-down. While it isn't accurate to state that I harbor(ed) any ill will towards the OpenLogic business model beforehand, I was, in fact, not aware of several factoids that would have strengthened my grasp of the entire picture. For example:
- The average OpenLogic customer uses an average of 75 open source packages. The fact that open source is used on average in bunches this large gives creed to the very existence of aggregation plays like OpenLogic. My personal observations had been that after a certain level of dependency on non-commercially supported open source software assets is reached, the odds of pursuing external support drops precipitously. This is obviously the other side of that tendency playing itself out.
- OpenLogic actively supports a Revenue Sharing program. I was informed that OpenLogic is proactive in seeking to share service and support revenue precisely because the company understands the need to connect to pools of project-specific expertise in order to provide the level of enterprise quality support expected by its customers. I also learned that Interface21 is somewhat of an exception in the sense that there is not (yet) a relationship between it and OpenLogic.
- 95% of support issues serviced by OpenLogic do not involve the fixing of bugs in the software. Granted, it would be next to impossible for me to actually verify this figure but assuming veracity it makes a compelling case for demand of CYA support at the enterprise level. Although, I am of the opinion that OpenLogic should consider expanding their service portfolio to include training which assists enterprises ramp up internal self-support teams.
- The OpenLogic Expert Community does indeed value committer status. It's a good sign that OpenLogic isn't just hiring random "support engineers" who are isolated from the comings and goings of the open source communities which produce the very software the company supports. I would add that a tinge of transparency related OpenLogic's various affiliations could work to buoy credibility and even work as a plug for the company's capabilities.
- Connections to supported open source software communities are maintained through its Expert Community. Kim and Stormy both expressed an understanding of OpenLogic's role as a type of knowledgeable aggregator made possible not by being the folks that pays developers to commit code or fix bugs, but by grooming non-conflicting relationships with those same developers through its Expert Community. This isn't the same as making an investment in collectively owned I.P. in communities but it does serve as a capable bridge.
I still stand by my original comments, only I'm hopeful the above will illuminate added dimensions of the subject matter.