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
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.
Explain to me how this isn't a fairly transparent effort to recruit developers to contribute for private gain without having to pay anyone for their work.
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.
So why the need for open source? What does the community get out of it? If you want to go open source then do it but it sounds like you don't. It sounds like you want the advantages of open source without having to reciprocate with the community fully.
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.
I have trouble imagining why any developer would want get involved with an arrangement like that. Being able to see the code is pointless unless you can distribute it yourself without unreasonable restrictions. Sounds to me like you want to have your cake and eat it too.
This doesn't sound like open source is your real desire. It's totally possible to have a proprietary license with source provided to the customer.
You could gain some mindshare by using one of the more restrictive Creative Commons licenses, like Attribution-NonCommercial-NoDerivs
(CC BY-NC-ND) or Attribution-NoDerivs
(CC BY-ND).
You could use something very similar to the pre-2007 qmail license. It allows people to download and use it. They can make any changes locally. They can redistribute the pristine sources or binaries made from them to others. They can't distribute their alterations. They can distribute patches against the pristine sources, but they can't call those part of the product.
The OSI has a whole list of licenses. I'd bet not one of these meets your requirements. You really shouldn't be saying it's "open source" unless you're using an OSI-approved license.
Software licensing is a legal issue. The people you really want to be talking to about what license language meets your exact needs in light of the laws where you operate are lawyers. More specifically, you want probably want people versed in both copyright and contract law to look into this.
I'll try to buck the trend here by skipping the derision and offering constructive advice. ;-)
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.
In this case, the closest match I can come up with off the top of my head is to apply the Microsoft Reference Source License to the source code.
This is not a Free/Libre or Open source license, because the constraints you are looking for are in direct conflict with the Open Source Definition, clauses 1 and 3; the Copyfree Standard Definition, clauses 1 and 3; and the Free Software Definition, freedoms 2 and 3.
Do you expect that if you were to permit redistribution of the core and modifications to it that others in the community would completely take over the project and continue its development without your business's involvement (a 'fork', in development jargon)? That would be the primary reason I can think of for such a restriction.
...when you're writing a game...tweak the difficulty of "Easy" to something [your mother] can cope with. -- onion2k
What you're describing is what Microsoft calls "Shared Source." You want your customers to have access to your source code for their benefit, but you don't want them distributing either source or binary to anyone else.
When you think about it, providing the source code to your customers without the right to share it with others is little different from what you're already doing - providing binaries without the right to share them. You're still asserting your copyright - you would just be providing a bit more copyrighted material.
If you want to create a community around your product's source code, you have to figure out a way for your customers to have the freedom to discuss the code on forums, mailing lists, etc., without your code escaping to the world at large. You could explicitly allow customers to discuss the code on YOUR forum, which they only get access to by being a customer.
If you agree that forums suck, then give your customers access to a private github or gitlab with your source code in it. They could make issues and merge requests, and thereby communicate with each other and with you about the code. Let them make branches, but don't let them touch your branches.
I suggest not providing source to your free (as in beer) users. Make access to the source one of the perks of being a paying customer.
I led the team that created the MOOSE Framework ( http://www.mooseframework.org/ ) an open source computational science package.
We decided to open source the framework (MOOSE)... and build proprietary (and many open source... depending on the line of funding) computational science apps on top of it. For that reason MOOSE (and everything that surrounds it) uses an LGPL license.
This has allowed us to grow a large community of people all working together to solve coupled systems of PDEs... while also allowing us to have a line of funding in the future (licensing some of our applications).
So... you may want to open source the core components... then use the core components to develop proprietary capabilities that you then sell.
Just an option...
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"?
It seems not so much making the software free but making it open to customers. It seems reminiscent of various source licenses I had for various past projects. The vendor offered binary-only and binary-plus-source licenses, fortunately I was able to get management to go for the later. Having the source meant our future was in our hands. I did fix some bugs that we ran in to. One was extremely technical and took a few days to find and fix, reproducibility was extremely low. It was dependent on random memory containing a value that when loaded into an x86 segment register passed verification but led to later permissions violations. It was not something the developers or other customers were running in to, we just got lucky with that random value. For everyone else the random value was failing verification and the erring code path was never executed.
My fixes and the fixes of other customers were incorporated into the vendor's source. We all benefited from the community effort. We had the source and the right to rebuild and link binaries into our projects and redistribute. If we cared to we could have customized things. In practice it was very much like open source efforts for us. Such models work, proprietary with rights to source works.
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.
The goal as I see it is not to build an OPEN SOURCE community but to build a large end USER community around the project. An open-source community would want, by most implied meanings of the term, the ability to modify the product and to share the changes. Of course, strictly speaking, open source is simply allowing others to view the source code. But that's the peep show definition, useful only to software voyeurs not developers/modders.
For the scientific community, this has actually been more important recently as people want to be able to reproduce other people's experiments. Which is part of the reason why why F/OSS tools like scipy and IPython/Jupyter have been growing very fast.