A plan for open source software maintainers
daemonology.net
daemonology.net
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.
Sean Larkin busts his ass to advocate for companies supporting the development of webpack.
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.
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.
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.
Uhhh... Please tell me you're joking?
There is a lot of developer targeted companies in the sponsors list for Webpack.
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.
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.
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.
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. :)
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.
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.
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.
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.
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 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.
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!
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".
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.
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
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".
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.
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, 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).
"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 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 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.
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.
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.
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.
That's called getting a job with said enterprise.
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.
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.
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.
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
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
"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."
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.
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.
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).
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.
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 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.
(Disclaimer: I work for Stripe, as of like last week. :)
* 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!)
Open source funding is a cause near and dear to my heart, and I hope something is able to work out.
(And thanks!)
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.
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.
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.
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.
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...
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.
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.
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).
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.
http://www.dr-chuck.com/csev-blog/2014/09/how-to-achieve-ven...
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.
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.
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.
Especially since as politics and culture tend to be more and more polarized, you don't want one company with that much power.
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.
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.
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.
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
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. :)
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...
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.
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.
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.
It's also open source: http://github.com/bountysource/core
There are no easy answers, is the conclusion I've come to.
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.
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 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 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 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).
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).
Unfortunately these two are sometimes diametrically opposed to each other.
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.
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-...
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.
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."
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.
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.
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.
Even registered a domain for that. If someone wants to implement this, I would donate the domain (5-letter flattr-like .com/.org).
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.
Also, please try to support PayPal, bad/evil as it is. Credit cards aren't a thing everywhere in the world.
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.
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.
(https://media.libreplanet.org/u/libreplanet/collection/resto...)
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'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?
Have a look at BitHub: https://github.com/WhisperSystems/BitHub
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 :-)
If you have problem write an issue on the project repo and offer an amount in bitcoin.
:-p
2) Create a brand new tax for business.
3) Distribute that money proportionally to stars over Github projects.
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.)