Commentary

Serdar Yegulalp
 

Open Three Ways, Or More

Ealier in the week the CAOS Theory blog of the 451 Group noted there were three, or actually four, ways you could handle "open core" licensing -- where the basic version of your product is free, but the add-ons and support and such are not. Everyone will (and should) do these things differently, and the details are full of devils.

Ealier in the week the CAOS Theory blog of the 451 Group noted there were three, or actually four, ways you could handle "open core" licensing -- where the basic version of your product is free, but the add-ons and support and such are not. Everyone will (and should) do these things differently, and the details are full of devils.


More Software Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

The blog post itself surrounded the three-and-a-half choices in question with a lot of good commentary. The options themselves run like so:

  1. Open core with paid services. Free product, with bonus features (support, management, auxiliary storage, hosting) delivered in a managed / SaaS fashion to the end user. Some folks who do open source CMS are taking an approach like this: you can snag the core product, run in on your own, or pay them to run it for you in a guaranteed-uptime fashion.
  2. Open core with closed add-ons. Such for-pay components usually consist of things like data connectors that allow you to plug into other proprietary products: you can be free on your own, but you'll have to pay to liberate your existing data. Or it's add-ons that transform what you have for the rest of the world's sake in ways that would involve a lot of additional programming.
  3. Open core under a custom license. That's right -- release an open core product using a license of your own devising, without hanging around for OSI approval.

The third option is a deviation of "open core under an OSI-approved license", which is the path most people take for such things anyway. Hence, three-and-a-half.

Option #1 and #2 are worth their own discussions. But Option #3? I can imagine a response from the existing open source folks that goes something like this:

It's hard not to make use of an existing OSI-approved license. There's plenty of them, they cover the vast majority of business or development scenarios; and (most useful if you are big on people giving back) picking the right one means you automatically attract a certain class of user and developer to you. Hatching your own license is an uphill battle, the sort of thing you only do when there is literally no other choice.

End imaginary quote. In fact, I've said things of a similar tenor myself more than a few times. But the problem with the "there's all the licenses you could need" mind-set is the same as the (admittedly mythological) "640K should be enough for anyone" quote.

Things change. That includes the circumstances under which software licenses are created, adopted, and put to use. It's also going to include the way open source is handled by commercial outfits, and whether or not it forms the real basis for their business.

InformationWeek has published an in-depth report on Sun's future under Oracle. Download the report here (registration required).

Follow me and the rest of InformationWeek on Twitter.


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links