I was fortunate to be asked by my friend, Jon Williams, to speak at Wednesday's New York CTO Club, a gathering of dozens of CTOs from a range of interesting (and some quite large) enterprises. The topic today was "Open Source as a Renewable Resource," with the focus on how enterprises can contribute cash or code (or other contributions) back to open-source communities.
However, much of the discussion turned on how open-source companies should be making money, rather than how enterprises should be contributing code. The interesting thing was that while the CTOs looked to open source as an inexpensive means of discovering and evaluating software, all seemed to believe that adding proprietary services or software was the right way to monetize it.
I was surprised, to say the least. I talk with a lot of enterprises in the course of my business, and open source is always a primary reason for why they purchase my company's product, even if they don't intend to view or modify source code. The question I never asked, however, because my company doesn't offer proprietary software, is how the buyers would react to proprietary ("commercial") components.
From what I heard today, it's a non-issue. Every CTO that spoke up (and it was a very open forum) said that they are happy to pay for proprietary extensions to open-source software, and criticized pure-play open-source vendors for not providing an obvious, compelling reason to pay: proprietary bits. (One actually said that we have built a great financial model...for SIs, not for ourselves.)
Trying to shift the burden of proof back onto themselves, I asked why they don't contribute to the open-source projects from which they derive so much value. Many indicated that it's too hard to contribute back to open-source projects due to internal legal issues and the high bar to knowing how to contribute. They suggested that they would instead prefer to pay the open-source companies to do that work for them.
Along these lines, one noted that a marketplace for feature requests would be ideal. Enterprises could bid on features that they want added to an open-source project, and perhaps pool costs between different customers (as Collaborative Software Initiative does).
When I asked about concern over vendor lock-in, this didn't seem to be a major concern. In fact, a few advocatedso as to productize our support, even though SaaS locks in enterprises more than normal proprietary software would (because once you stop paying, you completely lose access to the software).
It was an enlightening conversation, one that can be summarized as follows: Don't expect code contributions back from enterprise IT, but instead make it easy to financially justify giving open-source communities and companies money, with proprietary add-ons or extensions being the primary mechanism for accomplishing this.
This isn't the response I expected going into the meeting. Food for thought.