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?
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.
My guess is that this is more like a Matlab style system, where users can create and share content and build a community that way. Having worked for a time at one of Matlab's competitors, I remember more transparency into the engine was something our users wanted and is one of the reason's R/Python have taken off (in addition to the fact that they're free). Every now and then there was something a customer wanted to do and contribute back to the engine, but we didn't have a mechanism for it.
In this case, I suspect the poster is looking for a way to find that level of transparency, but still do maintain control over core development without the chance of forks. It also gives the users a path if the company goes out of business without having to execute one-off escrow agreements with each customer.
I see people all the time on /. complaining that proprietary software is bad because they can't see the code. The poster here seems to be trying to find a way to address many of the issues about transparency while still controlling re-distribution. With a free version, it sounds like everyone can use it, but changes to the core can't be propagated without going through the company.
Full disclosure: I saw this post in the firehose and modded it up since we're wrestling with similar issues right now. I'd love to see more models evolve that take the best of both proprietary and open source methods. Hopefully this discussion will yield some interesting ideas beyond the typical fanboy banter. :)
-Chris
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...
We want employees that work for free!
No, what he wants is to allow paying users the ability to have a lot of the benefits of open source, while not reducing the company's downstream cashflow. It might come as a surprise to you, but not every project can be open sourced and still make money. In fact, I always wondered about the pay-for-support model - why should I make my software easy to use and maintain (eve at large-scales) if my main source of income requires users to come and pay me to help with the product?
Also, this is a scientific computing software - the target market is small as it is. Very likely the core is something that is highly mathematical, and not something the average programmer can work on. I wouldn't be surprised if there were several statisticians and researchers on the payroll. People like these don't necessarily write high quality code - see the R library for example (yes, there are many excellent packages, but a huge number are written sloppily by academics). The customers who use it might need highly specific tweaks for their application - something they can only do with the source. I myself would have loved to "fix" some of Matlab's functions for my specific use case. But if the customers don't have the source, there isn't much they can do.
This type of license should actually become the norm - but it is unlikely to happen. There is always the risk that a customer who bought software might give a copy of the source to their friend, and before long I lost all control of the product. While binaries are still copied today, companies are trying to crack down on it through registration and DRM. If the source is out, there is even less they can do to stop it.