An idea I’d like to throw in the wild.
Open source is software businesses use to shorten time to market and accelerate their product. Some businesses build and collaborate in public because it’s a leverage strategy to get more from less. Most businesses maximize their use of open source software because they get it for “free”.
Debt is the financial term, stolen for the sake of illustrating a concept.
Open source is debt because:
- Open source software is not a sellable asset. It’s both priceless and devoid of monetary value. What counts is the business value it enables.
- The liability, and effort required to service this liability, grows as: 1) the software gains users, and 2) those users become more dependent the software. Support is a variable accelerant to the liability (e.g. it can grow the liability at an exponential rate).
- Maintainers hold the debt liability. Their ongoing labor is required to service the debt. Typically, maintainers can only escape the obligation by declaring bankruptcy: “it’s done” or “I’m done.”
This idea could be helpful framing for:
- Businesses to understand their dependency on open source in CFO-friendly terms.
- Communities to understand the debt burden carried by maintainers, and general health of the project.
Another, possibly more correct, way of thinking about this is: “every line of source code, open or closed, is a liability.” Businesses own 100% of their closed source liability. They like open source because they would rather own 0% of the liability.
5 Comments
Interesting analogy. Somewhat related tweet I saw once, saying “all code is technical debt”. https://twitter.com/pwim/status/549463179084853248
I have a more optimistic view of open source.
It’s true that releasing code always creates responsibilities, and these responsibilities scale up quickly with the number of users and with the complexity of the software. It’s also true that project maintainers don’t always succeed in upholding these responsibilities in a way that benefits everyone.
However, the potential benefits of open source far outweigh these costs and responsibilities.
The analogy to financial debt breaks down when you consider scale. If 1000 businesses use a piece of open-source software as part of their product or service, and 10 of these businesses contribute fixes and features back to the software, then it becomes that much better for all 1000 of those businesses, as well as any hobbyist users. Financial debt does not work this way.
So how do we make this the reality rather than an idealist dream?
There are two main responsibilities of an open-source maintainer as I see them:
– Enabling community contributions to succeed.
– Being able to hand off the project when you are done.
So, maintainers: set up contribution guidelines and go looking for and accepting quality contributions. Write automated test cases so that the computers do as much of your work for you as possible. Look for people who are qualified to take over after it’s time for you to move on.
These things benefit you directly as a maintainer, but also they make it easier for you to hand off the project and for others to keep it going.
How does the maintainer get paid to do this work?
You’re right: except for a lucky few developers, most people don’t get paid directly to work on open source projects.
I can only speak for myself of course, but here are some reasons why I contribute and maintain open source software:
– To give back to the community which has made it possible for me to make a living doing what I enjoy.
– To improve my marketable skills.
– To build tools that I can use in future paid projects.
– Because I sometimes enjoy solving a problem in an abstract, general sense, or creating exactly the tool I have in mind, more than I enjoy privately fixing specific bugs for clients.
It’s easy to give too much time as a maintainer and start to feel like this is not worth it. If you start to feel like maintaining an open-source project is “a bunch of unpaid labor upfront to own the ongoing, unpaid, responsibility of fixing other peoples’ bugs” then it is probably past time to take a step back and let others handle the maintenance for a while.
Hopefully, ideally, you’ve done the work up front to make this possible.