Supported Source – Great Software Projects Deserve Great Support(supportedsource.org)
supportedsource.org
Supported Source – Great Software Projects Deserve Great Support
https://supportedsource.org
71 comments
I agree, however we should support projects like this, i think many engineers including myself dream of being able to make a living via open-source.
But if you do this "supported source" thing, you wouldn't be making a living off of open source, you'd be making a living off of proprietary software, which changes nothing.
But you'd be making a living, if companies want your software enough to buy it. If it's FOSS, companies could and often would profit from its use without paying you for it. Sometimes they even demand support without paying for that: http://www.coglib.com/~icordasc/blog/2015/11/corporations-an...
But at least the source would be available, so it would have some of the advantages of open source.
But no one could do anything with it. It completely negates what open source is about.
Couldn't there theoretically be a license that allows open source projects to use it and remix it, but business usage must be sub-licensed? There are some downsides, but I'd be willing to consider that if it meant more sustainable funding sources for those contributing the most to maintenance.
I don't think that's possible in the spirit of open source or free software.
If I under stand you correctly, projects that use a commercial-paid/non-commerial-free project as a dependency would also be required to use a compatible business-paid/personal-free license.
This is what people complain about re: the GPL.
It says that the most important thing is getting paid, and we'll throw the non-commercial people (non-profits, personal projects, etc) a bone, because maybe they'll contribute something back to us.
That's fine to do if someone wants to. But, it's certainly not free software. And, it's not open source either, except that the source is visible.
Like others have said, visible source it's all that helpful if you can't do anything with it.
Business should donate more to free software.
If I under stand you correctly, projects that use a commercial-paid/non-commerial-free project as a dependency would also be required to use a compatible business-paid/personal-free license.
This is what people complain about re: the GPL.
It says that the most important thing is getting paid, and we'll throw the non-commercial people (non-profits, personal projects, etc) a bone, because maybe they'll contribute something back to us.
That's fine to do if someone wants to. But, it's certainly not free software. And, it's not open source either, except that the source is visible.
Like others have said, visible source it's all that helpful if you can't do anything with it.
Business should donate more to free software.
> Couldn't there theoretically be a license that allows open source projects to use it and remix it, but business usage must be sub-licensed?
No, those two requirements are incompatible.
I'm in favor of the goal here, just not this particular method.
No, those two requirements are incompatible.
I'm in favor of the goal here, just not this particular method.
"Couldn't there theoretically be a license that allows open source projects to use it and remix it, but business usage must be sub-licensed? "
Yes. I think it's possible. I've proposed one here before that had all the advantages of FOSS, including remixes, so long as originator or owner of copyright continued getting paid. The main, remaining risk was rates getting jacked up due to inability to move off the product. An upper limit can be put into the license itself or terms fixed per version w/ perpetual license for that version. BSD or Apache licensed code could be integrated into such projects with contributions going to them under their license if commercial one merely interfaced with OSS subsystem. Finally, there's potential for time limits on how long a release stays proprietary with it going OSS after a period of time.
So, quite a few models can work. It should be noted that FOSS largely didn't work in terms of making good money or long-term maintenance of the software. Those that do are uncommon or rare. Easy with proprietary, shared-source software since you get paid if they really want it. :)
Yes. I think it's possible. I've proposed one here before that had all the advantages of FOSS, including remixes, so long as originator or owner of copyright continued getting paid. The main, remaining risk was rates getting jacked up due to inability to move off the product. An upper limit can be put into the license itself or terms fixed per version w/ perpetual license for that version. BSD or Apache licensed code could be integrated into such projects with contributions going to them under their license if commercial one merely interfaced with OSS subsystem. Finally, there's potential for time limits on how long a release stays proprietary with it going OSS after a period of time.
So, quite a few models can work. It should be noted that FOSS largely didn't work in terms of making good money or long-term maintenance of the software. Those that do are uncommon or rare. Easy with proprietary, shared-source software since you get paid if they really want it. :)
> Yes. I think it's possible
I think the point is that it would break license compatibility. You can't have other projects use it without either giving it away (in which case your own commercial use is broken) or having them switch to your license (their desires are broken).
I think the point is that it would break license compatibility. You can't have other projects use it without either giving it away (in which case your own commercial use is broken) or having them switch to your license (their desires are broken).
You mean FOSS projects desire to use it under their terms. That's a subset of potential users and contributors. Commercial users can license it. FOSS might also use it as an optional, paid component (eg plugin). They sort of do already with Open Core, Paid Extras model. These options won't be popular among FOSS-only types but commercial users might be fine with extensible, source-included software. Even Microsoft had huge community of developers supplying code for stuff depending on their proprietary software.
Of course they can do things with it. Non-commercial users could run it for free. Commercial users could run it after paying the licence fee. Programmers could contribute to the project and be paid a share of the revenue.
It would have the advantage of being able to see it for debugging. Nothing else beyond that that I can think of and multiple disadvantages.
I'm skeptical. Not sure how this can be useful.
I'm skeptical. Not sure how this can be useful.
You could rewrite portions, fix portions, do extensions, and contribute back any of these to developer. These are quite advantageous esp if it's small enough for customers to understand. One of the first systems to send the source to customers and accept good contributions into next release was Burroughs B5000: a 1961 mainframe that cost more than a house.
> You could rewrite portions, fix portions, do extensions, and contribute back any of these to developer.
Contribute back to the developer yes but it gets real iffy if they don't accept your patches that you need. Also really depends on the licensing regarding rewriting and fixing portions. Depending on the platform you're using you may need to shove that into a repository for delivery of your customized version; is that type of distribution going to be allowed?
I didn't see an explicit "here's the license all of our stuff uses" unless I missed it but a lot of these use cases could be pretty difficult IMO.
Contribute back to the developer yes but it gets real iffy if they don't accept your patches that you need. Also really depends on the licensing regarding rewriting and fixing portions. Depending on the platform you're using you may need to shove that into a repository for delivery of your customized version; is that type of distribution going to be allowed?
I didn't see an explicit "here's the license all of our stuff uses" unless I missed it but a lot of these use cases could be pretty difficult IMO.
Oh, Im not talking about this license. Im talking about how to do a hypothetical license combining payment and OSS-like advantages. In terms of what you asked, you could word license as such that they could do about anything they wanted to it... from applying local mods to distributing them... so long as the users are paying customers. Optionally, getting perpetual use of each year's release if longevity is an issue.
I agree with the goal, just not with the method.
Many people already make a living working on Open Source, for a wide variety of companies. This project, however, doesn't help people make a living via Open Source; it encourages people to release code under a proprietary license with source code available.
Many people already make a living working on Open Source, for a wide variety of companies. This project, however, doesn't help people make a living via Open Source; it encourages people to release code under a proprietary license with source code available.
Is that not better than adopting a more classic proprietary model where the source code isn't available?
I totally agree with the philosophical argument around OSS --but at the end of the day, people need to eat. If you're going to argue that we should all OSS our code, you need to specify a way to make it sustainable (see http://www.fordfoundation.org/library/reports-and-studies/ro... for more on the unsustainability).
I totally agree with the philosophical argument around OSS --but at the end of the day, people need to eat. If you're going to argue that we should all OSS our code, you need to specify a way to make it sustainable (see http://www.fordfoundation.org/library/reports-and-studies/ro... for more on the unsustainability).
If it's not Open Source, better that it not look Open Source and cause confusion. See also the various "Shared Source" schemes over the years, which caused similar confusion.
I've seen that report; I don't think I'd characterize its description as "unsustainable" so much as "needs further attention".
I've seen that report; I don't think I'd characterize its description as "unsustainable" so much as "needs further attention".
OK, suppose I have some software which is well written, works straight out of the box, and doesn't require any support. I'm quite happy for people to use it, but would like a share of any revenue commercial users gain through its use. With FOSS, if I give it away, I won't get any. If I sell it, there's nothing to stop the purchaser from giving it away, so I get paid once before seeing my work being given away.
Various common models, in order of simplicity and effectiveness:
- License it under a copyleft license. Works the same as what you describe, except s/commercial/proprietary/, and is completely compatible with the FOSS ecosystem. You get paid by any company (or individual) who wants to ship proprietary software built on your code.
- Work for a company that gains revenue by releasing the code, and pays you accordingly. For instance, a company that sells more hardware because of the code.
- As mentioned elsewhere in this thread, charge for compiled binaries, for the convenience of non-developers.
- Provide a paid service based on the code.
- Require payment up front before releasing the software (crowdfunding model). Only works before you write/release the software, and benefits from an established reputation.
- License it under a copyleft license. Works the same as what you describe, except s/commercial/proprietary/, and is completely compatible with the FOSS ecosystem. You get paid by any company (or individual) who wants to ship proprietary software built on your code.
- Work for a company that gains revenue by releasing the code, and pays you accordingly. For instance, a company that sells more hardware because of the code.
- As mentioned elsewhere in this thread, charge for compiled binaries, for the convenience of non-developers.
- Provide a paid service based on the code.
- Require payment up front before releasing the software (crowdfunding model). Only works before you write/release the software, and benefits from an established reputation.
I don't see any way of legally enforcing payment for the use of software released under the terms of the GNU GPL. Points 2 and 3 have the risk of being undercut, though they might work in some cases. Point 4 might be valid, but once its released there's no further guarantee you'll be paid.
I've thought about licensing issues, as I have software I'd like to release when it's ready, but I also would like to be paid for it by anyone who uses it to generate revenue for themselves.
Up until the early 1980s, system software development was paid for by various computer manufacturers, as it could only run on their machines. As a result of generic hardware and open-source software, hardly any similar work exists today.
I've thought about licensing issues, as I have software I'd like to release when it's ready, but I also would like to be paid for it by anyone who uses it to generate revenue for themselves.
Up until the early 1980s, system software development was paid for by various computer manufacturers, as it could only run on their machines. As a result of generic hardware and open-source software, hardly any similar work exists today.
In a similar discussion, someone working for OpenSUSE pointed out that their business model is selling FOSS. They make about $20+ million a year. Red Hat even more despite the fact that CentOS is basically Red Hat for free. You have a potential advantage in the enterprise market where companies are hesitant to take free software since they want someone to be responsible for it. They'll pay you for GPL stuff if they can call you for improvements or fixes.
For the first point, it applies when releasing code other people will want to link to, such that the GPL would apply. It doesn't help with a standalone program that nobody wants to build on or derive from; you'd need the other cases for that.
I'd say a lot of it varies on who the audience is. Many FOSS projects try some form of crowdfunding at some point and I think a good detailed summary of the methods that they try are documented at: https://snowdrift.coop/p/snowdrift/w/en/othercrowdfunding
No, don't do that:
- supportedsource.org requires you to put your code under proprietary license, which is bad because it's not open-source (If someone wants to fix a bug in your software, they can't do it).
- It is absolutely possible to sell open-source software: https://www.gnu.org/philosophy/selling.html
- The drawback is, people can put your software for free on BitTorrent.
- But companies will pay you because they want the original, genuine copy. They don't want to risk getting an unofficial fork where someone might have introduced a keylogger, and a lot of engineers actually prefer to retribute authors for their software. They actually pay the service that someone has code-reviewed what was merged into the software they get.
- If that's not enough for you, you can put a lock in your code and distribute the binary packages for a price. Yes people can remove the lock, but most companies aren't willing to recompile or even look at the code, and they'll pay. Plus, those that are willing to recompile already have their hands dirty, so they're twice closer to submitting improvements to your code ;) which is the meaning of "open-source".
In conclusion, don't use supportedsource.org, and just sell the packaged copies of your software.
- supportedsource.org requires you to put your code under proprietary license, which is bad because it's not open-source (If someone wants to fix a bug in your software, they can't do it).
- It is absolutely possible to sell open-source software: https://www.gnu.org/philosophy/selling.html
- The drawback is, people can put your software for free on BitTorrent.
- But companies will pay you because they want the original, genuine copy. They don't want to risk getting an unofficial fork where someone might have introduced a keylogger, and a lot of engineers actually prefer to retribute authors for their software. They actually pay the service that someone has code-reviewed what was merged into the software they get.
- If that's not enough for you, you can put a lock in your code and distribute the binary packages for a price. Yes people can remove the lock, but most companies aren't willing to recompile or even look at the code, and they'll pay. Plus, those that are willing to recompile already have their hands dirty, so they're twice closer to submitting improvements to your code ;) which is the meaning of "open-source".
In conclusion, don't use supportedsource.org, and just sell the packaged copies of your software.
This is especially true with "app stores"; it's sufficiently difficult to get apps into the Apple and Android stores, and sufficiently common to have adware-laden variants, that people will pay for an official version linked from the main project site.
Also true on other platforms where people don't commonly have access to a compiler, such as Windows.
Also true on other platforms where people don't commonly have access to a compiler, such as Windows.
Don't give away your free software and open source software either.
Just because it's free doesn't mean you have to put it on a public server for anyone to download. It's perfectly within the definitions of the open source and free software licenses to only distribute the software to paying customers.
Or maybe it's impossible to do this now because the internet has made it trivial to redistribute software, I don't know.
Distributing free software is an opportunity to raise
funds for development. Don't waste it!
Just because it's free doesn't mean you have to put it on a public server for anyone to download. It's perfectly within the definitions of the open source and free software licenses to only distribute the software to paying customers.
Or maybe it's impossible to do this now because the internet has made it trivial to redistribute software, I don't know.
Have you seen any projects successfully selling the source code of a fully open source application/library and making a non-trivial amount?
I've seen some projects which receive some funding by charging for compiled binaries, but that revenue is for the additional service of compiling/supporting the use of pre-compiled binaries IMO.
I've seen some projects which receive some funding by charging for compiled binaries, but that revenue is for the additional service of compiling/supporting the use of pre-compiled binaries IMO.
No, but I have not seen anyone try either in a long time, not since Emacs source code used to cost 100 dollars. There are companies like Red Hat which charge you money for access to their repos, but I suppose you would argue that they're charging for building the binaries too.
Everyone nowadays just puts up all of their source code online without asking money for it. Nobody even tries to sell it. I also think perhaps buying software in general is becoming a bit of an outdated idea. Everyone wants to sell subscriptions now.
Everyone nowadays just puts up all of their source code online without asking money for it. Nobody even tries to sell it. I also think perhaps buying software in general is becoming a bit of an outdated idea. Everyone wants to sell subscriptions now.
[deleted]
But they are entirely free to give it to anyone else.
Tbh, I find some of the complaints in this thread about it not being totally free irritating. When food, houses and healthcare are all free, maybe all code can be free too. (But i don't think a society has ever succeeded by doing that.)
I personally don't have a problem with a license that allows a user to modify source code, and run modified source code, but only after paying a fee. It seems to me DOOM mods work like this already, the code is free, but the game resources like textures etc can only be used after paying for a license. Id software gets paid, people can hack all day on the game, seems like win win to me.
I personally don't have a problem with a license that allows a user to modify source code, and run modified source code, but only after paying a fee. It seems to me DOOM mods work like this already, the code is free, but the game resources like textures etc can only be used after paying for a license. Id software gets paid, people can hack all day on the game, seems like win win to me.
The problem is that it doesn't help.
Commercial open source tends to be done for two reasons:
1. Common goal development. Several companies needs a UNIX. Rather than do all the development themselves, they work together. That's how Linux works. 2. Backup if original company's strategic goals move from your goal.
Here, neither work as you can't cooperate with others due to licensing issues.
Commercial open source tends to be done for two reasons:
1. Common goal development. Several companies needs a UNIX. Rather than do all the development themselves, they work together. That's how Linux works. 2. Backup if original company's strategic goals move from your goal.
Here, neither work as you can't cooperate with others due to licensing issues.
If the license doesn't allow applying or distributing third party patches I would be annoyed. If it allows it provided each party has paid for a license I would be happy.
It says right here, https://supportedsource.org/definition "Modifications. The license must permit modifications to the source code."
But you also can't just take parts of the code and redistribute it for free, because "Restricted Uses. The license should include restricted uses, such as disallowing resale or sublicensing."
The point isn't to prevent people from customizing their use of the software. The point is to create a system where developers get paid and projects are financially sustainable, instead of being abandoned or barely maintained.
But you also can't just take parts of the code and redistribute it for free, because "Restricted Uses. The license should include restricted uses, such as disallowing resale or sublicensing."
The point isn't to prevent people from customizing their use of the software. The point is to create a system where developers get paid and projects are financially sustainable, instead of being abandoned or barely maintained.
> The point isn't to prevent people from customizing their use of the software. The point is to create a system where developers get paid and projects are financially sustainable, instead of being abandoned or barely maintained.
The problem is that's actually one of the main powers of Open Source - the ability to fork it past the desires of upstream.
For example, I use Windows, which is "supported source". OK. Microsoft decides to put spyware. Now I need to rip it out. OK. Did so.
Now, one day later, Windows gets updated.
I have to go through the code again.
If it would be "Open Source", I'd just fork it. But now, I can't even share modifications (is it a derivative work?).Now every user would have to go through the code, find the privacy violations, and re-compile it.
Also, what happens Microsoft get's fed up and fully closes source (no more updates to "Supported Source", and they drop out of the program)? Each user has to keep up his version of Windows?
Not too useful.
If you think about it, how are there commercial communities around Apache/MIT/BSD?
Because no one wants to upkeep his fork, so they contribute code back so others can help maintain it.
That freedom can only be maintained by the ability to fork.
The problem is that's actually one of the main powers of Open Source - the ability to fork it past the desires of upstream.
For example, I use Windows, which is "supported source". OK. Microsoft decides to put spyware. Now I need to rip it out. OK. Did so.
Now, one day later, Windows gets updated.
I have to go through the code again.
If it would be "Open Source", I'd just fork it. But now, I can't even share modifications (is it a derivative work?).Now every user would have to go through the code, find the privacy violations, and re-compile it.
Also, what happens Microsoft get's fed up and fully closes source (no more updates to "Supported Source", and they drop out of the program)? Each user has to keep up his version of Windows?
Not too useful.
If you think about it, how are there commercial communities around Apache/MIT/BSD?
Because no one wants to upkeep his fork, so they contribute code back so others can help maintain it.
That freedom can only be maintained by the ability to fork.
I personally don't have a problem with any license. I think Free and Open Source software is important, though, and this is not it. The problem here is not the fact that there is a license that allows licencees to view source code. The problem is that this organisation wishes to replace open source software with their view.
(Note: I'm not going to talk about software freedom here, which is a subtly different perspective. I just want to talk about open source). The idea behind open source is that when I decide to use the software, I am not locked in to a single vendor. Not only do I have access to the source code, but I have permission to modify it and distribute it for any reason that I want.
It's that advance permission for modification and distribution that de-risks your project. If, in the future, I want to do something differently than the original author, I can. For example, imagine that I tie my infrastructure in to version 2 of the software, but they release version 3, removing most of the functionality that I depend on. I want to use version 2 and backport security changes from version 3 into version 2. Similarly, I want to distribute my changes so that anybody else that's in the same boat can pitch in on the backporting effort.
So, as an author, you give up some control of the ultimate destiny of your code. There are some advantages as well, though. If your customers take advantage of their ability to add features of their own choosing, you have turned customers into collaborators. In that way, you have a kind of consortium effect. However, you are in a privileged position, because you still own all the trademarks wrt to the project. So even if someone starts to compete against you, they can't piggy back on your marketing and sales efforts. Not only that, but if you choose a copy-left style license, they can't effectively compete unfairly against you because all of their modifications are also usable by you.
So it's a kind of balancing act. You get this low barrier of entry for participation of your customers and they get a substantially de-risked product.
There are lots and lots of licenses out there which permit the viewing of source code. It has been very popular with game engines for a long time now. Microsoft made the attempt (now abandoned, I think) of have the "Shared Source" license. Even back before free and open source was a thing, source code was often available, though there was no explicit license to use it.
This is not a "better" open source. It is objectively much worse at fulfilling the goals of open source software. Like I said, I don't care if they want to use licenses like that. I won't use their software, nor will I recommend that people accept a license like that. But I don't have a problem with them existing. I do have a problem with them pretending that what they have is an improvement on free and open source software.
(Note: I'm not going to talk about software freedom here, which is a subtly different perspective. I just want to talk about open source). The idea behind open source is that when I decide to use the software, I am not locked in to a single vendor. Not only do I have access to the source code, but I have permission to modify it and distribute it for any reason that I want.
It's that advance permission for modification and distribution that de-risks your project. If, in the future, I want to do something differently than the original author, I can. For example, imagine that I tie my infrastructure in to version 2 of the software, but they release version 3, removing most of the functionality that I depend on. I want to use version 2 and backport security changes from version 3 into version 2. Similarly, I want to distribute my changes so that anybody else that's in the same boat can pitch in on the backporting effort.
So, as an author, you give up some control of the ultimate destiny of your code. There are some advantages as well, though. If your customers take advantage of their ability to add features of their own choosing, you have turned customers into collaborators. In that way, you have a kind of consortium effect. However, you are in a privileged position, because you still own all the trademarks wrt to the project. So even if someone starts to compete against you, they can't piggy back on your marketing and sales efforts. Not only that, but if you choose a copy-left style license, they can't effectively compete unfairly against you because all of their modifications are also usable by you.
So it's a kind of balancing act. You get this low barrier of entry for participation of your customers and they get a substantially de-risked product.
There are lots and lots of licenses out there which permit the viewing of source code. It has been very popular with game engines for a long time now. Microsoft made the attempt (now abandoned, I think) of have the "Shared Source" license. Even back before free and open source was a thing, source code was often available, though there was no explicit license to use it.
This is not a "better" open source. It is objectively much worse at fulfilling the goals of open source software. Like I said, I don't care if they want to use licenses like that. I won't use their software, nor will I recommend that people accept a license like that. But I don't have a problem with them existing. I do have a problem with them pretending that what they have is an improvement on free and open source software.
From the FAQ:
> Open source is public source that's monetarily free
This isn't really true, as you really can charge for free software as much as you want, but you also can't forbid people from redistributing it without paying for it. This is why you can't download from RedHat's repos without paying for access, but also why CentOS can exist. (I have also heard that RedHat threatens to terminate your access if you exercise your redistribution rights, but I am not sure this is true.)
I guess "supported source" is a statement that there is only room for one Red Hat in this world, and everyone else must restrict redistribution.
> Open source is public source that's monetarily free
This isn't really true, as you really can charge for free software as much as you want, but you also can't forbid people from redistributing it without paying for it. This is why you can't download from RedHat's repos without paying for access, but also why CentOS can exist. (I have also heard that RedHat threatens to terminate your access if you exercise your redistribution rights, but I am not sure this is true.)
I guess "supported source" is a statement that there is only room for one Red Hat in this world, and everyone else must restrict redistribution.
Is there a name for companies that release their code under an actual free license, but charge for other things like support? Companies that come to mind are flynn.io or sidekiq.org (both of which were recently on the front-page).
Flynn co-founder here.
Great question. We just consider ourselves to be a normal company that happens to build open source tools. We also try to make money in ways that don't interfere with the open nature of what we build.
There are lots of different kinds of companies whose engineers primarily work on open source projects. In most cases where their core "product" is an open source technology they also sell commercial support, usually to large companies who need an SLA. Others (like us) sell managed services as well.
We made the decision before we started the company to make anything we ever asked users to run on their own machines permissively licensed open source and just be careful with our trademark (like Mozilla is[1]). That leaves the door open for closed-source SaaS in the future but gives our users (and investors) a clear set of expectations about how and what we'll build.
I think it's important for companies to be as clear as possible about how and why they license their code, what choices they'll make in the future, and what happens when the company changes hands. It would be great to see something like an "open source pledge" where founders/the company could contractually commit to either a final open source release before closing (like Parse did[2]) or staying open after being acquired (like Sun didn't after being acquired by Oracle [3]).
[1] https://www.mozilla.org/en-US/foundation/trademarks/policy/ [2] http://blog.parse.com/announcements/introducing-parse-server... [3] https://en.wikipedia.org/wiki/Solaris_(operating_system)#Pos...
edit: We tend to avoid calling ourselves an "open source company" which can get confused with the "open company" movement[4].
[4] http://www.opencompany.org/
Great question. We just consider ourselves to be a normal company that happens to build open source tools. We also try to make money in ways that don't interfere with the open nature of what we build.
There are lots of different kinds of companies whose engineers primarily work on open source projects. In most cases where their core "product" is an open source technology they also sell commercial support, usually to large companies who need an SLA. Others (like us) sell managed services as well.
We made the decision before we started the company to make anything we ever asked users to run on their own machines permissively licensed open source and just be careful with our trademark (like Mozilla is[1]). That leaves the door open for closed-source SaaS in the future but gives our users (and investors) a clear set of expectations about how and what we'll build.
I think it's important for companies to be as clear as possible about how and why they license their code, what choices they'll make in the future, and what happens when the company changes hands. It would be great to see something like an "open source pledge" where founders/the company could contractually commit to either a final open source release before closing (like Parse did[2]) or staying open after being acquired (like Sun didn't after being acquired by Oracle [3]).
[1] https://www.mozilla.org/en-US/foundation/trademarks/policy/ [2] http://blog.parse.com/announcements/introducing-parse-server... [3] https://en.wikipedia.org/wiki/Solaris_(operating_system)#Pos...
edit: We tend to avoid calling ourselves an "open source company" which can get confused with the "open company" movement[4].
[4] http://www.opencompany.org/
Red Hat is a billion dollar company that does exactly that.
One line summary: DRM-free, licensed-for-commercial-use, source code.
I like the idea, strongly. But I am a bit apprehensive about how the projects that sign up for this may exploit it; especially considering how some projects put up a facade of being open while important bits and portions remain closed.
On the other hand, if such a project becomes used to being paid for its visible-source bits, and paid a bit more for the hidden-source bits, I suspect they'd see little incentive to remain on the Supported Source platform and instead move entirely to hidden-source. "They're paying for it anyway. Why give away our code for cheaper, when we can keep it and charge more!"
I like the idea, strongly. But I am a bit apprehensive about how the projects that sign up for this may exploit it; especially considering how some projects put up a facade of being open while important bits and portions remain closed.
On the other hand, if such a project becomes used to being paid for its visible-source bits, and paid a bit more for the hidden-source bits, I suspect they'd see little incentive to remain on the Supported Source platform and instead move entirely to hidden-source. "They're paying for it anyway. Why give away our code for cheaper, when we can keep it and charge more!"
We need a better funding model for Open Source than a relatively small number of tech companies effectively paying everybody else's bills, but I don't think that this is it.
Other people have talked about the developer side, but not-quite Open Source doesn't necessarily work for users, either. Open Source is often less about money than convenience: the difference between totally free and $1 is sometimes all the difference. If Product A is FOSS under a OSI-approved license you can use it everywhere: you can try it out at home and on personal projects, install it on your machines at work, perhaps try and get your company to standardize on it, and work with third-party services that use exactly the same software. Once there's a form or a fee then there's meetings, and paperwork, and hassle.
Other people have talked about the developer side, but not-quite Open Source doesn't necessarily work for users, either. Open Source is often less about money than convenience: the difference between totally free and $1 is sometimes all the difference. If Product A is FOSS under a OSI-approved license you can use it everywhere: you can try it out at home and on personal projects, install it on your machines at work, perhaps try and get your company to standardize on it, and work with third-party services that use exactly the same software. Once there's a form or a fee then there's meetings, and paperwork, and hassle.
Who is "Supported Source" ? Domain is behind privacy wall, no mention of a formal company/foundation name, etc.
Looks just like an intermediary to sell licenses.
Looks just like an intermediary to sell licenses.
> The Supported Source License is comparable to a license you'd typically find with proprietary software. What makes a project Supported Source, instead of closed proprietary software, is that the code is online, open to pull requests, and there's a free trial.
Can anyone explain how pull requests would work in this situation?
Does part of the pull request sign the contribution over to the original license holder? How iron-clad is that? I can just imagine how much legal headache that could cause if a contributor decided that they owned part of the software.
I'm also curious about accepting pull requests in this way. Implicitly, the project owner takes over responsibility. In this respect, regular open source projects benefit from a lack of "official" support to begin with: if the PR does something that causes a complete breakage at some point, it's considered par for the course and fixed in due time. If however, something breaks with commercial software, there is a pretty high burden on the vendor to fix it.
I have worked in commercial software for years. It's a constant struggle as it is to say No to feature requests (for various reasons: not worthwhile, very hard to support, going in opposite direction of roadmap, etc). The worst are from the technical customers who say things like "why don't you just.." but don't understand the other ways the software is used (maybe by their competitors) with which their change is incompatible.
I imagine it would be an order of magnitude harder to say No to a full fledged pull request, and there would be immense pressure to accept it, since after all, the work is already done.. except that also means taking on the burden of maintaining and supporting it.
Anyone have experience accepting contributions from customers for commercial software?
Can anyone explain how pull requests would work in this situation?
Does part of the pull request sign the contribution over to the original license holder? How iron-clad is that? I can just imagine how much legal headache that could cause if a contributor decided that they owned part of the software.
I'm also curious about accepting pull requests in this way. Implicitly, the project owner takes over responsibility. In this respect, regular open source projects benefit from a lack of "official" support to begin with: if the PR does something that causes a complete breakage at some point, it's considered par for the course and fixed in due time. If however, something breaks with commercial software, there is a pretty high burden on the vendor to fix it.
I have worked in commercial software for years. It's a constant struggle as it is to say No to feature requests (for various reasons: not worthwhile, very hard to support, going in opposite direction of roadmap, etc). The worst are from the technical customers who say things like "why don't you just.." but don't understand the other ways the software is used (maybe by their competitors) with which their change is incompatible.
I imagine it would be an order of magnitude harder to say No to a full fledged pull request, and there would be immense pressure to accept it, since after all, the work is already done.. except that also means taking on the burden of maintaining and supporting it.
Anyone have experience accepting contributions from customers for commercial software?
I imagine it would work like a CLA in a lot of company sponsored open source. You retain copyright, but allow the owner to distribute it under their specified license terms. Or you could have a CLA that actually assigns copyright.
The ongoing maintenance of the contribution is definitely an interesting question. That is the same with classic OSS projects too, though. I know a number of projects that are going towards making a pluggable core with plugins maintained externally to reduce this burden.
The ongoing maintenance of the contribution is definitely an interesting question. That is the same with classic OSS projects too, though. I know a number of projects that are going towards making a pluggable core with plugins maintained externally to reduce this burden.
Interesting idea, though explaining the complications of licensing may cause problems when it comes to marketing.
I've had a related idea for a while, setting up SaaS for FOSS maintainers to charge for a SLA (license/source is still open, corps essentially have some security that the project won't be abandoned). Is there anything out there like that?
I've had a related idea for a while, setting up SaaS for FOSS maintainers to charge for a SLA (license/source is still open, corps essentially have some security that the project won't be abandoned). Is there anything out there like that?
Not quite with a SLA, but there's Bountysource:
https://www.bountysource.com/
https://www.bountysource.com/
Bad idea when it's presented as a substitute for FOSS. You can charge for support of FOSS based products as well.
I agree that it shouldn't be called FOSS, but let's stop kidding ourselves about the 'charge for support' model. Few kinds of software require the kind of support that would keep a single developer off the street. Most of the types that do can rarely be supported by a single developer.
I like the idea of a paid-source licensing program. I just don't know how it could work, long-term.
I like the idea of a paid-source licensing program. I just don't know how it could work, long-term.
One model that does work quite well: release code under a copyleft license, and charge for licenses/exceptions that allow linking to proprietary software.
Next time you're thinking of releasing some code under an all-permissive license, consider using a copyleft license instead, which leaves you with options in the future.
Next time you're thinking of releasing some code under an all-permissive license, consider using a copyleft license instead, which leaves you with options in the future.
While that model does help those who are developing libraries, it doesn't address the problems presented by open source applications.
There's plenty of open source applications for which the charge-for-support and dual-licensing models don't create enough funds to assist development.
The other option would be open core (crippled open source).
However, I dislike both, I still would prefer supported source as the goal is more clear.
I dislike the "open core" model as well. However, I don't see anything wrong with the copyleft, "release your source too or pay us" model. That provides very similar results: fellow developers can collaborate on the source, and companies building something they don't want to share can pay for an alternative license/exception so they don't have to. But instead of using a proprietary license to do so, that model uses a standard FOSS license, and works with the rest of the FOSS ecosystem.
Copyleft only affects changes to the original work. Usage with proprietary software is not affected.
Ok crazy idea but we do need to solve this OSS problem somehow.
My personal view is that governments should take the lead in paying for development of OSS (http://www.oss4gov.org/manifesto - full disclosure I run this site (badly))
My personal view is that governments should take the lead in paying for development of OSS (http://www.oss4gov.org/manifesto - full disclosure I run this site (badly))
This site is a joke. It misunderstands what open source is, says it's "like" open source despite being completely incompatible. Open source isn't just about being able to view the source, it's about being able to redistribute it, modify it, and distribute those modifications.
This is such a political topic that I know I should keep my mouth shut. But, I've had this brewing in my head for a long time and now's as good a time as any to put it down in digital ink.
I remember seeing an interview with Karl Lagerfeld. As many people know, there is no copyright on fashion designs. That means that when he makes a design and sells it, virtually the next day there are knockoffs in the market. They asked him if this upset him. He said (and I paraphrase), "No. People who would buy those knockoffs are not my customers".
In other words, if you don't care about the Karl Lagerfeld brand, or if you don't have enough money to afford his brand, you might buy a knock off bag. This doesn't really affect his sales because you wouldn't have bought his bag anyway. Similarly, people who want to buy his bag, will not buy a knockoff -- no matter how cheap it is. They are his customers.
In the same way, as a software author, it is not actually difficult to get paid for free software. The main thing is you have to ask to get paid. If you are the author of a major piece of software, people will pay you for that work. Those people are your customers.
The main thing (very much like fashion) is that only some software will attract paying customers. This isn't really a problem with the license. As a programmer, locking your customers in so that they can only turn to you for help is not necessarily going to increase your sales. What you really need is exposure. You need to be popular. This is where open source works well.
With open source, you have a very low barrier of entry for your potential customers. They also have a very low risk profile. They can use your code, or even parts of your code and if it doesn't work out, they can replace it cheaply. Again, as a programmer without access to lots of marketing money to bring in customers, I think this is going to help you out a lot better than locking your customers in to your platform.
The key here is that once you have exposure and your project is popular, then you can ask your customers to pay for new work. Experience has shown that people who can afford to pay, and who value your work will actually pay. Just like the fashion industry.
Where things diverge is when you are not a programmer. Let's say, you do not want to make money from writing code. Instead you want to make money from code as an asset. You have a bunch of source code that is already written and you want to treat it like it was a bushel of apples (err... a kind of endless bushel of apples, since you can sell it over and over again). In that case, you absolutely do not want to allow competition -- because anybody can sell a bushel of apples (endless bushel's of apples are especially appealing, it seems).
So, if you are saying to yourself, "How do I get paid for writing free software", I really don't think this is going to work (especially since it isn't free software!) You are raising the barrier to entry for your customers. This is going to make your project less attractive, not more. The only people this can potentially help are non-programmers who want to reduce competition with their proprietary software.
I remember seeing an interview with Karl Lagerfeld. As many people know, there is no copyright on fashion designs. That means that when he makes a design and sells it, virtually the next day there are knockoffs in the market. They asked him if this upset him. He said (and I paraphrase), "No. People who would buy those knockoffs are not my customers".
In other words, if you don't care about the Karl Lagerfeld brand, or if you don't have enough money to afford his brand, you might buy a knock off bag. This doesn't really affect his sales because you wouldn't have bought his bag anyway. Similarly, people who want to buy his bag, will not buy a knockoff -- no matter how cheap it is. They are his customers.
In the same way, as a software author, it is not actually difficult to get paid for free software. The main thing is you have to ask to get paid. If you are the author of a major piece of software, people will pay you for that work. Those people are your customers.
The main thing (very much like fashion) is that only some software will attract paying customers. This isn't really a problem with the license. As a programmer, locking your customers in so that they can only turn to you for help is not necessarily going to increase your sales. What you really need is exposure. You need to be popular. This is where open source works well.
With open source, you have a very low barrier of entry for your potential customers. They also have a very low risk profile. They can use your code, or even parts of your code and if it doesn't work out, they can replace it cheaply. Again, as a programmer without access to lots of marketing money to bring in customers, I think this is going to help you out a lot better than locking your customers in to your platform.
The key here is that once you have exposure and your project is popular, then you can ask your customers to pay for new work. Experience has shown that people who can afford to pay, and who value your work will actually pay. Just like the fashion industry.
Where things diverge is when you are not a programmer. Let's say, you do not want to make money from writing code. Instead you want to make money from code as an asset. You have a bunch of source code that is already written and you want to treat it like it was a bushel of apples (err... a kind of endless bushel of apples, since you can sell it over and over again). In that case, you absolutely do not want to allow competition -- because anybody can sell a bushel of apples (endless bushel's of apples are especially appealing, it seems).
So, if you are saying to yourself, "How do I get paid for writing free software", I really don't think this is going to work (especially since it isn't free software!) You are raising the barrier to entry for your customers. This is going to make your project less attractive, not more. The only people this can potentially help are non-programmers who want to reduce competition with their proprietary software.
I'd say there's a few issues with framing the problem this way. Project popularity and exposure does not necessarily correlate with funds raised. Many people within the communities that a piece of software is popular within are not interested in funding it as up to that point the expectation for zero cost software has been generated.
When the change to a funding model happens, who is specifying what is being worked on? who is benefiting from the new work? who would be expected to pay? What about backlash from the change in how the project evolves?
In fashion people expect to pay for things and pay quite a lot to get what they consider to be quality. Do you think a similar attitude exists in the average user of open source software?
As for the tail of your post, I'm confused. Are you trying to argue that the code is what is of value here or are you trying to argue that the work the developer can put into it is valuable? (from a funding standpoint)
When the change to a funding model happens, who is specifying what is being worked on? who is benefiting from the new work? who would be expected to pay? What about backlash from the change in how the project evolves?
In fashion people expect to pay for things and pay quite a lot to get what they consider to be quality. Do you think a similar attitude exists in the average user of open source software?
As for the tail of your post, I'm confused. Are you trying to argue that the code is what is of value here or are you trying to argue that the work the developer can put into it is valuable? (from a funding standpoint)
I love the idea and hope it succeeds. The problem is that programmers are cheap and won't pay for open source software.
I'll happily pay for Open Source software, and have done so many times. This isn't Open Source, though.
The problem is that paying for open-source software isn't something that people do by default in the normal course of obtaining it, as one does when legally obtaining proprietary software, a book, music, etc. It's something that you have to deliberately go out of your way to do. Until that problem is solved, most users won't pay for open-source software, even if they'd have no problem doing so in principle.
Consider that paying for copies of bits isn't viable and that the proprietary software industry must do nasty things to extract money for copies. Programmer time is valuable, and that is where the money is in FOSS. "Would you like feature X? I need $Y to do it."
[deleted]
You're the exception. Github has commoditized software to the point where most programmers think it's worthless.
I'm curious, which ones?
I've donated to half a dozen FOSS projects or organizations, and to a couple of individual FOSS developers. For two of those, I provide monthly donations, for more than the typical cost of a proprietary software license. I've paid for crowdfunding projects whose result got released as FOSS. I've also helped arrange corporate donations to FOSS projects.
I've donated to Ubuntu (I felt it got me started on programming and interested enough in computers). Usually when I download their desktop OS (~$79/a year)
It's similar to how M$ does their "open" source licenses
Except for being completely incompatible with both the Open Source Definition and Free Software definition, incompatible with any copyleft license, and otherwise incompatible with the entire FOSS ecosystem.
OSD #5 and DFSG #6 specifically prohibit restrictions on commercial/business use, as does the FSF's Free Software Definition ('“Free software” does not mean “noncommercial”.')
I've seen many attempts at this come and go, and they all have this same fundamental problem.