
A plan for open source software maintainers - fabrice_d
http://www.daemonology.net/blog/2017-05-11-plan-for-foss-maintainers.html
======
Androider
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.

~~~
educar
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.

~~~
Androider
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.

~~~
GordonS
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?

------
dvnguyen
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)

~~~
caf
_" 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.

~~~
jdmichal
> ... 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.

~~~
justinclift
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. :)

------
apatters
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.

~~~
cperciva
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.

~~~
apatters
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!

------
ScottBurson
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

~~~
cperciva
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?

~~~
ScottBurson
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.

~~~
cperciva
_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.

~~~
ScottBurson
> 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).

~~~
cperciva
_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".

------
annnnd
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.

~~~
cperciva
_... 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.

~~~
agibsonccc
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.

------
metalmanac
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.

~~~
cperciva
_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.

~~~
watwut
It is more likely that big corp will have their own team fix the problem,
unless the original code is too big or convoluted.

~~~
pjmlp
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.

~~~
watwut
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.

------
buovjaga
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)

~~~
cperciva
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?

~~~
smichel17
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)

------
brudgers
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.

~~~
qznc
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.

~~~
brudgers
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.

------
sheetjs
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).

~~~
uiri
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.

------
tav
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.

~~~
kevinr
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. :)

~~~
tav
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!)

~~~
kevinr
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!)

------
peterburkimsher
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.

~~~
chubot
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.

~~~
smichel17
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.

~~~
chubot
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.

~~~
Mathnerd314
> 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)

~~~
watwut
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.

------
wink
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).

------
hoodoof
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.

~~~
hoodoof
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.

~~~
cperciva
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.

~~~
hoodoof
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.

~~~
watwut
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.

~~~
hoodoof
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.

~~~
watwut
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.

------
brunosan
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/)

------
lifeisstillgood
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

------
JoeE
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. :)

~~~
progx
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.

~~~
JoeE
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.

~~~
progx
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.

------
wkonk
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)

~~~
danieldk
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.

~~~
wkonk
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)

------
davidw
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.

------
infinity0
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.

~~~
Xylakant
> 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.

~~~
infinity0
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.

------
jondubois
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.

------
saulrh
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).

~~~
miclill_kit
Ease of use is key, I agree. I would add trust though.

Unfortunately these two are sometimes diametrically opposed to each other.

~~~
smichel17
Sometimes. Ongoing donation systems naturally build trust because your
patronage is more valuable than this month's donation.

------
shubhamjain
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)

------
clarkevans
[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.

------
africajam
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)

------
shoyer
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.

~~~
sillysaurus3
_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."

------
jcoffland
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.

~~~
z3t4
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 your@email.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.

~~~
GordonS
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.

~~~
z3t4
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.

------
augb
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.

------
seibelj
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.

------
cleeus
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).

~~~
cperciva
_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.

------
panic
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.

------
akavel
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.

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

~~~
grzm
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.

------
mikegerwitz
> 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)

~~~
mikegerwitz
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/))

------
Nomentatus
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.

------
protomikron
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?

------
rayalez
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?

~~~
dllthomas
Once it actually gets launched, also consider Snowdrift.

------
kristoffer
"a cross between Patreon and Bugzilla"

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

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

A few thoughts:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Just my $0.02 :-)

------
aidenn0
Right now there are companies who employ people who maintain OSS. This would
be crowd-sourcing the money for that?

~~~
cperciva
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".

------
la_fayette
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.

~~~
voltagex_
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.

------
zellyn
(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

------
Chiguire
1) Nationalise Github.

2) Create a brand new tax for business.

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

~~~
educar
GitHub stars can be easily gamed socially.

------
RandomInteger4
Isn't this what github and friends are for?

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

~~~
JoachimSchipper
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.)

~~~
cperciva
Did you read the blog post? I specifically described this as a cross between
Patreon and Bugzilla.

~~~
JoachimSchipper
A fair response; sorry, I expanded the comment to something more reasonable.

