A plan for open source software maintainers - <AUTHOR> http://www.daemonology.net/blog/2017-05-11-plan-for-foss-maintainers.html <comment><USER4> Look at [https://webpack.js.org/](https://webpack.js.org/) and [https://github.com/webpack/webpack](https://github.com/webpack/webpack)

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.

<comment><USER5> Are we seeing the same page? The sponsor page hardly lists anybody noteworthy and nobody is going to click through those links. It's wasted marketing money (developers are the worst segment you can try to sell to).

I think it is pure imagination to think marketers throw 100k for this.

Also thinking of funding opensource as a marketing fund is really not the right approach. The companies are then coming to you for the wrong reasons.

<comment><USER4> Webpack sponsors: Capital One ($12K), ag-Grid ($7.5K since March), Hubspot and Rollbar. Those are some great names, with Webpack offering some not that great logo placement and linkage.

The StdLib logo on [http://vuejs.org/v2/api](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/](http://javascriptweekly.com/)). And JS Weekly has a much smaller audience than most prime open source project pages.

<comment><USER6> Wow, I'm really surprised at the $2k/month figure for a logo on the Vue API page. How do you go about finding sponsors for such a page? Or is it a case of being visible and lucky enough for sponsors to come to you?

</comment></comment></comment></comment><comment><USER7> Patreon is a perfect example how people are willing to support good works. Currently, the Vue's creator is receiving $10k monthly for his works [0].

I was happy recursively paying for Pycharm even sometimes I didn't use it for months. I see many people do that with Adobe products. If I had an option to pay Postgresql, Flask, VSCode developers a small amount every month , I would be happy to pay it.

One thing I would love to see is to have an option to _pay_ the OSS developers. There works are worth not only donations but payments. In the other side, I've seen enough higher managers refuse to use OSS. Their reasons are really understandable: "Who I'm gonna call if the software has some bugs?". Contracts, and sometimes expensive prices, are what they need before invest in new softwares.

So how these contracts should work in a Patreon-like site? If I had implemented the site, I would shamelessly copy the Patreon's tiers model. The cheap tier would require the developers just keep doing whatever they are currently doing. More expensive tiers would be for support contracts. I pay this developer for that project, and I'm guaranteed that I'll receive email support within 24h. If I pay more, I may have access to phone support. What kind of supports and how much are they worth is the OSS developer's decision.

[0]: [https://www.patreon.com/evanyou](https://www.patreon.com/evanyou)

<comment><USER8> _" 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.

<comment><USER9> > ... 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.

<comment><USER10> 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. :)

</comment></comment></comment></comment><comment><USER11> Great thought exercise but I feel it's more focused on how developers would like to get paid, versus how people with money would like to pay them. It's telling that the proposed system confers no meaningful rights to the sponsor -- his support grants him only the right to open issues which the developer may choose to consider.

I don't think that would pass muster with most purchasing/procurement people. They would rather just license a piece of software with a clear-cut usage agreement and get a support entitlement. The business value is all in knowing what the software/vendor will deliver and having some guarantees if things go wrong. I meet IT people with purchasing authority _all the time_ who think open source is cool, they love the concept and the values, they know there's great software out there, they're just baffled that they can't buy it and get the type of support they need to replace that decrepit proprietary system that charges 6-7 figure annual license fees. The big open source vendors -- RedHat etc. make tons of money on these situations already, but there's much more to be made and you could argue they aren't returning enough to the devs.

Anyway, the proven money is in selling support contracts, and perhaps if you could pay to have some real influence over feature/bugfixing priorities there would be a market for that as well.

Developers often don't realize that all widely adopted software benefits from having a support team. The support team deals with as many customer inquiries as they can for you, and they inform you about how the software is really being used in the wild. I think there would be a place for some sort of "technical support done for you" service where an open source developer can just hand off the responsibility for support contracts to someone else, and that someone else splits the revenue with the dev.

There's tons of money in the world right now for anyone who familiarizes themselves with a popular open source project and then learns how to do the sales & support for it. It's just that the devs don't want to deal with this stuff.

<comment><USER12> It was always my intention that this could in some manner encompass "support contracts" in a way that companies could pay for. I think I mentioned the possibility of tiered pricing; one tier might be "$1000/month, guaranteed reply to issues within 24 hours". I don't know enough of how corporate software support contracts work to flesh out the details here.

<comment><USER11> There's a lot of variability, but yeah, that's the right general idea.

Support contracts basically come down to providing higher levels of insurance in exchange for charging (potentially exponentially) higher premiums. You CAN guarantee that you'll fix issues. That might raise the monthly commitment to $10K, or even $100K. There are companies which will pay those premiums because it's worth it to them and they might be paying even more to someone like IBM.

You just have to have a really good support org and make them believe that they're going to get what they need, since that sort of commitment doesn't come lightly. An open source project also needs to consider on whether they're giving up too much autonomy by doing this sort of deal, but the opportunities are out there.

I think the idea of having a rider on the support contract which basically says "you get to vote on the next feature we develop" is a very interesting compromise. Basically no proprietary software vendor offers something like that, you're at their whims, if they decide to spend all their dev time on features that lock you in and then they double your licensing fees, tough luck, you have no recourse. If you went to procurement and told them, hey we'll never do that because if enough of our big customers got together they could vote against that work and we'd have to cancel it, it would blow their minds. It would be the ultimate form of insurance against single vendor lock- in. Who knows how much you could charge for that, because most corporations understand very well how much it costs them many millions of dollars to be locked into some proprietary vendor, they just don't see a good alternative.

So cool to get a response from the founder of Tarsnap btw!

</comment></comment></comment><comment><USER13> A few years ago I built a site addressed to this problem. I had seen BountySource, but thought they didn't have the right system, so decided to take a crack at it myself. The site was pretty rough, but even so, I was surprised when my "Show HN" posts about it drew nothing but crickets. Subsequent attempts to stimulate discussion on the topic here, by posting on the related threads that pop up from time to time, were also pretty much failures. I lost interest, shut the site down, and moved on.

So Colin, I think you're doing the right thing by soliciting feedback before you try to build anything. This seems like a real problem, and one that should have a solution, but somehow there just aren't as many people who want to make a living as independent open source developers as one might think.

It's true I didn't do much evangelizing. As I think is mentioned somewhere on the YC site, two-sided marketplaces, which is what this is, are especially difficult to get going, so it's not surprising that a half-hearted effort wouldn't have gotten me far. Anyway, I'm not absolutely convinced that, with far more effort than I put into it, I couldn't have turned this into a viable lifestyle business. But it did seem clear that at the very least, I had not hit a nerve.

Edit: clarity

<comment><USER12> 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?

<comment><USER13> 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.

<comment><USER12> _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.

<comment><USER13> > 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).

<comment><USER12> _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".

</comment></comment></comment></comment></comment></comment><comment><USER14> The main problem I see with this is misalignment of interests. If you are a founder of OSS project who gets contracted to do support work then the amount of money depends on number of users and pain level of their problems. Which means it is not in your interest to develop robust and bug-free software. Of course, it must still be usable, just not technically perfect (there are many successful OSS projects which are nightmare to support - the latest I saw was SuiteCRM, but there are many others).

The solution would be to build a platform which would collect some fixed amount of money from enterprises in exchange for support on _all OSS projects said enterprise uses_ (limited by hours per month?). Foundation behind the platform should employ or sign contracts with maintainers of different projects. It would also employ developers willing to maintain different projects where maintainers are not prepared to help. All fixes should then be offered as pull requests back to original maintainers, or in case of still used but abandoned projects a support fork could be made.

I am sure there are hole in this scheme too - if there weren't somebody would have implemented it already. But I see this as win/win/win solution. Hell, I would love to work for such foundation. I also see my company paying for such support. And it definitely benefits OSS projects. So what am I missing?

EDIT: just to clarify, enterprise gets a number of hours per month which are used in part for active support and features development but also for maintenance of projects (cleaning / refactoring code, writing tests, documentation,...) they use. And maintenance should also be used on libraries these projects use, so the effect should trickle all the way down.

<comment><USER12> _... the amount of money depends on number of users and pain level of their problems. Which means it is not in your interest to develop robust and bug- free software._

Agreed. I've heard people refer to producing highly painful software in order to encourage support contracts as the "RedHat model" of open source software.

But it cuts both ways -- if you as a developer have a bunch of people signed up to pay you monthly, you'd like to get their money while doing the minimum possible amount of work; so there's an incentive for you to make your software bug-free and easy to use so that your supporters aren't bugging (no pun intended) you all the time.

<comment><USER15> Disclaimer: My company basically has this model for AI. We work heavily with consulting companies and have a licensing structure relative to the number of cpu/gpu cores you use.

We have found this to be a great way to charge. There's a clear value prop for the customer when they see what they get (usually compliance features, security,..). Also for both sides, there's some basic reassurances: The company won't disappear because they make money, _and_ the vendor has incentives to do what they say they do.

A more mainstream company I think HN knows more of that does this is gitlab.

I'm definitely _not_ a "save the world" type founder. I run a for profit entity focused on commercializing technology that captures a large market opportunity.

Our product is open core for marketing, recruiting, and distribution purposes.

Because we're open source, I get to write books, run classes, and speak at technology conferences all over the world as way of doing sales and marketing. Turns out it works.

As a side benefit, we also get a small share of the market that use us in academic research.

As a comparison: The major cloud vendors all "run" and market open source frameworks in AI to get more people to spend money on their compute clouds (same reason they give away credits).

Widely used open source projects _usually_ have commercial backing somewhere in the chain.

My biased opinion I would love to learn counter points about: These utopian platforms can't work. They might be a great way to make a short term living. It feels like there wouldn't be incentives for maintenance or support under this kind of model for individual developers. My biggest reason for this is the support volume. Once you get to a certain scale, that "small repo developer" has a risk of getting overwhelmed. Pretty soon they hire someone. Then it's not about just code anymore. Granted, you can share the work among several contributors eventually, but at scale, this becomes fragile at some point.

This is a big reason why these things end up being companies.

</comment></comment></comment><comment><USER16> 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.

<comment><USER12> _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.

<comment><USER17> It is more likely that big corp will have their own team fix the problem, unless the original code is too big or convoluted.

<comment><USER18> The majority of big corp outside IT world just use consulting.

If they happen to have an internal team, it is mostly to manage contractors and architecture decisions for what they want to get delivered to them.

<comment><USER17> 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.

</comment></comment></comment></comment></comment><comment><USER19> 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](https://snowdrift.coop/how-it-works)

To learn a lot about the field and its history:

[https://wiki.snowdrift.coop/market-research/other- crowdfundi...](https://wiki.snowdrift.coop/market-research/other-crowdfunding)

[https://wiki.snowdrift.coop/market- research/history/software](https://wiki.snowdrift.coop/market- research/history/software)

<comment><USER12> 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?

<comment><USER20> I'm on the snowdrift.coop team. This type of thing was part of the original vision -- you'll see bits and pieces if you poke around our wiki[0] -- and remains that way.

Ironically, we struggle from the same funding problem we're looking to solve. At some point we realized we needed to drastically reduce scope if we were ever going to launch. For context, Snowdrift has been around for slightly _longer_ than Patreon, but we didn't receive several million dollars of VC funding (or solicit it -- our mission is strictly ethical, not competitive[1]). We're planning on adding community-support-type features back in as we (hopefully) grow and open up the platform to more projects.

I'm happy to chat more, but am also in the hectic last few days of my semester; I'll come back to this but am not sure exactly when. If you'd like to get someone else's response, you can try pinging people in #snowdrift on freenode.

[0]: [https://wiki.snowdrift.coop/](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...](https://wiki.snowdrift.coop/market-research/other-crowdfunding) [3]: [https://wiki.snowdrift.coop/about/mechanism](https://wiki.snowdrift.coop/about/mechanism)

</comment></comment></comment><comment><USER21> There are two economic factors that come into play here:

1\. Open source software is price anchored at $0. I know that there are commercial alternatives that might anchor open source software: say Photoshop for Gimp. But the direct pricing is "Here, it's free."

2\. I run Ubuntu. A measly $5.00 per piece of open source adds up to many thousands of dollars. That's not going to happen, even if it was practical. Someone is surely getting stiffed. If I think about libraries like padleft too, then it's pretty much everyone...or to a first approximation, everyone.

Should I send a check to Google for Chromium and throw a quarter toward Facebook every time I visit a website that uses React.js? What about a utility that's compiled with GCC, do I write one check to the author and another to FSF?

It's just not that simple.

<comment><USER22> I like the idea of [https://flattr.com/](https://flattr.com/)

The consumer just pushes money into his account (maybe 5$ monthly) and lets the system distribute it monthly.

The distribution is influenced by visiting flattr-enabled websites, staring projects on Github, etc.

However, this is a donation system. There is no obligation for the receiver, while Percival envisions it as payment for maintenance.

<comment><USER21> 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.

</comment></comment></comment><comment><USER23> BountySource ([https://www.bountysource.com/](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).

<comment><USER24> There is also [https://gratipay.com/](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.

</comment></comment><comment><USER25> 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.

<comment><USER26> tav, have you looked at Stripe's Connect product ([https://stripe.com/connect](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. :)

<comment><USER25> 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](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!)

<comment><USER26> tav, I'm sorry for my delay getting back to you. I just sent you an email at your profile address to introduce you to someone on our New Business team, who may be able to help.

Open source funding is a cause near and dear to my heart, and I hope something is able to work out.

(And thanks!)

</comment></comment></comment></comment><comment><USER27> 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.

<comment><USER28> 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.

<comment><USER20> 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.

<comment><USER28> 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.

<comment><USER29> > 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](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.trustedreviews.com/news/trump-win-changes-nothing-for- apple-says-time-cook-in-staff-pep-talk) [http://www.businessinsider.com/trump- do-nothing-presidency-2...](http://www.businessinsider.com/trump-do-nothing- presidency-2017-4)

<comment><USER17> 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.

</comment></comment></comment></comment></comment></comment><comment><USER30> You can call me cheap or unthankful, but for me open source contribution is kind of a zero sum game.

I'm not willing to spend money on maintainers fixing their stuff, but I'm also not expecting anything in return. I think out of ~15? years of sporadic contributions to dozens of projects all tangible rewards I've got were a single CD from my amazon wishlist and a handful of stickers and t-shirts (the kind that are not handed out in dozens at conferences.)

If we're talking about "using open source software for business, e.g. making money" then I'd probably be most happy with an "office hours" model, e.g. paying a maintainer/core contributor X per 1-2h of their time to help me troubleshoot/get started. That's usually all I/we need, seldom it would be "give me a specialist freelancer for days or weeks".

That said, I do think it's very sad that (at least in my experience) self- marketing is everything, so for example if you don't contribute at all to project X but can show a slightly better talk proposal (with a mainstream/beginner) topic, you're invited to speak and the people who focus on code/bugs/whatever and less on being rockstar presenters get picked less for "boring internals talks" (this depends on the community of course).

</comment><comment><USER31> Not really talking exactly to the topic, but I recently went to use an open source project which said something like "this is open source software under a permissive license, but if you use it commercially you have a social obligation to financially support it".

It's probably important to note that it was web-facing code so it's public information if you are using it, which is encouragement to pay, BUT I still felt that they were striking an explicit bargain with me - use it commercially and you must pay - I liked that.

I thought this was a really good way of putting it - use it, it is free, but you are in fact obligated to support it financially if you use it commercially.

Again on another slight tangent, I think open source developers tend not to be business savvy and do things like say "pay what you think it is worth", or they ask for "tips" \- these are good ways to get nothing. If you want people to pay something then you must set the price expectation clearly in the mind of the buyer/user.

<comment><USER31> Answering myself with another slightly off topic point - I wonder if a public register of financial support to open source projects would encourage more of it?

For example, if payments went through github for verification, and there was a public list to see the rankings of which companies give the most to which open source projects.

We could then see for example how Amazon which makes billions from open source, contributes (? $0) to open the open source projects that it packages and sells as services.

<comment><USER12> A lot of companies want to support projects without advertising that fact. Sony spent a seven-digit amount on open source software while doing things like contributing code via shell companies in order to avoid revealing what tools they were building their products around. I've received more than one email saying "this patch fixes a bug PLEASE DON'T TELL ANYONE IT CAME FROM ME".

Amazon has chosen for some reason to avoid advertising their open source contributions, but they absolutely do make contributions. Would it be nice if they contributed more? Sure. But that's true of every company.

<comment><USER31> If the goal however is to get companies to contribute more then the simultaneous applauding/shaming of a public donations registry is likely to encourage some companies to contribute because they like to be seen as good corporate citizens and not poor corporate citizens.

I can imagine for some companies it would be a matter of corporate pride to advertise their "projects financially supported" page, perhaps even as part of their recruiting effort to advertise how developer-centric they are.

github is the logical home for this, and indeed it is in the interests of github to do it - open source projects are far more likely to want to host on github if it has a public donations registry that, due to its public nature, actually works.

<comment><USER17> Is it really good idea to give github defacto monopoly power? This would make it much harder for github competitor to arise and business competition is a good thing.

Especially since as politics and culture tend to be more and more polarized, you don't want one company with that much power.

<comment><USER31> On the other hand, imagine if it really worked and money poured in to support open source projects - it would be transformative for the lives of many open source developers.

<comment><USER17> Github did populist political decisions in the past. They will move from "united meritocracy of Github" to full sjw and back in blink of eye.

They do a lot of good for open source, but I would not trust them not to close project due to political reasons - especially under pressure. They are not the pick of a company I would do for project that aims to "shame" companies/individuals when they misbehave.

</comment></comment></comment></comment></comment></comment></comment><comment><USER32> OpenCollective [1] is a possible solution. It provides a way to support (monthly contributions or dedicated campaigns), but also the whole back-end of tracking the money and spending, and at least some degree of legal support with paperwork, invoices, ...

1.- [https://opencollective.com/](https://opencollective.com/)

</comment><comment><USER33> I have been occasionally pushing a oss in government campaign(www.oss4gov.org).

OSS is a perfect match for government software, but it is painful to get a OSS project started and funded by government. Which kind of blocks development as there is only one customer.

So I am trying to argue that there should be a collaborative license that someone kicks off a fully funded project and slowly others who see value come in and take on more slices of the original cost of the project.

The point I am trying to make is that even the current raft of OSS projects are a tiny slice of those that are or should exist, and that we need to look at less private more communal funding models.

We rarely build roads by subscription or toll anymore. Software should be the same

</comment><comment><USER34> This discussion is very interesting.

We are currently building something that let's you donate / offer a bounty for a specific github issue. You can check it out at [https://octotreat.com](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. :)

<comment><USER35> Will have an eye on it.

I maintain an OS-Project and for me it would be a great feature if contributors could receive the money (up to 100%).

The main problem for me is, that i did not have the time for many request, with or without money, it will not change anything for me, but it could encourage others to do something for the project.

<comment><USER34> If you would be able to earn a good hourly salary for the issues, could you 'make' time for it?

We believe that merging a PR is work and should be rewarded with around 20% to ensure a good code quality. It's weird to hear you say that you want all that money to go to the contributor. I'll keep that in mind and will ask more people about their opinion. Thanks for the input.

<comment><USER35> For me it is a side project (got payed from my company to create it), for more than 1 year i could do some support, but since than i work fulltime on other projects.

In my (less) free time i watch for issues and PR, but if somebody could be payed for doing this, i had no problem with that.

For famous projects it is not a huge problem to find free maintainer and contributors, but for smaller projects it is a problem. I did not know if paying a contributor would help, but i think it's worth a try. I can imagine, that there are some developers that could work fulltime for many small projects and earn money.

</comment></comment></comment></comment><comment><USER36> Bountysource has both software bounties ([https://www.bountysource.com/](https://www.bountysource.com/)) and monthly donations ([https://salt.bountysource.com/](https://salt.bountysource.com/)).

It's also open source: [http://github.com/bountysource/core](http://github.com/bountysource/core)

<comment><USER37> 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.

<comment><USER36> Bountysource has voting built in. As well as a browser extension that lets you thumbs up when on a tracker like GitHub:

[https://www.bountysource.com/extension](https://www.bountysource.com/extension)

</comment></comment></comment><comment><USER38> How to fund open source software has been an ongoing debate since... forever. There used to be a great mailing list with a lot of key people on it: [http://www.crynwr.com/cgi-bin/ezmlm-cgi?ddn:0:0#b](http://www.crynwr.com/cgi- bin/ezmlm-cgi?ddn:0:0#b) if you'd like to dig through the archives.

There are no easy answers, is the conclusion I've come to.

</comment><comment><USER39> Part of the problems is that certain software ecosystems (npm, rust+cargo, golang with "build against HEAD") seem to think it's "sexy" to declare war on the traditional package management systems, because they see proper long-term maintenance issues as being a burden on developer time and the "move-fast-and- break-things" paradigm.

In certain cases this is driven by leaders of those ecosystems having more experience developing in a corporate environment where indeed everything builds against HEAD, not realising that this model completely breaks down in a decentralised free software environment where different teams are more asynchronous and have no chance of globally syncing with everyone else _all the time_.

Please stop treating FOSS distributions like dirt, our model works better in an environment where most _maintainers_ are volunteers rather than full-time paid developers, for shipping stuff that is usable over a long (> 3 months) period of time.

<comment><USER40> > rust+cargo ... seem to think it's "sexy" to declare war on the traditional

That's not true. They do solve different problems, both are related to packaging, but still tangential to each other. You can use npm, cargo, bundler to build software which you then wrap to RPM/DEB ... system packages. I can recommend the talk that Yehuda Katz held on packaging/package managers at the Rubyconf Portugal '16 [https://www.youtube.com/watch?v=Bwk8mdU6-ZY](https://www.youtube.com/watch?v=Bwk8mdU6-ZY) It's mostly about bundler and cargo and the design decisions behind them.

<comment><USER39> I'm not going to watch a 1 hour video just to "get" your point.

I _am_ a package maintainer, and my _actual experience_ is it's much harder to package software in these ecosystems. When I bring up issues, they get brushed aside as "that's not how things are done", ignoring the actual issues. This _is_ "declaring war", no matter how you try to paint it.

Bundling is not packaging management, it's doing a disservice to your users. Bundled software is not maintained in the long run, no teams bundling software are tracking security and bug fixes for the full dependency tree. It's too costly to do this across all pieces of bundled software. That is why FOSS distributions put an emphasis on deduplication, proper API compatibility, and loose version constraints.

The package managers I mentioned take the opposite approach, of strict version constraints and little API compatibility. This makes things easier for the developers, but much harder for maintainers. Every new version we have to carry, simply because developers were too lazy to maintain API compatibility, means more work for maintainers to track bugfixes.

The original article is proposing a way to reward more maintainers. This is one way to put resources where they're needed. A better way is to arrange your system to _not need so much resources_. That is what FOSS distributions do.

</comment></comment></comment><comment><USER41> 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 - <USER2> 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.

</comment><comment><USER42> 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).

<comment><USER43> Ease of use is key, I agree. I would add trust though.

Unfortunately these two are sometimes diametrically opposed to each other.

<comment><USER20> Sometimes. Ongoing donation systems naturally build trust because your patronage is more valuable than this month's donation.

</comment></comment></comment><comment><USER44> I would also like to point out another alternative with which Mike Perham, author of Sidekick, has been immensely successful. He makes significant income by selling commercial licenses that also have certain premium features [1]. Isn't it possible to make it simple to sell commercial licenses? It'd be less favourable approach in terms of the open source spirit, but I think it can benefit everyone in the long term. Authors can be motivated to maintain the project and provide business value at the same time.

Some commercial features can include things like dashboards, monitoring, or notifications. Of course, it'd likely work if the many businesses would find the project useful and would be willing to pay.

[1]: [https://www.indiehackers.com/businesses/sidekiq](https://www.indiehackers.com/businesses/sidekiq)

</comment><comment><USER45> [http://www.fordfoundation.org/library/reports-and- studies/ro...](http://www.fordfoundation.org/library/reports-and- studies/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure) is an excellent summary of the issue.

</comment><comment><USER46> Probably different strategies will be needed for different markets.

I created PropertyWebBuilder, an open source tool for creating real estate websites and I find in that sector there just isn't enough technical knowledge for people to get involved directly. I think in that case some sort of groupfunding initiative where estate agents / brokers club together to finance projects that help them might be best.

You can find a more detailed examination of this in an article I wrote about the subject:

[https://hackernoon.com/open-source-software-for-real- estate-...](https://hackernoon.com/open-source-software-for-real-estate- obstacles-and-opportunities-b36d2c0cfcc4)

</comment><comment><USER47> 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.

<comment><USER48> _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."

</comment></comment><comment><USER49> Much of the discussion here is about software useful to Internet businesses. These companies are likely to pay to support Open-Source that they depend on. Yet, this focus misses vast areas of valuable software.

For the last 6 years I've been working on an Open-Source CNC simulator called CAMotics. See [http://CAMotics.org/](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.

<comment><USER50> Is that project lifetime total users, or daily active users ? Each daily active user is worth ca 1 USD/month ... Just put up a banner like _" your ad here ? Contact email@example.com"_ And write in big letters on the front page how many users are using the program right now. Then call some news papers with a cool story about how you made a program that is used by 100k people, and talk about the DIY movement or whatever.

<comment><USER6> Is a newspaper really going to be interested in such a thing? Even the local paper in my small town would likely find this a non-story.

<comment><USER50> local news papers love local succes stories. even a bad story can be published if you do most of the work yorself basically writing the story for them and supplying photos. there are people making a living _selling_ stories and photos to news papers.

</comment></comment></comment></comment><comment><USER51> It seems one _small_ approach in the right direction would be for someone+ to provide a discovery/marketing service for helping spotlight, bring to the forefront those working on the infrastructure-type projects. Thinking more along the lines of a podcast, blog, etc. that would generate revenue from sponsors. Akin to Changelog or other podcasts, but specifically focused on the behind-the-scenes/infrastructure/maintaince type stuff - the "backstory" if you will. Folks could donate to this service and funds could be funneled to the highlighted projects/developers.

The "marketing service" angle would be to provide free marketing to these types of projects. Inviting folks as guests, writing about projects, etc.

It does solve the overall problem for everyone, but it would be going in the general right direction. There may be efforts like this already, but I am not aware of them.

\+ I do not have the time it would take to do this well.

</comment><comment><USER52> 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.

</comment><comment><USER53> 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).

<comment><USER12> _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.

</comment></comment><comment><USER54> 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.

</comment><comment><USER55> 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.

<comment><USER36> [https://salt.bountysource.com/](https://salt.bountysource.com/) has monthly and one-time donations for OSS projects. And PayPal is supported.

<comment><USER56> I understand you're trying to follow up in conversations. Posting a link once or twice is okay. This is beginning to look like spam.

</comment></comment></comment><comment><USER57> > If this existed, would you — an open source software developer — sign up and > use it?

To whomever does create such a thing, please make any JavaScript served to the user free software (it'd be a bonus if the server software were too, of course).[0] There are sites I'd use to make donations, but I can't because the code is non-free; I don't find this to be an unreasonable request for free software projects.

[0]: [https://www.gnu.org/philosophy/javascript- trap.en.html](https://www.gnu.org/philosophy/javascript-trap.en.html)

<comment><USER57> I expected downvotes, but I consider this to be a serious issue to which I devote much of my activism, so I would like to hear rationale.

([https://media.libreplanet.org/u/libreplanet/collection/resto...](https://media.libreplanet.org/u/libreplanet/collection/restore- online-freedom/))

</comment></comment><comment><USER58> In general we pay for infrastructure with taxes. It's getting harder and harder to argue that no software counts as infrastructure: "An organizational structure needed for the operation of a society or enterprise." The current President talks about tossing money at infrastructure; maybe he'd like to spend an outrageous 1% of that on software. It's nice when volunteers fill in potholes or replace bent railway ties - but it's no way to run a railroad.

</comment><comment><USER59> Maybe unpopular and not true for all software, but in general, I would say the idea to base a business on support for software is in contradiction with the idea that _this_ software should solve problems in a mostly automatic way.

Because good software doesn't need support, or at least a lot _less_ support than bad software, so there might be some conflict of interest?

</comment><comment><USER60> I'm building an app I'd love to open source, but can't because that would make it's development unsustainable.

I've been thinking that I could open a patreon account, and then open source the code after I reach $5k/mo in monthly donations.

Do you think it's a good idea?

<comment><USER61> Once it actually gets launched, also consider Snowdrift.

</comment></comment><comment><USER62> "a cross between Patreon and Bugzilla"

Have a look at BitHub: [https://github.com/WhisperSystems/BitHub](https://github.com/WhisperSystems/BitHub)

</comment><comment><USER63> Having both written & maintained open source software, and negotiating (commercial) support and development contracts, I find myself thinking about this issue every couple of months.

A few thoughts:

Bounties are a problem since each is basically a tiny contract (what to deliver, what it'll cost, when, etc) in itself, so they need to be haggled over, ie. there's a nontrivial transaction cost to each. In practice, you get a crossbreed between a graveyard of ignored stuff and a race-to-the-bottom wishlist amounts - FIX THIS URGENT MULTITHREADED PROGRAM FOR $15 PLZ I'M PAYING YOU! I'd rather do open source obligation-free than _that_.

Monthly donations (like Evan You's Patreon campaigns that dvnguyen mentioned) can work, but from the client standpoint, it's not really clear what you gain ("if this breaks tomorrow, who I'm gonna call?"), so while theoretically nice, in practice there's not a lot of uptake.

As Colin mentions in the post, if there's a large company (or a few) that use the software and see the value, they can be persuaded to support it via explicit support contracts with the developer(s) or just hiring them (I think redis is a success story here). But many projects don't have such large companies as users (or they don't know that they have!).

Another issue that I think we always stumble in these discussions is the pricing and talking about value, esp. in context of open source software. My strong opinion (feel free to disagree is): in open source, the software itself is a commodity, and its PRICE is $0. If you don't like that, don't do open source. However, there's no question that the software has a VALUE that's over $0 (otherwise why'd anyone use it). But the value of the software is not only in the code, and as patio11 always reminds us (in the context of business discussions), determine your value and charge based on value, not on cost (ie. amount of effort needed to write the code).

The value is that the company developers are faster (increase/multiply their value). The RISK to the company is that the developers will have to spend their time maintaining, fixing, updating, the software if there's no external vendor to do it (the "who am I gonna call?" problem), which will decrease the developers' productivity, ie reducing the software value (perhaps below zero). So, removing this risk should have business sense to the company.

Borrowing from risk management, we can try to estimate the probability of it happening ("how often does the code need to change", "how often bugs that should be fixed are found", not "what is the probability of open source dev burning out" since that hides the externality - developer's labor), and the cost ("if we have to maintain it ourselves, how much time (ie. money) would we spend"). It's more of a ballpark estimate rather than a rigorous calculation, but for many highly used projects, a reasonable figure can be estimated. This figure, then, is the amount the company could reasonably be expected to pay each month.

So the company is not paying for the software. They're paying for their piece of mind - to minimize risks inherent in their use of unsupported software. I am convinced this argument is MUCH easier to sell to the companies than social or moral obligations.

On the developer side we want a steady, stream of income, so combining the two might mean a (tiered) subscription based model. For $0 (free) you use the software but the developer has absolutely no obligation to ever listen to your bug reports or feature requests. For $X (monthly), you can expect the bugs to be fixed (and prioritize which should go first), up to a specific limit in amount of hours worked, but the developer has the sole discretion over the _new features_ to be implemented. There can be multiple tiers ($X, $Y, $Z... for different amounts of work).

The limit in amounts worked is there to set expectation of what exactly the company gets for their money, ie. what to do if the company asks for more work (bugfixing) than you'd be happy doing for the subscription amount. For $X, it's Y hours of developers time (non-refundable retainer). $X could be set based on the calculated risk above, an Y (hours) is based from the dollar amount and a hourly consulting rate that the developer could ask for when doing a real retainer contract.

An example: let's say I'm a proud developer of libwidget, an indispensable library for managing widgets in a nosql database. There's dozens (respectable, but not high) of companies using my code. I do a few updates a month, mostly bugfixes. If I disappear each company would probably need to spend an hour of their developer time each month maintaining this, let's say that'd cost them $100. Let's also say my target retainer rate is $100/hr, so this ends up being an hour of my time. (To clarify, the rate would be lower than the usual consulting rate since there is a possibility that no work will be needed in a month).

Based on the above, I'd set up a subscription plan that says: for $100/mo, you can file bugfixes (private or public), and I will spend up to 1hr per month fixing those issues (if there are more of them, I'll let you prioritize). If more work is needed, I can either set up a larger plan, or agree to do extra work for $Z ($Z > $X), or any combination of the above.

Something like this would, I believe, scale nicely from almost no work (and getting a few bucks a month for coffee and ice cream :) to being basically fully employed in support of your work (and being paid fairly for it), while making everyone clear about what they can expect from you as a open source dev.

As a footnote - many companies budget for a year, so offering year subscription may work as well, or better (since it'll be almost the same to the company financial-wise, and they'll know they have you on support for the next 12 months). Or you can pull an oldest trick in the book and price- differentiate yearly and monthly fee so that the yearly fee looks like a better value for money. The yearly fee makes the subscription model even more smooth and with less surprises than the monthly-based one, so it's useful to keep in mind.

Great thing about this is that it's possible to do with existing infrastructure for monthly subscriptions (say, Patreon for subscriptions, github for issues, email or a separate private bug tracker for private "technical support"). But if a platform that nails this approach would appear, I'm betting in itself it'd be a $1B+ company (think GitHub for - gasp - <USER3> hosting - actually, no, wait - GitHub why haven't you done this already ?!?).

Just my $0.02 :-)

</comment><comment><USER64> Right now there are companies who employ people who maintain OSS. This would be crowd-sourcing the money for that?

<comment><USER12> 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".

</comment></comment><comment><USER65> Why not just use github issues and bitcoin for payment.

If you have problem write an issue on the project repo and offer an amount in bitcoin.

<comment><USER66> 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.

</comment></comment><comment><USER67> (a) talk with patio11 and tptacek and follow _all_ their advice for tarsnap (b) work on this new idea while the picodollars flow in…

:-p

</comment><comment><USER68> 1) Nationalise Github.

2) Create a brand new tax for business.

3) Distribute that money proportionally to stars over Github projects.

<comment><USER5> GitHub stars can be easily gamed socially.

</comment></comment><comment><USER69> Isn't this what github and friends are for?

<comment><USER12> Github provides the "issue tracker" side of things. But I'm not aware of any "sign up to pay this developer $X/month" functionality?

<comment><USER70> Patreon, I guess? You mention it, but not really why it wouldn't work at small scale. At large scale, you'd need to build something to link Bugzilla and Patreon users.

I can imagine wanting to self-host, but I'm not sure that giving up the established (if expensive) Patreon platform would be worth it.

(EDIT: comment has been expanded twice; sorry.)

<comment><USER12> Did you read the blog post? I specifically described this as a cross between Patreon and Bugzilla.

<comment><USER70> A fair response; sorry, I expanded the comment to something more reasonable.</comment></comment></comment></comment></comment>


Leaving Java EE Behind - <AUTHOR> http://www.hildeberto.com/2015/02/leaving-javaee-behind.html <comment><USER2> Tying yourself to Oracle (or keeping being tied, after Sun Microsystems was bought) was the most important error on your side. Oracle doesn't love you, is just a profit-focused company, and apparently heavily at that. Sun did love their users/customers.</comment>


Ask HN (again): What is the best affordable programmable drone? - <AUTHOR> Almost a year ago, a HN participant asked about the best affordable programmable drone: https://news.ycombinator.com/item?id=8989411
I'd like to ask the question again. Are there any new contenders for the best programmable drone, ideally for $100 or less? I have two daughters, nine and seven years old, who have just seen a demonstration of a drone by a friend of our family's, and they're hooked. Before we purchase one, I'd like to take the opportunity to buy a programmable one so I can mess around with it, too (and teach the kids to program it).
EDIT: Ideally, I'd like something like this, but programmable/hackable: http://www.amazon.com/gp/product/B00MNG37C2/ref=s9_simh_gw_g21_i1_r?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=desktop-1&pf_rd_r=01GMYMFRR2QNC3AT5DG0&pf_rd_t=36701&pf_rd_p=2079475242&pf_rd_i=desktop
Thanks! <comment><USER2> $90. Completely open source. PCB-structure. App Enabled. Steve Holt.

[http://www.amazon.com/Crazepony-Quadcopter-Development- Platf...](http://www.amazon.com/Crazepony-Quadcopter-Development-Platform- Student/dp/B015MYR1GO/ref=sr_1_1?s=toys-and- games&ie=UTF8&qid=1452373186&sr=1-1&keywords=bitcraze)

<comment><USER3> \o/

<comment><USER4> I just realized that this emoticon is of someone raising their arms into the air in triumph, and _not_ someone squishing their face with their hands so that their mouth makes an O.

<comment><USER5> \ö/

</comment></comment></comment></comment><comment><USER6> Forking off this question, if I may, I am looking for the same thing but with a budget of around $250. If anyone knows something good but doesn't post it because it's >$100, please reply to this message.

Many multirotors you see on webshops are finished and ready to fly, which tells me nothing about their repairability or hackability. There are also kits which I'd prefer (so I can learn what's in there and how to put it all together) but they have nearly the same issue: can I replace or add components, or is this combination the only way it's going to fly? Is there room to add components, like a missing GPS module? Or could I swap out those motors for stronger ones in a year without needing to replace 90% of the electrical system? Does it run open software that I can modify or do I need to overwrite its firmware to do that?

All that is a bit difficult to judge as a beginner (I can fly alright, but not build) and I've been casually looking around for at least three months now, coming back to this point every time I saw something cool.

(@OP, ph0rque, if you think this pollutes the thread, reply and I'll edit/remove it!)

<comment><USER7> Have a look to Erle Copter.

[http://erlerobotics.com/blog/home- creative/](http://erlerobotics.com/blog/home-creative/)

</comment></comment><comment><USER8> I'd have to say your best option would be the Parrot AR Drone. It's probably will be higher than your price range but it's definitely worth it. I personally have one and have even programmed it to dance to music. It's extremely easy to work with and there are numerous libraries out there for most languages. I highly recommended it, you don't even need to modify the drone to start developing for it. I've built my own quadcopter and would have to say I still prefer the AR Drone when it comes to development.

<comment><USER2> but it uses JAVASCRIPT. barf

<comment><USER9> What? Sure, you can program them with javascript, but that's not required (just popular). There are libraries for clojure (clj-drone), ruby (argus or artoo), and I'm sure other languages.

</comment></comment></comment><comment><USER10> What sort of drone are you looking for, and what sort of programmable?

This tiny $20 quad has a hacked, open firmware: [https://hackaday.com/2016/01/07/open-source-firmware-for- a-m...](https://hackaday.com/2016/01/07/open-source-firmware-for-a-mini- quadrotor/)

<comment><AUTHOR> Ideally, something like this, but programmable/hackable: [http://www.amazon.com/gp/product/B00MNG37C2/ref=s9_simh_gw_g...](http://www.amazon.com/gp/product/B00MNG37C2/ref=s9_simh_gw_g21_i1_r?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=desktop-1&pf_rd_r=01GMYMFRR2QNC3AT5DG0&pf_rd_t=36701&pf_rd_p=2079475242&pf_rd_i=desktop)

<comment><USER11> Just link to the product without all the ref parameters... It feels like you're just dropping links for referral fees: [http://www.amazon.com/gp/product/B00MNG37C2](http://www.amazon.com/gp/product/B00MNG37C2)

<comment><USER12> Amazon's referral values always ends with "-20" and is usually placed under the parameter "tag". OPs link doesn't have any referral attached to it. For those who aren't familiar with Amazon's links, it may be hard to figure out how to detach it while still keeping it valid.

</comment></comment></comment></comment><comment><USER13> For a starter drone even $100 is a lot. Two things that you don't realize in demos are:

1\. Drones are notoriously hard to fly.

2\. The battery life is a true buzzkill. Even Parrot lasts 15 minutes or so.

What you want to do is buy a cheap 2-pack for $25-30 each. See if your girls and you still like them. You'd probably break them while learning. But that won't hurt you cause they are cheap. You'd also get a good idea of kinds of projects to do with them.

Then get a drone that fits, as you'd have a better understanding of what matters to you. I settled on a $80 drone that's not programmable. That's cause I stick a BLE arduino on it. Turns out that's all I needed. But get something cheap and break it while learning how to fly.

<comment><USER14> Do you have a specific 2-pack for $25-30 that you would recommend? I've never seen anything like that before?

<comment><USER15> I can't recommend a 2-pack, but for a nearly unbreakable single learner drone the Hubsan x4 is the standard, and it's great.

When you and your kids start flying drones you WILL crash them. A lot. Hence why the "unbreakable" bit is important.

My girlfriend and I both bought one each last year, and we had a lot of fun with them. They have a (terrible) camera, they can go pretty fast, they can fly outdoors and fight at least light wind, and most importantly, particularly if you add the propeller guard, they're almost indestructable.

We bought an extra pack of propellers and an extra pack of batteries (the latter to extend flight time) and that's all we needed for a few months of near-daily flight.

We crashed them into trees, dropped them from 100 feet up, flew them at inadvisable speeds indoors, bounced them off walls, ceilings, light fittings, furniture, and occasionally each other, and they survived fine barring a bunch of propeller replacements (which are very cheap).

10/10 would crash again.

</comment></comment></comment><comment><USER16> Unfortunately I cannot help you with your question, I haven't found anything cheaper than building your own. And that's going to cost you >200USD.

I do have some advice before you invest in a drone. Buy a cheap non- programmable mini-drone first ~15 USD. Flying a drone is not easy, you'll crash a lot in the beginning and you rather wreck such a mini-drone than a more expensive one. Plus, mini-drones are almost indestructable.

<comment><USER17> This is good advice, but if you're fairly confident that you're really going to get "into" quadcopters I recommend starting with something larger like the Syma X5/X5C. They're more expensive (~$50) but far more versatile - can fly outside with a range of 150-200m or more, and are actually quite a bit easier to control because their size gives them stability and makes it easier to see the drone and its orientation.

</comment></comment><comment><USER18> The Parrot AR Drone isn't quite in that price range but is very programmable and works decently well with Node.js libraries. I once controlled five of them at the Yahoo! Open Hackday in a swarm using a Leap Motion controller. Everything my team wrote for that hack was in JavaScript (leap motion interface, parrot flight controller, and server that linked it all).

<comment><USER18> Here's most of the source code from that hack:

[https://github.com/jsjohnst/leapcopter](https://github.com/jsjohnst/leapcopter)

And here's a promo video I made after the hack to show at work the following week:

[https://vimeo.com/76095888](https://vimeo.com/76095888)

</comment></comment><comment><USER19> I think [http://bitcraze.io](http://bitcraze.io) might be a good fit.

It's a bit more expensive($180) but have a lot of open source apps and libs that you can play with.

</comment><comment><USER20> Might be off topic, but can we map 3-d space to detect obstacles like how a roomba maps 2-d space and avoids obstacles ? (like this [http://www.technologyreview.com/sites/default/files/images/i...](http://www.technologyreview.com/sites/default/files/images/iRobot_Newsx299.gif))

I mean, is that a solved problem ?

</comment><comment><USER21> There is only one kid-friendly programming tool that connects with drones: [https://tickleapp.com/devices/](https://tickleapp.com/devices/) and it only appears to work with Parrot drones, the cheapest of which is $99.

In case you don't have an ipad, there are other visual coding tools that work with robots, but not drones, like Scratch. Someone did make a hack to connect Scratch to the Parrot AR Drone, which is more like $300: [https://github.com/campk12/ScratchForARDrone](https://github.com/campk12/ScratchForARDrone)

</comment><comment><USER22> [https://www.kickstarter.com/projects/728836843/codrone- learn...](https://www.kickstarter.com/projects/728836843/codrone-learn-to- code-with-programmable-drone)

</comment><comment><USER23> Lots of good guidance here [http://copter.ardupilot.com/wiki/build-your-own- multicopter/](http://copter.ardupilot.com/wiki/build-your-own-multicopter/)

</comment><comment><USER24> Freudian reading: I read OP as _What is the best affordable programmer drone?_

</comment><comment><USER25> At first glance, I thought it said the best affordable "programming" drone. I was thinking, "Damn, the HR people are getting really honest in the job offers now." Made more sense after a double take.

</comment><comment><USER26> You can try Emlid's Navio [http://www.emlid.com/](http://www.emlid.com/)

It's a RPi based autopilot, it runs Linux and therefore much easier to program and use.

</comment><comment><USER27> Sorry for being slightly off-topic, does anyone have the Yizhan Tarantula x6 - It's around £35-40 and from a number of videos I've seen, is able to carry a GoPro.

I fancied getting that for shooting some video.

</comment><comment><USER28> Wait why do you want to program it? The fun is in the flying of it. Especially FPV in acro mode.

</comment><comment><USER29> CoDrone on Kickstarter now. Robolink.com/kickstarter

</comment><comment><USER30> Just start with any drone first and don't make the poor kids suffer through you trying to program it</comment>