Delay the Revolution—Support Your Software Dependencies

Every one of your dependencies is made and maintained by people. If their ambitions stop aligning with yours, the dependency will stop being useful to you—sooner or later. Stop or delay this revolution against your interest by actively supporting these people with your money, time and goodwill.

Every component your system is made from, from the nuts and bolts in the computers running it to the programming language and software libraries it is made from, is made by some constellation of people with some end in mind. If and when these ends shift, your ambitions and theirs will no longer align. You might recognize this as an open-source library no longer being maintained, a breaking API change, or a discontinued product. What can you do to prevent—or at least delay—this revolt against your interests?

This post is the second in a series. To learn more about how dependencies are more about people than technology, please have a look at the first post.

A Little Support Goes a Long Way

Let’s contemplate the fact that most of us need money to make ends meet. A lot of priority shifts happen because not enough money is flowing in the desired direction. While this is obviously the reason why many a late-night hacker must abandon his or her open-source pet project, or why polished products from large companies are discontinued, it can also be the triggering factor behind subtler changes of events, like individual features in cloud services being pulled back, or improvements not being made that would greatly benefit you.

In a well-functioning market economy, the flow of money tends to communicate what is valued. If your system relies on components you are not paying for, you are communicating that you put little to no value on these components. If others are paying for a component but not you, their needs will likely be prioritized over yours. If no one pays for it, it will most certainly be abandoned at some point. You should be very interested in paying for the components you depend on relative to the value you extract from them, or to the damage you would suffer if they were abandoned.

Does your system depend on a free tier of a cloud service, or on open-source components acquired via a package manager? If your system is more than a hobby project or a proof-of-concept, you should do what you can to pay for these things. Nowadays, a lot of open-source projects advertise that they accept donations via the package managers that distribute them. Identify your most important dependencies, and then do what you can to pay for them. You likely depend on programming languages, hardware architectures, standards and a lot of other things. How critical are these to you? Are there risks of them becoming misaligned with your interests? What can you do about it? These questions are important for the long-term survival of your system.

Apart from giving money, there are other ways of showing your goodwill. You can donate time to support open-source components, express your appreciation, take part in events or discussions, report bugs, or simply point out improvements you would value.

A Lot of Support Goes Even Longer

Let’s assume that you have a lot of resources at hand. Enough to support multiple people—or even buy a whole company. Rather than only being able to influence with your resources, you then become able to take over your dependencies. Is a critical component provider about to go bankrupt or discontinue a key product? You just might be able to buy the rights for the product, or even the company itself, at a bargain.

If the provider is a charity or some kind of foundation, you may have to get a bit creative. You might buy an overly expensive support agreement, aimed at making the project sufficiently financially dependent on you to prioritize your needs. Or you could hire a bunch of experts and donate their time to the project. Since they are on your payroll, they will feel obliged to prioritize your needs. Open-source projects can be forked, and other software can even be reverse engineered, should you become desperate enough.

If you’ve been reading industry news for long enough, I believe you can think of real-world examples of all the above takeover tactics. Do they sound shady to you? They sure can be. If, however, you do these things and are transparent with your intentions, you will be a benefactor or partner rather than a sly subverter. Most people need money to make a living, and if you can help satisfy the needs of your clients, your dependencies and society at large, everyone is better off.

In summary, use the resources you have, however little or much, to communicate where your interests lie. I’ll be back in the coming weeks with another post on the topic. Then on preparing for and quelling dependency revolts. Until then—support your dependencies!

Posted in ,

Discover more from Systems and Society

Subscribe to get the latest posts sent to your email.

Leave a comment