I'm the lead developer of an open source project used in radiation therapy clinics around the world and I know I would be ecstatic to be able to get enough funding to work on the software full time. I'm trying to bootstrap a consulting business around the software now, but it's tough getting people to open their wallets (and it's much less fun than writing code)!
I think having funding in place for OS projects might have trickle down effects as well. I know I would spend more time contributing patches back to other OS projects I use if I didn't have to worry about trying to build a business so I can put food on my kids table. I imagine there are many other project maintainers who feel the same.
1) Bounties: Some mechanism for people to easily pay $100 for fixing the bug, $1000 for implementing a feature, and so on. If Github takes care of the payment part, I think it can even be used in big companies and would definitely incentivize people. Sites like bountysource.com show that the model already works, it just has to be handled by Github so adoption would definitely be higher.
2) Second one is more ambitious: Although bounties are a nice way for people make money, it still cannot allow people to just focus on their OSS work, since it does not offer a revenue stream. Github should become what Youtube is to video creators. If Github were to share a percent of its revenue with OSS maintainers, that'd make a huge difference in the OSS space and in the world.
This recent tweet from the creator of ESLint captures the essence of the status-quo really well: https://twitter.com/slicknet/status/1086053326007881728
What, a metrics-driven controversy/clickbait factory?
We'd be far better off with what Patreon is to creators, a system that gives people enough predictability of income that they can make a job of it.
On youtube this is done with advertising. I can't imagine people being happy with that embedded in open source software. People got upset enough about Ubuntu and the Firefox/Pocket deal.
> A Github that pays people based on the usage of their code might not be the easiest problem to solve
A github that charges people to use code is even harder; that sounds like instant suicide.
https://wiki.snowdrift.coop/market-research/history/software... for further reference.
> Github should become what Youtube is to video creators
A surveillance advertising system tying your work to misc manipulative ads for things you don't endorse??
Complaining about "I do things for free" while your free product is the gateway to your paying products (in this case gaining followers and popularity to sell them other things or directing them to his ad-containing website) seems totally dishonest to me.
Doesn't mean he's not doing god's work with ESLint <3, it's just that this specific tweet is really not covering the full story. Maybe his books and website earns him pennies a month and it's a shame, maybe he does six figures with them, I won't hasard a guess.
I personally feel like npm and Github are sitting on goldmines, in a financial sense and in a simple solution sense, yet they are their own worst enemy, chasing all value to $0 as fast as possible.
GitHub/npm: just charge me $10-20+/more/month and distribute it out for me. I want to support the community, but I don’t want to deal with it. I code e-very-day. It’s worth it to me to support tools and the community, but don’t leave it up to my own arbitrary choices or timing. Maybe check my package.json or code coverage with said packages to dish out funds auto-magically. Just do something-charge me!
Side note — last week Github announced free private repos, while I was gladly paying. Why not instead just charge for the repos and create a massive fund to help solve the problem? Maybe the catch is: to receive funds you have to primarily host your source code on Github. That may help retain popular libs from leaving to other platforms.
The marginal cost of distribution of software is nearly zero. Therefore the cost of software, not just OSS, gets driven to zero. Hence why so many commercial services have switched to "advertising supported", "SaaS/hosted/online-only", or cloud subscription.
Each individual customer is not willing or can't commit the resources (which can be hours to weeks of development time) to fund us to fix those. If they were to pool the resources it'd be easier.
But that's not how those companies work. They have their purchasing processes and kicking that off for minor things is often too much work, kicking it off for major things may take ages and strain budgets.
All the other models I've seen so far (Patreon etc.) don't really fit into the corporate world as we currently see it.
We've tried asking for sponsorship directly, in conference talks or on Twitter (https://twitter.com/opencore/status/1057939697413079040) but so far have not found any sustainable way that works.
I'm convinced that solving this single issue will do more good for the OSS projects (which in turn might lead to better lives for people as can be seen in the example of your project) than any other action anyone could do.
We're eager to hear any model that worked for someone else.
If you want a model that works, build your own open source projects or paid components around Apache Big Data. It's in your company name anyway .. open core, and it's a model employed by many companies like Sidekiq
To be really blunt: We are basically busy 100% of the time and it would not economically make sense for us to work for free on major issues. If you look at my Apache history (committer on various projects, contributor to more) you'll see that we DO contribute a lot. But it's mostly minor stuff that can be done within a day or so.
For major stuff we just don't have the resources. We could add encryption to Kafka at our own expense and it'd take a couple of weeks of development time but we wouldn't have any immediate benefit from it. Companies like Cloudera or Amazon would benefit though.
This is how I see it at least but this is very much a plea for ideas. Maybe I'm just set in my ways.
> If you want a model that works, build your own open source projects or paid components around Apache Big Data. It's in your company name anyway .. open core, and it's a model employed by many companies like Sidekiq
Yep, that "just" requires us to have a good idea, plus the free cycles (basically investing money) plus we'd now need to learn how sales work etc. and to be honest...we're not good at that. We're really really good at the stuff we do now though. It's hard to change your own ways ;-)
I hope you manage to find some good balance that keeps your work funded!
Nailing the future down to worst case scenarios isn't very constructive from my experience, visualization is a powerful tool and cuts both ways.
It's not sustainable right now. But predicting the future is a fool's game, everything changes all the time and no one really knows anything for sure.
Try to picture where you want to go instead, it's more challenging but at least it has the potential to lead there.
And good luck to us all :)
I would also love nothing more than to work on my open source project (OctoberCMS) full time too, but gotta pay the bills somehow.
Go to any play or recital, and the program will have an entire page devoted to donations -- big companies up at the Platinum level, medium companies and rich folks at the Gold level, on down to random folks at the $0-50 level. Until you get up to the Hollywood movie / arena rock level, art always operates at a loss.
Hospitals and universities also frequently have wealthy patrons. I'm sure there are other fields, too, that I'm forgetting or don't know about.
Solving this problem for the field of software would be very cool, and it's always a great idea to start with one particular domain. The big picture remains: how can people continue to do good and worthwhile work, when the economics aren't on their side?
I know many people doing work they hate, and which isn't in any way worthwhile, just to pay their bills. When I was younger, I worked for 2 years on a "death march project" that never shipped. I was young enough to not realize that I couldn't make a difference. The older and more cynical people knew all along it would never ship. The Invisible Hand can't always deal with the complexities of modern life.
I'm not even convinced that money is part of the answer. I don't care about money, except in that I need it to pay taxes, rent, health care, and so on. Maybe I watched too much Star Trek as a kid, but it feels like a post-scarcity world shouldn't require citizens to worry about cash, unless they want to do something especially extravagant.
I do care about money: not only do I need it to pay rent, healthcare, (not taxes, that's just a portion of your income, so no income = no taxes) etc., but I also need to it buy things I enjoy and to enrich my life: foreign travel, for instance, costs money. If I had to sit around my apartment for the rest of my life because I couldn't afford to travel anywhere, my life would not be worth living.
Seems perfectly reasonable to me, who down voted this and why?
If the software is something you yourself is using because you needed it (or is already capturing the value sufficiently), then opensourcing it is a no brainer.
However, if the software is being written, but not being used by you, then it doesn't really make sense to opensource it. The value being created by the software would then be captured by those who would otherwise have had to pay. This value should instead be captured by you, and that should then pay for the improvements. Eventually, when you decide to stop or when you feel you've made enough money and want to move on - then opensourcing it makes sense.
You mean potentially sick people that might not have access to this diagnosis if the software was not open source? Some times Open Source and co is just to help others! Not everything is profit-motivated :)
Not that either is bad or good, but you're having your cake and eating it too.
I don't mean any disrespect, I'm genuinely trying to get to the bottom of the concerns around funding. There's no lack of funding mechanisms for open source (see oss.fund) and certainly no lack of money flowing into open source (see COSSCI) but arguably the 30M+ developers on GitHub don't see much of that.
The argument I often see floating around is that this isn't a new problem, there's just more of us and more money and from a different source this time around (VC) and yet open source has been "sustained" as a model.
Snowdrift.coop is trying to (lacking resources itself for the same reasons) build an actual solution for as-good-as-we-can while being fully voluntary (unlike taxes).
All the money that goes into back offices on wall st in the old closed financial system, goes to Open Source in the blockchain ecosystem.
I hope that this trend continues and helps make OSS Funding a more mainstream thing as blockchain becomes more mainstream itself.
/me battens down the hatches inb4 blockchain-haters brigade me :)
Some ideas that I frequently wish existed:
1. It would be neat if there was some sort of place in Github where people could upvote interesting project ideas, i.e. "Load testing tool in Go"
2. I'd also love to have a way to say, "I can devote 1-5 hours a week to this project" and be notified when someone tags an issue as 'help wanted'
3. Harder, but still do-able (I think). A place for open sourcers to organize a "team" to get a new project off the ground. I often think that there _must_ be other people interested in the same sort of projects I am -- but we have no way to "discover" each other unless you're some high profile Twitter user.
4. Moderation for trolls. Some people frequently open issues that frustrate maintainers. While they can just create a new account, I think creating a small barrier to entry would do some good.
5. A way for companies / individuals / etc. to donate to maintainers through Github. I think this would be a huge incentive for people to continue their work long-term and not just "hand over" repositories to people with ulterior motives.
Most of the solutions proposed in this thread for one-off bounties here have already been implemented for years, which is why I am convinced that (with the current level of funding), bounties don't work.
Sometimes, I’d have my company pay $50 to merge a pull request :-)
When I find an issue on GitHub requesting a new feature or reporting a bug that is important to me I should be able to throw down $5+ bucks to incentivize someone to fix it. I also know that I would personally contribute to OSS more if it didn't feel like I was doing community service but rather actually getting paid for my time.
If you want that, you probably should look at UpWork instead of GitHub. Bounties are a nice way of prioritizing things, but most OSS projects won't get the kind of OSS contributions they want for the kind of money they need, simply because the kind of contributors they want can get 10x better pay on the job market, so why they should bother with OS when they can freelance?
Discounting the recent trends of companies open-sourcing stuff to build a market for themselves elsewhere, open source was always, first and foremost, doing a community service. This aspect is why OSS developers put time into it instead of getting extra paid work.
It would still be nice for those who are interested in working on those issues regardless of payment.
A person who wants to pay for a bounty would need to submit an issue, and the maintainer estimate it's complexity. At that point, the person filing the issue could click "Buy this issue" if the maintainer has bandwidth.
Again, not easy -- and I'm sure the UX / business / execution would be delicate.
Every oss project trying to make money by dual licensing currently sets up their own payment system, and winds up writing their own commercial license because the well known ones like MIT, Apache or BSD don’t work (if a business buys one of those licenses they can just make a competitor to your project). Because each project writes their own license, businesses need to waste time reviewing each license carefully. It’ll be so much easier if there’s a Github Commercial License that’s Apache 2.0 plus a non compete and no resale clause.
What Github would bring to the table are easy marketplace dynamics, trust, and a team of lawyers capable of writing good licenses. Also, the same code analysis tools that check for security problems in your dependencies could also license checking. There's a very compelling use case for businesses if all their code hosted on Github can 1) automatically check for license violations and 2) just pay for all licenses on a single screen with a single click.
1. Required fields on new issues. Has been requested since 2016.
2. Better issue search.
Open Source projects face a lot of issues. It's good to talk about them, but some GitHub can solve some GitHub can't. I'd be much happier to see these problem addressed instead of learning about updating my profile status.
Currently when a project becomes popular the issues easily drown the author. As the communication portal between OSS authors and users, GitHub can and should give OSS authors more power.
I really like this idea if for no other reason that it would raise the bar for submitting an issue. So many open source maintainers on Github are overwhelmed with vague issues or support requests masquerading as issues.
That is unlikely to improve matters IMO. If people are forced to populate a box they were otherwise going to ignore they'll populate it with repeated detail from elsewhere, a single character if no minimums are imposed, or keyboard mashing gibberish, not the sort of detail you are asking for.
Many people are just incapable of, or unwilling to spend the time to, produce useful bug reports and feature requests. They expect you to be clairvoyant, or be willing to go back and forth re-asking the same questions until you have the information you need.
In DayJob we have commercial clients who are supposed to perform their own first-line support and triage issues before sending them to us (their procurement people expect a per-user price reduction because they claim to do this), yet we still always have a collection of issues on-hold awaiting information because the report essentially said nothing more detailed than "a user says that they did something and there was an error message" with the required detail fields containing something along the lines of "see title". Bad reports end up costing them in various ways and they still can't be bothered to raise them correctly. (Heck, sometimes internal work items & bug reports raised by other devs/BAs/management can be just as bad but at least I'm allowed to be sarcastic in response to those!) I wouldn't expect the general public filing a reports/requests in a project on GitHub to average any better.
(I'm the open source PM at GitHub, for context... and yes I realize that's not directly verifiable from my sn here so feel free to tweet at me if you want to check: http://twitter.com/devonzuegel)
Without this, I can't pay someone to make some minor changes. I'm left hunting for their details, and when I do connect with them over GitHub or LinkedIn, I'm at their mercy to respond, and most of the time I can't give any valued weight to my request since I'm not paying them to do the work.
When I do hear back, devs aren't always the most gracious folks, and they don't have the same priorities I do. Money can help make people more cheerful, and helps me align their priorities to my own. I've lost count of times I've gotten a snarky, "I didn't build this to do what you're asking."
There are so many great libraries out there that went stagnant. I make money off their work, but I can't pay them to make upgrades and they find the work to be boring or my request to be out of their target audience (if they even think that way).
I think if GitHub could build in some features around donations that would be great.
"Fix this, and I'll pay you $50."
Only trick... how to verify the fix.
A lot of times someone would just mark the issues as done, but it'd need to be verified as being completed as expected. And that creates a situation where the person looking to make $50 does the work and (rightfully) says, "Pay me," but the person who has to pay the $50 says, "Uh... hold on, I have to do a new build, and that'll be 3-4 weeks minimum to get it prioritised and tested and through UAT and into production before I can get procurement to release funds for this," or, "Doesn't work on my build..."
Not impossible... just complicated in practice. Thinking it through, I can see why GitHub hasn't done anything like this yet. I think I'd prefer bounties, and donations -- I can easily get a donation approved as basically a "license fee" but bounties would be very hard to get through the accountants I think. At least in agency-land where I work.
When an issue comes in, once verified, a test that reproduces the unwanted/unexpected behavior is attached to the issue. This lets both the reporter and dev prove the issue exists, and lets the dev trigger the behavior on-demand to aid in his troubleshooting efforts. Then, once the issue is fixed, the test proves it. Afterward, that test should go into the regression test suite that gets run before each release to make sure it doesn't come back.
When the fix is released, it ideally would be released only in a bugfix release, bumping only the patch version number a al SemVer, and not wrapped up in a feature release. It should be a lot easier to get a patch release prioritized through testing, staging, UAT, and finally into production when the version number tells you that the bugfix was the only thing that has changed, and the test suite can prove that.
Coming back from fantasy land to reality there's other things that would have to happen to make this feasible, but it's well past bed o'clock for me. I'll try to remember to post an additional reply later this morning.
From a finance perspective... I don't want to argue that this is sane, but a lot of firms view software still as a Capital Expenditure (CapEx), not Operational Expenditure (OpEx).
CapEx is like buying a car, or buying a laptop. OpEx is like a taxi service, or monthly power bill.
With CapEx, I generally can't get approval for payment until the product is fully delivered, and signed off.
A lot of companies use agencies to do software work for them, and see an agency as a sort of credit card / insurance policy for getting the work done before they have to pay, and getting work done on a fixed-price scheme.
A lot of times too, work has to come with like a 90-day warranty, and final payment won't be due until that period is up. For larger clients anyway.
Yes, I like bounties... and we use a lot of open-source software, but I don't think anyone would want to get paid the same ways as agencies get paid. Likely we'd be better off just being able to donate.
I think that, other than high profile OSS projects that receive donations from multiple companies and have salaried maintainers from said companies, only monthly donations work. But this way only one or two key people can live off them. And those donations can only be in general sense "do what you're doing" or "please focus on this side a bit more".
And my own personal take on this whole Game of Throne'ing that's currently happening out there with open source:
FWIW, I just started a petition to help secure the tax status of open-source orgs in Germany. Not sure if I have much motivation to promote it though:
All the examples I know are from what seems to be much bigger projects, with all of them failing to be recognized as tax-exempt.
Bounties are not a good incentive to maintaining high quality open source - in fact it's the opposite. It encourages putting in rarely used functionality that is not in line with the goal of the software. In the cases where adding a feature is warranted, a small bounty rarely comes close to the development time required to implement it.
Even the act of properly vetting pull requests is an extremely time consuming process. Will this contribution affect the stability and performance of the code base? Does it follow the conventions of the project and include comprehensive test cases and documentation?
Micropayment donations are nice in theory but don't work in practice. The handful of projects that are able to self-fund do so only because large corporations support them, not individual users. And even those popular projects do not pay for the development of the the many project dependencies they rely on - without which their software would not be possible.
So I don't have any solutions to free software sustainability. The users of the software derive great benefit, but the producers - not so much. By in large, open source will always rely on the charity of its creators.
Some projects use Patreon. Why not just make it direct for those projects that are using github to host?
I think the harder problems are things like "who gets the money", "how is it used", etc... How to deal with scam clones. (once money is involved the scammers will show up)
As soon as you introduce money, some people will get alienated, work 'value' will be ranked, just -- all kinds of new headaches on top of what maintaining a large project for free (which is already often a big headache)
Giving money away feels great (not sure why) and you can pretty much count on a thank you note.
I am now trying out cloud providers that use and contribute to open source software and standards. ie, mailbox.org
Companies can commit a small amount till the funding point is hit
And then code is released for a limited time only to sponsors - the code base is released to everyone else only after a known time period.
We get scarcity, openness and funding???
My first question would be: Who are the users of your project and how did you find them?
It's a weird situation as we're a desktop app. Many Open Source users aren't used to paying for things but if you want good tools there needs to be a economic background.
I've started polling my users to ask WHY they aren't donating and I'm getting some interesting initial feedback.
So far "I didn't know how to donate" is apparently a big issue I have to resolve.
Additionally a top issue is that the user base doesn't feel the core feature set is there.
Now part of this might be bias. They might not want to support simply because they don't have money.
In the next month I'm going to be turning on monetization so this should be an interesting process.
Have you considered scoping out a browser extension that would let you send polar a webpage with a single button click? I'm not sure what complications there would be getting firefox and polar to talk to each other, but maybe in conjunction with the sync feature it would be easier?
Might give you a feature to charge for too since you it does afterall cost money to run servers
edit - elaborated
The fundamental problem with "smart contracts" is that they are neither "smart", nor are they "contracts". Contracts deal with ambiguous meatspace issues, and are resolved through courts. Smart contracts are in no form a novel idea, they are just trading/finance bots with some added blockchain to get the suckers to give up their money. They cannot make any decisions on things that can't be verified on the network itself, which includes things like "who does this apple belong to?", "does this code solve the issue?" etc.
When the project started, Gorgonia had dynamic and static graphs. Then TF caught up and now has surpassed Gorgonia in terms of features.
I wonder what Github would be doing to help maintain projects. Right now it's just pretty five people maintaining Gorgonia. Sustainability for me would simply be more contributions to maintain feature parity with TF
It helps to have written down a clear vision for the project, so everyone can quickly see what kind of feature request even makes sense.
From time to time, users do make actually good requests, and I think every good developer should recognize good ideas.
I always insta-close support requests because they have no place on a bugtracker. But I very rarely get such requests in a bugtracker in the first place.
TL;DR: please give us a Google Wave analogue built into Github
As any b2b startup will tell you, the number one concern of a large client is "how do I know you'll still be here in a year?" They say nobody gets fired for buying IBM, but what they really mean is nobody gets surprised by IBM; nobody outgrows IBM and has to find a bigger vendor; nobody includes IBM insolvency in their contingency planning. IBM is predictable in the exact way an independent open source developer isn't.
The mismatch is that an ideal vendor delivers a predictable result across a wide price range, and a small open source project just can't do that. Think AWS: you can spend $1 or $100,000 and you know exactly what you're going to get. It's not so hard to get $100,000 of value from an open source project: just hire the maintainer. But how do you get $1,000 worth? Or even $10,000? You can definitely get a result for that much money, but you can't get certainty. Unless you're paying that maintainer enough to live off, they're always just one really good coffee chat away from the loving arms of FAANG.
I think the missing piece is a trustworthy intermediary to handle professional services contracts for open source projects. Rather than dealing with the overhead and uncertainty of a bunch of individual contributors directly, you just pay for one central service that covers your entire open source surface area. This organisation then contracts out to a network of interested open source contributors for maintenance and feature development.
In many cases, this would mean the maintainer of the project, but it could also be someone on the team, a new maintainer if the project is abandoned, or even someone to keep a fork up to date if you need changes that upstream doesn't want. The point is you don't have to manage this in great detail: you just pay the money like you would with any other service. In this case, the service is "all my open source software works, continues to work, and will grow with my business"
In order to be trustworthy, I don't think this could be a for-profit company. Many developers are skeptical of commercial interests in open source, and the larger independent projects often specifically limit the influence of any one company. For developers or companies to trust an intermediary, it would have to be provably acting in their interests. In other words: an independent non-profit with an open and transparent governance model.
Further, I think it would need to be run by respected figures from various open source communities. Open source is fundamentally weird to people who don't deal with it regularly, and there are plenty of opportunities for boneheaded mistakes that destroy trust. Why contribute and engage with the community rather than fork everything? Why invest in existing contributors instead of paying the cheapest contract devs you can find? Why not use your leverage against contributors that don't agree with your decisions?
The answer to all of those, as well as many similar scenarios it would be easy to imagine, is the same: it's bad for open source, which is bad for businesses that rely on open source. Businesses won't always know that or act accordingly, but an organisation working on behalf of the community will. And, of course, all of this only works if the projects and contributors in question trust it to do so.
There is a fair bit of successful precedent for community-driven foundations (eg Linux Foundation), the professional services model (eg Red Hat), and project-agnostic funding (eg Google Summer of Code). But, as far as I know, no initiative that combines all three. That's not incredibly strong evidence that it'll work, but at least suggests it might, and it's not like we're exactly drowning in workable ideas for open-source funding.
But this applies to early-stage startups just as well as to open-source projects?
For example, equating well polished equates to manipulative marketing and folksy poorly written to authentic. Of course both forms are being used heavily for manipulation today.
It is a really dreadful situation. I thought the post was genuine, with the obvious motivation of the author to be successful in their new role.
I could be reading too much into it, but it reads to me as corporate-ese. Not because it’s polished and well-written, but because the subject matter seems on topic for GitHub but isn’t something a GitHubber seems they would have blogged about, historically. I may be off the mark but that was my first impression.
FOSS , except for a few technology, will never be sustainable .
- Because entreprises prefer to pay Billions to proprietary products and have someone that can be held accountable for failure.
- Because entreprises executives consider that Open Source = You don’t have to pay anything.
- Because Oracle , IBM , Microsoft have spent the last decades telling entreprises executives that FOSS « does not scale » and is « very insecure » while they are actually just copying stuff from open source and rebranding it as their own.
FOSS will never ever be sustainable because the industry has been shaped around proprietary ecosystems by companies who are now worth hundreds of Billions of dollars.
Outside of few startups very few companies make donations to FOSS projects to keep them running.
Maybe it’s juste me but I’m fairly confident that a blog post and a Google Form won’t fix anything in the industry.
On the other hand , Microsoft , IBM advocating their customers to fund open sources instead of buying proprietary products while they are selling consulting services would fix the entire problem.
Will this ever happen ? It won’t. Licencing bring billions in revenue to these companies it would be absolute suicide.
I wonder about software that has a secondary or supporting role in the ecosystem. Working on them does not provide the level of career opportunities that seem to be available from working on core distributed computing or machine learning platforms. Apparently the default is that they will be abandoned in place.