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.
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.
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).
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.
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.
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."
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).
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.
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?
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.
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.
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, ...
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.
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.
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.
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.
> 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).
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".
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.
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.
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.
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 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.
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.
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".
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
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 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."
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.
[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.)
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.
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.
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. :)
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!
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.
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.
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.
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).
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).
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.
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 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.
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.
> 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...
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.
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.
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
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.
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.
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 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.
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.
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.
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.
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.
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.
"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 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
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. :)
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.
> ... 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.
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. :)
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.
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 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.
> 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.
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.
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.
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.
164 comments
[ 4.8 ms ] story [ 158 ms ] threadI 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.)
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, 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."
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.
https://salt.bountysource.com/
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.
1.- https://opencollective.com/
It's also open source: http://github.com/bountysource/core
https://www.bountysource.com/extension
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
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.
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".
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
If you have problem write an issue on the project repo and offer an amount in bitcoin.
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
"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."
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
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!)
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).
Unfortunately these two are sometimes diametrically opposed to each other.
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).
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.
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.
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.
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
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.
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.
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.
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.
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.
https://graphtreon.com/top-patreon-creators
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.
2) Create a brand new tax for business.
3) Distribute that money proportionally to stars over Github projects.