Ask Slashdot: Building an Open Source Community For a Proprietary Software Product? 85
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?
Re: (Score:2)
Unless the API is very low level, and a lot of black box between API and end user application needs to be filled in by the community. And perhaps that black box might be more than one black box, for various industries. It sounds like they don't want to write those black boxes (maybe don't even understand them) and what customers to write open source implementations around their API. OpenGL is a nice API that's apparently way too low level for say, many game development companies to directly target, and most
Re: (Score:3)
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.
Re: Don't bother (Score:1)
This!
From a true scientist's point of view, full open source is critical. I avoid closed source to the very bitter end because I know that there's always another error/mistake to be found and that's less likely to found in closed source.
(Then there's a bunch of folks who just want to be first and get another manuscript accepted and who care zero about reproducibility and sustainable science.)
Translation (Score:5, Informative)
We want employees that work for free!
qmail and Microsoft (Score:5, Informative)
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.
Re:qmail and Microsoft (Score:5, Interesting)
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
Re: (Score:2)
Re: (Score:3)
Thing is, given that Python and R have set the bar to F/OSS effectively (at least for the "core" that's necessary to run things, if not the associated tooling), anything less than that will quite rightly be seen as deficient. Whether they have something else to offer that could compensate is another question, but from my experience talking to people in that community, it's a fairly major point that I doubt they can easily compensate for.
Re: (Score:2)
Actually it is like a model proven to work ... (Score:5, Insightful)
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.
Re: (Score:2)
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's so important to get the source when a company gives you a binary blob. There will be bugs in the code, and even if they aren't, the documentation is unlikely to be really high quality. In my experience, if you get a binary blob without getting the source, you should add several months to your estimate.
Because it will take longer.
Re: (Score:3)
That's unfair, I use a lot of software that I pay for but want to make peripheral changes to. For instance I use a compute job scheduler that costs about $180 per compute node + maintenance. It's worth the price for the existing features, but I also want to implement esoteric features that maybe nobody else needs but will help it work better with our workflow so I have forked a number of the built in options. The company even has a github repository of the latest release so that you can get performance a
Re: (Score:3)
Interesting, some great examples in these followups, thanks! But why not mention the concrete products?
Re: (Score:3)
The reason there are open source communities is because by making the source open, it belongs to everybody in the community. This is not so with "shared" source (aka Microsoft's "look but don't share" approach). Merely publishing source code doesn't make it open. Open means I can change it, and I can republish
Re: (Score:2)
The reason there are open source communities is because by making the source open, it belongs to everybody in the community. This is not so with "shared" source (aka Microsoft's "look but don't share" approach).
And note how this has largely failed for Microsoft. Very few people actually bothered to do anything with those "shared source" projects, and there was no community to speak of as a consequence (and as you rightly note, it's a misnomer anyway). I don't think there are still any MS projects shipping under any of these licenses anymore; pretty much everything is either AL 2.0 or MIT now, including things like CLR that used to be "shared source".
Re: (Score:2)
Cake! (Score:2)
"The cake is a lie."
Re: (Score:3)
Exactly right.
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.
What you are suggesting sounds like you want the benefit of that deal, while negating the benefit for those who are doing work for you. Psycholog
Re: (Score:2)
Sounds more like they have a proprietary product with a (good? maybe?) API, and they'd like to get the folks that write to the API to have their own community going. The marketing droids they hired have noticed this, and want to use the "We have tens|hundreds|thousands of community users working on add-ons that you can get to make our product even better!" sales pitch.
The fact that their product is written in a (mostly) interpreted language and remains human readable means everyone with a copy has (most of
Its not closed if you have the source ... (Score:5, Informative)
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.
Re:Translation (Score:4, Interesting)
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.
Wrong title then (Score:3)
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.
Re: (Score:2)
We want employees that work for free!
Actually they want 100% the opposite. They want revenue so they can continue to pay employees. If they had employees that would work for free they could just open source the product and stop worrying about revenue. The problem is, in most software companies if you allow your revenue to drop to zero your employees will likely leave when the paychecks start bouncing.
I'm a huge proponent of Open Source, but if you're an existing company contemplating open sourcing your existing code base you'd better have a cl
Have you considered APIs or Plug ins ? (Score:5, Informative)
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.
Re: (Score:2)
5. Profit!
Re: Stop thinking like a greedy Republican... (Score:1)
I don't think anyone is in a rush to welcome our "All your free labor belongs to us" wanna be overlords.
Yeah, no. (Score:1)
The old MySQL did this (Score:2)
MySQL used to have a forkable (thank [diety]) open source code with a special commercial license if you wanted to embed the code in your application. Seemed to work for them pre-Oracle.
Have your cake and eat it too? (Score:3)
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.
I don't think you want an OSI license. (Score:4, Interesting)
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 [creativecommons.org]
(CC BY-NC-ND) or Attribution-NoDerivs [creativecommons.org]
(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 [opensource.org] 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.
Re: (Score:2)
Creative commons licenses don't fit their preferred use case, because it allows redistribution:
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.
More generally, creative commons licenses aren't an appropriate fit to software. They're designed with creative works in mind and protect the expression of a work, rather than the way in which that expression is created.
Re: (Score:1)
real desire. It's totally possible to have a proprietary license with source provided to the customer.
That's still open source. Contrary to what Stallman and the libretards have tried to do and usurp the wording, open source doesn't mean giving it away for free. It means the source is available, maybe even at an additional cost.
It's only GPL fanboys that think OSS implies free. OSS software predates Stallman and FSF, GNU and GPL, he didn't come up with the idea ... He just tried to usurp it and twist it to his own narrow definition based on his viral agenda.
Re: (Score:2)
No. Just no. Providing the source TO THE CUSTOMER does not make it open source. Allowing the customer TO DISTRIBUTE THE CODE AND THEIR CHANGES makes it open source.
Reciprocal Public License (Score:2)
As much as I find it distasteful to recommend a license that is Open Source but NOT Free Software, you may want to check out the Reciprocal Public License: http://opensource.org/licenses... [opensource.org]
It basically says that anyone who makes any changes to the software, whether they're "just internal" or distributed to a third party, must share those changes back to the community.
It would allow your company to release your software under Copyleft terms similar to the GPL, but with an added *restriction* that prevents co
It doesn't work. (Score:1)
Examples are MySQL. The result is a fully proprietary product nobody wants to use or contribute to.
QT is another. QT is now GPL and receives a lot of development. During the dual licence era GTK was was created to counter the proprietary QT.
You are either open source or you aren't. The "inbetween" doesn't promote a long term existence as developers learn their code is being stolen from them, and with little to no recompense.
The advantage of GPL and LGPL is that no one can make it private. Any development, a
Re: (Score:1)
The advantage of GPL and LGPL is that no one can make it private. Any development, any distribution, mus also provide the source - thus you benefit from anyone improvements by anyone else.
The "Any development" part is not true. Only redistributed copies. And even then, under LGPL only direct modifications -- wrappers/extensions don't apply.
Re: (Score:2)
Just to correct the above, Qt is not LGPL. GPL was a solution to the KDE problem. GTK was created while Qt had a non-commercial license. The problem was with KDE that the combination of KDE & Qt created a derived product which Debian Legal believed was illegal for anyone other than KDE to distribute i.e. no redistribution. The GPL license for Qt solved the problem with KDE but didn't solve the problem that KDE desktop couldn't support non-GPL software without Trolltech getting a cut.
Re: (Score:2)
You are many years out of date. Not remotely true anymore.
Re: (Score:2)
The first sentence should read "Qt is not GPL it is LGPL".
This isn't Open Source, then (Score:4, Interesting)
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 [microsoft.com] 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 [opensource.org], clauses 1 and 3; the Copyfree Standard Definition [copyfree.org], clauses 1 and 3; and the Free Software Definition [gnu.org], 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.
Re: (Score:2)
You are confusing open with free. There are many open source licenses not "approved" by the FSF.
I'm highlighting a point on which the FSF, OSI and CFI are in agreement: the significance of the right to fork a project.
Shared Source License (Score:4, Interesting)
What you're describing is what Microsoft calls "Shared Source [wikipedia.org]." 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.
Re: (Score:2)
Microsoft "shared source" licenses were actually more restrictive than that, as they had only allowed read-only access to the code, even for private and personal use without redistribution - i.e. fixing a bug and building your own version would already be a violation of the license.
If that is really what is meant by "accessing the source code" by the article submitter, then this is the way to go. You can just use MS-RSL [microsoft.com] verbatim for that. Just, please, don't call it "open source". Even Microsoft, back in th
Contribution Bounties and other thoughts (Score:2)
One thing you could do is write up a custom license and have contribution bounties.
The license would go something like this:
- Only "Your Company" can sell either the code (any part of it), any derived works based on the code, or the binaries.
- Any party who pays for a license for the "Ultimate Plan" (or whatever you want to call it) gets a copy of the source code.
- Any party that does not have an "Ultimate Plan" does NOT get the source code, and MAY NOT distribute any binaries they g
Re: (Score:2)
They don't want this. They might want anyone with the source code to be able to distribute binaries to other license holders who may not redistribute at all.
The way we do it (Score:5, Interesting)
I led the team that created the MOOSE Framework ( http://www.mooseframework.org/ [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...
Talk to your customers ... (Score:2)
Explain what you are trying to accomplish, and ask your customers for their thoughts since they know what their needs are.
Asking Slashdot, or anyone from the open source world, for their thoughts won't get you far. Their motivations are different from your company's. At a bare minimum, they are unlikely to agree with your licensing policies because they usually want more freedoms than your company's willing to grant. It is also probable that their thoughts won't reflect those of your customers. There is
Sounds like Unreal Engine (Score:2)
The whole source code is available on GitHub once you sign up. You can share improvements with Epic or other licensees of the engine, but nobody else. Though I guess you'll have to replace the "if you make money you owe us royalties" bit, since science doesn't usually make money with something suited to who you want to pay. Just don't pretend it's open source, because it's definitively not.
No open source (Score:2)
As I read the requirements, I have the feeling open source is not the within the goals.
It is more like an early Unix source license, where the ones that pay have access to the source, can modify it, and exchange with other licensees
Learn from successful people (Score:1)
It's been years since I posted to /. and I can't be bothered to figure out how to log in, so possibly you will never see this. However, in the slim chance that you do, I will trot out the same advice I give everybody who asks this question :-) Read:
http://www.oreilly.com/openbook/opensources/book/tiemans.html
It is short and will describe a business model based on Free Software that is known to be successful. They started with $6K and what the article doesn't explain (because he wrote it before it happene
Ingres (Score:2)
It might be worth looking at INGRES (not INGRESS) and their business history.
They've managed to stay in business as long as Unix has had commercial databases (albeit with a close call every decade or so) and currently are in a similar position to yours but are still standing and still innovating. Many lessons in tech company survival, some of them of the "don't do that" variety to be learned there.
Sadly, the people that know the name tend to think of Ingres as what it was way back in the 70's-80's, not what
Dual license GPL (Score:2)
If you want to charge then pretty much you want no redistribution. That's the default for copyright. By opening source you are just allowing people to create their own derived works. Of course if a license makes a derived work and wishes to assign you copyright they can and you just create a process for this.
The comments about your goals being close to the late early 1970s and earlier licenses are correct. That's what you are aiming for. Those licenses worked well from people who were mainly selling ha
Re: (Score:1)
If you get software and don't pay for it, guess what- it's free. To you.
You'll most likely die anyway (Score:2)
The problem with selling closed source to the scientific community is that there are already open source alternatives to your product, regardless of your market, because generally it's easier for a scientist to program something as part of their job (they generally have a lot of time and are highly motivated) than procure something that costs $10k+ (because then you'll need grants or other sources of income etc).
You may have a customer base for a while until the open source stuff settles out the bugs and us
Re: (Score:2)
I personally would throw open the entire codebase and monetize your product as a service.
The problem is that it's already a crowded market. And furthermore, Amazon, Google and Microsoft have all discovered it, and now want their slice - and they all already have solid cloud compute platforms to use as a backend; so it's going to get even more crowded in short order.
(Full disclosure: I'm on the MS team that is working on the Azure IPython/Jupyter notebook service [technet.com] that just went live on PyData, which is one piece of that.)
Allow redistribution, Charge to run, Reward forks (Score:2)
SuperMongo (Score:1)
SuperMongo (SM) [mcmaster.ca] has been doing something similar for many years, check their website.
Kill it with fire (Score:2)
You lost me at "HTML/JavaScript/Python/SQL". The only right thing you did there was Python.