- Hyperic has a feature that the open source community would like;
- They have that feature in the commercial version;
- It would be stupid for them to take that feature and make it part of the Open Source version.
Almost at the same time, Zack Urlocker (M7 Alumni In Da Hizzy Yo!) has a new post where he provides the most interesting clue as to why Tarus doesn't fully understand how you can do it right:
Find a way to distinguish between capabilities that businesses want and individual community members may not even care about. For example, Scott Dietzen mentioned e-mail features related to archiving and compliance issues are really only relevant to larger companies. And as he noted, community members will even support the the idea that if you need those features, you should pay.
My Open Source Cookies stream has hit on this before. Just because one firm chose the wrong feature to be part of their cookie doesn't mean that the whole concept is flawed. That's like saying "McDonalds sells disgusting hamburgers; therefore, all hamburgers are rubbish."
Again, to continue my statements on this:
- Pursuing Split Licensing means that you have to be very careful about what you put in the Open Source vs Commercial versions;
- More importantly, it's a case of constant refinement as you discover some features that you thought were commercial only but should be migrated to the Open Source version;
- Targetting features that are only of use to committed commercial users is the key.
It may be that you have a product which is so generic that you can't come up with something that satisfies the Cookie requirement. If it is, you shouldn't be trying Split Licensing at all. Not every business model suits every Open Source project. Choose the right one.