Much has been said about open core, but with the OSI coming out squarely against it on the one hand, and Rackspace and NASA creating the OpenStack.org project as a "true open source replacement" for Eucalyptus on the other hand, it seems open core is now much less attractive than it was only a week ago. It seems everyone has now learned what open core is and agrees that it is not open source, nor is it good for open source. (And by "everyone" I mean everyone that really are open source advocates, naturally those who directly or indirectly are trying to profit from open core will continue to promote the model for a long time to come.)

The final question that remains to be answered is, if I know about open core and don't like it, what can I do to help prevent its spreading and rather promote the adoption of true open source?

With my personal experience working for MySQL, I've had a few years to collect some ideas, and would like to share them below. Please add your own in the comments and I'll keep updating this post so it can remain a useful reference.

(Last updated Aug 29, 2010.)

Sending a message in a language they understand

As a general rule, it is important to realize that the managers who run open core companies don't work in the same universe as the average open source blogger (like myself) does. For instance, that SugarCRM get's criticism for being closed source on Slashdot is of course helpful, but let's face it: has anyone ever changed their business strategy based on some rants on Slashdot? Ok, so MySQL actually had to backtrack on its plans to further close source backup modules, because Sun (in its desperation, more than anything else) was sensitive to such criticism, but MySQL's managers themselves would not have cared, they were used to being bashed by a small group of PostgreSQL fanboys anyway each time MySQL was mentioned on the site.

And that's what you have to remember when talking about open core. The business managers practicing open core will not care to educate themselves about values of the open source community, Open Source Definition, Building a vibrant community or any of the things we in the open source community have learned to value. To them, such arguments are just one word against another, indistinguishable from the teenager who has to mention "PostgreSQL" as a reflex every time someone mentions "MySQL". Who's to say what's right or wrong, there are so many opinions...?

Business people also will typically think that everyone in the end is looking after their own interests (this is actually a cornerstone of free market capitalism and supposedly a good thing), so for instance this blog I'm writing would not so much be motivated by my interest in defending open source in general, but is clearly just because I work for a company that is 100% open source and competes against an open core vendor, so of course I'm trying to spread "FUD" about open core (they would say).

Ultimately, the business managers care about making money. If they think that they can sell their wares to paying customers, they will not care how much you hate them for it. (This is no different than any other proprietary software company like Microsoft or Oracle - it seems only Apple has learned the secret how to make people give you money and then also love you for all the lock-in you give them!)

Therefore, if you want to do something against open core, make sure your message is targeted against the business motivations, not just "preaching to the converted". So here we go:

What everyone can do

Educate yourself about open core, what it is and what it isn't. Then educate others.

This blog from Matthew Aslett explains what open core is and distinguishes it from other common ways to work with open source. My blog goes into more detail on which open core aspects in particular are deceitful and constitute an attack on open source:

• What is Open Core Licensing (and what isn’t)
• So if I don't call myself 'open source vendor', then everything is fine? (yes)

These 2 blogs from the Open Source Initiative are good in being short and to the point about what is wrong with open core:

• A simple declaration about "Open Core"
• Why Open Core has a problem and is not a problem

You can also read more posts from this site and their links to other bloggers for more history, background and countering arguments that open core proponents actually make.

• Open core is not open source
• Open core is not open source and don't trust someone trying to convice you otherwise
• What others say about open core

After this home work, other things to do include:

• Continue to educate others in blogs, online forums, conferences, user groups. Focus on the basic facts that open core software is closed source, an attempt at lock-in, an attempt at diluting the open source brand and doesn't result in a healthy and strong community. Subjective arguments about "crippleware" or "usefulness" only play into the hand of the open core proponents (they think their software is useful and not crippled).
• Most importantly, educate people at your work and other companies, especially those that choose and buy software. Make sure they are aware of alternatives (either alternative open source projects, or alternative vendors for the same software).
• Learn how to identify open core vendors, since they are not always very open about their closed source software. Some will just give you a lecture on how open they are (but not open source) even when confronted with awkward facts. In other words, you cannot trust them, you have to dig the facts up yourself.
• I'm sure there is room for much more advocacy, for instance maybe someone could start a wiki where we could collect and expose open core vendors, explain what the problem is, and instead promote "truly open" alternatives. (If you have time and energy to do this, contact me.)

What users and buyers of software can do

Avoid open core software

This is a no-brainer, but how to avoid open core software will actually vary from case to case. For instance, if you need an open source database, you could use PostgreSQL instead of MySQL. However, in my experience, almost all enterprise businesses would be reluctant to consider adopting Postgres, but they are interested in adopting MySQL, since commercial support is much easier to find. In such a case - especially since "truly open" forks of MySQL exist - you are probably better off sticking with the MySQL base, and then buying support from an independent vendor and looking for open alternatives to replace the closed software like monitoring tools. (...and there are reasonably good open source monitoring tools available).

In other cases, like OpenStack vs Eucalyptus, it seems clear OpenStack has strong momentum and we should do all we can to promote it in favor of closed alternatives.

Target the sales and business managers

This is perhaps the most important point of all.

The open core vendors care most about what their paying customers think (and this is how it should be). If you are not a customer and unlikely to become one, they will not listen to you much. From their point of view you are just one of those freeloaders that wants to get their valuable software without paying (which is not true, but they don't understand open source).

There are many things you could do to "send a message" to these vendors. You should target your account manager in the sales organization, since this is the part of a company responsible for reporting on what customers think and where the demand is. (If you have an opportunity, you can of course also target product management or the executive level with similar messages.) If you are the buyer in your organization, you know that you have an account manager who is your contact person at the vendor. If you are one of the architects making the choice of what software to use, you are typically not in direct contact with the account manager, but you can still influence the process to make sure the following things happen.

The overall theme of the below points is that the open core vendor as an organization should receive feedback that we in the open source community don't like their closed source strategy, and this feedback should accumulate into hopefully significant statistics.

• If you are already a customer to an open core vendor:
  Contact the vendor and let them know you have just realized that part of the software included in the subscription is in fact closed source. Explain to them that you always prefer to work with (fully) open source software if possible. You could use any of the reasons commonly used to prefer open source, but a good idea may be to invent some specific need of a feature that is lacking from their closed source software, and complain that this would be easy to fix if it only were open source. Ask the vendor if they could help you find a fully open solution instead. To emphasize the message, you could say that you really like the support or service they are providing and you would love to continue being their customer, but if they are unable to solve your needs with fully open source software, you will be forced to look for alternatives.
• In addition to the above:
  Since the vendor will refuse to help you find a fully open source solution (that would be a competitor to itself), ask if they could offer you only the support service without the closed source software with a 50-70% discount. (They will most often refuse, but to be confident with this demand, you do of course have to be prepared to stop using the closed source software if you actually get what you want.)
• When your vendor is accused (on Slashdot) for going closed source:
  Contact your account manager and ask him to explain himself. Make sure he understands you prefer open source software and are concerned about this news.
• If you are not currently a customer of an open core vendor, but are considering or could potentially be one:
  Make sure an open core alternative is included in your bidding round! Even if it is a good practice to simply avoid these vendors completely, an even better one is to fisrt make sure they know you are spending money, and then let them know they didn't get it. So include them in your Request For Proposals even if you don't intend to choose that vendor. When they offer their closed source Enterprise version, return their proposal saying that you had contacted them to provide an open source alternative, but you now realize they are offering a closed source solution and ask them to resubmit their proposal with only open source software offered. (As above, when they refuse, then ask them to remove the closed source software and give a discount instead...)
• A variation of the above, esp if you are a large customer:
  Contact an open core vendor and say that you have a budget available for buying support for open source software, and you would have considered them, but you now realize their Enterprise offering is closed source. Ask them if they are a) willing to deliver their Enterprise version under OSI certified open source license and you'd be happy to pay for it then, or b) if they are willing to find or develop an alternative (fully) open source solution you'd be happy to use the budget for that instead (as a consulting service). Finally, when they refuse, say that you will then spend the budget on a 3rd party that can deliver an open source alternative.
• If you end up using closed source software:
  If you use or end up choosing a closed source alternative anyway (like Oracle or Microsoft for databases), you could still give feedback to the open core vendor that you were interested in their open source alternative, but since they were not really open source, you compared them on equal terms with other closed source alternatives and didn't choose them, but you would have re-considered if there had been a good truly open source alternative.
• If you are not planning to buy any kind of support, but are using the for-free version (Community Edition):
  Even if you are not planning to actually spend money on any kind of support subscription, but you are using the free version provided by an open source vendor (often known as "Community Edition"), then you can still be in touch with the company to inquire about their commercial offerings. As a user of their free version, you belong to the target group to whom they would like to sell their closed source stuff. Then, when you are presented with an offer, you can say that even if you weren't sure about buying support to begin with, now that you see they are offering you closed source software, you can say for certain that you will never accept such an offer.
• Tip: Many open core vendors use their website(s) to find leads. If you register at their site and participate in forums, read whitepapers, tutorials, webinars and anything else they offer, you may get contacted by the vendor, which could be preferable to you contacting them.

What developers can do

Be critical of copyright assignments

Copyright assignments are not against open source per se. The Free Software Foundation takes assignments to projects it governs. An example of a good reason to take copyright assignments would be the ability to change to another open source license if need be (such as to increase compatibility with other open source software or react to new licenses). There are some vendor centric open source business models, which are perhaps not popular in the community, but still valid open source models (dual licensing is a good example) which need to use copyright assignments to work.

Even so, it is the fact that a vendor owns all the rights that allows him to become an open core company, even if he isn't one today. (For instance, this happened with MySQL, that always required copyright assignments to enable the dual licensing model, and then started adding closed source software into the Enterprise package in 2006.) Also, even a good vendor can be acquired by a proprietary software company (Sun by Oracle, say). It is probably a good idea to be very critical about copyright assignments so that code developed by you isn't inadvertently used to develop and sell proprietary software against your wishes.

Contribute to fully open source alternatives

If you are looking for an open source project to contribute to, one important option would be to contribute to projects that are truly open source alternatives to open core brands.

As above when choosing what software to use, the choice on what is the best alternative to the open core product will vary case by case. It may be a completely separate project (OpenStack instead of Eucalyptus) or it may be a fork of the same codebase (MariaDB for MySQL or vTiger for SugarCRM).

Finally, if there is no obvious alternative available, you might consider creating such a fork yourself. This will require energy and dedication from you - and persistence to stand up against the well funded marketing team of the open core vendor you are going head to head against - but it is a good way to fight against open core.

If working on a fork, an obvious route to go is to replace the vendor's closed source offerings with open source alternatives.

Prefer fully open source alternatives in adjacent projects

If you are a developer of some other open source project - especially the very popular ones - you should make sure you focus on supporting well the fully open source alternatives, and possibly focus less on supporting the open core products, since this will help the open core vendor with his ultimate intent to sell his closed source software. (Of course, many open source projects wish to be compatible with closed source software too, and open core is no different in this regard.)

As examples, one could expect Linux distributions to start supporting OpenStack as their primary cloud software, instead of the open core Eucalyptus. Programming languages and frameworks that use a database, could make sure they support alternatives to MySQL and that this is well documented so their users easily find these alternatives.

If you work in an open core company

Many open source enthusiasts end up working for an open core company in good faith, only to then find out they are now producing and/or promoting and selling closed source software. (This was also my personal experience with MySQL. When I joined, I had not realized the subscription was all about selling proprietary addon software, I was naive and thought it was a Red Hat like support subscription only including 100% open source software.)

To give advice to these people is difficult, since most acts could be seen as sabotaging your own company. From personal experience I can tell that in MySQL there was always a strong camp of open source supporters, and this group participated actively, even encouraged, the outcry about closed source backup modules. Some developers also made clear they will only develop software that is licensed under an open source license. It is rumored some early developers had a clause in their contract that guaranteed them such a right.

The founder of the Drizzle project, Brian Aker, used the opportunity given by Sun to fork MySQL into a more community oriented development project. This was not directly linked to the open core business model of MySQL, but solving that problem clearly was part of the motivation. However, in most open core vendors such an opportunity will of course never present itself again.

If it is not widely known that your employer is in fact an open core company, writing about that in your blog or otherwise in public may be helpful, and not strictly speaking against your employer, since you are only reporting on your company's strategy, which you assume the company has chosen as something they believe in, not something that needs to be company confidential.

If you have something to say that you cannot say in public with your own name, you can still pass the information to a 3rd party (I'm happy to help out). There are also tools like WikiLeaks which could be used to leak documents, for instance if you have emails or memo's where it is clear that your executives knowingly engage in deceiving the open source community. (...which in my experience is not usually the case, usually they are rather ignorant.)

Added Aug 29, 2010:

Sometime in 2007 MySQL employee Jan Kneschke wrote and published an interesting little tool known as MySQL Proxy. When hearing about this, MySQL management ordered that the code be un-published so that they could decide whether it should be an open source tool or kept closed source. In reaction to this, Patrick Galbraith published his own proxy that could do similar things. Thanks to this, MySQL management reverted its decision and Jan Kneshckes original MySQL Proxy became open source. (However, after a while, most or all developer resources were still directed to develop a close source branch used for MySQL Query Analyzer.) Lesson learned: You can compete with open core by writing open source duplicates of closed source functionality.

Another person suggested that developers of open core companies may want to ask a friend to publish something they have written as open source. Usually if the initial publication of some code is open source, your employer will allow you to contribute to it. So you can ask your friend to publish some simple skeleton as GPL, and then you can build on top of that. (In this circumstance the GPL is a great license to use.)

Note that if you write that simple skeleton yourself and then ask your friend to publish it in his name, you may get in trouble with your employer. (But I know of such cases, some people are really committed to open source so it does happen.)