Ask HN: Dear open source devs how do you sustain yourself
I have been using open source software for a while. I feel like sometimes Open Source software is better than the proprietary ones. Since it allows you to customize and it gives you more control.
But the question is how do you sustain yourself while working fulltime on building/maintaining open source software
What are some tips to get into open source and turn it into fulltime career
316 comments
[ 2.7 ms ] story [ 286 ms ] threadMy solution is that as much as I love open source and the community I’m in, I do not let it get in the way of work and family.
I’ll only contribute when I have spare time. Unless I were to be paid for it.
I don't get to write as much Go code as I'd like, but whenever I do, testify is my first stop on GoDoc (just to refresh my memory in the assertion names).
For example, Everybody on the Open-JDK program is on the Oracle payroll.
Yes, that's right. Large Corporations are the biggest contributors to open-source software. I know that might burst a bubble of people thinking we all sit in mommies basement coding the best software around for free, the reality is different. Microsoft, for example, is one of the biggest contributors to the Open Source community on the planet.
Most people dont realize that open source is unsustainable. Only the big and strong (the megacorps) will be able to outcompete everyone by providing complex stuff for free.
https://github.com/sponsors/Lemmih
gives Intuit the stink eye
Another 1099 example: For most states Stripe won't issue you a 1099-K if you don't meet both $20K volume and >200 charges. Is Stripe shady?
Isn't that just an escape hatch if you do have additional income to report? The tax office should present it as such. Here, the tax office gets that kind of report from a bank. If I agree that it's correct, all I have to do is sign a prefilled form digitally. Unless I've generated income elsewhere, doing the taxes as an employer literally takes less than 5 minutes.
When you actually understand the system, it makes sense why it is the way it is.
Countries like Estonia prefill the tax filing and they say somewhere above 90% of people don't need to make any changes when they file. Most people file within the first day and get their rebate within less than a week. If you had no significant changes (eg opened foreign bank accounts or sjmjlsr) you likely have no need to change anything. There's little fraud possible as data gathered is good and even less mistakes are possible. No one spends a day on their taxes and few need tla tax advisor for regular filing. This is increasingly common across at least Europe but sadly in few countries does it reach such sophistication yet.
Are you sure the US system works that well?
I'm sure the tax authorities would like argue it is income, if you're making $8K monthly on patreon (e.g. Dwarf fortress creators).
https://support.patreon.com/hc/en-us/articles/207477063-Taxe...
Which makes me wonder, is there some other way to aggregate donations such that they are gifts?
And “give €5 and get a sticker” might make it a sale, making it subject to VAT, too.
Also, what if people donate and there are various contributors to the project beside the main author(s)? Should they get a piece too?
There are some caveats here that probably mean we get more donations than most: the software is end-user facing, people who use the software generally use it every day and really like it, the audience skews heavily towards developers and we invite donations prominently without it being annoying (I think - no-one has complained so far).
As for deciding where funds go, most projects only have a handful of core contributors and it's very obvious which these are from how much they contribute. We just talk about it.
[1]: https://github.com/tridactyl/tridactyl
[1] https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
The "trick" in my case is that I am an independent consultant, and open-source is how I dedicate some days of my workload (and a bit of weekends too, but only when I want it).
I have published an open-source Ruby data processing framework in 2015 (https://www.kiba-etl.org).
I sustain myself by two ways: 1/ consulting on either Kiba ETL (which brings leads) or other data projects and 2/ "Kiba Pro" commercial extensions providing more features with vendor support (yes, proprietary code, not OSS, on that specific part).
I have explained in depth how and why I decided to go that route in a talk this year:
https://www.youtube.com/watch?v=yv1EnYTXIeA
About GitHub Sponsors: I'm giving it some thoughts, but some parts are blurry for me as a French company, lawyers have no answers yet, and GH support could not help me from a legal/fiscal standpoint here. I also do not expect much, but will likely try it out.
Hope this helps, although this road is not for everyone!
I spend about 1/2 of the time doing services and 1/2 hacking on the software. Quite often, customers are paying for new features in the software so it is paid hacking. Great!
I'd estimate that at least 99.9% of open source software is written by people without direct payment eg for every 1 paid contributor there are 999 who do it either as part of their role in a job or for free. Even the paid contributors mostly have other income from consulting, social media, speaking, etc.
That's not to say you can't make a job out of it, but actually planning to do that would be incredibly hard. You'd need to recognise something that's missing from the software ecosystem, implement it, release it, and find enough people willing to pay you to develop it to make it a full time job. Alternatively, find a role at a company that pays people to work on open source, eg Google, Facebook, Canonical, etc. Arguably that's going to end up feeling like a normal developer job though.
If we include all software released under an Open Source licence, I imagine that's true, but it will include millions of trivial GitHub projects that don't really matter.
It may be that only 0.1% of FOSS development is paid, going by lines-of-code, but far more than 0.1% of the value of FOSS is done by paid developers. Plenty of paid Linux kernel devs, for instance.
There's loads who work on the kernel as part of their job, but that's no different to any other dev job. I think the question "how do I get paid to work on open source?" is subtly but very importantly different to "how do I get a job that includes working on open source?". The former implies the person asking wants to get paid directly to work on an open project in their own right rather than being part of a company's team of contributors.
That might not be the case here but it's how I've interpreted it, because "how do I get a job at a company that contributors to open source?" isn't very interesting. You find an opening at a company that works on open projects and apply for it.
What's the problem with that? It's win-win that this arrangement is relatively common.
> I think the question "how do I get paid to work on open source?" is subtly but very importantly different to "how do I get a job that includes working on open source?". The former implies the person asking wants to get paid directly to work on an open project in their own right rather than being part of a company's team of contributors.
You're right to point out the distinction, but I don't think how do I get paid to work on open source should necessarily be taken to have that meaning.
I'm not seeing the problem with that. You'll never have full freedom to work on whatever you like and get paid for it.
Seems to me the salaried job approach will give the developer less freedom compared to the patronage model, as you say, but it also has advantages. It introduces corporate/organisational resources, so you won't have to personally fund your test server, and hopefully there will be competent management, etc. In practice I imagine it means better job security too, and at the risk of being circular, it's just more likely to happen and to pay you properly.
> the dev will only get paid to work on aspects that advances the employing corporation's interests
True, but compared to the work just never happening, that's still a good thing.
If you instead rely on patrons, you're still beholden to someone else's interests. This takes us back to my first point: you can never have total freedom to work on what you want, and get paid for it.
But there's also some good monetisation strategies:
- Consulting, at the bottom of your project "Hire the creator"
- Donations, at the bottom of your project "Donate here"
- Open-core, have an open-source core and a premium version with more features (these suck)
- Sponsorware, Open-source the library after enough people have paid you for it [1]
The easiest is to create open-source projects in your day job (where needed). It makes for a better architecture of modular components and plugins and helps you learn open-source development without the pressure of making money from it.
[1] https://twitter.com/calebporzio/status/1221437814748909571
Out of genuine curiosity, are there some egregious examples that merits (these suck), or is it more of a blanket statement?
I would love to avoid making those mistakes.
The incentive of an "Open-core" business is to convert people to the premium version of the product.
This has the effect of hindering/restricting development on the community/free-version, as it's vital that the community version needs to be worse than the premium version.
Almost any monetisation strategy has this effect on open-source though. Say for example consulting; if you're paid to help users setup/configure your project, then your incentive is to have people struggle with your project so they need to pay you for help...
As you can tell I'm a little pessimistic, but in my opinion almost any project that is open-source and trying to make money off it's users, has incentives that will negatively impact the project and it's users...
Hope this helps, I'm still open to projects which have any of these monetisation strategies, but they have to be of much, much higher quality for me to seriously consider.
I can see there's a whole ecosystem built up around kubernetes, cloud management and microservice meshes, for example. You can set it all up for free using the FOSS offerings but it will sink a lot of time learning how to and maintaining the stack. Or you can pay to use someone elses "batteries included" distro which can be deployed with a few commands and save yourself a lot of time but spend $$$($..$??).
As long as projects don't actively refuse to accept contributions to the core, respond well to issues, document stuff well and keep a nice pluggable architecture allowing other people to fork it and hack in their own features, you're allowing people to choose between time or money.
Benefits of having a "pro" version also filters down to the open core - if you're wanting to market your product to businesses, you're likely going to spend more effort on making it more user-friendly and therefore documentation and howto guides become more slick and comprehensive.
TimescaleDB is a good example - everything is open, but most is open source. The only parts that you need a commercial license for are "obviously" enterprise/scale features.
I use TimescaleDB in my ISV, and think it's a fantastic tool. Should I ever need the enterprise features, I would gladly pay for them and fund maintenance and growth of a tool I love.
It occasionally felt like "open source is a good marketing point, so here's the essential source, good luck, we're not going to help you with anything else, pay us". Fair enough, but that doesn't sound "open source" to me.
Open source is very hard to monetize (yeah, RedHat, but that is not similar to most open source projects.
If you’re looking to make money, I don’t recommend you get into open source. I wish this weren’t the case, but this is the current situation.
Unfortunately, it seems the best path if you want to do open source as a career is to do enough open source to get your name out there and then leverage that into a job offer at some megacorp. Maybe you’ll be able to get a role doing open source, but that’s rare. Hopefully you can continue to do open source in your free time at least.
That said, if you insist your goal is to get paid doing open source full-time, here are my tips:
1. Create a project that is end-user facing. No one is aware of which transitive dependencies they are using, so no matter how useful your software, you’ll struggle to get donations, sponsors, or consulting work unless the end user knows your name. Reliable, error-free transitive dependencies are invisible. Therefore, the maintainers are invisible, too. And, the better these maintainers do their job, the more invisible they are. No one ever visits a GitHub repository for a transitive dependency that works perfectly – there’s no reason to do so. But a developer investigating an error stack trace might visit the repository if for no other reason than to file an issue. At least then there’s a small chance they’ll see the maintainer’s plea in the README. (I wrote more about this here: https://feross.org/funding-experiment-recap/)
2. Make sure it’s something that the enterprise cares about. If you build a cool P2P project or a new programming language you’re gonna have a tough time. No matter how useful or innovative the project is. On the other hand, if you’re making a front end framework or a UI library for React or something like that, you’ll have a much better shot at getting companies to sponsor your project.
3. Don’t be afraid to ask for money. Contact companies that are using your library and tell them you want them to sponsor your package. One great hack for finding out who is using your package is to open an issue called “Who is using this?” and ask for testimonials or offer to put users’ logos or links in the README under a “Who uses this” section. Lots of developers will out their companies as users of your package if you do this. This gives you a good list of companies to initially reach out to. Without tricks like this it’s impossible to know who’s even using your package. That’s the first to step to finding sponsors.
In fact, from the perspective of the bigco, there seems to be a thriving ecosystems for leftpad-style packages already even without additional money pouring in. Why subsidize it to become even bigger?
Everyone has costs for things like shelter, power, food, water and other necessities, there is a need for some form of income.
I certainly think they should fund projects based on quality, as your reputation for quality increases I would hope that your ability to bring in sponsorship would be higher, though it's also a shame that people need years of their own funding to break in to open source software development properly full time. In many ways, open source development is only for the privileged/rich.
Jack Dorsey has Devs he pays in BTC whose sole job is to contribute to Bitcoin Core development and nothing else [1], they have no affiliation to his companies other than that.
Also, he's an investor in LN labs who are technically their own thing led by Starkbot (Elizabeth Stark) [2].
So, it can and has been done.
Personally speaking, a lot of the 'how would it ever work...' questions that come up here that are thought to be seemingly impossible to solve have often been pilot-tested inside the cryptocurrency space to one degree or another, so if nothing else I hope most of you can find value in that 'us crazy people' are actually pushing the envelope in the edge-cases of innovation.
For example, because many of us have been proponents of UBI (from various source points, mind you) from either a pragmatic or an ideological standpoint, we've tried to see what verifiable widescale UBI deployment (in Iceland) would entail back in 2014; it failed, as many of us expected it would, but we tested hypothesis whose data could ultimately be used later to iterate and improve a system.
1: https://bitcoinist.com/bitcoin-jack-dorsey-square-crypto/
2: https://www.forbes.com/sites/michaeldelcastillo/2020/02/05/j...
I have no idea how a small developer could ramp this up, but for a larger project, the approach appears to be to form a foundation, and to give contributing companies a chair that's closer to the table.
This is where I fall over - damn my parents for teaching me to feel guilty about asking for money!
> One great hack for finding out who is using your package is to open an issue called "Who is using this?" and ask for testimonials or offer to put users' logos or links in the README under a "Who uses this" section
This is a fantastic idea - I'm going to try it! If companies don't know I'm open to the possibility of advertising their logo on my website (in an innovative way, using my library) then how can they consider giving me money for it?
Especially in those situations, doing right by one another depends on a rich environment of information about costs, benefits, needs, and opportunities. You have to talk frankly about your time, money, and interest, and you have encourage and listen to others when they do so. Otherwise, nobody can have any confidence that people are being treated fairly, rather than seething or starving in silence, and good work is being rewarded.
I've tried in the past to write up a few of the basic lessons we all learn the hard way in freelance work:
https://blog.licensezero.com/2017/10/16/mercenary-rapport.ht...
To spoil it:
Give as you take.
Talk frankly about time and money.
Slice the pie fairly.
Keep your integrity at all costs.
Pay help forward to new people.
Honest pay for honest work.
So writing and releasing OSS may not lead to direct monetization opportunities, but it can be a great way to get in touch with enterprises and to get demand readings quickly.
[1] https://segment.com/
Their website doesn't seem to mention that in any way. :/
Like https://www.group-office.com/
or https://www.proxmox.com/en/
That way maintainers give and receive, not only give.
1. University, some time after it. No much obligations. Take low-effort job to sustain yourself (maybe freelance), spend the rest of the time contributing to open source. Treat it as a time to learn. The main goal is to become good. You can learn very different things by contributing to OSS packages, as compared to working for some outdated local company. Try to internalize how popular software is organized, how people review code, etc. Find people you respect, work with them. You don't need to have a shiny CV and pass technical interviews to work with great people you can learn from, developing great real-world technology, solving hard problems.
2. You need a real job. Try to find one which allows you to spend some time doing Open Source; have it as an important criteria for choosing a job, among salary, work environment, etc.
For me two types of companies worked as a "real job" which allows OSS contributions.
First, some small startups / companies. They often don't mind if you open source a few libraries from the codebase you've created, because usually it is not the code itself which is important for startups; they're trying to find product-market fit. For them a benefit is that code become organized better (after an idea fails, code can be reused for the next idea), and developers are happier, so it can be win-win. You won't be working on open source full time, but you'll be able to create something useful, and spend significant amount of time on it.
Second, there are companies which are built around open source, or contributing a lot to open source. Often there is a company behind a popular OSS software (e.g. Elasticsearch for Elasticsearch, or Scrapinghub for Scrapy). Sometimes company's github has many actively developing OSS projects, which is a good sign. Look for such companies, apply. There is a higher chance to be able to work on open source if you join such company. It is not given you'll be allocated to work on OSS, but a previous experience maintaining Open Source and contributing to it helps. That's good to be proactive here - use your experience gained from unpaid OSS work or small startup OSS work, start contributing without being asked.
According to my experience, working full time, having family and having significant Open Source contributions is very hard, unless an employer supports it, or unless the job is not really a full time job.
There are "rockstars" which are able to sustain themselves just by working on their own OSS projects, but I think currently they are outliers, not a norm. It may be possible to do this, but I've personally seen way more opportunities to do sustainable OSS work as a part of day job, as compared to donations or a new business.
Getting paid for open source software is like becoming a successful musician, from the outside it's easy to only see the few "superstars" who make bank but for every one of them you have thousands of people for whom it'll never be their main source of income.
While none of my stuff made outside a contract ever yielded money, I also never made it a goal.
I know the guy who wrote Jepsen makes enough from consulting to live off of the consulting.
The guy who wrote haproxy started a company that sells basically haproxy consulting and custom services.
The guy who wrote Sendmail did the same, and then Sendmail was acquired. The core maintainers have always done Sendmail as part of their job.
Netflix had a lot of core maintainers of key software on staff who got paid to work on OSS alongside internal projects.
I've been looking into the very same question, IMO:
1. Build a software that you can use as a magnet lead for your services
2. Build PRO/Enterprise version that you will charge for.
3. Become a very know individual in your field and get donations (very hard)
4. Provide services related to the project.
5. Offer paid version of the project, like Ghost I guess.
6. Get hired by a company to continue your work.
Personally, I don't think donations work that well. If you are gonna put a price tag on something, people are gonna pay for it if they need it. Also worth remembering that most of the projects aren't gonna earn you anything. No one is gonna donate to you for the nth existing JS lib you crafted.
I think the point is: the contributions of some companies to few, very large projects are about the same as the thousands of 1-dollar-contributions private people do to the remaining 99.9% of open source software.
I've been involved in the FOSS world for 15 years, and can't remember ever working with, or receiving patches from a large corporation.
I think large corps generally think they can dominate the landscape, and are therefore less likely to adopt the more collaborative approach inherent to FOSS.