paying-the-piper
paying-the-piper copied to clipboard
beeware
Solved problem?
Just a reality check: is funding open source projects already a solved problem?
There are tens of thousands of people working full-time on developing open source software and being paid for it. For one example the OpenStack project shipped a new release this week that was developed by 1,944 people from 164 organizations over the past 6 months.
One alternative to inventing new ways to fund open source projects would be to think really hard about how to replicate the methods that are working for other projects.
I think it is solved for companies at a certain scale, but not really solved for solo developers or small groups willing to "just maintain a library properly" on the long run.
The simple fact that I'm trying to figure out how to sustain the development of more features on one of my gems (which will likely be via a "pro" version, but then you have to figure out what makes the good "pro" version, one that companies will buy etc for a reason), despite being a freelancer for 10 years and a (paid, B2B) SaaS bootstrapper for 4 tends to tell me this is not "dead easy".
Just a data point!
@lukego it really varies from projects to projects. Some are maintained by people who do not have to chase money too often (employees), either out of office hours (night, week-ends) or during work-day (if lucky or if there's a high financial incentive for the employer). Other (like I did in the past) are maintained by solo freelancers or small agencies, in order to scratch an itch but "funded" by the billable days they have to chase otherwise (the hope being that the gem brings back consulting etc - but this works better at a given scale, much less as a solo developer).
If I'm pointing that out, it's because I know a fair number of (usually solo freelancers, or micro-agencies) developers who just ended burning out because essentially, the work for open-source was handled "as an extra", an addition to the "rest of the work".
For instance, see LocomotiveCMS feedback on this.
I did the "maintenance of gem brings consulting" dance in the past, but it only works to a given point, and I personally prefer to aim for the "Sidekiq Pro" model now.
Again, just one data point based on my own experience + what I've seen around me!
I hope more will chime in with their own experience.
In terms of Django and most open source projects, this problem is NOT solved.
Yes, in the world of corporate-scale open source server configuration management (Linux variants, Open Stack, Docker, et al) this problem is indeed solved. They provide support and training for complicated critical projects - and those projects are arguably over complicated to ensure they get hired as domain experts.
Outside of big corporate for open source server configuration management, individuals and their projects have similar problems of funding (thanks @coderanger!)
Outside of that domain for the most part it isn't, certainly not in the realm of web frameworks. Sure, there are a few lucky projects that have funding and/or working business plans to employ their maintainers:
- Meteor (VC funded, business model still yet to be proven)
- npmjs.org (VC funded, business model still yet to be proven)
- ReadTheDocs (funded, business model still yet to be proven)
- Sentry (business model proven)
- Django (community funded)
For the rest of us, who do work on projects that support major companies, there is nothing or nearly nothing coming our way, and nothing is forthcoming. For example, I personally get regular demands for unpaid work (Discussions about payment for work always stall) by healthy high profit companies large and small for the following projects:
- Cookiecutter
- dj-stripe (Which is about getting collecting payments from users!)
- django-mongonaut
- cookiecutter-django (small number of such demands but growing)
If I don't respond in a timely fashion, if I'm not willing to accept a crappy pull request, I/we get labeled a jerk. There is nothing like having core Python/PyPA maintainers working for Redhat demanding unpaid work while criticizing what they consider your project's shortcomings to ruin your day and diminish your belief in open source.
Yes, most users are nice, but invariably the nastiest ones belong to big companies - with about an anecdotal 50% of them being Corporate Open Source like Redhat and the whole Open Stack crowd.
Finding co-maintainers is hard, about 75% of them don't work out, and you still get demands for unpaid work. Even if you totally offload a project to a different leader you still get those demands for unpaid work. Even if you put a loud notice on a project, saying "This is unmaintained" you still get demands. Ugh.
For someone like @jezdez, I can't begin to imagine how many similar demands he gets.
"In the world of open source server configuration management this problem is indeed solved."
Citation needed.
@coderanger, the definition of the classic business model for open source server configuration management:
- Create a server product
- Make it sophisticated
- Charge for support and training (Enterprise support is best, as it gets past the low-price barrier in big corporate)
- Invest heavily in marketing at grassroots and corporate levels
This has worked for:
- Redhat
- Canonical
- Docker
- The entire Open Stack community
- Puppet
- Chef (unless you know something I don't know)
- etc
Saying that companies exist doesn't mean there is a healthy, paid ecosystem. Company != community.
@coderanger Thanks. Updated that sentence to be:
Yes, in the world of big-corporate open source server configuration management (Linux variants, Open Stack, Docker, et al) this problem is indeed solved.
Also stuck in another sentence that clarifies things to be big corporate.
@pydanny @coderanger Quoting @xof, the model works well for "boring fuddy duddy" software - operating systems, databases and infrastructure software that has enterprise uptime and support requirements, or requires significant expertise to configure efficiently at large scale. It works less well for smaller consumer stuff or developer tools/libraries.
No way is this solved. I could go on and on and on about how worthy projects are under-resourced currently while bullshit redundant crap nobody needs gets funded on the proprietary side.
@wolftune I think GnuPG is an excellent example here: htps://www.propublica.org/article/the-worlds-email-encryption-software-relies-on-one-guy-who-is-going-broke
The small-but-sophisticated library is something that would be great to be able to support.
@ariddell Absolutely. As co-founder of Snowdrift.coop, I had tons of people emailing me when that article came out desperately asking if we could get working soon. I only wish we could, but we have a lot of challenges and work to still do today to get our system operating.
Even in the case of boring fuddy duddy software, the problem is not fully solved. While a lot of money goes into (say) PostgreSQL development, much of that is for forks that are not fully (or at all) open source.
Smaller companies tend to feel that they don't have the budget to fund development (they're usually wrong, but the perception is there).
Larger companies are worried that they will end up running a fork of the main project, and thus be shut out of updates, or at least that their update strategy will be seriously complicated.
Perhaps we need a revised problem statement. Is an option:
We need a guide for people interested in including open source software engineering in their day job to enter, maintain and grow an appropriate career.
