"feels like the fabric of the universe" kind of thing, except unlike some of the bigger projects, these often have frighteningly few core maintainers. We saw this with OpenSSL after Heartbleed, with most of the world unaware that such a critical library was maintained by a single digit number of volunteers.
a bit stuffy compared to the simpler structures around the GitHub generation. But these projects also usually have very important history, having been built to stick around for the long haul even as individual developers come and go.
about those soon, but the fundamental limiting factor on most open-source projects is the rate of burnout of the contributors and maintainers. Most projects fail because people don't want to work on them anymore.
these. A cycle of feeling guilty about letting down your users, leading to dread about working on the project, and finally bitterness towards the project itself or sometimes even the users of it.
almost every facet of technology, communal resources have pushed us farther and faster. If we want this pace of progress to continue we need these shared resources, but with this cross-pollination comes inter-dependence. While open licensing helps ensure the possibility of someone picking up a fallow project, that doesn't help us if there are no new maintainers left to pick up a fallen banner.
I think open source itself is important, I think together we can build things better than any one team or organization. With a lot of problems in software, the value to the market is small or hard to define such that no one company can easily build a solution. But collectively we all can, and we are all better off for it.
clearly I think there are problems with the system or I wouldn't be giving this talk. How did we end up with a worldwide ecosystem built on the backs of a relatively tiny number of volunteers?
been lagging everywhere. Putting time and money into things like bridges and dams rarely shows returns immediately, if a return can even be quantified. If your focus is only on the earnings for the next quarter, it's easy to let things slip.
things. I can only put my brain towards building one thing at a time, but even while doing that I am almost certainly making use of hundreds of other projects and tools. Even in the best scenarios there will always be more users than contributors, and that imbalance has spiraled far out of control.
app sits on top of a mountain of other projects and libraries. As we build better and better abstractions, it becomes easier to forget the shoulders of the giants on which we stand.
basically everyone that consumed open-source software also produced. Maybe I worked on gcc and you worked on bash, but we both benefited from each other.
of the system than are putting it back in. As the third wave of open-source developers is reaching middle age and deciding that other pursuits are more important, often there are no longer fresh faces waiting to take up the banner. And so, here we are.
probably either the LAMP stack (PHP, MySQL, and Apache) or Ruby on Rails that really got the ball rolling on corporate use of open-source. VC-funded startups realized they could switch to free as in beer tools and save money. And since VCs hadn't learned about this one cool trick yet, the checks coming in stayed just as big.
now startups and big companies alike know that zero-cost software stacks exist and many are very high quality, and budgets around the world have adapted to that reality. For many young startups, using free stacks is not just a technical choice, they often can't afford anything else.
at loggerheads. Capitalism requires privatization, and open-source is the opposite of that. As long as the bulk of companies continue to draw more value from the commons than they put back in, we'll always have a sustainability problem.
Both were originally built by VC-backed startups but as open source projects from the start. One of the founders of RethinkDB has a fantastic post-mortem on what he thinks went wrong which I think should be required reading for all open-source users, but roughly it's a very saturated market in both finance terms and on mind-share. Whatever your feelings on MySQL and Postgres, they have set a high bar for what is available for free.
and their former OS distribution CyanogenMod. In 2016, after a big management shakeup, they decided the benefits of remaining open were simply not making up for the huge costs in user support and lost potential revenue from people that would pay for the OS if it wasn't free.
Mark Pilgrim. I say this not as a callout or critique of either, more of a cautionary tale of how putting the burden of a big community on one person rarely works out well for either side.
On one hand, drive-by contributors are often bringing important fixes and features, and can sometimes convert into regular contributor or maintainers. On the other, it often takes a lot of time and mentorship to shepherd a first contribution and doing that every time for a dozen drive-bys is a big load itself. There is no good answer, but at least be aware of the issues and know when to step back from mentoring first-time contributors if you don't have the energy.
from. The project is created by one person, and even as more contributors and maintainers join, they remain in control of overall direction. This can work well for a young project, but having to run all decisions through one person can quickly become a bottleneck which leads to frustration.
fragmented into a small number of BDFL- like maintainers all exchanging patches with each other and the community. This helps reduce friction in some ways, but can be intimidating for a new contributor.
you can forgo most of the rules and run purely on rough consensus. This can feel great for long-time contributors but can easily result in hidden power structures that are incomprehensible to new folks.
of these. Each project pulls together a (hopefully) coherent set of these ideas and does their best to tweak as needed for their specific circumstances and people
going to eventually look a lot like the org chart of that team. This is intended to be a bit tongue-in-cheek but is still remarkably accurate. A choice of leadership and decision making structure affects not just the humans, but the software those humans produce.
to move in to improve sustainability. For some projects, more structure will help unload overburdened maintainers, but in others the increase in bureaucracy and paperwork will push them further into burnout. When playing with governance structures always make sure to listen to the people it impacts and be ready to change gears if you got it wrong.
of open source. It's not directly related to the governance model used, but one often influences the other. A good license ensures that even if all the contributors from a project move on, at least the source code will remain available. But what about cases where it can be more than just a backstop?
talk about dual licensing later, but the promises of the GPL are around code access. Exactly how it works depends on which flavor you use, but overall the idea is that changes to the code should be made available to users, which means they are also available to you as the maintainer in most cases.
that someone can fork your code, make some kind of change to it, keep that change to themselves, and then turn around and sell the whole thing. This could, in theory, pull resources away from your project to their fork. So if you make your code available under a copyleft license, you can head off this whole cycle, again, in theory.
zero, big projects like the Linux kernel continually have issues with proprietary extensions causing friction for both users and maintainers. But it's by far the exception. My personal view is that copyleft causes more problems than it solves, but perhaps your project is different.
be a volunteer project. And those are great, some people enjoy coding for its own sake, or want to build up their professional portfolio, or just really need a problem fixed. But always remember that volunteering your time is an act of altruism. I speak from personal experience that it's easy to end up stuck in that cycle of guilt and bitterness I mentioned before until you never want to see another computer again.
normal work hours. This might be a project that belongs to the company that you are improving, or contributing a bug fix back to a project you use. This is a great option when you can find it, but many employers don't yet see why they should pay someone to give a product away for free.
company time is everyone using company time. This isn't a long-term solution so you'll need to explore other options to eventually repay your investors, but VC funding can be a way to get a new or nascent project off the ground.
attempting to be self-sustaining, to bring in enough income to support at least some of the time spent on it. By far the most popular method is to sell support for your project. This can be very hit-or-miss though, many small companies can't afford anything that takes away from their launch runway, and big companies often think "we'll just support it ourselves". Examples include MySQL and Java.
project aren't set up to offer commercial services, so maintainers set up smaller commercial entities specifically to sell support services or similar stuff, but with the goal still being to sustainably fund their work. This is the dominant model in the Postgres community.
around having an "open core" and selling related closed-source software on top of that to add additional functionality that caters to some specific use case, often things that are only needed for large enterprise customers.
like SAML login support or cross-team reporting. But other times it can be hard to find ways to sell these features without making life difficult for your open-source users. This has been popular in the DevOps space, Chef, Puppet, Salt, and Ansible all offer commercial add-ons.
the same software they could get for free, but under difference license terms. The common case is a project available under a copyleft license, a company wants to modify it without sharing the patches so they purchase a license that doesn't include the copyleft restrictions. Not very common these days but still an option. Qt is probably the biggest example still using this model.
is usually some mix of consulting to help them best use or deploy the project, customization to make any custom plugins or modifications they need, or running a hosted version if the project has a server component. Examples are too numerous to count, but Pivotal Software is a big one, providing services around CloudFoundry among others.
time immemorial, and we've slowly seen more available for software projects. Like with other kinds of grants, you write a list of things you want to do, why they're important, and how long you think it will take, and use that to come up with a dollar amount to ask for.
grants but they were the first I encountered. A lot of other groups in the Python ecosystem have taken up this mantle as well, offering project-specific grants.
another example. Rather than being ecosystem-specific, they aim a bit more broadly for projects that help with Mozilla's core mission to improve the open web.
any other non-renewable income stream is it is highly dependent on how good your time estimates were. If it turns out you missed some complex requirement and that takes you an extra 6 weeks, that might end up coming out of your own pocket. And we all know that engineers are super great at estimation.
is easy to set up, but rarely very useful. It can be heartening to get $10 every now and then, but if you aren't already okay with working for free, I doubt those random rewards will help you keep away the burn out very much. As a maintainer, I would much rather a nice thank-you email than $5 from one person.
donation, allowing you to plan out how much income you'll have to work with and allocating time appropriately. Patreon currently mostly owns this market, and is very easy to get set up with, but they haven't done much to make in-roads with the software world.
problem, friends all paying each other while the companies deriving the economic benefit from the projects do nothing. I can only speak for myself, but I don't want individual users to ever feel like they owe me for my code. What I want most of the time is for some of the places making money with things I write to let those resources get back to me in some form so we can both benefit and continue improving things.
a Kickstarter to fund some open-source development and it was successful, but it was very stressful and I wouldn't really recommend it. In the same way as I mentioned with grants, I ended up mis- estimating my timeline by about 3 months, but the money you have is what it is.
than people look to get non- profit status so those donations can be tax deductible. Creating a non-profit from scratch is rather hard, so often they join existing umbrella groups that can accept donations and distribute them out to projects.
Software Freedom Conservancy, which has helped dozens of projects set up this arrangement. If you're interested in being able to accept donations like this, I highly recommend talking to them.
donations is working out how to divide them if there is more than one maintainer. Sometimes this can be sidestepped by using donations to pay for project-level stuff (hosting, swag, whatnot) but it can lead to hurt feelings and perverse incentives very easily.
the form of discounted service or free credits. For example Rackspace has graciously hosted part of the CI infrastructure for my Chef cookbooks for many years by providing a discounted Rackspace Cloud account. It can often be easier to ask for a company to donate these kinds of resources rather than cash.
but interesting funding strategies. Various projects have tried funding themselves through book sales, notably the Lua language. This can often be a difficult line to walk between making the free documentation good enough, but still having something left to sell. More often the book content is made available for free on the website but physical copies are available for purchase, though this will bring in much less revenue.
sales basically run the world these days, right? Setting up google ads is very easy, but also doesn't usually bring in much revenue. Negotiating your own ad deals gives a lot more control over the kinds of ads you get, but is also time-consuming. And all of this might be for naught if your highly-technical audience all immediately blocks the ads anyway.
a tool to try and incentivize people away from selling attacks to the bad guys, but they do sometimes pop up for normal feature requests and bugs. Outside of infosec it's still too rare to be a sustainable funding source, but maybe in the future this could improve.
medicine, and the arts we have many national and international organizations the provide public funding for things like basic research, projects that won't reap commercial rewards directly, but form the basis for future work. This sounds a lot like many open source projects, so maybe one day we could see a National Institute of Software.
the only maintainer on a library you use will have a child and decide that's more important, maybe you'll get a new job and realize that utility you made just isn't fun to work on anymore, or maybe something totally unexpected will change how open source works. We've all only been doing this for a few decades, we still have a lot to learn about how to build software the best way.
their advice and wisdom over the years about how to run sustainable projects, but I would like to extend an extra special thanks to Nadia, Russell, and Eric as true luminaries. I highly recommend all of their writings if you're interested in diving deeper.
coderanger
manfredsteyer
naokihaba
x5gtrn
yukikurage
har1101
tonkotsuboy_com
ochtum
panda728
iidatakuma
niftycorp
kotetuco
yusukebe
mfonobong
caitiem20
morganepeng
orderedlist
badams
swwweet
holman
stephaniewalter
sonatard
tmiket
schlessera
samlambert
