Color me deeply skeptical of the suggestion to try to lock people out of community participation unless they pay.
The real secret to not burning out is to scale up the set of maintainers in proportion to the users. You do that by lowering the barriers to involvement, not raising them.
Most maintainers err on the side of controlling too much. Which makes them into bottlenecks.
One or two good PRs is enough for me to give you commit bit on my repos. This has never yet resulted in abuse, and has brought in a many helpful co-maintainers.
Bad commits can be easily reverted. Whereas giving people a bit of trust often inspires them to help more.
Bad commits are the absolute most difficult thing to reverse when they get released and the userbase codes to them. When I don't pay super close attention to what's being contributed, it creates three times as much work after I let it through.
"a bit of trust" this! Most often maintainers ego is the issue and too much control over ones baby project is the road to frustration and burnout. The way the power is shared and the shape of community structure is huge factor often neglected by tech-only focused maintainers/owners. There is a good piece of wisdom on social aspect of open-source in Social Architecture by Pieter Hintjens[0]. I recommend learning about his pov to anyone interested in open-source open-projects.
A gitlab feature I miss on Github is "protected branches" and being able to add contributors that can only push to unprotected branches. This way you can give people access to the main repo while still being able to check code before it goes into master
We kind of did this with a project I was working on once. Someone was being helpful, main maintainer was getting tired, so helpful guy got full rights to the repo. He went on a several-year-long frenzy of activity, up to being a release manager, putting lots of micro-optimisations into the code and still being generally helpful until he got sucked up by Google and vanished.
Sadly, lots and lots of little bugs and awkward design decisions crept through. Obscure ones, hard to find, and a coding style that tended towards obfuscation. Guy had a habit for assemblyish/fortranish code.
I think the lesson learned is, sure, maybe give the helpful guy full access, but still keep your eye on them and encourage everyone else to do so too.
> One or two good PRs is enough for me to give you commit bit on my repos. This has never yet resulted in abuse, and has brought in a many helpful co-maintainers.
In addition, I find it's helpful to identify the really keen contributors and ask them privately see if they want to take on more responsibilities.
> We also need to bury the idea that any developer who submits an issue or pull request is automatically entitled to the attention of a maintainer.
> The message to users should be “do whatever you want with the code, but pay us for our time if you want to influence the project’s future.”
So, for me, this goes against the reasons I decide to give my personal time to the community. For me, creating an open source project is a contract with the community, and part of that contract is to assist members of this community that might require features or have issues. Statements such as the ones quoted above go wholeheartedly against my idea of an open source community, and I have a feeling most of the open source community shares this sentiment.
Breaking this contract would be, for me, a cease and desist of the project. For me, it is very simple, if a personal project is stagnated, that’s acceptable as no one owes anyone here anything. If a company’s open source projects go stagnant, but the company continues to boast how pro-OSS they are, it is a cardinal sin, as they have broken this contract with their users. This may be a naive look, but I don’t think a company should be able to have it both ways—boast about its OSS projects, lure people in and then ignore them and move on to their next PR OSS project.
Donations are a different proposition than the suggestions in the article, and should definitely be encouraged.
> creating an open source project is a contract with the community, and part of that contract is to assist members of this community
I disagree. Creating an open source project is a gift to the community.
Expecting further time and attention from somebody who gave you a gift, out of a sense of entitlement from having received the gift, is just being rude.
Pay for my time and I'll help you with your issues. Demand my time because you're somehow my "community" and I'll just re-explain the above.
That's a strange view of open source that borders on communism.
You don't have any duties or obligation towards any individual to assist them with their issues.
The only obligations you have is to be honest about the project. For example, if you know that the project is not written with security in mind, you must announce the fact, so that people don't go using the project assuming you took care of all potential exploits.
Beyond that, you have no obligations towards anyone. Quite the opposite. You've already done your part. You donated the product of your effort for free. The obligation is on people who use your product. If they want you to care of their issues, they are obliged to give something back in return. At the very least, appreciation.
> creating an open source project is a contract with the community, and part of that contract is to assist members of this community that might require features or have issues.
If this were strictly enforced, there would be much fewer open source projects, as not all authors would be able to meet the obligations.
I led a small open source project more than a decade ago.
Most people involved had more time than money. I'm quite certain that trying to charge an annual fee from members would have killed the entire project before it was even born.
Introducing money to the equation changes everything. People start to look at the project as a product they are buying, instead of a cause they are contributing to.
I believe the author of this article is deeply misguided. Money is not a way to make open projects work, but it is a good way to kill them.
As soon as money is involved there is a certain expectation of quality and the work being done properly. If you start depending on that money then you are under the control of your customers and your hobby will quickly degrade into a regular job.
As much as I agree with the sentiment behind this post, I disagree with the implementation. The nature of open source code is collaboration. Paying for collaboration seems like it would hinder progress altogether and possibly direct the project into a direction that is not suitable for the poor majority not paying. One more thing that bothers me is that money for maintenance should not come from developers. This is like robbing Peter to pay Paul.
Code Sponsor is trying to help provide those who are maintaining OSS projects with untethered sponsorship funds. They can go about doing their business on the projects and be making money through sponsor-based ad revenue. This provides them with the incentive and finances to justify continued support on those projects that end up being abandoned when unfunded.
I agree that this is a HUGE problem that needs to be addressed. Code Sponsor's approach is to go where money can scale: marketing budgets.
I've seen these kinds of things and have always been dubious that they are able to pay a full time salary for someone that is even close to what they could make with a normal full time dev job. What's the highest monthly amount your company pays a dev? What's the average and median?
> Short version: We do not generally prohibit use of GitHub for advertising. However, we expect our users to follow certain limitations, so GitHub does not become a spam haven. No one wants that.
Devil's advocate: How about an issue/PR tracker that lets users pay for priority? A simple bidding system. If BigCorp International is willing to pay $200/hour for IE10 support, they can be next on your list. And afterward, an bug with significant community support totalling $50/hour, pledged by 50 different users. With allowances for your own preferences as maintainer and the needs of the community, of course, but giving people who care the most the opportunity to put their money where their pain is.
I built a site like this a few years ago, got absolutely no traction, and shut it down.
I'm very open to the possibility that I went about it the wrong way, but I don't really know what I should have done differently. Maybe it could have worked if I had done a lot more evangelizing -- I admittedly didn't do much, but what I did do was so poorly received that I gave up.
I haven't seen any large scale, long-term open source projects succeed with a 'pay to play' process; what usually happens is the original maintainers realize that even with some amount of compensation, they still don't like scratching other people's itch when it comes to their project.
And then they realize that the amount of people/companies even willing to pay at all is a tiny fraction of 1% of their potential target market.
The better advice is to do what you want, know your limits, consider sharing some maintainance responsibility with another committer or two, and don't ever feel obligated to do anything with other people's issues and PRs. It's nice to do, but if it's interfering with anything else, or taking away valuable time, ignore them or just blanket close them, with a note that it's not something you'd be interested in maintaining.
The great thing about open source is someone can fork your code and do what they need. You have no obligation to help them, it's just nice if you can. And if they don't get that, that's not your problem.
It's not your problem only in the sense that it shouldn't be your problem. E.g., in theory.
Some people can be quite belligerent about their FOSS entitlement. I've also seen folk publicly bash open source projects just because the license wasn't permissive enough, in their opinion (GPL vs. their darling I'll-bend-over-do-what-you-will-with-me BSD or MIT).
It can be hard to maintain poker face with "not my problem"... as hard as the "fuck you, pay me" proposed by the OP. The social pressure to give away your work for free is real, and humans are social animals. Just look at this thread.
Sidekiq by Mike Perham is following the open core, paid subscription for a "pro" version containing extensions. His single founder company has a monthly recurring revenue in excess of $80k, as featured on Indie Hackers[1].
I think what open source needs is some very deliberate price discrimination. Have the license be free to the vast majority of users, and cost money for large corporations that can damn well afford it. Not, like, large amounts of money, just something vaguely close to the all-in cost of one full time developer.
Basically, "BSD, unless you're a $1B+ valued company that is not paying our software foundation $10k/mo".
Many moons ago I developed a moderately successful shareware program. My licensing terms were simple: If you owned the computer where you installed and used it no license was needed, but if someone else owned the machine, you owed me money.
It allowed students, hobbyists and freelancers to use the software for free, for any purpose, but companies, institutions and governments had to pay to play.
This idea does not seem to translate in an obvious way to software released under an open source license.
This is pretty much exactly how I feel about this issue. The contributors you really want are the youth that are young and ambitious, setting a price to contribute would hinder this growth. The contributors you probably don't want are the large corps who will try to push the project based on there income, charge them a lot for the privilege of dealing with their bias.
The problem with this is if you are anything more than a small company, it's pretty hard to get authorisation and approval to pay for software.
A couple of years ago I was working for a UN organisation, and to get approval to upgrade our plan of an alerting tool from something like $10/mo to $25/mo required many people involved and weeks of time (not weeks of people time, but weeks from 'we want this' to 'ok'). For something new we would have to evaluate it against other competing products, and then it's just a waste of everyone's time, instead of 'gem install sidekiq'.
Admittedly not every company/organisation is this extreme, but once you get to a certain size most companies have something like this.
(I felt we paid our dues to the open source community as we open sourced a lot of our own in house tools and helped maintain a lot of other projects we regularly used)
"bury the idea that any developer who submits an issue or pull request is automatically entitled to the attention of a maintainer... If you’re the leader of one of these projects, charge an annual fee for community membership. Open source, closed community. The message to users should be “do whatever you want with the code, but pay us for our time if you want to influence the project’s future.” Lock non-paying users out of the forum and issue tracker, and ignore their emails."
I dislike the key suggestion. What's the point of open-source - if not to give back? It's a developer's codex/morale to answer.
It seems the author is salty about the fact he doesn't make money from open source, but is investing a lot of time. Well my dear colleague, offer support to the bigger companies that use your software in production or use that software to sell another. Simple.
Open source was never meant to be for-profit, at least from my understanding. Something you give back to the community, because you have taken a lot from it in the first place. You dislike new issues by non-payees? Well, write better docs. Someone is also giving YOU time by submitting that issue or by finding a bug - so should you pay them money for testing? Be grateful.
Should we all pay for the open source tools/frameworks we use? I can guarantee this would cause riots. If you don't want to contribute to OSS don't, but please do not whine about it.
Your employer benefits financially from the open source community. People who purchase software cheaply due to lower barrier to entry and more competition also benefit. As a coder I generally don't benefit so don't feel the need to give back.
As a coder the tsunami of FOSS is a negative. My job is now to glue free modules together rather than design stuff. I'd be quite happy to pay for a compiler if I had to.
The notion of charging people to be part of the community seems like a terrific way to immediately kill any semblance of community.
Realistically, the only people who will pay a membership fee are those who can charge it to a company. That means you'll lose all the people hacking on the project in their free time.
Personally, I contributed a lot more to open source when I was in college and had more free time than money. There's no way I would have paid to be able to contribute.
The solution is really just to have lower expectations on maintainers, both around timely responses/support (want fast support, pay for it) and improvements. They can and should also be more liberal with adding maintainers.
I shudder to think of the sense of entitlement some of my users would have towards getting me to fix their pet issues that they had to pay to tell me about. This article got a lot right but then charging for community membership is a super bad idea.
The open source community defies definition. It's a diverse multitude of people with different motivations. This will ensure its survival even under challenging circumstances.
There is a risk, maybe significant, of the generational hand off. A lot of folks who built this rich legacy were academics and pioneers motivated by ideology. Software has moved on from early pioneers motivated by liberty and freedom issues to being subsumed by establishment interests.
At the moment there is also widespread cynicism about ideology in general and a lot of open source is increasingly developed by corporate interests. This could have repercussions for the 'nature' of open source as institutions and a connection to individuals beyond their identity as 'users' has not really been built.
maybe some sortof point system would be nice. You get points by providing good bug reports, good forum answers, good PRs, good code reviews, providing tests, donating, etc., but you can lose points by wasting people's time or being a jerk, for instance. Then maintainers can prioritize PRs by people with good points, regardless of how they got the points (be it from donating time, code, or other ways of helping the community & project).
The dude's key project has a total of 4 contributors (working at the same company?) 0 forks and 0 stars. I am sure we should all follow his guidance on the subject.
But if opensource truly is infrastructure, why not nationalize it? i.e. government pays maintainers a subsistence wage (provided they meet some scale crtieria, perhaps similar to automatic royalties for pop-song airplay).
Users (i.e. big corporations) would pay a levy to fund this. Of course, it could be set up privately, independent of a government.
What works for me is locking down the application behind a plan. Users can submit whatever feedback, bugs, suggestions, enhancements, and wishlists they want. These contributions are important, but they won't change the roadmap.
This only works when an open source application becomes ubiquitous or nearly ubiquitous and the users want it everywhere. Popularity and consumption rates are irrelevant to whether this works. This is because ubiquitous software solves an extremely common problem and takes too much effort to replace with an alternate solution. Ubiquitous software is not necessarily good software.
When somebody wants a change in the roadmap they can pay you money to compensate you for the additional time it takes to pivot into another direction. You probably aren't going to make any money like this. Then benefits of this approach is that the maintainers won't burn out. They just work to the plan and occasionally respond to issues. The software has a transparent and published trajectory.
And so should "open-source code is utility software".
Stallman was right when he said that the Open Source movement would eventually abandon any conceptions of software freedom - it seems to me that we now have a whole generation of "open source" contributors for whom the only type of freedom that matters is the freedom of downstream developers, rather than users, and who seem to think that the role of open source in the world is just to provide a base on top of which one can write proprietary applications. Where do developers of open source end-user applications fit into this picture?
The author has many good points however it's either his writing style (thinking), ideas, or conceptual mental model where he is missing the point of open source. It is actually a bit confusing. His title doesn't correlate with what he writes later which contains several somewhat vacuous statements. People love to work together and produce something for the common good, humanity wouldn't be here without that good feeling and collaborative spirit. open source comes from people's time, time has led us to a point where open source is everywhere. Not all people are greedy, every coder owes another coder their livelihood. I think this draft just needed like 100 more edits. Also, "Many" does not equal 3.
In the proposed approach, what would happen to a high-quality and desirable code contribution from someone who cannot afford to pay for their code to be reviewed?
[+] [-] ef4|8 years ago|reply
The real secret to not burning out is to scale up the set of maintainers in proportion to the users. You do that by lowering the barriers to involvement, not raising them.
Most maintainers err on the side of controlling too much. Which makes them into bottlenecks.
One or two good PRs is enough for me to give you commit bit on my repos. This has never yet resulted in abuse, and has brought in a many helpful co-maintainers.
Bad commits can be easily reverted. Whereas giving people a bit of trust often inspires them to help more.
[+] [-] zzzeek|8 years ago|reply
[+] [-] imhoguy|8 years ago|reply
[0] https://www.gitbook.com/book/hintjens/social-architecture/de...
[+] [-] Klathmon|8 years ago|reply
If you want commit access, just ask. But I still want to validate releases that get pushed out to a bunch of people.
[+] [-] ATsch|8 years ago|reply
[+] [-] jordigh|8 years ago|reply
Sadly, lots and lots of little bugs and awkward design decisions crept through. Obscure ones, hard to find, and a coding style that tended towards obfuscation. Guy had a habit for assemblyish/fortranish code.
I think the lesson learned is, sure, maybe give the helpful guy full access, but still keep your eye on them and encourage everyone else to do so too.
[+] [-] j_s|8 years ago|reply
http://felixge.de/2013/03/11/the-pull-request-hack.html
> Whenever somebody sends you a pull request, give them commit access to your project.
I agree with requiring more accountability before granting the ability to create official releases.
[+] [-] asdfasdfasd333|8 years ago|reply
This applies to engineering at software companies as well.
[+] [-] hacking_again|8 years ago|reply
In addition, I find it's helpful to identify the really keen contributors and ask them privately see if they want to take on more responsibilities.
[+] [-] ngo123|8 years ago|reply
Burnout can happen by working too much. It can also happen by too many discussions/politics if you give out commit rights like cookies.
[+] [-] LeoNatan25|8 years ago|reply
> The message to users should be “do whatever you want with the code, but pay us for our time if you want to influence the project’s future.”
So, for me, this goes against the reasons I decide to give my personal time to the community. For me, creating an open source project is a contract with the community, and part of that contract is to assist members of this community that might require features or have issues. Statements such as the ones quoted above go wholeheartedly against my idea of an open source community, and I have a feeling most of the open source community shares this sentiment.
Breaking this contract would be, for me, a cease and desist of the project. For me, it is very simple, if a personal project is stagnated, that’s acceptable as no one owes anyone here anything. If a company’s open source projects go stagnant, but the company continues to boast how pro-OSS they are, it is a cardinal sin, as they have broken this contract with their users. This may be a naive look, but I don’t think a company should be able to have it both ways—boast about its OSS projects, lure people in and then ignore them and move on to their next PR OSS project.
Donations are a different proposition than the suggestions in the article, and should definitely be encouraged.
[+] [-] jasonkester|8 years ago|reply
I disagree. Creating an open source project is a gift to the community.
Expecting further time and attention from somebody who gave you a gift, out of a sense of entitlement from having received the gift, is just being rude.
Pay for my time and I'll help you with your issues. Demand my time because you're somehow my "community" and I'll just re-explain the above.
[+] [-] hasenj|8 years ago|reply
You don't have any duties or obligation towards any individual to assist them with their issues.
The only obligations you have is to be honest about the project. For example, if you know that the project is not written with security in mind, you must announce the fact, so that people don't go using the project assuming you took care of all potential exploits.
Beyond that, you have no obligations towards anyone. Quite the opposite. You've already done your part. You donated the product of your effort for free. The obligation is on people who use your product. If they want you to care of their issues, they are obliged to give something back in return. At the very least, appreciation.
[+] [-] hartator|8 years ago|reply
[+] [-] thinkloop|8 years ago|reply
If this were strictly enforced, there would be much fewer open source projects, as not all authors would be able to meet the obligations.
[+] [-] metafunctor|8 years ago|reply
Most people involved had more time than money. I'm quite certain that trying to charge an annual fee from members would have killed the entire project before it was even born.
Introducing money to the equation changes everything. People start to look at the project as a product they are buying, instead of a cause they are contributing to.
I believe the author of this article is deeply misguided. Money is not a way to make open projects work, but it is a good way to kill them.
[+] [-] imtringued|8 years ago|reply
[+] [-] cavneb|8 years ago|reply
Disclaimer: I am the CEO of Code Sponsor (https://codesponsor.io)
Code Sponsor is trying to help provide those who are maintaining OSS projects with untethered sponsorship funds. They can go about doing their business on the projects and be making money through sponsor-based ad revenue. This provides them with the incentive and finances to justify continued support on those projects that end up being abandoned when unfunded.
I agree that this is a HUGE problem that needs to be addressed. Code Sponsor's approach is to go where money can scale: marketing budgets.
[+] [-] mjibson|8 years ago|reply
[+] [-] vjeux|8 years ago|reply
https://help.github.com/articles/github-terms-of-service/#k-...
> Short version: We do not generally prohibit use of GitHub for advertising. However, we expect our users to follow certain limitations, so GitHub does not become a spam haven. No one wants that.
[+] [-] isaaclyman|8 years ago|reply
[+] [-] sbov|8 years ago|reply
https://en.wikipedia.org/wiki/Bountysource
[+] [-] ScottBurson|8 years ago|reply
I'm very open to the possibility that I went about it the wrong way, but I don't really know what I should have done differently. Maybe it could have worked if I had done a lot more evangelizing -- I admittedly didn't do much, but what I did do was so poorly received that I gave up.
[+] [-] bocklund|8 years ago|reply
[+] [-] a3_nm|8 years ago|reply
However, the donation is about helping poor children in Uganda, not about running the project.
[+] [-] geerlingguy|8 years ago|reply
And then they realize that the amount of people/companies even willing to pay at all is a tiny fraction of 1% of their potential target market.
The better advice is to do what you want, know your limits, consider sharing some maintainance responsibility with another committer or two, and don't ever feel obligated to do anything with other people's issues and PRs. It's nice to do, but if it's interfering with anything else, or taking away valuable time, ignore them or just blanket close them, with a note that it's not something you'd be interested in maintaining.
The great thing about open source is someone can fork your code and do what they need. You have no obligation to help them, it's just nice if you can. And if they don't get that, that's not your problem.
[+] [-] Radim|8 years ago|reply
Some people can be quite belligerent about their FOSS entitlement. I've also seen folk publicly bash open source projects just because the license wasn't permissive enough, in their opinion (GPL vs. their darling I'll-bend-over-do-what-you-will-with-me BSD or MIT).
It can be hard to maintain poker face with "not my problem"... as hard as the "fuck you, pay me" proposed by the OP. The social pressure to give away your work for free is real, and humans are social animals. Just look at this thread.
[+] [-] slashdotdash|8 years ago|reply
[1] https://www.indiehackers.com/businesses/sidekiq
[+] [-] ThrustVectoring|8 years ago|reply
Basically, "BSD, unless you're a $1B+ valued company that is not paying our software foundation $10k/mo".
[+] [-] doozy|8 years ago|reply
It allowed students, hobbyists and freelancers to use the software for free, for any purpose, but companies, institutions and governments had to pay to play.
This idea does not seem to translate in an obvious way to software released under an open source license.
[+] [-] ghthor|8 years ago|reply
[+] [-] lucaspiller|8 years ago|reply
A couple of years ago I was working for a UN organisation, and to get approval to upgrade our plan of an alerting tool from something like $10/mo to $25/mo required many people involved and weeks of time (not weeks of people time, but weeks from 'we want this' to 'ok'). For something new we would have to evaluate it against other competing products, and then it's just a waste of everyone's time, instead of 'gem install sidekiq'.
Admittedly not every company/organisation is this extreme, but once you get to a certain size most companies have something like this.
(I felt we paid our dues to the open source community as we open sourced a lot of our own in house tools and helped maintain a lot of other projects we regularly used)
[+] [-] firasd|8 years ago|reply
"bury the idea that any developer who submits an issue or pull request is automatically entitled to the attention of a maintainer... If you’re the leader of one of these projects, charge an annual fee for community membership. Open source, closed community. The message to users should be “do whatever you want with the code, but pay us for our time if you want to influence the project’s future.” Lock non-paying users out of the forum and issue tracker, and ignore their emails."
[+] [-] bkovacev|8 years ago|reply
It seems the author is salty about the fact he doesn't make money from open source, but is investing a lot of time. Well my dear colleague, offer support to the bigger companies that use your software in production or use that software to sell another. Simple.
Open source was never meant to be for-profit, at least from my understanding. Something you give back to the community, because you have taken a lot from it in the first place. You dislike new issues by non-payees? Well, write better docs. Someone is also giving YOU time by submitting that issue or by finding a bug - so should you pay them money for testing? Be grateful.
Should we all pay for the open source tools/frameworks we use? I can guarantee this would cause riots. If you don't want to contribute to OSS don't, but please do not whine about it.
[+] [-] quickthrower2|8 years ago|reply
As a coder the tsunami of FOSS is a negative. My job is now to glue free modules together rather than design stuff. I'd be quite happy to pay for a compiler if I had to.
[+] [-] morgante|8 years ago|reply
Realistically, the only people who will pay a membership fee are those who can charge it to a company. That means you'll lose all the people hacking on the project in their free time.
Personally, I contributed a lot more to open source when I was in college and had more free time than money. There's no way I would have paid to be able to contribute.
The solution is really just to have lower expectations on maintainers, both around timely responses/support (want fast support, pay for it) and improvements. They can and should also be more liberal with adding maintainers.
[+] [-] erikpukinskis|8 years ago|reply
[+] [-] zzzeek|8 years ago|reply
[+] [-] throw2016|8 years ago|reply
There is a risk, maybe significant, of the generational hand off. A lot of folks who built this rich legacy were academics and pioneers motivated by ideology. Software has moved on from early pioneers motivated by liberty and freedom issues to being subsumed by establishment interests.
At the moment there is also widespread cynicism about ideology in general and a lot of open source is increasingly developed by corporate interests. This could have repercussions for the 'nature' of open source as institutions and a connection to individuals beyond their identity as 'users' has not really been built.
[+] [-] jamiesonbecker|8 years ago|reply
* custom features
* prioritization
* training
* enterprise support
* sponsorships
* invites to free conferences and swag
* t-shirts and swag sales
* commercial software integrations/partnerships
* brand sponsorship/inclusion on docs/websites/etc.
* professionally managed and scalable hosting
What did I miss?
[+] [-] Temasik|8 years ago|reply
[+] [-] partycoder|8 years ago|reply
By using a small project and reporting bugs you are helping to test it, giving feedback and allowing it to grow.
Also, reporting a bug sometimes saves the maintainers the effort of finding the bug themselves... something that actually takes time.
A better policy is to encourage people to help fix the bugs they report, with a test case or a pull request if possible... something actionable.
[+] [-] em3rgent0rdr|8 years ago|reply
[+] [-] qaq|8 years ago|reply
[+] [-] hyperpallium|8 years ago|reply
Sleepycat did this https://wikipedia.org/wiki/Sleepycat_Software and seemed to work out for them.
But if opensource truly is infrastructure, why not nationalize it? i.e. government pays maintainers a subsistence wage (provided they meet some scale crtieria, perhaps similar to automatic royalties for pop-song airplay).
Users (i.e. big corporations) would pay a levy to fund this. Of course, it could be set up privately, independent of a government.
[+] [-] austincheney|8 years ago|reply
This only works when an open source application becomes ubiquitous or nearly ubiquitous and the users want it everywhere. Popularity and consumption rates are irrelevant to whether this works. This is because ubiquitous software solves an extremely common problem and takes too much effort to replace with an alternate solution. Ubiquitous software is not necessarily good software.
When somebody wants a change in the roadmap they can pay you money to compensate you for the additional time it takes to pivot into another direction. You probably aren't going to make any money like this. Then benefits of this approach is that the maintainers won't burn out. They just work to the plan and occasionally respond to issues. The software has a transparent and published trajectory.
[+] [-] davidgerard|8 years ago|reply
This redefinition of a basic term should have been at the beginning, not the end.
[+] [-] ajdlinux|8 years ago|reply
Stallman was right when he said that the Open Source movement would eventually abandon any conceptions of software freedom - it seems to me that we now have a whole generation of "open source" contributors for whom the only type of freedom that matters is the freedom of downstream developers, rather than users, and who seem to think that the role of open source in the world is just to provide a base on top of which one can write proprietary applications. Where do developers of open source end-user applications fit into this picture?
[+] [-] kalat|8 years ago|reply
[+] [-] walterbell|8 years ago|reply