CTOs vote for open source, but buy proprietary software

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 advocated open-source vendors introducing SaaS offerings so 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.

[jkunz001]

Matt,

Your experience mirrors the feedback we have been receiving from our clients, partners, and prospects. One reality of the enterprise is that they are not oriented towards a sharing of technology approach to software development and use. This is not to say that they can't or won't contribute to an open source project. In most cases they don't know how and lack a strategic vision that places any value on doing so. I don't know that it is fair to place an expectation of contribution at the feet of enterprise IT. What is very interesting to us is the finding that many organizations want to adopt an internal version of the open source ecosystem and project ethos. Imagine a far flung and highly disparate global organization that has multiple development centers and lines of business. Now overlay the idea of open projects, communities, etc. Some very progressive enterprises are starting to realize some very large ROI as they adopt these "open source" tactics to their proprietary development environments. A very interesting development indeed.

Jeff Kunz
Director of Business Development
Olliance Group
The leader in open source business and strategy planning and implementation

[jbarmash]

> 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.

I don't believe it. They buy it because it's good software at a reasonable price. If "open source was the primary reason", then there would be much fewer customers.

IT Managers are interested in solving problems - if open source can do that faster / better or cheaper, all the better.

[daftkey]

>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.

How many people do you talk to that have decided to purchase a competing product? Do you have a good insight on why your competitors might win business that you were seeking? I know it's easier to get the answer for why you were the chosen, but it might be harder to find out why you were not. However, the latter can give you a lot more insight, and may make the rest of the conversation less of a surprise.

>When I asked about concern over vendor lock-in, this didn't seem to be a major concern.

When you asked about why it's not a major concern, what was the answer?

>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.

Or to summarize further - Enterprise IT is about strategic business advantage, which requires software solutions which are valueable and hard to reproduce. Contributing code related to an IT initiative destroys the "hard to reproduce" part of this equation, and as such it removes the strategic advatage.

[rtddtr]

Ok, but regardless of whether its proprietary or open source, when management has their budgets, they need to make it appear that that budget is necessary or risk have it shrink the following year, so purchaing whatever software you can afford will do the trick. Now, my view may be slightly skewed, as my experience is mostly in not- for-profits, primarily government funded where you almost always loose what you don't use, and rarely ever rewarded for fiscal efficiencies.

[moulaha]

Moulaha first free Arab Online Auction House - List for Free in Internet Auctions site for the : Algeria, Saudi Arabia, Bahrain, Comoros, Djibouti, United Arab Emirates, Egypt, Iraq, Jordan, Kuwait, Lebanon, Libya, Mauritania, Morocco, Oman, Palestine, Qatar, Somalia, Sudan, Syria, Tunisia, Yemen. Buy and Sell everything and anything for free and no final value fees in our multi-currency online auction.
http://www.moulaha.com