Don't Be Too Quick to Dismiss Open Core

Open source business models need a chance to work.

By  

I've been taking some shots at open core lately, because I've come to the realization there are inherent flaws in this business model as it relates to open source.

I have some concerns about how these companies will handle open source contributions to the free "core" software if the contribution gets too close to the functionality offered in the commercial add-ons. Under open source, traditionally all contributions should be accepted (or not) based on technical merit or the scope of the software.

Technical merit is a fairly easy criteria to implement: a submitted piece of code either works well, or it doesn't. If it breaks something, or is grossly inefficient, it doesn't belong.

Scope is a little trickier, because it relies on any number of technical and non-technical variables. For instance, you could stipulate that the current discussions between Google and the Linux kernel maintainers on the inclusion of Android within the Linux kernel are a matter of technical scope. The changes that Google is introducing should work, but not quite the way the kernel maintainers want. Neither team is right or wrong, and clearly some sort of compromise will need to be worked out.

An example of non-technical scope would be the decisions Canonical made regarding the desktop interface for Ubuntu 10.04. Based on their usability research, Canonical opted to shift the window controls to the left side of desktop windows within the new Light theme... a move that upset some Ubuntu developers.

Non-technical scope such as this can strongly affect what code gets pulled into a project and what doesn't. This type of scope must include commercial interests as well.

All open source projects are managed by the interests of those developers and maintainers in charge of the project. When a commercial entity is heavily involved or in control of an open source project, there is little to no chance that commercial interests will not dictate the direction of the project.

That's something the opponents of open core are a little quiet about. They argue that open core companies are abusing open source to their own commercial ends, but the truth is that to some degree, every commercial open source company manipulates open source projects to favor them.

Back up to the Canonical/Light theme example: Canonical based its decision on usability issues. But why was it conducting usability studies to begin with? To make Ubuntu better, more appealing, and (ultimately) more used. The more popular Ubuntu is, the more chance it gains more commercial users on the server side, more cloud customers, and more developers in its community--all stated goals for Canonical. Bottom line, this was a bottom-line decision.

Not that there's anything wrong with that. Canonical is allowed make some money--that's what businesses do, even open source businesses.

There are countless examples of how commercial interests will define the scope of an open source project. It happens in open source all of the time. Ironically, I would argue that open core companies are just more open about where their commercial interests lie.

I have another concern about all the open core chest beating: resistance to new ways to commercialize open source software ignores the fact that exploring new business models is not only to be expected, it should be encouraged. Why? For two simple reasons: developers have to eat, and other commercial projects are tapping into the finite resources of the developer ecosystem and leaving important free and open source projects short-handed.

Here's an example that popped up today: The GNOME Project has just delayed GNOME 3.0 to March 2011. The press release would like us to believe that it's because they would like to take the time to get it right:

"The extra time will be used to improve performance for GNOME Accessibility support, GNOME Shell, and documentation for GNOME 3.0. GNOME 2.32 will still have a number of interesting new features such as color management and UPnP support as well as the usual performance enhancements and bug fixes that have marked GNOME's timed releases for years."

I can appreciate that, but I also cannot help but wonder if the release would not be delayed if there were more funding for dedicated developers in the project. This really worries me, because as time goes on, desktop Linux could find itself less relevant in the face of competition from other platforms, like mobile. That's not just competition at the user level, it's at the developer level, too.

Android is a real draw for Linux developers because said developers can build an application and have a real chance of getting paid. The fact that they get to work on a more open system than Apple's is just icing on the cake. It is far more difficult to build an application for desktop Linux and expect financial rewards.

Am I arguing that only commercial open source projects can be successful? No. Clearly Oracle's (and Sun Microsystems before it) handling of OpenOffice.org can highlight what happens when commercial interests completely short-circuit a perfectly good open source project. Other companies have been known to put their interests before those of the overall project, too.

What I would like to see is the presence of at least some funding in the developer/project ecosystem, which can help focus a project, generate interest, and build resources faster. Yes, non-commercial open source projects can do this, too, but such gems are few and far between.

One way to inject some funding into open source (and free software) is to use the Flattr social micropayment system, as suggested by Debian developer Raphaël Hertzog. This is a great non-partisan method to financially support projects.

Is open core the be-all-end-all? Nope. I, among others, see limitations in it. But as long as no licenses are violated, it deserves no less of a chance to work than any other commercial open source business model.

Until something better comes along.

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Answers - Powered by ITworld

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Ask a Question
randomness