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?
Boy I sure can't wait until scipy and numpy eat your lunch.
Shyeah.
How about you start at the beginning: What do you want that licence to do?
Keep it closed. Charge money for it. Keep and open stable API. End users don't care about source access as long as they can get a API and data in and out of the system.
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
"Ask Slashdot: How Can We Make Our Customers Work For Us For Free?"
Atlassian operates near to open source, and purchasing a license grants access to the sourcecode. Bugs are also tracked publicly. You might check them out as an example.
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.
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.
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...
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 companies (and individuals) from modifying your code to suit their purposes and then not distributing the code to you.
Of course, people are free to violate your license and never tell you; enforcement of the license in the case of non-distribution would be difficult to impossible without unauthorized trespassing on their property to obtain evidence (and then you have fruit of the poisonous tree).
The RPL tries to write into the license what many (most?) developers do anyway: if you're going to make any enhancements, give them back to the "mothership" so they can include them in the main product, thus making the main product better.
You'd have the following situation, thus:
(1) Individuals are so unlikely to be caught that, unless they are very careful and deliberately ethical, they will probably not respect the wishes of the RPL.
(2) Companies are less likely to knowingly violate the license because of the risk of possible damage to their reputation in court, but you may find employees within a company who choose to "risk it" and not inform their management about the risks of not distributing their changes to RPL'ed code. So you'd have a certain group of companies that WOULD contribute back (to comply with the letter of the license), and a certain group that WOULDN'T contribute back (and risk the consequences if it's ever discovered).
Funnily enough, you wind up with a very similar situation with the GNU General Public License or Affero General Public License 3.0, except that:
(1) Not distributing their code is *legal*, unless they distribute binary copies to someone who is considered not to be a member of the organization. So an employee can legally hand his coworker a binary-only copy of your product, but if he gives it to his neighbor or posts it on a mailing list, he would be obligated to include the source code, or at least an offer to provide the source code upon request (possibly with a monetary fee attached to the distribution medium; the fee does not have to be reasonable or cheap).
(2) Some third party who (legally) gets a copy of the binaries from them could go through the process of obtaining the source code, as they'd be entitled to, and they would then be free to hand you a copy for free (or not, as they please). Basically anyone willing to pay the distribution fee / ransom would be able to "liberate" the code by posting it on Github, and that would be 100% legal.
(3) You'd *still* have companies and individuals in both the "not sharing with you" and "sharing with you" camps, except that those who choose *not* to share with you are not necessarily violating the license of the code (unless they give you binaries only, and then cackle maniacally and refuse to hand over the source).
Enforcement concerns make the *expected outcome* of licensing under either the GPL3/AGPL3 or the RPL1.5 almost identical, except that you would be technically entitled to sue anyone you happen to witness as having made modifications to the original source without sharing those modifications with the original developers (you). But the likelihood of you actually finding someone foolish enough to violate your license, and then willingly share that fact with you, is pretty low.
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, any distribution, mus also provide the source - thus you benefit from anyone improvements by anyone else.
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
I don't think anyone is in a rush to welcome our "All your free labor belongs to us" wanna be overlords.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
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.
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 get, whether purchased from you or given to them by others.
- Anyone who has a legit copy of the source code may distribute binaries (modified or originals) to any third-party they wish, royalty-free. That third party can only use and distribute the binaries but may not modify or view the code unless they also have an "Ultimate Plan" with Your Company.
- Anyone who distributes modified binaries to others containing changes that they themselves made using the source code, MUST provide the source code changes they made back to you (for free).
- Anyone who does NOT distribute modified binaries to others MAY do one of two things: either keep all their code/binary changes a "secret" (don't share them with anyone), OR they may submit them for a Contribution Bounty to Your Company. Your Company will look at the source code (without storing a copy of it or taking any ideas from it) and place a value on it, and offer a "take it or leave it" monetary compensation for the contribution. If accepted, Your Company will receive copyright attribution to the code, so you can do whatever you want with it. If refused, Your Company must destroy all copies of the code/binaries you got from them.
So we'd have situations like the following:
Scenario A: The University of Vulcan buys your Ultimate Plan and has the source code. Their researcher comes up with an innovative new algorithm that will make your software better. They use it and your product in a paper, and distribute their compiled binaries so other researchers can test it. As soon as they go to distribute modified binaries to third parties, they realize that they are now required to give you back the source code they changed. They comply with the license and do so. You win because you get code to enhance your product for free. The university wins because they can give away their modified copy of your product to other researchers as a way of demonstrating their work.
Scenario B: The University of Tassadar buys your Ultimate Plan and has the source code. Their researcher finds a neat security vulnerability in your product. They don't have any incentive to share it with anyone else, but they want to bring in some revenue from it, so they sell the vulnerability details and patch to fix it to you for $5000. The university wins because they got some money (and the guy can probably write a paper on it). You win because your product has one less security vulnerability.
Scenario C: An independent self-taught researcher wants to use your product. They are not a very advanced user so they don't have a special need to modify the code. For a reasonable price that a person making a living wage (or slightly less) can afford, they go to your site and purchase a "Basic Plan" that gives them access to the binaries and some type of support. The researcher wins because he got a good product at an affordable price. You win because you made money.
Scenario D: An independent researcher knows a friend who's also a researcher as part of a large institution with an Ultimate Plan. The independent guy wants to use your product, but is very poor. Since he knows the guy from the institution, he gets him to provide a binary, free of charge, so he can work on stuff that needs to use a product like this. The independent researcher benefits by getting access to your product for free without breaking his budget. The institution benefits by increasing its networking with the larger scientific community. You benefit because you alread
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...
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 a huge difference between using a piece of software for which the source code is available and contributing to an open source project. For instance, scientists may only be interested in verifying algorithms or making modifications that are used internally. The open source community has many motivations, but they almost always go beyond having access to the code.
Thinks he can reply to his own posts to make it seem like someone cares.
Really? Your definition of scientific software is a web site? Wow.
By that definition, I could post whetstone numbers and be a "hardcore scientific computing" provider. Or even do nothing more than repost top500 results.
If you are not fully fluent in the specifics of IEEE 754, you are NOT doing "scientific computing".
So tell us about your "product" - I'm pretty sure I could do better by hiring some 10yr old kids.
You might consider changing your proprietary binary license to a proprietary source + binary license. That would allow your users access to the source and allow them to make changes, etc.
That would kind of make sense anyway for your core product. Not many people outside of your industry will be interested. And it means that users will continue to pay for annual licenses / support, which you said they are happy to do.
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.
Live today, because you never know what tomorrow brings
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.
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
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 happened) is that they sold the company to Red Hat for $600 million.
"Giving away" your product and charging for "support" doesn't work for any sector, really. The biggest difference between an Open Source business model and a proprietary business model is that with open source you have to get paid before you write the software. After you write the software, anyone can get it for free, so there is no real incentive to pay for it.
You say that your customers are already used to paying a yearly fee for their software. This is an excellent start. Cygnus also had a subscription fee for GCC and related tool sets at the time. I remember the company I was working for were paying ~$2 million per year. What that got them was a right to negotiate new work each year.
Instead of immediately switching to an open source model (or, as it seems a "shared source" model that you seem to be going towards), I recommend changing the way you approach your work. If you are like most proprietary shops, you will have a PL/PGM/BL/BA thinking up and prioritising new work. It will be prioritised by how much your management (or that person) thinks that the feature/bug fix will be valued by current and new customers. You then implement the work and ship it to the customers, hoping that it meets their needs.
If you want to move to an open source model, the first thing you need to do is to engage your customers more. You need to move from a "push" system where you dictate what the next version is going to look like, to a "pull" system where the customer is engaged in what they are going to get. I would start negotiating features with the customer based on how much money they pay you. Go to your highest paying customers first and ask them what they want. Negotiate scope so that if fits within the amount of money they are paying. Then prioritise those features/bug fixes up to the very highest level and ship them ASAP (possibly even having a special release for it). Keep doing this, including more and more customers into the negotiation process. Eventually modify your pricing structure so that instead of paying for "seats" they are paying for the work that you are doing.
Once you have managed that, *then* you can open source the code with no detriment to you. In fact, it will be of great value to you because it acts as a focal point for new customers.
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 it is, so the company is called "Actian" these days.
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.
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 hardware. Just giving the source without the ability to do much won't encourage much of a community, you might as well just manage this all yourself.
There are more recent examples of something like this being used. Many of the early GPL licenses came from dual usage where GPL was unacceptable to most customers but allowed them to go open source. For example Qt's free license (when they were Trolltech) varied overtime but mostly were restrictive enough that anything that linked to Qt free was unsellable so most shops had to buy Qt commercial. But since Qt was part of the Open Source community groups like KDE did submit patches. If you want to do something similar you might assert that any derived work, i.e. the output becomes public domain for the free version but the commercial version allows you to keep your data private. Of course that depends crucially on you being able to tell what came from your application and your questions was so vague...
Anyway I think you need to be a bit clearer from the customer's perspective what they are getting from the source and from contributing.
Can we please stop using the phrase "free as in free beer"? It's trite and simplistic and over simplifies the fact that there is no such a thing as free software.
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 user friendliness but at some point your company will stagnate the product and you will die. MATLAB/Mathematica/IDL is slowly going that way and there are a number of other small companies that have already gone the way of the dodo or have been bought out by bigger companies (eg. SPSS) because they can't implement requirements as fast as a community of scientists can unless you can afford a small army of field-specific scientists to work for you as is the case with The Mathworks and Wolfram.
I personally would throw open the entire codebase and monetize your product as a service. If you can't figure out a way to monetize your product in an open sourced fashion, you've already lost to the inevitable open source alternatives that are springing up left and right.
Custom electronics and digital signage for your business: www.evcircuits.com
You can still sell your code and binaries under GPL. The only things not protected by the GPL that are "protected" (by stealth) with a closed source license are things that aren't copyrightable.
Meanwhile people will see ways to use your product you never thought of.
By the way, ALL code was open source, and much of it for science purposes, most of the rest for engineering use, to begin with. It's a recent bastardisation to have all code closed by default. There's bugger all reason to have closed source for scientific programs.
Hi, we work on a construction site and we want to treat women with respect but when the hot ones walk by we wolf-whistle at them. We want to keep doing that because we like it and it's good for morale. We also want to not whistle at feminists although we won't treat them with any respect... we'll just be pretending.
Is there any way we can build a community of people who can help us TREAT WOMEN RIGHT except for the times we want to objectify, harrass, and annoy them? It's not that we're bad people, it's just hey, man's gotta do what man's gotta do, and we're like that.
I've been reading SlashDot for years. This is the stupidest posting from a self-serving delusional a-hole I've ever read [excluding comments]. I hope I've captured the essence of the original poster in this analogy.
M
SuperMongo (SM) has been doing something similar for many years, check their website.
You lost me at "HTML/JavaScript/Python/SQL". The only right thing you did there was Python.
"The cake is a lie."
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).