informa
/
2 min read
article

Who's Paying For Open Source And Why

So who's buying licenses for open source applications? Enterprises, from the look of it -- which would explain why most of the for-pay editions of FOSS applications are branded as the "enterprise" edition. But there's more.

So who's buying licenses for open source applications? Enterprises, from the look of it -- which would explain why most of the for-pay editions of FOSS applications are branded as the "enterprise" edition. But there's more.

During my time at OSCON, and since then, I've been talking to a number of different companies who offer community/FOSS and enterprise versions of their products. My question to them has been: How do you define what features are available in each edition? What's the dividing line between a core feature and a for-pay feature?

After a whole slew of discussions, the picture became clear. Features that are worth charging money for tend to revolve around the same two basic conceits: management and migration, both on a large scale. If you're dealing with just one instance of something and the feature set you have reflects that, you're probably dealing with the core/FOSS edition of a product. If you're dealing with multiple instances (not three or four, but more like fifty or a hundred) and need to manage them from one central console, then you're probably in an enterprise setting. In such cases, you're not only able to pay for the enterprise edition, but more than willing -- you need that functionality to make things run well without going bananas.

Another key concept is that in both the enterprise and FOSS editions, the core APIs are the same for features exposed in both -- but it's the end-user interface for those APIs that may be exposed in different scopes. For instance, you might have a FOSS edition of something with a backup API, but the user interface in the FOSS edition only supports working with a few basic functions. The enterprise version has an interface with the full gamut of backup options (e.g., backup to a remote server instead of just a local flat file).

This obviously isn't the only way to do it, but for the market it's serving, it makes a great deal of sense. In the future I'll talk about other possible ways to split the market, but for now I'd be curious to hear from people who fall into either camp.