Hacker News new | more | comments | ask | show | jobs | submit login
Let’s talk about open-source sustainability (github.blog)
280 points by steveklabnik 36 days ago | hide | past | web | favorite | 145 comments



My personal feeling is that funding has got to be the biggest issue with open source sustainability.

I'm the lead developer of an open source project[1] 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[2] 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] http://qatrackplus.com [2] https://www.multileaf.ca


I also think the biggest issue in OSS is incentives and see two ways of handling this issue:

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


> Github should become what Youtube is to video creators

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.


You are right about what Youtube is, but what I meant by Youtube instead of Patreon is this: With Patreon, you have to work for building an audience, but Youtube pays you based on your views. A Github that pays people based on the usage of their code might not be the easiest problem to solve, but what I'm suggesting in the end is the same thing with you. Only time might show what such incentives may turn the platform into, but considering the general audience of the site, I doubt it'd turn out like Youtube.


Getting the money from the intermediary to the developer is only half the problem. First you have to get the money into the intermediary.

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.


I was happily paying 7 USD/month up until last week for the private repos, and they apparently had 300M USD/year revenue when Microsoft bought them a few months ago. I am not aware of their costs, but since they are part of Microsoft now and trying to foster adoption, integrating money into the system should be considerable.


As for bounties, I think it messes up with the OSS governance model. Let's say there's a bounty for feature X. You implement the feature, want to merge it in, but the maintainers don't like it and don't want to merge it. Now what?


Yeah. Science has a (some would argue) slightly more sophisticated approach to bounties in the form of grants. The inconvenient part is that many things ending in "Foundation" in open source have no resemblance to things like the NSF.


Bounties are full of problems. Adding them to GitHub introduces huge issues in the same way as a recent discussion brought out how AirBnB can be one thing early on but starts running into tons of problems at scale.

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


> Bounties + Allow pledging for issues with money. Here, have 5€ from me, and €3 from this and that for fixing that bug or implementing that feature.


I don't think it's fair to say the creator of ESLint is not making a buck out of his code. His twitter page for example is full of commercial links to his own products.

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.


Yet, I use eslint every day, I have money, I’m willing to pay, but I’m not familiar with the owner or his products, (nor inclined to seek them out), nor will I go find their Patreon page (although I do support several YouTuber Patreon pages).

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.


Exactly my thoughts. Considering Github's recent numbers (300M USD/year revenue) and its recent acquisition by Microsoft, something like 30M USD/year would be enough to fund 250-1000 people a year full time. Maybe there might be an upper limit on how much you can make through the platform (like 10k USD/month), so instead of ending up with a few millionaires, a 10% revenue share would be enough to fund 250-1000 people full time, much more people half-time. With such a system in place, I think everyone would be better off, including Github - Microsoft.


> chasing all value to $0 as fast as possible.

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.


I also agree with this. While I don't (yet, but about to) have my own project to take care of we mostly consult on the Apache Big Data ecosystem. These tools are used by thousands of companies in major internal programs (e.g. "we're moving the whole companie to an Event Driven architecture based on Kafka" or "we're building a Data Lake in Hadoop") but there are major and minor issues which we see at every single customer and which go unfixed.

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.


Thought experiment: If you see problems with many customers, why don't you fund yourself or someone else to do the work? It would obviously save you time and energy dealing with each of the companies, and you could use that as a way to officially associate your company with the project. This is a similar calculation that happens with every one of your customers and every other company.

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


> Thought experiment: If you see problems with many customers, why don't you fund yourself or someone else to do the work? It would obviously save you time and energy dealing with each of the companies, and you could use that as a way to officially associate your company with the project. This is a similar calculation that happens with every one of your customers and every other company.

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


This. Right now I'm basically on a year sabbatical where I'm doing almost entirely open source software without worrying about funding, but I also know that's not sustainable

I hope you manage to find some good balance that keeps your work funded!


Metoo, don't have that many options lately for health reasons. So I figured I might as well use the opportunity to have a go at the status quo.

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 agree with this 100%. When you sit down and think about it, there are a lot of major projects used all over the world with just a few developers working on it, volunteering their time.

I would also love nothing more than to work on my open source project (OctoberCMS) full time too, but gotta pay the bills somehow.


The fact that you have such a widely used project and are still unable to make a living doing it is disheartening.


It's not unique to software.

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 don't care about money, except in that I need it to pay taxes, rent, health care, and so on.

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.


Instead of being dishearted, propose a solution to enable the ability to make a living. First thing that popped into my head was some sort of support model. CentOS vs RHEL. Give the farm away for free but consult how to run the farm...


Your farm has to be complex enough to need help using it. You either have to make an absolutely massive farm or intentionally make it hard to use/maintain.


You would think that at least one big company finds it in their interest to make sure the product is bug-free, at least enough to compensate core FOSS devs for their time.


It's a problem similar to the tragedy of the commons - why should I pay for something when company X, my competitor to boot, would not only benefit but clearly has more money/uses the software more/whatever other reason I feel justifies washing my hands of it.


The history of Openssl bugs before Heartbleed is at least one counter example.


Yes this is one of the two obvious potential solutions for that particular project (the other being a hosting service) but transitioning from open source project to open source company can be challenging!


@irishcoffee: “Instead of being dishearted, propose a solution to enable the ability to make a living. First thing that popped into my head was some sort of support model. CentOS vs RHEL. Give the farm away for free but consult how to run the farm...”

Seems perfectly reasonable to me, who down voted this and why?


Because it's so trite and obvious.. Oh really, support, geez why didn't I think of that? This discussion has been going on for 20+ years and the conclusion is simple: OS is not a viable business model in the vast majority of cases, and certainly not for those who only want to sit in their basements coding. Want to make money from software? Charge for it.


I think the vast majority of people who want to make money building software don't start off by finishing a product and then trying to sell it. A much more common scenario is building software for someone from the start (or building a service, but let's focus on "pure software" for now). In that case the developers are paid for time spent, not copies licenced, so using a FLOSS licence isn't a roadblock for making money.


If you're building software for someone & being paid your time for it, you typically don't get to license it & release it as open source.


> open source project used in radiation therapy clinics

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.


> The value being created by the software would then be captured by those who would otherwise have had to pay

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 on the diagnostic side in this case but yes, open sourcing was both to help other cancer centres manage their QC data better and operate more efficiently as well as an attempt to attract others to contribute to the project.


The original poster was commenting on trying to obtain revenue from the open source product of their creation. You are right that sometimes things are just to help others, but its meaningless here unless we are strictly talking about the initial creation and not the continued support of it as the poster is now trying to monetize it.

Not that either is bad or good, but you're having your cake and eating it too.


I mostly agree with you. However, I wrote it (and we released it) while I was working full time at a large Canadian cancer centre (and we really needed it!). I have stayed involved with it as a "hobby" for the last few years with the goal of being able to eventually generate enough income from the project to support myself full time.


I was recently told about Tidelift [0] who represents that it wants to improve funding for OSS. I was surprised that I hadn’t heard about it before on HN in similar discussions.

[0] https://tidelift.com


I think you probably won't hear much about it since, as far as I can tell, the general sentiment in previous discussions[0][1] about Tidelift here was quite critical, mostly due to their lack of transparency.

[0]: https://news.ycombinator.com/item?id=17957744

[1]: https://news.ycombinator.com/item?id=18063250


The sustainability of your project, or the sustainability of open source?

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.


Funding is the obvious biggest issue with open source sustainability. But it's arguably not the lowest hanging fruit. Because it seems to be a hard problem. Perhaps even a wicked problem.


Yes, exactly. It's the public-goods funding dilemma. The one that has only ever been really solved by mandatory taxation (with all its problems).

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


A few friends of mine have been trying an alternative approach for funding FOSS software. I encourage HNers to check them out and give them a try: https://polyglot.network


Have you considered adding pro features on top of the free core that clinics could pay for? Similar to the redis model


I know theres a lot of blockchain-skeptics on HN (and rightfully so), but I'd like to just point out that...

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


Neat that that Github is looking into making open-source sustainable. I think a lot of maintainers hit a wall at some point. You have to have pretty thick skin to weather the entitlement people have to the thing(s) you put your life's free time into.

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.


5a) a way for me to add a bounty to an issue, I’ve had team members fix bugs and do pull requests that I’d have happily paid $50 $100 or more to the maintainer instead


From everything I've seen (and I've also put up a few bounties myself), bounties generally don't work. Most bounties are put up only for longstanding issues, and those issues are longstanding because they are not trivial to fix. A $100 bounty then isn't much of an incentive, if e.g. $3000 worth of working hours have to be spent on fixing the issue.


Maybe there should be (if there isn't already) a way for multiple people to add to the same bounty. So if 100 people are all annoyed by some longstanding issue and each offer $100 bounties, that's $10k for someone to fix it.


With Bountysource (the platform I used), there is. IIRC, they will also post a comment on the issue, listing the current bounty, and optionally also automatically apply appropriate labels to issues, so it's obvious to anyone on the Github issue.

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.


Yeah, unfortunately it seems like one of those things that's a great idea in theory, but doesn't work well in practice.


Yeah, mixed bag for me as well, but if the mechanic was easier I think small bugs or improvements would easier to bounty.

Sometimes, I’d have my company pay $50 to merge a pull request :-)


This. I've always wondered why sites like GitHub/GitLab won't allow issues to have a bounty. It seems to me like its the obvious solution to crowdfunding OSS.

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.


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


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

It would still be nice for those who are interested in working on those issues regardless of payment.


Probably less of an issue now they're part of Microsoft, but if you're focused on source control / open source, you probably don't want to take on crowdfunding with all the associated drama and complexity, too. That's a business in itself.


True, but with the right hooks in place other providers could fill that niche.


If general consumers of OSS act entitled, then how entitled are bounty contributors who think their issues haven’t been properly fixed to their satisfaction going to be?


It's not an easy problem to solve. I could see there being a queue of bounty slots available for purchase that maintainers set and could be increased or decreased at anytime.

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.


I'd love this as well - especially for small chunks of projects where it's not worth trying to track down a consultant for.


#2 is more or less why I built https://www.codeshelter.co/. I tried to post it here (and I see that others did too) but it didn't take off. It's going well, though, as a project.


#1 - Somewhere to post your projects to interested audiences would be awesome. It's difficult to get some eyes on your project unless you already have a large social media following.


My suggestion was to add a page allowing maintainers to sell licenses. I think dual licensing can work really well if 1) there’s a very easy and trusted way to buy licenses -with strong predefined terms set by a trusted third Party like Github, and 2) if there are well written and understood commercial licenses available for use that businesses can trust on sight.

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.


This is the best suggestion I've seen and yet the one which Microsoft cannot do for tear of people running after then with pitchforks.


Github could do it. Doesn't look they're rebranding into Microsoft Code Office Space (TM) any time soon. And one would assume they'd put the licenses on Github as well, so you could suggest changes and sell your project on whichever version of the license you want.

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.


Well, here are two things that have been brought up many times:

1. Required fields on new issues. Has been requested since 2016[0].

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[1].

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.

[0]: https://github.com/dear-github/dear-github

[1]: https://github.blog/changelog/2019-01-09-set-your-status/


Regarding 1: Please no. Prefilling the entry box is a decent compromise and doesn't require turning the Github issue screen into a Jira issue screen.


If someone is filing an issue to an open source project -- whose maintainer will very often be working on said issue for free -- the least that person can do is submit the issue with the information that the maintainer requests.

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.


Issue templates already exist. As I've seen recently the possibility for multiple issue templates (that also auto-apply some labels) even exists now. If an issue doesn't fall into any of those templates, they are still free to close the issue and ask for it to be resubmitted with the correct information.


There are some projects that are fine with having support requests on the Issue tracker, and some that have another system for that. At the very least, it may highlight missing documentation.


> 1. Required fields on new 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.


If you're worried about the domain github.blog, be aware it's what blog.github.com redirects to. I really hate what's happened with TLDs, but at least this one is verifiable.


At FastMail, when we moved from our old in-house blog engine to Ghost(Pro), we moved from blog.fastmail.com to fastmail.blog, because the blog engine was being run by a third party, and if it was at blog.fastmail.com then we’d be giving our *.fastmail.com authentication cookies to said third party. So it was always going to have to be a different domain; then it’s just a matter of fastmail.blog being nicer than fastmailblog.com.


Hi! Thanks for clarifying this for everyone. Yes, we just migrated the blog, so both `github.blog` and `blog.github.com` work.

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


Hey, that reminds me about Keybase. It's not talked about that much anymore, as far as I can see, but it's nice how it lets you verify your identity across different sites.


Hey Devon, not to worry. I follow you on Twitter! Congrats on the new gig. :)


This seems to be recently new. Early this morning the Github blog hadn't been updated yet.


I think the biggest issue with open-source projects is that we can't incentivize the creators to do the work. What I'm looking for is an easy way to "donate now" on the library.

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.


It would be ideal to integrate the donation system with the existing issues system. That way individual issues could carry a bounty added by people wanting that issue fixed.


I love this idea.

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


I think for this to be feasible, a project would need to maintain firm to strict discipline about testing and versioning. Let me expand on that.

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 technical perspective, this isn't wrong.

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.


Yeah, I hadn't considered that. Ultimately as with any online peer-to-peer marketplace, there would need to be some process for handling disputes.


Exactly.

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


Integrating bug bounties and donations into GitHub could be one of the best things to happen to Open Source. Funding new features and bug fixes could become seamless, and it would sway more devs to adopt this model for their projects.


Oh nice, it looks like an actual "let's talk", rather than a "I have something to say" like I've apparently started to expect that phrase to mean.


I read it as pls give us some ideas how to cater to developers MS hearts OSS


Have talked to Dave about sustainability. Strongly recommend.


Autocorrect fail. s/Dave/Devon/


Also probably worth mentioning:

https://sfosc.org/

https://medium.com/sustainable-free-and-open-source-communit...

And my own personal take on this whole Game of Throne'ing that's currently happening out there with open source:

https://medium.com/@echohack/we-need-more-sustainable-free-a...


Some U.S. states have "social purpose corporation", which might work for open source: https://en.wikipedia.org/wiki/Social_purpose_corporation


Something similar exists in Germany. Sadly in the past courts have ruled that even corporations that have been solely dedicated to providing a structure for open source projects are not eligible for tax exemption because "they serve special interest groups rather than the common good".


You probably mean gGmbHs which, unlike SPCs, are strictly non-profit. A gGmbH is more similar to a 501(c) (tax-exempt) corporation in the US. That said, it's really tragic that many open-source organizations aren't tax-exempt in Germany.


Seems to be not a hard rule though, since e.g. the Center for the Cultivation of Technology (https://techcultivation.org/) managed to achieve gGmbH status.


The Document Foundation (LibreOffice) is also recognized as German charity. German open-source orgs typically claim to support science and education which is charitable under German tax law (I think this is similar to the situation in the US). There's also a catch-all clause in the tax code, but in the end you're at the mercy of tax authorities, and judges if you can afford a law suit (see J&Beyond eV, for example).

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:

https://www.openpetition.de/petition/online/anerkennung-der-...


I can't seem to find much info about the CCT. Have the actually picked up stewardship for any projects, and managed to file taxes without the tax authorities challenging their status? As long as there is nothing to tax, gGmbh status is quite attainable.

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.


No, haven't seen much of them, just remembered reading about them somewhere, and looking at the issue tracker they link seems activity stopped a while back - if status is easier if not active, then that's a problem, I would have thought the initial step is hard already. :/


Maybe if github itself was open source people could make a lot of improvements to it to help other open source contributors. I don’t understand why we expect people writing a closed source system to fully grok open source.


My thoughts, exactly! It's so ironic, isn't it? I keep saying this to fellow developers all the time, it seems I am talking against a brick wall.


It's not always about money. You put out free software because you're proud of it and hope it can help others. But I've given up on sharing and maintaining open source because of the users' toxic self-entitlement. It's not worth the aggravation.

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.


Thank you Devon for this post and for your ongoing efforts to help make the open source economy thrive. I’m very eager to see the follow up based on visitor feedback. This is Eric Berry btw


I should also mention here that I am the founder of https://codefund.app. We generate recurring, consistent revenue for open source projects and developers through ethical advertising.


You were downvoted, maybe because some people consider all advertising as evil per definition, but ethical advertising is an interesting subject. I made mention of Codefund in a forum discussion we have on the topic:

https://community.humanetech.com/t/humane-advertising-ethica...


Funny meeting you here ;) So much to do!


I have a feeling this would be a bad idea for some reason I can't quite put my finger on but ... what if github added a sponsor/donate/pledge button and ran a service for doing such?

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)


"who gets the money" was a hard enough question to push me away from trying the patreon / tip jar approach. There are a ton of documentation / translation / one-liner style contributors on my project. Do they all get an ongoing cut of the funds? Or is it a one time thing? How is that number determined?

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)


I now list all of the open source (applications, libraries, etc) I use at the end of the year and I decide on a bucket of funds and split the donations between the top 5 most important projects to me this year (application, library, etc).

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


Thought: OSS Kickstarter - a developer puts up a page for say "improve config handling for apache spark" or "fix the radiation therapy UI".

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


All those problems could be solved with money.


"Sparse analytics" is not a problem; it's a feature.


I love Github dearly but this proposal to "talk" is hard to understand. The questions we should be asking go to the economics of open source projects. Problems like overload or lack of resources look like symptoms not root causes.

My first question would be: Who are the users of your project and how did you find them?


I'm working hard now on trying to make my project sustainable:

https://getpolarized.io/

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.


I tried polar at one point and found that adding web pages was a bit clunky in terms of UX. I'm looking forward to trying it again in the future however since I love the premise.

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


You don't have a visible donation button on the front page.


FYI I downloaded and installed your app when I saw it here on HN, didn’t work or I didn’t know how to use it.


Crypto has crashed a bit but there could be some opportunity for an ethereum style contract to help here. Opensource projects are like the ideal 'DAC'(decentralized autonomous corporations) so they could have funding pools that pay out for feature or bug additions. Basically if enough of the DAC vote a feature or bug is important and you contribute code that addresses said issue, you get paid. Similarly OSS licenses could shift to a scheme where if your MRR > $X you are obligated to kick either ether or equivalent code value into pool. Self sustaining, self governing. Corporations might even open source more projects to basically outsource work where hiring dedicated software engineering doesn't make sense.


How exactly is a "smart" "contract" going to decide if some code fixes some bug? And how is it going to measure someones MRR?

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.


Smart contracts are smart enough to allow formation of groups of devs, form a vote and disperse funds. Devs who are directly responsible for maintaining a portion of code can vote if the contributed code solves the issue.


If a trusted group of developers is in charge of dispersing funds, why involve a blockchain/smart contracts at all? You can just donate to the developers, and they can disperse funds according to some predefined terms. The DAO or whatever is exactly that, but with extra steps. In either case, you still have to trust that the people in charge of distributing the funds will do so according to the terms that were agreed upon(fixing bugs or adding features or whatever).


They'd still be trusted in the sense that they decide if a bug was fixed or not, but at least transparency would be achieved. You could independently check exactly where your money went.


I've been working on my own open source projects (the Gorgonia family of deep learning packages for Go[0]). Competing with TensorFlow and PyTorch is hard and I'm quite sure, unsustainable.

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

[0]: https://github.com/gorgonia


Definitely a problem. Initially I really enjoyed sharing open source projects. But after a while you get a little bit fed up with the support requests and random why you no haz feature x threads on Github.


We need new open source cultural leaders that set the tone for open source engagements. I see the poor attitude here on HN all the time. Someone posts about their open source project and they often get burned down for not doing x,y,z. It's open source. We should all be grateful for the work people are putting in so that we may benefit. I don't know why so many people regress to neolithic end-users when an OSS project they are using doesn't do something they like or has bugs. It's like just because they have access to it and use it, they are entitled to world class support, as one would expect as a paying user. It's a toxic situation. We need a cultural change that curbs this behavior.


I usually just close feature requests I disagree with. I also reject feature requests that are written so broadly and vague that it could mean anything.

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.


I'm in the process of moving from macOS to Ubuntu for everything that is not my phone, and I was looking to replace Google Keep and Inbox as they are EOL this year. Found this note tool called Standard Notes (https://standardnotes.org/). Linux and iOS support, extensions, 2FA and encryption, and FOSS. Tried it out. Plunked down $150 USD for a five-year membership without further hesitation.


I find the communication tools to be lacking most, for the goal of solving the problems collaboratively. Github issues are absolutely unusable for discussions whenever there is more than 10 comments. External sites like discourse help a bit, but still far from ideal.

TL;DR: please give us a Google Wave analogue built into Github


Github summer of code for projects except there is a voting from community taken into account for final decision.


What is very ironic about this poll is that GitHub itself isn't open source at all.

For instance, to even use this site, you have to allow JavaScript in your browser. Otherwise, some features are completely broken (because fuck security-minded people, right?).

The JavaScript that GitHub ships is obfuscated and proprietary, so the moment you visit GitHub with default browser settings, you have already executed proprietary software. Heck, even the poll about open source does not work without proprietary JavaScript, which is especially ironic.


I think the biggest problem is the fundamental impedance mismatch between companies and independent open source projects, especially smaller ones.

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.


> how do I know you'll still be here in a year?

But this applies to early-stage startups just as well as to open-source projects?


The quickest and easiest thing to add first is bounties.


Quick and easy ≠ good


A Microsoft product using google forms. Lol. I mean I know they want to keep their image of "startup" but using inferior tools isn't necessary for that.


Kudos to this initiative.


Reads like begging the question for all the stuff they're saying will come at https://spectrum.chat/features


These hyper-polished, exactly on-tone, on-message blog posts from what is basically Microsoft PR are causing credibility loss for the GitHub brand in my eyes. I don’t really believe we’ll see non-corporatese from them ever again, now.


...what? Devon Zuegel doesn't come from Microsoft and she's not working in PR.


They do now.


What's wrong with well polished, on-tone, on-message writing?


I have started to notice a strong anti-professional writing attitude in the last year or so from my US colleagues, so I expect this trend will grow. I think that in general, manipulators have become so good at their trade that people have developed false intuition on how to identify it.

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.


It’s not “anti-professional-writing”, at least not in my case. It just seems like the message and focus itself has changed. It doesn’t seem like it would have been “on brand” two or three years ago. It seems to me to portend the vanilla-ification of GitHub.

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.


Honestly the person who wrote this post is absolutely out of touch with reality.

FOSS , except for a few technology, will never be sustainable .

Why ?

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


When you say sustainable, do you mean, is it possible to train another generation of engineers to take over the maintenance and development of the software?

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.


You realize IBM was one of the bigger champions of the 2000-2010 for open source and Microsoft for this decade?




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: