Slashdot Mirror
Ask Slashdot: Building an Open Source Community For a Proprietary Software Product?
An anonymous reader writes: I run a company that develops scientific computing software. Our core product is a traditional proprietary application — we develop the software and deliver the "binaries" to our customers. We're considering changing our deployment to include all of the source code and giving our customers some additional rights to explore and extend it. The codebase is HTML/JavaScript/Python/SQL, so a lot of the code is available in some form already, albeit minified or byte compiled.
Because we are in a scientific domain, most of our customers use Open Source software alongside our product. We also maintain Open Source projects and directly support others. We're strong supporters of Open Source and understand the value of having access to the source code.
We also support a free (as in beer) version of the software with a smaller feature set (production and enterprise elements that individual users don't need are removed). We'd like that version to use the same model as well to give users that don't need the full commercial version the ability to extend the software and submit patches back to us for inclusion in future releases.
Overall, we'd really like to find a model that allows our core product to work more like an Open Source product while maintaining control over the distribution rights. We'd like to foster a community around the product but still generate revenue to fund it. In our space, the "give the product away but pay for support" model has never really worked. The market is too small and, importantly, most customers understand our value proposition and have no problem with our annual license model.
We've looked at traditional dual licensing approaches, but don't think they're really right fit, either. A single license that gives users access to the code but limits the ability to redistribute the code and distribute patches to the "core" is what we'd prefer. My questions for the Slashdot community: Does anyone have direct experience with models like this? Are there existing licenses that we should look at? What companies have succeeded doing this? Who has failed?
Because we are in a scientific domain, most of our customers use Open Source software alongside our product. We also maintain Open Source projects and directly support others. We're strong supporters of Open Source and understand the value of having access to the source code.
We also support a free (as in beer) version of the software with a smaller feature set (production and enterprise elements that individual users don't need are removed). We'd like that version to use the same model as well to give users that don't need the full commercial version the ability to extend the software and submit patches back to us for inclusion in future releases.
Overall, we'd really like to find a model that allows our core product to work more like an Open Source product while maintaining control over the distribution rights. We'd like to foster a community around the product but still generate revenue to fund it. In our space, the "give the product away but pay for support" model has never really worked. The market is too small and, importantly, most customers understand our value proposition and have no problem with our annual license model.
We've looked at traditional dual licensing approaches, but don't think they're really right fit, either. A single license that gives users access to the code but limits the ability to redistribute the code and distribute patches to the "core" is what we'd prefer. My questions for the Slashdot community: Does anyone have direct experience with models like this? Are there existing licenses that we should look at? What companies have succeeded doing this? Who has failed?
We want employees that work for free!
That way you can give your users the ability to extend your product to their needs without risking killing off your revenue stream.
Which begs the question where is your revenue currently coming from ?
1. Product Sales
2. Training
3. Maintenance/support
If it isn't 2 or 3 you may be killing yourself off. Especially if your product is user friendly and needs little in the way of support.
Yeah, you seem to want to have your cake and eat it too. Doesn't produce a lot of sympathy. Think again about how to make your software free but still want users to pay. What about keeping value-adding plugins or frontends closed and opening the core? If you open source but limit ability of people to make use of the core, what exactly do you expect to gain from such a "community"?
Still, take a look at the licence of qmail. This worked not so bad for them, and might be the right equilibrium. If you just want legalese for your scenario, take a look at Microsoft's Shared Source licences.
It's not the fall that kills you. It's the sudden stop at the end. -Douglas Adams
The incentive for people to contribute to a closed source project isn't all that much. Remember that open source isn't a gift by your company to the public, it is an offer of trade -- you let the public have the source, the public provides you with feedback (bug fixes, enhancements, etc.) and gets its suggestions provided back to it. It's a circle.
You are confusing proprietary with closed, its not closed if you have the source and sometimes the source is available for proprietary code. Consider libraries with binary-only and binary-plus-source licenses. In the later case I've had the source, complete rights to modify and redistribute my modification just like the vendor supplied binary. There was a community and a circle of benefits. Licensees provided fixes to the vendor, the vendor incorporated fixes in the main source, the main source was available to binary-plus-source licensees. It was very much like an open source community. We had the source, the right to modify and use it, our future was in our hands despite the proprietary nature of the library. Its a model that has worked.
What this particular vendor is suggesting seems similar to the binary-plus-source model, the main difference being no charge for the source option. History suggests this can work, it worked when the source option cost extra.