A plan for open source software maintainers(daemonology.net)
daemonology.net
A plan for open source software maintainers
http://www.daemonology.net/blog/2017-05-11-plan-for-foss-maintainers.html
164 comments
> but why does it attract so many sponsors?
Sean Larkin busts his ass to advocate for companies supporting the development of webpack.
Sean Larkin busts his ass to advocate for companies supporting the development of webpack.
Are we seeing the same page? The sponsor page hardly lists anybody noteworthy and nobody is going to click through those links. It's wasted marketing money (developers are the worst segment you can try to sell to).
I think it is pure imagination to think marketers throw 100k for this.
Also thinking of funding opensource as a marketing fund is really not the right approach. The companies are then coming to you for the wrong reasons.
I think it is pure imagination to think marketers throw 100k for this.
Also thinking of funding opensource as a marketing fund is really not the right approach. The companies are then coming to you for the wrong reasons.
I can understand your point. But here is our belief at webpack: The community owns us, sponsors and backers are our shareholders, yet at the same time, they are all candidates to expense and fund the time they sacrifice contributing to our community. Until Sokra (Tobias Koppers), went full time (thanks to our continued growth in support) we have expensed more of this sponsor and backers funds to our external contributers than to ourselves as the core team.
Our community is growing so rapidly that there is no reason why any person shouldn't be able to receive the same recognition and appreciation for their work, than we should as a core team.
I have been in charge of finding sponsors, backers, and partners for our organization and I always focus on this first: don't for funds but instead relationships, opportunities, and ways we can use their contributions (whether it is man hours or funds), as a vessel to mutually benefit those individuals through increased learning, mentorship, marketing value, support, and more.
An example of this would be our application to the MOSS Grant board to support an initiative dear to Mozilla to add first-class module support for WebAssembly. This not only allows us to potentially be awarded over 100k in funding, but also helping Mozilla support their initiatives, and finally, putting a feature such as WebAssembly in the hands of Developers in an accessible and pragmatic way.
As a project when you focus on money and who is sponsoring your project, you lose sight of the true beauty of open source.
In the end the only thing that matters to us is that you give a shit about our mission and want to find any way to give back to the organization, contributors, and users.
Our community is growing so rapidly that there is no reason why any person shouldn't be able to receive the same recognition and appreciation for their work, than we should as a core team.
I have been in charge of finding sponsors, backers, and partners for our organization and I always focus on this first: don't for funds but instead relationships, opportunities, and ways we can use their contributions (whether it is man hours or funds), as a vessel to mutually benefit those individuals through increased learning, mentorship, marketing value, support, and more.
An example of this would be our application to the MOSS Grant board to support an initiative dear to Mozilla to add first-class module support for WebAssembly. This not only allows us to potentially be awarded over 100k in funding, but also helping Mozilla support their initiatives, and finally, putting a feature such as WebAssembly in the hands of Developers in an accessible and pragmatic way.
As a project when you focus on money and who is sponsoring your project, you lose sight of the true beauty of open source.
In the end the only thing that matters to us is that you give a shit about our mission and want to find any way to give back to the organization, contributors, and users.
Webpack sponsors: Capital One ($12K), ag-Grid ($7.5K since March), Hubspot and Rollbar. Those are some great names, with Webpack offering some not that great logo placement and linkage.
The StdLib logo on http://vuejs.org/v2/api is $2k/month. It's probably under-priced, and entirely unnecessarily limited to a single sponsor.
For a comparison: it costs $2K+ to get a one-time ad entry into a weekly developer newsletter like JavaScript Weekly (http://javascriptweekly.com/). And JS Weekly has a much smaller audience than most prime open source project pages.
The StdLib logo on http://vuejs.org/v2/api is $2k/month. It's probably under-priced, and entirely unnecessarily limited to a single sponsor.
For a comparison: it costs $2K+ to get a one-time ad entry into a weekly developer newsletter like JavaScript Weekly (http://javascriptweekly.com/). And JS Weekly has a much smaller audience than most prime open source project pages.
[deleted]
Wow, I'm really surprised at the $2k/month figure for a logo on the Vue API page. How do you go about finding sponsors for such a page? Or is it a case of being visible and lucky enough for sponsors to come to you?
> The sponsor page hardly lists anybody noteworthy and nobody is going to click through those links.
Uhhh... Please tell me you're joking?
There is a lot of developer targeted companies in the sponsors list for Webpack.
Uhhh... Please tell me you're joking?
There is a lot of developer targeted companies in the sponsors list for Webpack.
Patreon is a perfect example how people are willing to support good works. Currently, the Vue's creator is receiving $10k monthly for his works [0].
I was happy recursively paying for Pycharm even sometimes I didn't use it for months. I see many people do that with Adobe products. If I had an option to pay Postgresql, Flask, VSCode developers a small amount every month , I would be happy to pay it.
One thing I would love to see is to have an option to pay the OSS developers. There works are worth not only donations but payments. In the other side, I've seen enough higher managers refuse to use OSS. Their reasons are really understandable: "Who I'm gonna call if the software has some bugs?". Contracts, and sometimes expensive prices, are what they need before invest in new softwares.
So how these contracts should work in a Patreon-like site? If I had implemented the site, I would shamelessly copy the Patreon's tiers model. The cheap tier would require the developers just keep doing whatever they are currently doing. More expensive tiers would be for support contracts. I pay this developer for that project, and I'm guaranteed that I'll receive email support within 24h. If I pay more, I may have access to phone support. What kind of supports and how much are they worth is the OSS developer's decision.
[0]: https://www.patreon.com/evanyou
I was happy recursively paying for Pycharm even sometimes I didn't use it for months. I see many people do that with Adobe products. If I had an option to pay Postgresql, Flask, VSCode developers a small amount every month , I would be happy to pay it.
One thing I would love to see is to have an option to pay the OSS developers. There works are worth not only donations but payments. In the other side, I've seen enough higher managers refuse to use OSS. Their reasons are really understandable: "Who I'm gonna call if the software has some bugs?". Contracts, and sometimes expensive prices, are what they need before invest in new softwares.
So how these contracts should work in a Patreon-like site? If I had implemented the site, I would shamelessly copy the Patreon's tiers model. The cheap tier would require the developers just keep doing whatever they are currently doing. More expensive tiers would be for support contracts. I pay this developer for that project, and I'm guaranteed that I'll receive email support within 24h. If I pay more, I may have access to phone support. What kind of supports and how much are they worth is the OSS developer's decision.
[0]: https://www.patreon.com/evanyou
"Who I'm gonna call if the software has some bugs?"
It's certainly understandable, but it's also worth remembering that for almost any business the idea that they could call, say, Microsoft and get their bug fixed is pretty much a fantasy.
It's certainly understandable, but it's also worth remembering that for almost any business the idea that they could call, say, Microsoft and get their bug fixed is pretty much a fantasy.
> ... the idea that they could call, say, Microsoft and get their bug fixed is pretty much a fantasy.
I don't know why you think this is a fantasy. I could call Microsoft right now and get an engineer within 24 hours to discuss an issue... I think that's our SLA. Might be a shorter time period for initial triage response. But typically we're talking to an engineer within a day. And yes, sometimes these discussions result in bug fixes in upcoming patches.
This is what first-class business support means. Large businesses want to be able to get someone on the phone to fix an issue, and they will pay well for it.
I don't know why you think this is a fantasy. I could call Microsoft right now and get an engineer within 24 hours to discuss an issue... I think that's our SLA. Might be a shorter time period for initial triage response. But typically we're talking to an engineer within a day. And yes, sometimes these discussions result in bug fixes in upcoming patches.
This is what first-class business support means. Large businesses want to be able to get someone on the phone to fix an issue, and they will pay well for it.
Microsoft (and several others, so they're not alone) has a pretty terrible reputation for their business support. It's something I can personally attest to when trying to engage them a few years ago with a mission critical systems problem for a reasonably large multi-million $ account at the time.
Note also the person you're responding to said "get their bug fixed", which is different from "get an engineer within 24 hours to discuss an issue". Discussing an issue can simply be a tick-off point for an SLA with no real substantial action behind the scenes beyond that.
Of course, you might have very different experiences so far too. :)
Note also the person you're responding to said "get their bug fixed", which is different from "get an engineer within 24 hours to discuss an issue". Discussing an issue can simply be a tick-off point for an SLA with no real substantial action behind the scenes beyond that.
Of course, you might have very different experiences so far too. :)
> It's certainly understandable, but it's also worth remembering that for almost any business the idea that they could call, say, Microsoft and get their bug fixed is pretty much a fantasy.
If you believe that, you've never been in an organization which purchased the topmost tiers of a support contract before from one of the big tech companies before. It's actually quite impressive.
If you believe that, you've never been in an organization which purchased the topmost tiers of a support contract before from one of the big tech companies before. It's actually quite impressive.
I have called Microsoft and gotten them to fix bugs and/or back-port fixes to the SP we were on. Anyone with a premier support plan can do the same.
While not for Microsoft I work for another organization in that size class and this is effectively my entire job. Customer opens a ticket, we engage, resolve, bug fix and deliver. It does cost a pretty penny but the problems go away no matter how vague the circumstance.
On the other side as much as I try to contribute with F/OSS support I'm not going to provide that same level of service as my dedicated job.
On the other side as much as I try to contribute with F/OSS support I'm not going to provide that same level of service as my dedicated job.
They just say: "You found a bug. Thank you. This product will move to extended support period in 10 months. We cannot promise to fix it by then, if you really need this bug to be fixed for you, you can pay us xxx USD for a hotfix." nuff said bug get never fixed, and will be present in newer product releases. So yes, it's just fantasy for CIOs.
it's also worthwhile mentioning that a lot of 3rd party companies provide support for open source products, it's paid support of course but most of microsoft's support options above the base level are far from free
Can confirm. One of my first programming jobs was with a company doing a lot of .NET work. They had the gold-tier support, or whatever it's called, but we never managed to get anything useful out of it.
Once we got IBM support to fix a bug on their JVM that was making a production WebSphere core dump.
Interestingly, IBM's WebSphere support team are one of the few commercial outfits I had good results from (a decade ago). Super expensive product, but for the environment at the time it was good choice due to the support people actually having a clue. :)
Patreon is a perfect example how well known people get support.
Not only good works or project. But sure, most people are known of their projects.
But not every project is so widely used as Vue, many good and really needed projects has not such a huge audience, and those devs did not get $10K per Month.
So Patreon is not the ultimative solution, it works for a small piece of devs.
Not only good works or project. But sure, most people are known of their projects.
But not every project is so widely used as Vue, many good and really needed projects has not such a huge audience, and those devs did not get $10K per Month.
So Patreon is not the ultimative solution, it works for a small piece of devs.
Let's look at what Evan's offering on his Patreon
Name in file in repository, $10 * 88 = $880
Name top of file in repo, $50 * 5 = $250
Small company logo in file in repo, $100 * 6 = $600
Medium company logo in file in repo, $250 * 0 = $0
Company logo on homepage and Github project: $500 * 11 = $5,500
Company logo on homepage, Github, and in documentation: $2,000 * (limited to one sponsor) = $2,000
So companies are paying for 80% + of the Vue.js income, and the more expensive options with better exposure are in fact more popular than the cheaper ones. To a company, the difference between paying $100 or $500 a month is not worth worrying over, but a direct link from a project page (700k+ impressions per month) is clearly valuable.
Evan should offer more than a single top tier slot, he could have 5 * $4000 instead of 1 * $2000. And why not add a new top-tier for 5-6 figures. If you don't ask, you'll never get it.
Name in file in repository, $10 * 88 = $880
Name top of file in repo, $50 * 5 = $250
Small company logo in file in repo, $100 * 6 = $600
Medium company logo in file in repo, $250 * 0 = $0
Company logo on homepage and Github project: $500 * 11 = $5,500
Company logo on homepage, Github, and in documentation: $2,000 * (limited to one sponsor) = $2,000
So companies are paying for 80% + of the Vue.js income, and the more expensive options with better exposure are in fact more popular than the cheaper ones. To a company, the difference between paying $100 or $500 a month is not worth worrying over, but a direct link from a project page (700k+ impressions per month) is clearly valuable.
Evan should offer more than a single top tier slot, he could have 5 * $4000 instead of 1 * $2000. And why not add a new top-tier for 5-6 figures. If you don't ask, you'll never get it.
> Currently, the Vue's creator is receiving $10k monthly for his works
I think this is commonly used as the best-case for Patreon, i.e. there are very, very few people reaching this, so it's definitely not something to base your future on.
I think this is commonly used as the best-case for Patreon, i.e. there are very, very few people reaching this, so it's definitely not something to base your future on.
Well its not as if the content is that high quality to excuse such a monthly payments. Vue is a tool that is used and appreciated by many and is already very popular. So definitely not Patreon's fault. Also even if you put your work on Patreon you still have to promote it , it does not matter if you make the best software in the world if none knows about it. Patreon is there to help not to do the work for you. Also 10k is far from top 1, not even top 10 or top 20 more like top 50. You need 20k to be on top 10 and more than 60k to be no 1 and I am willing to bet these numbers will only go up. So 10k is certainly awesome but far from best-case.
https://graphtreon.com/top-patreon-creators
https://graphtreon.com/top-patreon-creators
OT, but, I wonder when the Trap get knocked off the top spot?
For other references, I collected dozens of FOSS Patreon pages here (two posts): https://ubuntuforums.org/showthread.php?t=1946197&p=13597636...
Are there any developers on Patreon promising support hours or developing specific features in exchange for a given reward? For evanyou, all I see is visibility.
webpack does this on their open collective: https://medium.com/webpack/webpack-2-2-the-final-release-76c...
Great thought exercise but I feel it's more focused on how developers would like to get paid, versus how people with money would like to pay them. It's telling that the proposed system confers no meaningful rights to the sponsor -- his support grants him only the right to open issues which the developer may choose to consider.
I don't think that would pass muster with most purchasing/procurement people. They would rather just license a piece of software with a clear-cut usage agreement and get a support entitlement. The business value is all in knowing what the software/vendor will deliver and having some guarantees if things go wrong. I meet IT people with purchasing authority _all the time_ who think open source is cool, they love the concept and the values, they know there's great software out there, they're just baffled that they can't buy it and get the type of support they need to replace that decrepit proprietary system that charges 6-7 figure annual license fees. The big open source vendors -- RedHat etc. make tons of money on these situations already, but there's much more to be made and you could argue they aren't returning enough to the devs.
Anyway, the proven money is in selling support contracts, and perhaps if you could pay to have some real influence over feature/bugfixing priorities there would be a market for that as well.
Developers often don't realize that all widely adopted software benefits from having a support team. The support team deals with as many customer inquiries as they can for you, and they inform you about how the software is really being used in the wild. I think there would be a place for some sort of "technical support done for you" service where an open source developer can just hand off the responsibility for support contracts to someone else, and that someone else splits the revenue with the dev.
There's tons of money in the world right now for anyone who familiarizes themselves with a popular open source project and then learns how to do the sales & support for it. It's just that the devs don't want to deal with this stuff.
I don't think that would pass muster with most purchasing/procurement people. They would rather just license a piece of software with a clear-cut usage agreement and get a support entitlement. The business value is all in knowing what the software/vendor will deliver and having some guarantees if things go wrong. I meet IT people with purchasing authority _all the time_ who think open source is cool, they love the concept and the values, they know there's great software out there, they're just baffled that they can't buy it and get the type of support they need to replace that decrepit proprietary system that charges 6-7 figure annual license fees. The big open source vendors -- RedHat etc. make tons of money on these situations already, but there's much more to be made and you could argue they aren't returning enough to the devs.
Anyway, the proven money is in selling support contracts, and perhaps if you could pay to have some real influence over feature/bugfixing priorities there would be a market for that as well.
Developers often don't realize that all widely adopted software benefits from having a support team. The support team deals with as many customer inquiries as they can for you, and they inform you about how the software is really being used in the wild. I think there would be a place for some sort of "technical support done for you" service where an open source developer can just hand off the responsibility for support contracts to someone else, and that someone else splits the revenue with the dev.
There's tons of money in the world right now for anyone who familiarizes themselves with a popular open source project and then learns how to do the sales & support for it. It's just that the devs don't want to deal with this stuff.
It was always my intention that this could in some manner encompass "support contracts" in a way that companies could pay for. I think I mentioned the possibility of tiered pricing; one tier might be "$1000/month, guaranteed reply to issues within 24 hours". I don't know enough of how corporate software support contracts work to flesh out the details here.
There's a lot of variability, but yeah, that's the right general idea.
Support contracts basically come down to providing higher levels of insurance in exchange for charging (potentially exponentially) higher premiums. You CAN guarantee that you'll fix issues. That might raise the monthly commitment to $10K, or even $100K. There are companies which will pay those premiums because it's worth it to them and they might be paying even more to someone like IBM.
You just have to have a really good support org and make them believe that they're going to get what they need, since that sort of commitment doesn't come lightly. An open source project also needs to consider on whether they're giving up too much autonomy by doing this sort of deal, but the opportunities are out there.
I think the idea of having a rider on the support contract which basically says "you get to vote on the next feature we develop" is a very interesting compromise. Basically no proprietary software vendor offers something like that, you're at their whims, if they decide to spend all their dev time on features that lock you in and then they double your licensing fees, tough luck, you have no recourse. If you went to procurement and told them, hey we'll never do that because if enough of our big customers got together they could vote against that work and we'd have to cancel it, it would blow their minds. It would be the ultimate form of insurance against single vendor lock-in. Who knows how much you could charge for that, because most corporations understand very well how much it costs them many millions of dollars to be locked into some proprietary vendor, they just don't see a good alternative.
So cool to get a response from the founder of Tarsnap btw!
Support contracts basically come down to providing higher levels of insurance in exchange for charging (potentially exponentially) higher premiums. You CAN guarantee that you'll fix issues. That might raise the monthly commitment to $10K, or even $100K. There are companies which will pay those premiums because it's worth it to them and they might be paying even more to someone like IBM.
You just have to have a really good support org and make them believe that they're going to get what they need, since that sort of commitment doesn't come lightly. An open source project also needs to consider on whether they're giving up too much autonomy by doing this sort of deal, but the opportunities are out there.
I think the idea of having a rider on the support contract which basically says "you get to vote on the next feature we develop" is a very interesting compromise. Basically no proprietary software vendor offers something like that, you're at their whims, if they decide to spend all their dev time on features that lock you in and then they double your licensing fees, tough luck, you have no recourse. If you went to procurement and told them, hey we'll never do that because if enough of our big customers got together they could vote against that work and we'd have to cancel it, it would blow their minds. It would be the ultimate form of insurance against single vendor lock-in. Who knows how much you could charge for that, because most corporations understand very well how much it costs them many millions of dollars to be locked into some proprietary vendor, they just don't see a good alternative.
So cool to get a response from the founder of Tarsnap btw!
I usually use "guaranteed to respond to the issue within one business day" which gives extra leeway for the weekends/holidays, with the additional provision that I need to give advance warning for things such as vacations, etc..
Most customers I've dealt with seem perfectly fine with that.
The crucial part here is to be careful (as you were) and not say "guaranteed fixing of issues within X".
Most customers I've dealt with seem perfectly fine with that.
The crucial part here is to be careful (as you were) and not say "guaranteed fixing of issues within X".
As a data point, with DB Browser for SQLite (used to be known as "SQLite Browser"), which is reasonably popular (150k+ downloads/mo), we're trying a different approach.
We're making a "Cloud" platform for storing and sharing SQLite databases, with GitHub style forking/merging/social bits & integrating it with the next version of DB Browser for SQLite. Initial dev server online here showing the concept:
https://dev1.dbhub.io/justinclift/Belfast%20Bikes%20Docking%...
It seems like data scientists, universities, and government bodies will find it useful as it meets some needs they have which are completely unaddressed by anything else.
So, we're intending to generate revenue through this to support developing both DB Browser for SQLite and DBHub.io itself, though it's too early stage to say exactly how/what/where/etc yet.
Our initial hope ;) is that GitHub style public == free, private == $ will work. We'll find out over the next few months as we start putting real servers online, measuring usage, and figuring out possibilities from there.
We're making a "Cloud" platform for storing and sharing SQLite databases, with GitHub style forking/merging/social bits & integrating it with the next version of DB Browser for SQLite. Initial dev server online here showing the concept:
https://dev1.dbhub.io/justinclift/Belfast%20Bikes%20Docking%...
It seems like data scientists, universities, and government bodies will find it useful as it meets some needs they have which are completely unaddressed by anything else.
So, we're intending to generate revenue through this to support developing both DB Browser for SQLite and DBHub.io itself, though it's too early stage to say exactly how/what/where/etc yet.
Our initial hope ;) is that GitHub style public == free, private == $ will work. We'll find out over the next few months as we start putting real servers online, measuring usage, and figuring out possibilities from there.
A few years ago I built a site addressed to this problem. I had seen BountySource, but thought they didn't have the right system, so decided to take a crack at it myself. The site was pretty rough, but even so, I was surprised when my "Show HN" posts about it drew nothing but crickets. Subsequent attempts to stimulate discussion on the topic here, by posting on the related threads that pop up from time to time, were also pretty much failures. I lost interest, shut the site down, and moved on.
So Colin, I think you're doing the right thing by soliciting feedback before you try to build anything. This seems like a real problem, and one that should have a solution, but somehow there just aren't as many people who want to make a living as independent open source developers as one might think.
It's true I didn't do much evangelizing. As I think is mentioned somewhere on the YC site, two-sided marketplaces, which is what this is, are especially difficult to get going, so it's not surprising that a half-hearted effort wouldn't have gotten me far. Anyway, I'm not absolutely convinced that, with far more effort than I put into it, I couldn't have turned this into a viable lifestyle business. But it did seem clear that at the very least, I had not hit a nerve.
Edit: clarity
So Colin, I think you're doing the right thing by soliciting feedback before you try to build anything. This seems like a real problem, and one that should have a solution, but somehow there just aren't as many people who want to make a living as independent open source developers as one might think.
It's true I didn't do much evangelizing. As I think is mentioned somewhere on the YC site, two-sided marketplaces, which is what this is, are especially difficult to get going, so it's not surprising that a half-hearted effort wouldn't have gotten me far. Anyway, I'm not absolutely convinced that, with far more effort than I put into it, I couldn't have turned this into a viable lifestyle business. But it did seem clear that at the very least, I had not hit a nerve.
Edit: clarity
The biggest problem is that these things only really address user visible software. The modern tech stack is as deep as it is wide and even as a developer I often have little knowledge of who's maintaining things more than one level down from me.
Say I publish an awesome and useful library but suck at UI stuff, the person that comes along and incorporates my library in a slick front end would probably get the donations.
Say I publish an awesome and useful library but suck at UI stuff, the person that comes along and incorporates my library in a slick front end would probably get the donations.
> Say I publish an awesome and useful library but suck at UI stuff, the person that comes along and incorporates my library in a slick front end would probably get the donations.
Yep. One of my OSS projects has been installed 27 million times to date (and that metric doesn't track WordPress, which uses it), but it's unlikely to yield any sort of support contracts or revenue.
https://packagist.org/packages/paragonie/random_compat
I do get contacted to resolve support issues, but it's almost always solved by "Contact your host and tell them to make the following configuration change, because nothing I can devise will be secure without those changes".
Yep. One of my OSS projects has been installed 27 million times to date (and that metric doesn't track WordPress, which uses it), but it's unlikely to yield any sort of support contracts or revenue.
https://packagist.org/packages/paragonie/random_compat
I do get contacted to resolve support issues, but it's almost always solved by "Contact your host and tell them to make the following configuration change, because nothing I can devise will be secure without those changes".
Can you provide more detail about how your system worked? Based on the name (bountyoss) it sounds like it was more based on bounties rather than ongoing funding for maintenance and support?
Yes, I was thinking that bounties could be used for maintenance. Developers would post proposals for bug fixes and features. These proposals could stay open indefinitely, and there was no limit on the number of proposals a developer could post. At some point, the thinking went, the total bounty that users had pledged to a proposal would reach a point sufficient to prompt the developer to accept the bounty and start development. There was a fairly elaborate (i.e., probably over-engineered) process for acceptance of the work product, in which contributors could vote on it, their votes being weighted by their contributions, and the developer had three chances to obtain their approval.
I tried to design the system so that a business that was using some piece of open-source software and wanted something done to it could justify spending the money. I don't know that I succeeded in that, but it was a goal, and I think that any system like this would have to appeal to businesses in order to succeed. I did not see it as being like Patreon or even Kickstarter; I saw it as a B2B site, where both sides were engaging in transactions for business reasons and needed their interests protected.
I tried to design the system so that a business that was using some piece of open-source software and wanted something done to it could justify spending the money. I don't know that I succeeded in that, but it was a goal, and I think that any system like this would have to appeal to businesses in order to succeed. I did not see it as being like Patreon or even Kickstarter; I saw it as a B2B site, where both sides were engaging in transactions for business reasons and needed their interests protected.
both sides were engaging in transactions for business reasons and needed their interests protected
Yeah, I struggled with this part. As a security guy, I prefer to create systems which are hard to exploit; but there's a point where it becomes too heavy-weight. If you're contributing $100 into a pot towards some code being written, how many hours are you going to want to spend to verify that the code being submitted is actually good?
I think a monthly subscription model solves part of the problem, since people who don't do good work would lose their sponsors over time. I'd also be inclined to say that people can cancel their sponsorship at any time and not pay for the past month -- which could be abused (sign up as a $10,000/month sponsor, ask for a feature, then cancel your subscription) but I think it's better than the alternative.
Yeah, I struggled with this part. As a security guy, I prefer to create systems which are hard to exploit; but there's a point where it becomes too heavy-weight. If you're contributing $100 into a pot towards some code being written, how many hours are you going to want to spend to verify that the code being submitted is actually good?
I think a monthly subscription model solves part of the problem, since people who don't do good work would lose their sponsors over time. I'd also be inclined to say that people can cancel their sponsorship at any time and not pay for the past month -- which could be abused (sign up as a $10,000/month sponsor, ask for a feature, then cancel your subscription) but I think it's better than the alternative.
> As a security guy, I prefer to create systems which are hard to exploit
Yeah, me too. BountyOSS would even send contributors cryptographically signed receipts, which they could forward to developers to give the latter a way to check that BountyOSS wasn't skimming off more than our advertised share of the proceeds.
> If you're contributing $100 into a pot towards some code being written, how many hours are you going to want to spend to verify that the code being submitted is actually good?
Well, it depends. Maybe you needed that bug fix badly. My sense was that it would be sufficient to provide an approval process whereby, if a contributor didn't go to the effort to test the work product properly; the other contributors collectively approved the work (so the developer got paid); and then this contributor later discovered a flaw that was critical for them, they would at least feel that they had the opportunity to test it and it was their own fault they failed to do so. The site as built gave users 10 days to test the code and cast their votes; I could imagine adjusting that upward (and maybe even scaling it by the bounty amount, on the theory that large amounts of work take longer to test).
I think the reality, most of the time, would be that only the most demanding contributors would really invest much testing effort, but that's all you would need anyway. (The fact that their votes are weighted by their contributions is another incentive to pledge a substantial amount if the functionality is important to them.)
Not sure what I think about the subscription idea. That seems a lot like a support contract; and then what's the added value of having this site in the middle of the transaction? The attraction of the bounty model is that there's a good answer to that question: the site, with its approval process, performs an escrow-like function (though one must be careful with that word so as not to run afoul of laws governing escrow providers; I convinced myself at the time that my site was in the clear on this, but IANAL and YMMV).
Yeah, me too. BountyOSS would even send contributors cryptographically signed receipts, which they could forward to developers to give the latter a way to check that BountyOSS wasn't skimming off more than our advertised share of the proceeds.
> If you're contributing $100 into a pot towards some code being written, how many hours are you going to want to spend to verify that the code being submitted is actually good?
Well, it depends. Maybe you needed that bug fix badly. My sense was that it would be sufficient to provide an approval process whereby, if a contributor didn't go to the effort to test the work product properly; the other contributors collectively approved the work (so the developer got paid); and then this contributor later discovered a flaw that was critical for them, they would at least feel that they had the opportunity to test it and it was their own fault they failed to do so. The site as built gave users 10 days to test the code and cast their votes; I could imagine adjusting that upward (and maybe even scaling it by the bounty amount, on the theory that large amounts of work take longer to test).
I think the reality, most of the time, would be that only the most demanding contributors would really invest much testing effort, but that's all you would need anyway. (The fact that their votes are weighted by their contributions is another incentive to pledge a substantial amount if the functionality is important to them.)
Not sure what I think about the subscription idea. That seems a lot like a support contract; and then what's the added value of having this site in the middle of the transaction? The attraction of the bounty model is that there's a good answer to that question: the site, with its approval process, performs an escrow-like function (though one must be careful with that word so as not to run afoul of laws governing escrow providers; I convinced myself at the time that my site was in the clear on this, but IANAL and YMMV).
Not sure what I think about the subscription idea. That seems a lot like a support contract; and then what's the added value of having this site in the middle of the transaction?
"A lot like a support contract" is precisely what this is intended to be. The reason for having the site in the middle is that the vast majority of open source software developers don't have a clue about how to negotiate and manage a support contract.
When I first started thinking about this, I started at "we need to make it simpler for open source developers to sell support contracts" -- it was only a few weeks later that I decided that it might make a lot of sense to combine "support contract" with "some people will simply want to contribute, whether they get anything back or not".
"A lot like a support contract" is precisely what this is intended to be. The reason for having the site in the middle is that the vast majority of open source software developers don't have a clue about how to negotiate and manage a support contract.
When I first started thinking about this, I started at "we need to make it simpler for open source developers to sell support contracts" -- it was only a few weeks later that I decided that it might make a lot of sense to combine "support contract" with "some people will simply want to contribute, whether they get anything back or not".
I came to suspect, by the way, that a site like mine would be useful primarily for a particular kind of open-source project: one large and mature enough to have a significant user base -- a significant commercial user base -- yet not so mature that it already does most of what its users want, nor so large that it already has a well-known business supporting it. The best example of such a project I can think of offhand is D. It might be interesting to ask Walter Bright specifically what he thinks about this or would want in such a site.
I also think it's important to understand what the value is for contributors. I think we both have the same observation here: one thing an open-source developer has to sell is their choice of what to do next. Imagine a developer using an OSS package and trying to get their manager's approval to spend money to get some bug fixed or some new feature; they have to have a good answer to the question, "why are we spending this money?". After all, it's possible that if they just wait long enough, the fix or feature will appear anyway. And I think generally, the answer is that by offering to pay, they influence the developer's choice of what to spend their time on; this gives them an incentive to offer an amount related to the cost, to them, of not having the fix or feature.
I also think it's important to understand what the value is for contributors. I think we both have the same observation here: one thing an open-source developer has to sell is their choice of what to do next. Imagine a developer using an OSS package and trying to get their manager's approval to spend money to get some bug fixed or some new feature; they have to have a good answer to the question, "why are we spending this money?". After all, it's possible that if they just wait long enough, the fix or feature will appear anyway. And I think generally, the answer is that by offering to pay, they influence the developer's choice of what to spend their time on; this gives them an incentive to offer an amount related to the cost, to them, of not having the fix or feature.
The main problem I see with this is misalignment of interests. If you are a founder of OSS project who gets contracted to do support work then the amount of money depends on number of users and pain level of their problems. Which means it is not in your interest to develop robust and bug-free software. Of course, it must still be usable, just not technically perfect (there are many successful OSS projects which are nightmare to support - the latest I saw was SuiteCRM, but there are many others).
The solution would be to build a platform which would collect some fixed amount of money from enterprises in exchange for support on all OSS projects said enterprise uses (limited by hours per month?). Foundation behind the platform should employ or sign contracts with maintainers of different projects. It would also employ developers willing to maintain different projects where maintainers are not prepared to help. All fixes should then be offered as pull requests back to original maintainers, or in case of still used but abandoned projects a support fork could be made.
I am sure there are hole in this scheme too - if there weren't somebody would have implemented it already. But I see this as win/win/win solution. Hell, I would love to work for such foundation. I also see my company paying for such support. And it definitely benefits OSS projects. So what am I missing?
EDIT: just to clarify, enterprise gets a number of hours per month which are used in part for active support and features development but also for maintenance of projects (cleaning / refactoring code, writing tests, documentation,...) they use. And maintenance should also be used on libraries these projects use, so the effect should trickle all the way down.
The solution would be to build a platform which would collect some fixed amount of money from enterprises in exchange for support on all OSS projects said enterprise uses (limited by hours per month?). Foundation behind the platform should employ or sign contracts with maintainers of different projects. It would also employ developers willing to maintain different projects where maintainers are not prepared to help. All fixes should then be offered as pull requests back to original maintainers, or in case of still used but abandoned projects a support fork could be made.
I am sure there are hole in this scheme too - if there weren't somebody would have implemented it already. But I see this as win/win/win solution. Hell, I would love to work for such foundation. I also see my company paying for such support. And it definitely benefits OSS projects. So what am I missing?
EDIT: just to clarify, enterprise gets a number of hours per month which are used in part for active support and features development but also for maintenance of projects (cleaning / refactoring code, writing tests, documentation,...) they use. And maintenance should also be used on libraries these projects use, so the effect should trickle all the way down.
... the amount of money depends on number of users and pain level of their problems. Which means it is not in your interest to develop robust and bug-free software.
Agreed. I've heard people refer to producing highly painful software in order to encourage support contracts as the "RedHat model" of open source software.
But it cuts both ways -- if you as a developer have a bunch of people signed up to pay you monthly, you'd like to get their money while doing the minimum possible amount of work; so there's an incentive for you to make your software bug-free and easy to use so that your supporters aren't bugging (no pun intended) you all the time.
Agreed. I've heard people refer to producing highly painful software in order to encourage support contracts as the "RedHat model" of open source software.
But it cuts both ways -- if you as a developer have a bunch of people signed up to pay you monthly, you'd like to get their money while doing the minimum possible amount of work; so there's an incentive for you to make your software bug-free and easy to use so that your supporters aren't bugging (no pun intended) you all the time.
Disclaimer: My company basically has this model for AI. We work heavily with consulting companies and have a licensing structure relative to the number of cpu/gpu cores you use.
We have found this to be a great way to charge. There's a clear value prop for the customer when they see what they get (usually compliance features, security,..). Also for both sides, there's some basic reassurances: The company won't disappear because they make money, and the vendor has incentives to do what they say they do.
A more mainstream company I think HN knows more of that does this is gitlab.
I'm definitely not a "save the world" type founder. I run a for profit entity focused on commercializing technology that captures a large market opportunity.
Our product is open core for marketing, recruiting, and distribution purposes.
Because we're open source, I get to write books, run classes, and speak at technology conferences all over the world as way of doing sales and marketing. Turns out it works.
As a side benefit, we also get a small share of the market that use us in academic research.
As a comparison: The major cloud vendors all "run" and market open source frameworks in AI to get more people to spend money on their compute clouds (same reason they give away credits).
Widely used open source projects usually have commercial backing somewhere in the chain.
My biased opinion I would love to learn counter points about: These utopian platforms can't work. They might be a great way to make a short term living. It feels like there wouldn't be incentives for maintenance or support under this kind of model for individual developers. My biggest reason for this is the support volume. Once you get to a certain scale, that "small repo developer" has a risk of getting overwhelmed. Pretty soon they hire someone. Then it's not about just code anymore. Granted, you can share the work among several contributors eventually, but at scale, this becomes fragile at some point.
This is a big reason why these things end up being companies.
We have found this to be a great way to charge. There's a clear value prop for the customer when they see what they get (usually compliance features, security,..). Also for both sides, there's some basic reassurances: The company won't disappear because they make money, and the vendor has incentives to do what they say they do.
A more mainstream company I think HN knows more of that does this is gitlab.
I'm definitely not a "save the world" type founder. I run a for profit entity focused on commercializing technology that captures a large market opportunity.
Our product is open core for marketing, recruiting, and distribution purposes.
Because we're open source, I get to write books, run classes, and speak at technology conferences all over the world as way of doing sales and marketing. Turns out it works.
As a side benefit, we also get a small share of the market that use us in academic research.
As a comparison: The major cloud vendors all "run" and market open source frameworks in AI to get more people to spend money on their compute clouds (same reason they give away credits).
Widely used open source projects usually have commercial backing somewhere in the chain.
My biased opinion I would love to learn counter points about: These utopian platforms can't work. They might be a great way to make a short term living. It feels like there wouldn't be incentives for maintenance or support under this kind of model for individual developers. My biggest reason for this is the support volume. Once you get to a certain scale, that "small repo developer" has a risk of getting overwhelmed. Pretty soon they hire someone. Then it's not about just code anymore. Granted, you can share the work among several contributors eventually, but at scale, this becomes fragile at some point.
This is a big reason why these things end up being companies.
Or IBM, SAP,.... business model as well, as it is how every enterprise product works, one needs consulting to use them at all.
There will always be some amount of this at play. But changing motivation of people offering support ("you get paid because this works, not because it breaks") would result in much better software and better aligned interests of all parties involved.
Most maintainers wouldn't want to be or couldn't be an employee of such a company (e.g. due to existing employment contracts). I'd also question whether it's healthy to centralize the development of all OSS projects used by all your customers into one platform like this.
That is fine, and there is no need for it. That wouldn't be viable anyway (except for node.js and projects of similar size).
The foundation pays someone else (their contractor) to fix a bug in the OSS project and to make a pull request to the project maintainer. This way the bugs get fixed, enterprise have their support and contractor gets paid. Maintainer of the project also gets something - fixes of his code by seasoned professionals, paid to do their work.
The foundation pays someone else (their contractor) to fix a bug in the OSS project and to make a pull request to the project maintainer. This way the bugs get fixed, enterprise have their support and contractor gets paid. Maintainer of the project also gets something - fixes of his code by seasoned professionals, paid to do their work.
I don't think there is a misalignment of interest. Robust software is also correlated to the number of users. In my experience there is also no need to worry about not having enough open problems to work on. It could happen in theory I guess, but projects tend to have more open problems and feature wishes than developer time. If your software is used there will always be people asking for more features to work on. You don't get more projects because there are too many problems in your software which need fixing - you get more projects because your software is good and you are known to be the person to fix problems.
> would collect some fixed amount of money from enterprises in exchange for support on all OSS projects said enterprise uses (limited by hours per month?).
That's called getting a job with said enterprise.
That's called getting a job with said enterprise.
Yes, if you developed Keras and enterprise is Google. But what if enterprise wants to use some small plugin for Wordpress which is opensource, and needs some new functionality or a bug fixed? It seems unlikely that each enterprise will offer a job to each of the OSS maintainers, even if the said persons are even willing to offer such support.
It's more like paying a company like RedHat to do this work managing and testing OSS for you.
Not true. Support is fundamental to many software businesses and has been for a very very long time and I don't feel that people see it as a way to get developers to write bad software.
I think it would be better to focus on getting businesses who use open source software to pay the authors of the software. Businesses have money, most users of open source software don't have enough money to pay for (F)OSS donations or support.
The other issue with the model of paying for support is that it's just not scalable for the authors. What do the authors do if a big corp asks for support regarding something that only happens at scale? It's a huge time sink for the authors.
Here's my suggestion :
1) Get businesses to support authors of the software they use, by paying.
2) Get businesses to contribute to the development of the software. Eg- Have employees work on the code base.
I haven't thought about this enough, but a marketplace which lists software projects and their contributors, and companies can support projects of their choosing by paying monthly or annually. Individual users should also be able to contribute if they want to.
The other issue with the model of paying for support is that it's just not scalable for the authors. What do the authors do if a big corp asks for support regarding something that only happens at scale? It's a huge time sink for the authors.
Here's my suggestion :
1) Get businesses to support authors of the software they use, by paying.
2) Get businesses to contribute to the development of the software. Eg- Have employees work on the code base.
I haven't thought about this enough, but a marketplace which lists software projects and their contributors, and companies can support projects of their choosing by paying monthly or annually. Individual users should also be able to contribute if they want to.
Oss maintainers also need to provide 'commercial' licences that are no different to the normal license, except they come with an invoice. Some companies are happy to pay for free software as long as there is an invoice to keep the accounting people happy. A donation model doesn't work here.
What do the authors do if a big corp asks for support regarding something that only happens at scale?
I don't see the problem here. Presumably a big corp could afford to pay enough for support that a developer would be inclined to help even if said big corp was the only user encountering a particular problem.
I don't see the problem here. Presumably a big corp could afford to pay enough for support that a developer would be inclined to help even if said big corp was the only user encountering a particular problem.
It is more likely that big corp will have their own team fix the problem, unless the original code is too big or convoluted.
The majority of big corp outside IT world just use consulting.
If they happen to have an internal team, it is mostly to manage contractors and architecture decisions for what they want to get delivered to them.
If they happen to have an internal team, it is mostly to manage contractors and architecture decisions for what they want to get delivered to them.
I would count consultant as "own team" in this scenario. Someone company controls at that time, knows company code/cases and is available more or less instantly. A lot depends on how much special knowledge is needed to understand open source project codebase etc. Ordering contractors you already know around is easier then ordering someone on other side of the world who has different employer and priorities.
Actually big businesses pay to people to develop FOSS
Lots of mutations of this idea exist since the 1990s. Perhaps Snowdrift now matches OP's desire as it includes subscription donations: https://snowdrift.coop/how-it-works
To learn a lot about the field and its history:
https://wiki.snowdrift.coop/market-research/other-crowdfundi...
https://wiki.snowdrift.coop/market-research/history/software
To learn a lot about the field and its history:
https://wiki.snowdrift.coop/market-research/other-crowdfundi...
https://wiki.snowdrift.coop/market-research/history/software
It seems like snowdrift is crowdsourced fundraising aimed at open source software, but doesn't have the "issue tracker" / quasi-"support contracts" side of what I'm envisioning?
I'm on the snowdrift.coop team. This type of thing was part of the original vision -- you'll see bits and pieces if you poke around our wiki[0] -- and remains that way.
Ironically, we struggle from the same funding problem we're looking to solve. At some point we realized we needed to drastically reduce scope if we were ever going to launch. For context, Snowdrift has been around for slightly longer than Patreon, but we didn't receive several million dollars of VC funding (or solicit it -- our mission is strictly ethical, not competitive[1]). We're planning on adding community-support-type features back in as we (hopefully) grow and open up the platform to more projects.
I'm happy to chat more, but am also in the hectic last few days of my semester; I'll come back to this but am not sure exactly when. If you'd like to get someone else's response, you can try pinging people in #snowdrift on freenode.
[0]: https://wiki.snowdrift.coop/
[1] If someone else succeeds at creating sustainable support for FLO projects, we'll gladly pack our bags and join them. That said, there have been many, many other crowdfunding sites that fail in one respect or another[2]; I'm hopeful for snowdrift.coop because our Crowdmatching mechanism[3] has some unique properties and has never been tried before. (Also, I'm realizing the linked page has some details that are out of date; the general idea of a matching pledge remains.)
[2]: https://wiki.snowdrift.coop/market-research/other-crowdfundi... [3]: https://wiki.snowdrift.coop/about/mechanism
Ironically, we struggle from the same funding problem we're looking to solve. At some point we realized we needed to drastically reduce scope if we were ever going to launch. For context, Snowdrift has been around for slightly longer than Patreon, but we didn't receive several million dollars of VC funding (or solicit it -- our mission is strictly ethical, not competitive[1]). We're planning on adding community-support-type features back in as we (hopefully) grow and open up the platform to more projects.
I'm happy to chat more, but am also in the hectic last few days of my semester; I'll come back to this but am not sure exactly when. If you'd like to get someone else's response, you can try pinging people in #snowdrift on freenode.
[0]: https://wiki.snowdrift.coop/
[1] If someone else succeeds at creating sustainable support for FLO projects, we'll gladly pack our bags and join them. That said, there have been many, many other crowdfunding sites that fail in one respect or another[2]; I'm hopeful for snowdrift.coop because our Crowdmatching mechanism[3] has some unique properties and has never been tried before. (Also, I'm realizing the linked page has some details that are out of date; the general idea of a matching pledge remains.)
[2]: https://wiki.snowdrift.coop/market-research/other-crowdfundi... [3]: https://wiki.snowdrift.coop/about/mechanism
I asked on IRC #snowdrift @ Freenode and Bryan Richter said:
"We recognize that a funding mechanism is only one small piece of the puzzle for supporting public works! The founder wolftune in fact envisions an all inclusive site with integrated issue tracking and all manner of things. But we are trying to keep our scope realistic, and besides there are some pretty good FLO tools out there these days."
"We recognize that a funding mechanism is only one small piece of the puzzle for supporting public works! The founder wolftune in fact envisions an all inclusive site with integrated issue tracking and all manner of things. But we are trying to keep our scope realistic, and besides there are some pretty good FLO tools out there these days."
There are two economic factors that come into play here:
1. Open source software is price anchored at $0. I know that there are commercial alternatives that might anchor open source software: say Photoshop for Gimp. But the direct pricing is "Here, it's free."
2. I run Ubuntu. A measly $5.00 per piece of open source adds up to many thousands of dollars. That's not going to happen, even if it was practical. Someone is surely getting stiffed. If I think about libraries like padleft too, then it's pretty much everyone...or to a first approximation, everyone.
Should I send a check to Google for Chromium and throw a quarter toward Facebook every time I visit a website that uses React.js? What about a utility that's compiled with GCC, do I write one check to the author and another to FSF?
It's just not that simple.
1. Open source software is price anchored at $0. I know that there are commercial alternatives that might anchor open source software: say Photoshop for Gimp. But the direct pricing is "Here, it's free."
2. I run Ubuntu. A measly $5.00 per piece of open source adds up to many thousands of dollars. That's not going to happen, even if it was practical. Someone is surely getting stiffed. If I think about libraries like padleft too, then it's pretty much everyone...or to a first approximation, everyone.
Should I send a check to Google for Chromium and throw a quarter toward Facebook every time I visit a website that uses React.js? What about a utility that's compiled with GCC, do I write one check to the author and another to FSF?
It's just not that simple.
I like the idea of https://flattr.com/
The consumer just pushes money into his account (maybe 5$ monthly) and lets the system distribute it monthly.
The distribution is influenced by visiting flattr-enabled websites, staring projects on Github, etc.
However, this is a donation system. There is no obligation for the receiver, while Percival envisions it as payment for maintenance.
The consumer just pushes money into his account (maybe 5$ monthly) and lets the system distribute it monthly.
The distribution is influenced by visiting flattr-enabled websites, staring projects on Github, etc.
However, this is a donation system. There is no obligation for the receiver, while Percival envisions it as payment for maintenance.
That's sort of how digital music streaming works...for consumers mostly and not so much for creators. I mean even if I put $100/month into something like Flattr, across the thousands of open source authors whose work I use, each would get about a penny.
If someone were to go ahead and build the proposed sponsorship platform, it ought to have some method to identify dependencies - either through developers manually specifying them, or through automated analysis of package manager dependencies etc etc - and somehow automatically allocate some percentage of donations accordingly. No, such a system wouldn't be perfect, but it would be better than nothing.
It would certainly be easy to implement "take $X (or X%) out of the money I receive and give them to foo instead". Of course, that would only work if both projects were using the same platform.
BountySource (https://www.bountysource.com/) tries to monetize bug fixes and light work. This is probably closer to the Bugzilla side of the proposed solution.
IMHO the core problem, dependencies, is not addressed in the solution. "A lot of mid-size companies would like to be able to pay for support for the software they're using, but can't find anyone to provide it." makes a whole lot of sense for people developing products that are directly consumed by companies, but that funding rarely if ever reaches the developers of the dependencies. So you end up with a situation where people developing interfaces for technologies (and not those developing the core technologies) receiving the lion share of donations in the open source space.
If you think about open source development as "basic research", the current state of affairs makes perfect sense and the "funding model" is well-established: government grants or private grants (e.g. GSOC or hiring the developers).
IMHO the core problem, dependencies, is not addressed in the solution. "A lot of mid-size companies would like to be able to pay for support for the software they're using, but can't find anyone to provide it." makes a whole lot of sense for people developing products that are directly consumed by companies, but that funding rarely if ever reaches the developers of the dependencies. So you end up with a situation where people developing interfaces for technologies (and not those developing the core technologies) receiving the lion share of donations in the open source space.
If you think about open source development as "basic research", the current state of affairs makes perfect sense and the "funding model" is well-established: government grants or private grants (e.g. GSOC or hiring the developers).
There's also a monthly recurring donation platform:
https://salt.bountysource.com/
https://salt.bountysource.com/
There is also https://gratipay.com/ where you can donate a set amount every month instead of paying bug bounties.
I feel like there is a lot more glue code (that is, interfaces connecting core technologies) than there is code making up the core technologies themselves. From this it follows logically that the developers of the former ought to receive the lion's share of funding because they do the lion's share of the work.
I feel like there is a lot more glue code (that is, interfaces connecting core technologies) than there is code making up the core technologies themselves. From this it follows logically that the developers of the former ought to receive the lion's share of funding because they do the lion's share of the work.
[deleted]
This is the exact thing that I've been working on for the last year and a half. The biggest hurdle is actually handling the flow of money.
Because, unlike say Kickstarter/Patreon, where the money goes to a single entity/person, open source collaborations tend to be distributed and dynamic. So you effectively need to build a payments company and handle all of the headache that goes along with it.
But, having said that, I very much believe that something like this is needed — and thus why I'm still persevering with the project. Happy to chat further if cperciva/others are interested.
Because, unlike say Kickstarter/Patreon, where the money goes to a single entity/person, open source collaborations tend to be distributed and dynamic. So you effectively need to build a payments company and handle all of the headache that goes along with it.
But, having said that, I very much believe that something like this is needed — and thus why I'm still persevering with the project. Happy to chat further if cperciva/others are interested.
I think there are enough solo developers -- solo either because they're the only person working on a project, or because they're the only person working on a specific part of a project -- that this could be very useful even without the headache of splitting money between teams.
I agree that it would be good to be able to handle larger teams at some point, but it might be easier to figure out how to do that after seeing how people used a "solo developer" version of this.
I agree that it would be good to be able to handle larger teams at some point, but it might be easier to figure out how to do that after seeing how people used a "solo developer" version of this.
tav, have you looked at Stripe's Connect product (https://stripe.com/connect)? Stripe already is a payments company, and Connect is built to let you use it somewhat like your own payments company, to pay others. Lyft uses it to pay its drivers for example, who also tend to be distributed and dynamic.
(Disclaimer: I work for Stripe, as of like last week. :)
(Disclaimer: I work for Stripe, as of like last week. :)
Yes, that was actually the original plan. It all seemed so easy! Let developers connect their standalone Stripe accounts and have sponsors pay directly into those accounts. But this proved problematic for a few reasons, e.g.
* Most developers didn't want to handle matters like global VAT reporting individually, so ideally the money would flow through a central entity which took care of that for them so that they only have to deal with a single source of income.
* The need to support ad-hoc transfer of funds between standalone accounts when maintainers approved transfers to other developers they are collaborating with.
Stripe Connect with managed accounts helps to solve some of these issues, e.g. by creating charges on the platform account and then creating individual transfers to connected accounts. But according to https://stripe.com/docs/connect/charges-transfers:
"This approach is only fully supported when both your platform and the connected account are in the U.S. If your platform or the connected account is outside of the U.S., you can only use this approach for less than 10% of your total volume."
So, is there some other method that's available? Because right now, I'm looking at handling the payouts myself and using Stripe to handle just the incoming payment processing. And it'd be great to use Stripe for both instead!
(P.S. Congrats on the new job!)
* Most developers didn't want to handle matters like global VAT reporting individually, so ideally the money would flow through a central entity which took care of that for them so that they only have to deal with a single source of income.
* The need to support ad-hoc transfer of funds between standalone accounts when maintainers approved transfers to other developers they are collaborating with.
Stripe Connect with managed accounts helps to solve some of these issues, e.g. by creating charges on the platform account and then creating individual transfers to connected accounts. But according to https://stripe.com/docs/connect/charges-transfers:
"This approach is only fully supported when both your platform and the connected account are in the U.S. If your platform or the connected account is outside of the U.S., you can only use this approach for less than 10% of your total volume."
So, is there some other method that's available? Because right now, I'm looking at handling the payouts myself and using Stripe to handle just the incoming payment processing. And it'd be great to use Stripe for both instead!
(P.S. Congrats on the new job!)
tav, I'm sorry for my delay getting back to you. I just sent you an email at your profile address to introduce you to someone on our New Business team, who may be able to help.
Open source funding is a cause near and dear to my heart, and I hope something is able to work out.
(And thanks!)
Open source funding is a cause near and dear to my heart, and I hope something is able to work out.
(And thanks!)
What can we learn from the music industry? Both software and music experience a lot of piracy.
Apple Music & Spotify are using a subscription model, like you suggest.
YouTube is using advertising. So are Facebook, Google, and many web & mobile apps. Thankfully there's not been much advertising in desktop OS platforms (until Windows 10).
Some bands still sell CDs. It's a while since I saw software on an optical disc, but that could be a way to sell it.
Buskers beg for money on the streets. Wikipedia and the EFF do this, asking for donations.
Indie bands make most of their money by touring and performing live concerts. How can software be performed live? Hiring a developer to implement it in a big organisation? Paid workshops/training courses? I think that there's more opportunity for growth in this area.
Apple Music & Spotify are using a subscription model, like you suggest.
YouTube is using advertising. So are Facebook, Google, and many web & mobile apps. Thankfully there's not been much advertising in desktop OS platforms (until Windows 10).
Some bands still sell CDs. It's a while since I saw software on an optical disc, but that could be a way to sell it.
Buskers beg for money on the streets. Wikipedia and the EFF do this, asking for donations.
Indie bands make most of their money by touring and performing live concerts. How can software be performed live? Hiring a developer to implement it in a big organisation? Paid workshops/training courses? I think that there's more opportunity for growth in this area.
Software as a service is an excellent way to protect against piracy which is why its growing so fast. You can offer your client your software free that he could get through piracy but instead you keep him close and offer him a monthly service of improvements and support that the pirated software cannot offer. If he is unwilling to pay then a) he is not really interested b) he is not able to afford it . So you know that in his case piracy is not really a problem because he is not a potential client. Just because someone pirate something does not mean he is a potential client. Also piracy is not a new thing, I have been in front a computer since 1988 and piracy was there since day 1, software, games , music and film. Sure the internet made it easier but it was already super easy when I was teenager I had ton of pirated music because the price of a CD was certainly nowhere near my budget. The problem got worse because a) the industries became very, very greedy b) quality droped for the sake of mass production (especially true for the music industry) . So companies are 90% to blame here and not piracy.
Yes, good points. I think it is unfortunate that you can't really get paid for writing the open source code itself. You can get paid to write books, speak, or work for a big company.
I would guess that authors of books about Python have made more money than Guido himself did off Python, which seems a little wrong.
But I suppose the situation isn't different from that of other people who produce "IP", as you say. Recording the brilliant album is not enough -- you have to market it and go on tour too.
I would guess that authors of books about Python have made more money than Guido himself did off Python, which seems a little wrong.
But I suppose the situation isn't different from that of other people who produce "IP", as you say. Recording the brilliant album is not enough -- you have to market it and go on tour too.
I think about this a lot. Imagine a world in which all software (and other "IP") is FLO. How do we decide how to distribute money, without the mechanism of "consumers buy what they want and are willing to pay for"?
The best answer I have is -- it's no longer about paying for the software -- after all, anybody can fork it -- it's about paying the developer. If you've really enjoyed the Civ games, maybe you give your monthly donation to Sid Meyer. If you love Starcraft and Hearthstone, donate to Blizzard.
While there's some groupthink and over-indexing for excitement to look out for in such a system, the prospect of a more human-oriented approach to funding FLO development is exciting to me.
The best answer I have is -- it's no longer about paying for the software -- after all, anybody can fork it -- it's about paying the developer. If you've really enjoyed the Civ games, maybe you give your monthly donation to Sid Meyer. If you love Starcraft and Hearthstone, donate to Blizzard.
While there's some groupthink and over-indexing for excitement to look out for in such a system, the prospect of a more human-oriented approach to funding FLO development is exciting to me.
I somewhat agree with that, but the big problem I see is credit and politics.
Guido didn't develop Python alone -- there are a huge number of equally talented and hard-working Python contributors. How do you determine what to pay each one of them?
You could give the money to Guido to redistribute, but now you have a huge political problem on your hands, and the possibility of slowing down the project through hurt feelings and the like.
There's really no good solution that I see. That's not to say that we can't improve on the status quo, though. Patreon seems like a good step, though I haven't used it.
It's kind of a hole in capitalism, but I guess human nature has evolved to fill that hole. Some people are just motivated to do huge amounts of quality work, for the greater good, regardless of compensation.
I suppose the idea is that by paying people, we could encourage more work that benefits society. But to play devil's advocate, maybe it would have the opposite effect? Those people aren't motivated by money. Maybe paying them would bias the work they produce... they would come up with stuff that seems more "saleable/donateable" NOW rather than being creative about the things we need 10 years from now.
Guido didn't develop Python alone -- there are a huge number of equally talented and hard-working Python contributors. How do you determine what to pay each one of them?
You could give the money to Guido to redistribute, but now you have a huge political problem on your hands, and the possibility of slowing down the project through hurt feelings and the like.
There's really no good solution that I see. That's not to say that we can't improve on the status quo, though. Patreon seems like a good step, though I haven't used it.
It's kind of a hole in capitalism, but I guess human nature has evolved to fill that hole. Some people are just motivated to do huge amounts of quality work, for the greater good, regardless of compensation.
I suppose the idea is that by paying people, we could encourage more work that benefits society. But to play devil's advocate, maybe it would have the opposite effect? Those people aren't motivated by money. Maybe paying them would bias the work they produce... they would come up with stuff that seems more "saleable/donateable" NOW rather than being creative about the things we need 10 years from now.
> by paying people, we could encourage more work that benefits society
Generally, incentives have no effect on creativity (as measured by a panel of judges), or at most, slightly reduce it as they distract the person from the creative work: http://link.springer.com/article/10.1007/s10683-015-9440-5 And obviously fiscal pressure (loans, bankruptcy, etc.) would have a negative impact. But beyond that it's hard to see any correlation between payment and outcome, hence the argument for a basic income.
Payment only makes sense for the non-creative, "manual" aspects of society (which are responsive to incentives). As more of these manual tasks are automated, capitalism makes less and less sense. That's kind of what Marx was getting at when he said capitalism was "self-defeating", although he too got a little sidetracked by power structures. I still have no real evidence that power structures even exist; they're a nice theory but basically unmeasurable. E.g., Trump is president, the effect on society/culture/business/daily life seems basically nil: http://www.trustedreviews.com/news/trump-win-changes-nothing... http://www.businessinsider.com/trump-do-nothing-presidency-2...
Generally, incentives have no effect on creativity (as measured by a panel of judges), or at most, slightly reduce it as they distract the person from the creative work: http://link.springer.com/article/10.1007/s10683-015-9440-5 And obviously fiscal pressure (loans, bankruptcy, etc.) would have a negative impact. But beyond that it's hard to see any correlation between payment and outcome, hence the argument for a basic income.
Payment only makes sense for the non-creative, "manual" aspects of society (which are responsive to incentives). As more of these manual tasks are automated, capitalism makes less and less sense. That's kind of what Marx was getting at when he said capitalism was "self-defeating", although he too got a little sidetracked by power structures. I still have no real evidence that power structures even exist; they're a nice theory but basically unmeasurable. E.g., Trump is president, the effect on society/culture/business/daily life seems basically nil: http://www.trustedreviews.com/news/trump-win-changes-nothing... http://www.businessinsider.com/trump-do-nothing-presidency-2...
If the only way to earn living is to do manual work, creative people will end up manually working. Because they need to eat and their children need to eat. On a large scale, creative industrise happen when money happen to flow that way.
Moreover, while creativity matters in programming, large chunk of it is closer to manual work - you add features, you add tests, you test manually, you document, you debug etc.
Moreover, while creativity matters in programming, large chunk of it is closer to manual work - you add features, you add tests, you test manually, you document, you debug etc.
Sometimes I wish that online store like Amazon gave people the option to pay more than the asking price for some thing, where all surplus money would go to the creator of that thing.
This could even extend to zero-cost items like free software. You could "buy" a software package for zero dollars, with a five dollar tip going to the author.
Amazon uses a lot of free and open source software, so this sort of thing could be in their interests even if they don't make money off of it directly.
This could even extend to zero-cost items like free software. You could "buy" a software package for zero dollars, with a five dollar tip going to the author.
Amazon uses a lot of free and open source software, so this sort of thing could be in their interests even if they don't make money off of it directly.
You can look at his resume: https://www.linkedin.com/in/guido-van-rossum-4a0756/. I'm not sure what "Director of PythonLabs" is, but my guess is it's basically speaking at a ton of conferences about Python. And conference fees are not cheap; he probably made more than the books. Not to mention he still does speaking gigs, keynotes, etc. Pretty much his whole career/professional network came for free, from Python, so he has his pick of jobs or un-jobs
You can call me cheap or unthankful, but for me open source contribution is kind of a zero sum game.
I'm not willing to spend money on maintainers fixing their stuff, but I'm also not expecting anything in return. I think out of ~15? years of sporadic contributions to dozens of projects all tangible rewards I've got were a single CD from my amazon wishlist and a handful of stickers and t-shirts (the kind that are not handed out in dozens at conferences.)
If we're talking about "using open source software for business, e.g. making money" then I'd probably be most happy with an "office hours" model, e.g. paying a maintainer/core contributor X per 1-2h of their time to help me troubleshoot/get started. That's usually all I/we need, seldom it would be "give me a specialist freelancer for days or weeks".
That said, I do think it's very sad that (at least in my experience) self-marketing is everything, so for example if you don't contribute at all to project X but can show a slightly better talk proposal (with a mainstream/beginner) topic, you're invited to speak and the people who focus on code/bugs/whatever and less on being rockstar presenters get picked less for "boring internals talks" (this depends on the community of course).
I'm not willing to spend money on maintainers fixing their stuff, but I'm also not expecting anything in return. I think out of ~15? years of sporadic contributions to dozens of projects all tangible rewards I've got were a single CD from my amazon wishlist and a handful of stickers and t-shirts (the kind that are not handed out in dozens at conferences.)
If we're talking about "using open source software for business, e.g. making money" then I'd probably be most happy with an "office hours" model, e.g. paying a maintainer/core contributor X per 1-2h of their time to help me troubleshoot/get started. That's usually all I/we need, seldom it would be "give me a specialist freelancer for days or weeks".
That said, I do think it's very sad that (at least in my experience) self-marketing is everything, so for example if you don't contribute at all to project X but can show a slightly better talk proposal (with a mainstream/beginner) topic, you're invited to speak and the people who focus on code/bugs/whatever and less on being rockstar presenters get picked less for "boring internals talks" (this depends on the community of course).
Not really talking exactly to the topic, but I recently went to use an open source project which said something like "this is open source software under a permissive license, but if you use it commercially you have a social obligation to financially support it".
It's probably important to note that it was web-facing code so it's public information if you are using it, which is encouragement to pay, BUT I still felt that they were striking an explicit bargain with me - use it commercially and you must pay - I liked that.
I thought this was a really good way of putting it - use it, it is free, but you are in fact obligated to support it financially if you use it commercially.
Again on another slight tangent, I think open source developers tend not to be business savvy and do things like say "pay what you think it is worth", or they ask for "tips" - these are good ways to get nothing. If you want people to pay something then you must set the price expectation clearly in the mind of the buyer/user.
It's probably important to note that it was web-facing code so it's public information if you are using it, which is encouragement to pay, BUT I still felt that they were striking an explicit bargain with me - use it commercially and you must pay - I liked that.
I thought this was a really good way of putting it - use it, it is free, but you are in fact obligated to support it financially if you use it commercially.
Again on another slight tangent, I think open source developers tend not to be business savvy and do things like say "pay what you think it is worth", or they ask for "tips" - these are good ways to get nothing. If you want people to pay something then you must set the price expectation clearly in the mind of the buyer/user.
Alternatively, you could just use the AGPL:
http://www.dr-chuck.com/csev-blog/2014/09/how-to-achieve-ven...
http://www.dr-chuck.com/csev-blog/2014/09/how-to-achieve-ven...
Answering myself with another slightly off topic point - I wonder if a public register of financial support to open source projects would encourage more of it?
For example, if payments went through github for verification, and there was a public list to see the rankings of which companies give the most to which open source projects.
We could then see for example how Amazon which makes billions from open source, contributes (? $0) to open the open source projects that it packages and sells as services.
For example, if payments went through github for verification, and there was a public list to see the rankings of which companies give the most to which open source projects.
We could then see for example how Amazon which makes billions from open source, contributes (? $0) to open the open source projects that it packages and sells as services.
A lot of companies want to support projects without advertising that fact. Sony spent a seven-digit amount on open source software while doing things like contributing code via shell companies in order to avoid revealing what tools they were building their products around. I've received more than one email saying "this patch fixes a bug PLEASE DON'T TELL ANYONE IT CAME FROM ME".
Amazon has chosen for some reason to avoid advertising their open source contributions, but they absolutely do make contributions. Would it be nice if they contributed more? Sure. But that's true of every company.
Amazon has chosen for some reason to avoid advertising their open source contributions, but they absolutely do make contributions. Would it be nice if they contributed more? Sure. But that's true of every company.
If the goal however is to get companies to contribute more then the simultaneous applauding/shaming of a public donations registry is likely to encourage some companies to contribute because they like to be seen as good corporate citizens and not poor corporate citizens.
I can imagine for some companies it would be a matter of corporate pride to advertise their "projects financially supported" page, perhaps even as part of their recruiting effort to advertise how developer-centric they are.
github is the logical home for this, and indeed it is in the interests of github to do it - open source projects are far more likely to want to host on github if it has a public donations registry that, due to its public nature, actually works.
I can imagine for some companies it would be a matter of corporate pride to advertise their "projects financially supported" page, perhaps even as part of their recruiting effort to advertise how developer-centric they are.
github is the logical home for this, and indeed it is in the interests of github to do it - open source projects are far more likely to want to host on github if it has a public donations registry that, due to its public nature, actually works.
Is it really good idea to give github defacto monopoly power? This would make it much harder for github competitor to arise and business competition is a good thing.
Especially since as politics and culture tend to be more and more polarized, you don't want one company with that much power.
Especially since as politics and culture tend to be more and more polarized, you don't want one company with that much power.
On the other hand, imagine if it really worked and money poured in to support open source projects - it would be transformative for the lives of many open source developers.
Github did populist political decisions in the past. They will move from "united meritocracy of Github" to full sjw and back in blink of eye.
They do a lot of good for open source, but I would not trust them not to close project due to political reasons - especially under pressure. They are not the pick of a company I would do for project that aims to "shame" companies/individuals when they misbehave.
They do a lot of good for open source, but I would not trust them not to close project due to political reasons - especially under pressure. They are not the pick of a company I would do for project that aims to "shame" companies/individuals when they misbehave.
How would you count companies like Facebook that do open source directly - by releasing it and submitting patches. Facebook pays to facebook in order to get credit?
The fact is, companies and academia pay for open source development more then we are willing to admit - by having own employees do it. This gives them absolute support contract under their control so to speak.
The fact is, companies and academia pay for open source development more then we are willing to admit - by having own employees do it. This gives them absolute support contract under their control so to speak.
> If you use it commercially you have a social obligation to financially support it.
Sans the key word "financially", isn't this basically the premise of copyleft? It's free and open for anyone to use, as long as you pay it forward.
Sans the key word "financially", isn't this basically the premise of copyleft? It's free and open for anyone to use, as long as you pay it forward.
OpenCollective [1] is a possible solution. It provides a way to support (monthly contributions or dedicated campaigns), but also the whole back-end of tracking the money and spending, and at least some degree of legal support with paperwork, invoices, ...
1.- https://opencollective.com/
1.- https://opencollective.com/
I have been occasionally pushing a oss in government campaign(www.oss4gov.org).
OSS is a perfect match for government software, but it is painful to get a OSS project started and funded by government. Which kind of blocks development as there is only one customer.
So I am trying to argue that there should be a collaborative license that someone kicks off a fully funded project and slowly others who see value come in and take on more slices of the original cost of the project.
The point I am trying to make is that even the current raft of OSS projects are a tiny slice of those that are or should exist, and that we need to look at less private more communal funding models.
We rarely build roads by subscription or toll anymore. Software should be the same
OSS is a perfect match for government software, but it is painful to get a OSS project started and funded by government. Which kind of blocks development as there is only one customer.
So I am trying to argue that there should be a collaborative license that someone kicks off a fully funded project and slowly others who see value come in and take on more slices of the original cost of the project.
The point I am trying to make is that even the current raft of OSS projects are a tiny slice of those that are or should exist, and that we need to look at less private more communal funding models.
We rarely build roads by subscription or toll anymore. Software should be the same
This discussion is very interesting.
We are currently building something that let's you donate / offer a bounty for a specific github issue. You can check it out at https://octotreat.com. Right now the money will go 100% to the owner of the repository, later we might split it so that the contributer receives 80%.
We focus on a simple workflow and to allow small contributions.
If you have any direct comments or want to support us, don't hesitate. :)
We are currently building something that let's you donate / offer a bounty for a specific github issue. You can check it out at https://octotreat.com. Right now the money will go 100% to the owner of the repository, later we might split it so that the contributer receives 80%.
We focus on a simple workflow and to allow small contributions.
If you have any direct comments or want to support us, don't hesitate. :)
https://tip4commit.com/
Donate bitcoins to open source projects or make commits and get tips for it.
--
BitHub = Bitcoin + GitHub. An experiment in funding privacy OSS. | https://whispersystems.org/blog/bithub/
the owner of every merged pull request is paid 2% of our total balance at the time of the merge
https://github.com/WhisperSystems/Signal-Android/wiki/BitHub...
Donate bitcoins to open source projects or make commits and get tips for it.
--
BitHub = Bitcoin + GitHub. An experiment in funding privacy OSS. | https://whispersystems.org/blog/bithub/
the owner of every merged pull request is paid 2% of our total balance at the time of the merge
https://github.com/WhisperSystems/Signal-Android/wiki/BitHub...
Will have an eye on it.
I maintain an OS-Project and for me it would be a great feature if contributors could receive the money (up to 100%).
The main problem for me is, that i did not have the time for many request, with or without money, it will not change anything for me, but it could encourage others to do something for the project.
I maintain an OS-Project and for me it would be a great feature if contributors could receive the money (up to 100%).
The main problem for me is, that i did not have the time for many request, with or without money, it will not change anything for me, but it could encourage others to do something for the project.
If you would be able to earn a good hourly salary for the issues, could you 'make' time for it?
We believe that merging a PR is work and should be rewarded with around 20% to ensure a good code quality. It's weird to hear you say that you want all that money to go to the contributor. I'll keep that in mind and will ask more people about their opinion. Thanks for the input.
We believe that merging a PR is work and should be rewarded with around 20% to ensure a good code quality. It's weird to hear you say that you want all that money to go to the contributor. I'll keep that in mind and will ask more people about their opinion. Thanks for the input.
For me it is a side project (got payed from my company to create it), for more than 1 year i could do some support, but since than i work fulltime on other projects.
In my (less) free time i watch for issues and PR, but if somebody could be payed for doing this, i had no problem with that.
For famous projects it is not a huge problem to find free maintainer and contributors, but for smaller projects it is a problem. I did not know if paying a contributor would help, but i think it's worth a try. I can imagine, that there are some developers that could work fulltime for many small projects and earn money.
In my (less) free time i watch for issues and PR, but if somebody could be payed for doing this, i had no problem with that.
For famous projects it is not a huge problem to find free maintainer and contributors, but for smaller projects it is a problem. I did not know if paying a contributor would help, but i think it's worth a try. I can imagine, that there are some developers that could work fulltime for many small projects and earn money.
Bountysource has both software bounties (https://www.bountysource.com/) and monthly donations (https://salt.bountysource.com/).
It's also open source: http://github.com/bountysource/core
It's also open source: http://github.com/bountysource/core
As far as I understand, Salt would only need one addition to move things towards this proposal: allowing project maintainers to make a list of bugs/features that monthly contributors could vote on.
Bountysource has voting built in. As well as a browser extension that lets you thumbs up when on a tracker like GitHub:
https://www.bountysource.com/extension
https://www.bountysource.com/extension
How to fund open source software has been an ongoing debate since... forever. There used to be a great mailing list with a lot of key people on it: http://www.crynwr.com/cgi-bin/ezmlm-cgi?ddn:0:0#b if you'd like to dig through the archives.
There are no easy answers, is the conclusion I've come to.
There are no easy answers, is the conclusion I've come to.
Part of the problems is that certain software ecosystems (npm, rust+cargo, golang with "build against HEAD") seem to think it's "sexy" to declare war on the traditional package management systems, because they see proper long-term maintenance issues as being a burden on developer time and the "move-fast-and-break-things" paradigm.
In certain cases this is driven by leaders of those ecosystems having more experience developing in a corporate environment where indeed everything builds against HEAD, not realising that this model completely breaks down in a decentralised free software environment where different teams are more asynchronous and have no chance of globally syncing with everyone else all the time.
Please stop treating FOSS distributions like dirt, our model works better in an environment where most maintainers are volunteers rather than full-time paid developers, for shipping stuff that is usable over a long (> 3 months) period of time.
In certain cases this is driven by leaders of those ecosystems having more experience developing in a corporate environment where indeed everything builds against HEAD, not realising that this model completely breaks down in a decentralised free software environment where different teams are more asynchronous and have no chance of globally syncing with everyone else all the time.
Please stop treating FOSS distributions like dirt, our model works better in an environment where most maintainers are volunteers rather than full-time paid developers, for shipping stuff that is usable over a long (> 3 months) period of time.
> rust+cargo ... seem to think it's "sexy" to declare war on the traditional
That's not true. They do solve different problems, both are related to packaging, but still tangential to each other. You can use npm, cargo, bundler to build software which you then wrap to RPM/DEB ... system packages. I can recommend the talk that Yehuda Katz held on packaging/package managers at the Rubyconf Portugal '16 https://www.youtube.com/watch?v=Bwk8mdU6-ZY It's mostly about bundler and cargo and the design decisions behind them.
That's not true. They do solve different problems, both are related to packaging, but still tangential to each other. You can use npm, cargo, bundler to build software which you then wrap to RPM/DEB ... system packages. I can recommend the talk that Yehuda Katz held on packaging/package managers at the Rubyconf Portugal '16 https://www.youtube.com/watch?v=Bwk8mdU6-ZY It's mostly about bundler and cargo and the design decisions behind them.
I'm not going to watch a 1 hour video just to "get" your point.
I am a package maintainer, and my actual experience is it's much harder to package software in these ecosystems. When I bring up issues, they get brushed aside as "that's not how things are done", ignoring the actual issues. This is "declaring war", no matter how you try to paint it.
Bundling is not packaging management, it's doing a disservice to your users. Bundled software is not maintained in the long run, no teams bundling software are tracking security and bug fixes for the full dependency tree. It's too costly to do this across all pieces of bundled software. That is why FOSS distributions put an emphasis on deduplication, proper API compatibility, and loose version constraints.
The package managers I mentioned take the opposite approach, of strict version constraints and little API compatibility. This makes things easier for the developers, but much harder for maintainers. Every new version we have to carry, simply because developers were too lazy to maintain API compatibility, means more work for maintainers to track bugfixes.
The original article is proposing a way to reward more maintainers. This is one way to put resources where they're needed. A better way is to arrange your system to not need so much resources. That is what FOSS distributions do.
I am a package maintainer, and my actual experience is it's much harder to package software in these ecosystems. When I bring up issues, they get brushed aside as "that's not how things are done", ignoring the actual issues. This is "declaring war", no matter how you try to paint it.
Bundling is not packaging management, it's doing a disservice to your users. Bundled software is not maintained in the long run, no teams bundling software are tracking security and bug fixes for the full dependency tree. It's too costly to do this across all pieces of bundled software. That is why FOSS distributions put an emphasis on deduplication, proper API compatibility, and loose version constraints.
The package managers I mentioned take the opposite approach, of strict version constraints and little API compatibility. This makes things easier for the developers, but much harder for maintainers. Every new version we have to carry, simply because developers were too lazy to maintain API compatibility, means more work for maintainers to track bugfixes.
The original article is proposing a way to reward more maintainers. This is one way to put resources where they're needed. A better way is to arrange your system to not need so much resources. That is what FOSS distributions do.
What exactly do you find problematic about npm compared to the traditional package management systems (i.e. apt et al?)? I ask because having started using npm some months ago, I find it works better than anything I've ever previously encountered. Is there something I'm missing?
That's because you're using it as a developer. Trying maintaining software "packaged" using npm and shipping it to users later in a way that follows best practises. You'll want to kill yourself.
With my open source project, I'm offering remote consulting. I also offer specialized infrastructure management (to host projects built on top of it) for larger companies.
I was able to find enough small companies/customers to turn it into a full time contracting job but I have struggled to find large corporate customers.
My goal is to get at least one big contract from a corporate customer - That would allow me to bring other maintainers on board.
Finding big paying corporate users can be very important for open source projects because it gives it a credibility boost and helps convince other big companies to use your product/service in the future. Getting big companies on board is a difficult chicken and egg problem.
It would be great if big companies could make an effort to use solutions from small open source maintainers instead of massive already successful proprietary as-a-service alternatives.
If there was a platform to help Open Source teams connect with corporate clients, that would be extremely useful.
I was able to find enough small companies/customers to turn it into a full time contracting job but I have struggled to find large corporate customers.
My goal is to get at least one big contract from a corporate customer - That would allow me to bring other maintainers on board.
Finding big paying corporate users can be very important for open source projects because it gives it a credibility boost and helps convince other big companies to use your product/service in the future. Getting big companies on board is a difficult chicken and egg problem.
It would be great if big companies could make an effort to use solutions from small open source maintainers instead of massive already successful proprietary as-a-service alternatives.
If there was a platform to help Open Source teams connect with corporate clients, that would be extremely useful.
Ease of use is key. I'm much more likely to support a project if I don't have to enter credit card information, and even more likely to do so if I don't have to it once a month.
I already have a Patreon; I would absolutely dump money into a fire-and-forget Patreon-like system for OSS.
I keep seeing dependencies cited as an issue. Humble Bundle may be something to look at here. When you donate to obtain a Humble Bundle, there's a slider that you can use to adjust the ratio that goes to the game developer vs. a selected charity vs. the humble bundle system itself. I can see copying this - each project lists its dependencies along with the maintainer's estimate of how critical each was, and the patron has a slider for % going to the maintainer vs. % going to the dependencies. Possibly a similar slider for the maintainer, which'd add interest-group type packages (art package: one-click this to support gimp, inkscape, and blender).
I already have a Patreon; I would absolutely dump money into a fire-and-forget Patreon-like system for OSS.
I keep seeing dependencies cited as an issue. Humble Bundle may be something to look at here. When you donate to obtain a Humble Bundle, there's a slider that you can use to adjust the ratio that goes to the game developer vs. a selected charity vs. the humble bundle system itself. I can see copying this - each project lists its dependencies along with the maintainer's estimate of how critical each was, and the patron has a slider for % going to the maintainer vs. % going to the dependencies. Possibly a similar slider for the maintainer, which'd add interest-group type packages (art package: one-click this to support gimp, inkscape, and blender).
> fire-and-forget Patreon-like system for OSS
Add in the element of mutual assurance (like Kickstarter), and you've got Snowdrift.coop (disclaimer: I volunteer on the team). 100% of donations (after Stripe's fees) go to the project; we [are/will be] funded as a project on the site (currently the only one; although it's possible to pledge -- I'm patron #6 -- we're not quite ready to announce our launch to the general public).
Add in the element of mutual assurance (like Kickstarter), and you've got Snowdrift.coop (disclaimer: I volunteer on the team). 100% of donations (after Stripe's fees) go to the project; we [are/will be] funded as a project on the site (currently the only one; although it's possible to pledge -- I'm patron #6 -- we're not quite ready to announce our launch to the general public).
Ease of use is key, I agree. I would add trust though.
Unfortunately these two are sometimes diametrically opposed to each other.
Unfortunately these two are sometimes diametrically opposed to each other.
Sometimes. Ongoing donation systems naturally build trust because your patronage is more valuable than this month's donation.
I would also like to point out another alternative with which Mike Perham, author of Sidekick, has been immensely successful. He makes significant income by selling commercial licenses that also have certain premium features [1]. Isn't it possible to make it simple to sell commercial licenses? It'd be less favourable approach in terms of the open source spirit, but I think it can benefit everyone in the long term. Authors can be motivated to maintain the project and provide business value at the same time.
Some commercial features can include things like dashboards, monitoring, or notifications. Of course, it'd likely work if the many businesses would find the project useful and would be willing to pay.
[1]: https://www.indiehackers.com/businesses/sidekiq
Some commercial features can include things like dashboards, monitoring, or notifications. Of course, it'd likely work if the many businesses would find the project useful and would be willing to pay.
[1]: https://www.indiehackers.com/businesses/sidekiq
http://www.fordfoundation.org/library/reports-and-studies/ro... is an excellent summary of the issue.
Probably different strategies will be needed for different markets.
I created PropertyWebBuilder, an open source tool for creating real estate websites and I find in that sector there just isn't enough technical knowledge for people to get involved directly. I think in that case some sort of groupfunding initiative where estate agents / brokers club together to finance projects that help them might be best.
You can find a more detailed examination of this in an article I wrote about the subject:
https://hackernoon.com/open-source-software-for-real-estate-...
I created PropertyWebBuilder, an open source tool for creating real estate websites and I find in that sector there just isn't enough technical knowledge for people to get involved directly. I think in that case some sort of groupfunding initiative where estate agents / brokers club together to finance projects that help them might be best.
You can find a more detailed examination of this in an article I wrote about the subject:
https://hackernoon.com/open-source-software-for-real-estate-...
It's an intriguing idea, but where would the money come from? You'd need to convince companies that this is worth spending on.
Also, who funds development of essential upstream libraries? In my experience, such projects have much less visibility to users, but they are vitally important.
Finally, as an open source developer with a day job, I see serious potential for conflicts of interests if I'm getting paid for open source. I don't even know if my employer would allow it.
Also, who funds development of essential upstream libraries? In my experience, such projects have much less visibility to users, but they are vitally important.
Finally, as an open source developer with a day job, I see serious potential for conflicts of interests if I'm getting paid for open source. I don't even know if my employer would allow it.
Finally, as an open source developer with a day job, I see serious potential for conflicts of interests if I'm getting paid for open source. I don't even know if my employer would allow it.
We should fight for our rights. We hold the power, not employers. But we'll need to fight to keep it that way.
Imagine how strange it would sound for a plumber to say "I'm employed by XYZ Corp so I'm not allowed to receive money for fixing your toilet."
We should fight for our rights. We hold the power, not employers. But we'll need to fight to keep it that way.
Imagine how strange it would sound for a plumber to say "I'm employed by XYZ Corp so I'm not allowed to receive money for fixing your toilet."
[deleted]
Much of the discussion here is about software useful to Internet businesses. These companies are likely to pay to support Open-Source that they depend on. Yet, this focus misses vast areas of valuable software.
For the last 6 years I've been working on an Open-Source CNC simulator called CAMotics. See http://CAMotics.org/ With 100k+ users, I've struggled to get more than a few hundred dollars in donations per year. CAMotics is a mature software that my users rave about.
Gaining corporate sponsorship is difficult for software that is not geared to benefit corporations even when creating tons of value for users world wide.
It is important to recognize that there may not be a one size fits all solution to funding Open-Source software. Still, if we could find generalized solutions, with the right incentives, the world would reap massive benefits. An army of independent developers working on projects they love, full-time, would completely change the software landscape.
For the last 6 years I've been working on an Open-Source CNC simulator called CAMotics. See http://CAMotics.org/ With 100k+ users, I've struggled to get more than a few hundred dollars in donations per year. CAMotics is a mature software that my users rave about.
Gaining corporate sponsorship is difficult for software that is not geared to benefit corporations even when creating tons of value for users world wide.
It is important to recognize that there may not be a one size fits all solution to funding Open-Source software. Still, if we could find generalized solutions, with the right incentives, the world would reap massive benefits. An army of independent developers working on projects they love, full-time, would completely change the software landscape.
Is that project lifetime total users, or daily active users ? Each daily active user is worth ca 1 USD/month ... Just put up a banner like "your ad here ? Contact [email protected]" And write in big letters on the front page how many users are using the program right now. Then call some news papers with a cool story about how you made a program that is used by 100k people, and talk about the DIY movement or whatever.
Is a newspaper really going to be interested in such a thing? Even the local paper in my small town would likely find this a non-story.
local news papers love local succes stories. even a bad story can be published if you do most of the work yorself basically writing the story for them and supplying photos. there are people making a living selling stories and photos to news papers.
It seems one small approach in the right direction would be for someone+ to provide a discovery/marketing service for helping spotlight, bring to the forefront those working on the infrastructure-type projects. Thinking more along the lines of a podcast, blog, etc. that would generate revenue from sponsors. Akin to Changelog or other podcasts, but specifically focused on the behind-the-scenes/infrastructure/maintaince type stuff - the "backstory" if you will. Folks could donate to this service and funds could be funneled to the highlighted projects/developers.
The "marketing service" angle would be to provide free marketing to these types of projects. Inviting folks as guests, writing about projects, etc.
It does solve the overall problem for everyone, but it would be going in the general right direction. There may be efforts like this already, but I am not aware of them.
+ I do not have the time it would take to do this well.
The "marketing service" angle would be to provide free marketing to these types of projects. Inviting folks as guests, writing about projects, etc.
It does solve the overall problem for everyone, but it would be going in the general right direction. There may be efforts like this already, but I am not aware of them.
+ I do not have the time it would take to do this well.
I have a similar idea, where a website would allow you to donate a set amount every month, and then allow you to choose worthwhile projects at a high level or get very granular. For example, you could say "apache" and all the relevant projects would get a portion of your money in some percentage, or you could individually select projects. There would also be a tool to scan your code base and tell you what to support. You would then get a statement at the end of year listing what's tax deductible.
Whether this is a good implementation or not, CLEARLY there is a desperate need for some way to compensate open source developers in a frictionless manner. We also need this model to be seamless for corporations and even startups. Even a boot strapped startup could afford $20 / month and then scale up as they grow. I'm surprised github hasn't added some sort of "pay for this bug to be fixed" feature.
Whether this is a good implementation or not, CLEARLY there is a desperate need for some way to compensate open source developers in a frictionless manner. We also need this model to be seamless for corporations and even startups. Even a boot strapped startup could afford $20 / month and then scale up as they grow. I'm surprised github hasn't added some sort of "pay for this bug to be fixed" feature.
[deleted]
I few years ago I envisioned exactly this, something like a cross between bugzilla and kickstarter/patreon. I want something fixed/done and want to pay someone a small amount to do it.
Even registered a domain for that. If someone wants to implement this, I would donate the domain (5-letter flattr-like .com/.org).
Even registered a domain for that. If someone wants to implement this, I would donate the domain (5-letter flattr-like .com/.org).
I want something fixed/done and want to pay someone a small amount to do it.
Are you thinking of the "bounties for specific issues" model? That's something I would specifically want to avoid -- it doesn't provide funding for ongoing "behind the scenes" work, and "feature bounties" often get claimed with horribly bug-ridden code which just barely passes the five minutes people spend to confirm that the bounty should be paid out.
A subscription model has the advantage that if a developer stops producing good code, people can decide to stop funding them.
Are you thinking of the "bounties for specific issues" model? That's something I would specifically want to avoid -- it doesn't provide funding for ongoing "behind the scenes" work, and "feature bounties" often get claimed with horribly bug-ridden code which just barely passes the five minutes people spend to confirm that the bounty should be paid out.
A subscription model has the advantage that if a developer stops producing good code, people can decide to stop funding them.
I think this is a great idea! Patreon has already figured out how to make this kind of service successful -- taking what worked for them and adding features specifically for software development seems so obvious I'm surprised no one else has done it yet.
It would be cool if it also allowed one off donations. I live and earn in a country, where "a [US-priced] coffee cup monthly" is a tad too much for me to accept in budget; but I've just recently donated for the first time to an OSS project, and was very happy about this. I imagine that such a obe-off could become a kind of "gateway drug" to slowly increase the spending, and maybe at some point get accustomed enough so that I could even become a recurring payer.
Also, please try to support PayPal, bad/evil as it is. Credit cards aren't a thing everywhere in the world.
Also, please try to support PayPal, bad/evil as it is. Credit cards aren't a thing everywhere in the world.
https://salt.bountysource.com/ has monthly and one-time donations for OSS projects. And PayPal is supported.
I understand you're trying to follow up in conversations. Posting a link once or twice is okay. This is beginning to look like spam.
Hm. You actually made me look at it, and it indeed does look interesting. Somehow, I always had an unfavourable impression about BountySource before; now that I think of it, possibly because of clunky GUI? Or, I believe it may be that the "capturing/overlaying" of GitHub Issues they do feels uncannily scammy to me?
Edit: don't fully understand it, but somehow I have a feeling it'd help me if I saw people behind the project emphasized more? I now remember I also supported the Voxel Quest author (Gavan Woolery) via his project. The "regular" (non-Kickstarter) one however was Calibre.
Edit: don't fully understand it, but somehow I have a feeling it'd help me if I saw people behind the project emphasized more? I now remember I also supported the Voxel Quest author (Gavan Woolery) via his project. The "regular" (non-Kickstarter) one however was Calibre.
> If this existed, would you — an open source software developer — sign up and use it?
To whomever does create such a thing, please make any JavaScript served to the user free software (it'd be a bonus if the server software were too, of course).[0] There are sites I'd use to make donations, but I can't because the code is non-free; I don't find this to be an unreasonable request for free software projects.
[0]: https://www.gnu.org/philosophy/javascript-trap.en.html
To whomever does create such a thing, please make any JavaScript served to the user free software (it'd be a bonus if the server software were too, of course).[0] There are sites I'd use to make donations, but I can't because the code is non-free; I don't find this to be an unreasonable request for free software projects.
[0]: https://www.gnu.org/philosophy/javascript-trap.en.html
I expected downvotes, but I consider this to be a serious issue to which I devote much of my activism, so I would like to hear rationale.
(https://media.libreplanet.org/u/libreplanet/collection/resto...)
(https://media.libreplanet.org/u/libreplanet/collection/resto...)
In general we pay for infrastructure with taxes. It's getting harder and harder to argue that no software counts as infrastructure: "An organizational structure needed for the operation of a society or enterprise." The current President talks about tossing money at infrastructure; maybe he'd like to spend an outrageous 1% of that on software. It's nice when volunteers fill in potholes or replace bent railway ties - but it's no way to run a railroad.
Maybe unpopular and not true for all software, but in general, I would say the idea to base a business on support for software is in contradiction with the idea that this software should solve problems in a mostly automatic way.
Because good software doesn't need support, or at least a lot less support than bad software, so there might be some conflict of interest?
Because good software doesn't need support, or at least a lot less support than bad software, so there might be some conflict of interest?
I'm building an app I'd love to open source, but can't because that would make it's development unsustainable.
I've been thinking that I could open a patreon account, and then open source the code after I reach $5k/mo in monthly donations.
Do you think it's a good idea?
I've been thinking that I could open a patreon account, and then open source the code after I reach $5k/mo in monthly donations.
Do you think it's a good idea?
Once it actually gets launched, also consider Snowdrift.
"a cross between Patreon and Bugzilla"
Have a look at BitHub: https://github.com/WhisperSystems/BitHub
Have a look at BitHub: https://github.com/WhisperSystems/BitHub
Having both written & maintained open source software, and negotiating (commercial) support and development contracts, I find myself thinking about this issue every couple of months.
A few thoughts:
Bounties are a problem since each is basically a tiny contract (what to deliver, what it'll cost, when, etc) in itself, so they need to be haggled over, ie. there's a nontrivial transaction cost to each. In practice, you get a crossbreed between a graveyard of ignored stuff and a race-to-the-bottom wishlist amounts - FIX THIS URGENT MULTITHREADED PROGRAM FOR $15 PLZ I'M PAYING YOU! I'd rather do open source obligation-free than that.
Monthly donations (like Evan You's Patreon campaigns that dvnguyen mentioned) can work, but from the client standpoint, it's not really clear what you gain ("if this breaks tomorrow, who I'm gonna call?"), so while theoretically nice, in practice there's not a lot of uptake.
As Colin mentions in the post, if there's a large company (or a few) that use the software and see the value, they can be persuaded to support it via explicit support contracts with the developer(s) or just hiring them (I think redis is a success story here). But many projects don't have such large companies as users (or they don't know that they have!).
Another issue that I think we always stumble in these discussions is the pricing and talking about value, esp. in context of open source software. My strong opinion (feel free to disagree is): in open source, the software itself is a commodity, and its PRICE is $0. If you don't like that, don't do open source. However, there's no question that the software has a VALUE that's over $0 (otherwise why'd anyone use it). But the value of the software is not only in the code, and as patio11 always reminds us (in the context of business discussions), determine your value and charge based on value, not on cost (ie. amount of effort needed to write the code).
The value is that the company developers are faster (increase/multiply their value). The RISK to the company is that the developers will have to spend their time maintaining, fixing, updating, the software if there's no external vendor to do it (the "who am I gonna call?" problem), which will decrease the developers' productivity, ie reducing the software value (perhaps below zero). So, removing this risk should have business sense to the company.
Borrowing from risk management, we can try to estimate the probability of it happening ("how often does the code need to change", "how often bugs that should be fixed are found", not "what is the probability of open source dev burning out" since that hides the externality - developer's labor), and the cost ("if we have to maintain it ourselves, how much time (ie. money) would we spend"). It's more of a ballpark estimate rather than a rigorous calculation, but for many highly used projects, a reasonable figure can be estimated. This figure, then, is the amount the company could reasonably be expected to pay each month.
So the company is not paying for the software. They're paying for their piece of mind - to minimize risks inherent in their use of unsupported software. I am convinced this argument is MUCH easier to sell to the companies than social or moral obligations.
On the developer side we want a steady, stream of income, so combining the two might mean a (tiered) subscription based model. For $0 (free) you use the software but the developer has absolutely no obligation to ever listen to your bug reports or feature requests. For $X (monthly), you can expect the bugs to be fixed (and prioritize which should go first), up to a specific limit in amount of hours worked, but the developer has the sole discretion over the new features to be implemented. There can be multiple tiers ($X, $Y, $Z... for different amounts of work).
The limit in amounts worked is there to set expectation of what exactly the company gets for their money, ie. what to do if the company asks for more work (bugfixing) than you'd be happy doing for the subscription amount. For $X, it's Y hours of developers time (non-refundable retainer). $X could be set based on the calculated risk above, an Y (hours) is based from the dollar amount and a hourly consulting rate that the developer could ask for when doing a real retainer contract.
An example: let's say I'm a proud developer of libwidget, an indispensable library for managing widgets in a nosql database. There's dozens (respectable, but not high) of companies using my code. I do a few updates a month, mostly bugfixes. If I disappear each company would probably need to spend an hour of their developer time each month maintaining this, let's say that'd cost them $100. Let's also say my target retainer rate is $100/hr, so this ends up being an hour of my time. (To clarify, the rate would be lower than the usual consulting rate since there is a possibility that no work will be needed in a month).
Based on the above, I'd set up a subscription plan that says: for $100/mo, you can file bugfixes (private or public), and I will spend up to 1hr per month fixing those issues (if there are more of them, I'll let you prioritize). If more work is needed, I can either set up a larger plan, or agree to do extra work for $Z ($Z > $X), or any combination of the above.
Something like this would, I believe, scale nicely from almost no work (and getting a few bucks a month for coffee and ice cream :) to being basically fully employed in support of your work (and being paid fairly for it), while making everyone clear about what they can expect from you as a open source dev.
As a footnote - many companies budget for a year, so offering year subscription may work as well, or better (since it'll be almost the same to the company financial-wise, and they'll know they have you on support for the next 12 months). Or you can pull an oldest trick in the book and price-differentiate yearly and monthly fee so that the yearly fee looks like a better value for money. The yearly fee makes the subscription model even more smooth and with less surprises than the monthly-based one, so it's useful to keep in mind.
Great thing about this is that it's possible to do with existing infrastructure for monthly subscriptions (say, Patreon for subscriptions, github for issues, email or a separate private bug tracker for private "technical support"). But if a platform that nails this approach would appear, I'm betting in itself it'd be a $1B+ company (think GitHub for - gasp - git hosting - actually, no, wait - GitHub why haven't you done this already ?!?).
Just my $0.02 :-)
A few thoughts:
Bounties are a problem since each is basically a tiny contract (what to deliver, what it'll cost, when, etc) in itself, so they need to be haggled over, ie. there's a nontrivial transaction cost to each. In practice, you get a crossbreed between a graveyard of ignored stuff and a race-to-the-bottom wishlist amounts - FIX THIS URGENT MULTITHREADED PROGRAM FOR $15 PLZ I'M PAYING YOU! I'd rather do open source obligation-free than that.
Monthly donations (like Evan You's Patreon campaigns that dvnguyen mentioned) can work, but from the client standpoint, it's not really clear what you gain ("if this breaks tomorrow, who I'm gonna call?"), so while theoretically nice, in practice there's not a lot of uptake.
As Colin mentions in the post, if there's a large company (or a few) that use the software and see the value, they can be persuaded to support it via explicit support contracts with the developer(s) or just hiring them (I think redis is a success story here). But many projects don't have such large companies as users (or they don't know that they have!).
Another issue that I think we always stumble in these discussions is the pricing and talking about value, esp. in context of open source software. My strong opinion (feel free to disagree is): in open source, the software itself is a commodity, and its PRICE is $0. If you don't like that, don't do open source. However, there's no question that the software has a VALUE that's over $0 (otherwise why'd anyone use it). But the value of the software is not only in the code, and as patio11 always reminds us (in the context of business discussions), determine your value and charge based on value, not on cost (ie. amount of effort needed to write the code).
The value is that the company developers are faster (increase/multiply their value). The RISK to the company is that the developers will have to spend their time maintaining, fixing, updating, the software if there's no external vendor to do it (the "who am I gonna call?" problem), which will decrease the developers' productivity, ie reducing the software value (perhaps below zero). So, removing this risk should have business sense to the company.
Borrowing from risk management, we can try to estimate the probability of it happening ("how often does the code need to change", "how often bugs that should be fixed are found", not "what is the probability of open source dev burning out" since that hides the externality - developer's labor), and the cost ("if we have to maintain it ourselves, how much time (ie. money) would we spend"). It's more of a ballpark estimate rather than a rigorous calculation, but for many highly used projects, a reasonable figure can be estimated. This figure, then, is the amount the company could reasonably be expected to pay each month.
So the company is not paying for the software. They're paying for their piece of mind - to minimize risks inherent in their use of unsupported software. I am convinced this argument is MUCH easier to sell to the companies than social or moral obligations.
On the developer side we want a steady, stream of income, so combining the two might mean a (tiered) subscription based model. For $0 (free) you use the software but the developer has absolutely no obligation to ever listen to your bug reports or feature requests. For $X (monthly), you can expect the bugs to be fixed (and prioritize which should go first), up to a specific limit in amount of hours worked, but the developer has the sole discretion over the new features to be implemented. There can be multiple tiers ($X, $Y, $Z... for different amounts of work).
The limit in amounts worked is there to set expectation of what exactly the company gets for their money, ie. what to do if the company asks for more work (bugfixing) than you'd be happy doing for the subscription amount. For $X, it's Y hours of developers time (non-refundable retainer). $X could be set based on the calculated risk above, an Y (hours) is based from the dollar amount and a hourly consulting rate that the developer could ask for when doing a real retainer contract.
An example: let's say I'm a proud developer of libwidget, an indispensable library for managing widgets in a nosql database. There's dozens (respectable, but not high) of companies using my code. I do a few updates a month, mostly bugfixes. If I disappear each company would probably need to spend an hour of their developer time each month maintaining this, let's say that'd cost them $100. Let's also say my target retainer rate is $100/hr, so this ends up being an hour of my time. (To clarify, the rate would be lower than the usual consulting rate since there is a possibility that no work will be needed in a month).
Based on the above, I'd set up a subscription plan that says: for $100/mo, you can file bugfixes (private or public), and I will spend up to 1hr per month fixing those issues (if there are more of them, I'll let you prioritize). If more work is needed, I can either set up a larger plan, or agree to do extra work for $Z ($Z > $X), or any combination of the above.
Something like this would, I believe, scale nicely from almost no work (and getting a few bucks a month for coffee and ice cream :) to being basically fully employed in support of your work (and being paid fairly for it), while making everyone clear about what they can expect from you as a open source dev.
As a footnote - many companies budget for a year, so offering year subscription may work as well, or better (since it'll be almost the same to the company financial-wise, and they'll know they have you on support for the next 12 months). Or you can pull an oldest trick in the book and price-differentiate yearly and monthly fee so that the yearly fee looks like a better value for money. The yearly fee makes the subscription model even more smooth and with less surprises than the monthly-based one, so it's useful to keep in mind.
Great thing about this is that it's possible to do with existing infrastructure for monthly subscriptions (say, Patreon for subscriptions, github for issues, email or a separate private bug tracker for private "technical support"). But if a platform that nails this approach would appear, I'm betting in itself it'd be a $1B+ company (think GitHub for - gasp - git hosting - actually, no, wait - GitHub why haven't you done this already ?!?).
Just my $0.02 :-)
Right now there are companies who employ people who maintain OSS. This would be crowd-sourcing the money for that?
In a sense, yes. RedHat sells support contracts and pays developers; this would create a system for people to buy support from the developers of individual projects rather than buying the "RedHat bundle".
Why not just use github issues and bitcoin for payment.
If you have problem write an issue on the project repo and offer an amount in bitcoin.
If you have problem write an issue on the project repo and offer an amount in bitcoin.
Because the amounts people would normally (be able to) offer can often be tiny. Also, estimating time to fix specific issues is hard, and this still doesn't solve the maintenance problem.
(a) talk with patio11 and tptacek and follow all their advice for tarsnap
(b) work on this new idea while the picodollars flow in…
:-p
:-p
Isn't this what github and friends are for?
Github provides the "issue tracker" side of things. But I'm not aware of any "sign up to pay this developer $X/month" functionality?
Patreon, I guess? You mention it, but not really why it wouldn't work at small scale. At large scale, you'd need to build something to link Bugzilla and Patreon users.
I can imagine wanting to self-host, but I'm not sure that giving up the established (if expensive) Patreon platform would be worth it.
(EDIT: comment has been expanded twice; sorry.)
I can imagine wanting to self-host, but I'm not sure that giving up the established (if expensive) Patreon platform would be worth it.
(EDIT: comment has been expanded twice; sorry.)
Did you read the blog post? I specifically described this as a cross between Patreon and Bugzilla.
A fair response; sorry, I expanded the comment to something more reasonable.
[deleted]
[deleted]
See all the company logos? Webpack is great for sure, but why does it attract so many sponsors? There's loads of other great projects not receiving a dime despite having Patreon pages or whatever.
It's the logos (and links) themselves! Because by putting my logo on your Github and project page, I can both mentally and practically claim it as a marketing expense. Marketing being an established bucket of money you can use for things that increase your company's visibility.
But if you simply offer a donation system, or feel-good sponsorship, how would I even classify that? Sounds complicated from a business point of view. Even a support contract is a harder sell than just pure marketing.
Heck, if I know my customers are using projects X and Y, I'm willing to pay just to put my logo in front of those users even if we as a company are not using X and Y ourselves! And by payment, I don't mean a $50 one-time donation, companies are willing to pay $X00-$X0000 per month for that kind of targeted exposure. And if you do this for your project, please note that companies value direct links to their chosen landing page much more than to some generic "sponsorship aggregator" page for the company.