1. Maintainers and authors are found everywhere throughout our dependency trees. This includes the authors of the tooling others use for maintaining, building, testing, writing and running the infrastructure they depend on. Even maintainers depend on other maintainers.
2. Maintainers’ mental health and well-being is also a dependency.
3. So is their outlook on the sustainability of their projects, both in personal, technical, systemic and economic respects.

This means that personal, technical, systemic and economic well-being in the end are all actual and real dependencies for the businesses that rely on these people and their projects.

What can an ecosystem provide to make the lives of these maintainers easier in this regard?

…continued

Let’s have a thought experiment. Assume there is an Open Source-licensed Perl module published on CPAN that you care about, and that hasn’t had any updates in a very long time - what are your options?

In this blog post, I’ll take a dive into this problem, and use the Geo::Postcodes::NO module as an example. As of this writing, the module version is 0.31, and it’s most recent release was in September 2006.

Initial assumptions

Before we begin, let’s lay bare the most important assumptions I’m having. Your case may differ, but I think the following ones are pretty safe.

• There is a long-term need for this module, and we need it to be up-to-date and bug-free.
• We would like the module to be usable in an environment where recent or modern styles of developing Perl are preferred and used.
• We have the time, competence and calories to have the necessary conversations with the authors and their upstream peers.
• The author is available and approachable. If he or she isn’t responsive, then there are options for taking over as maintainer of the module after due diligence. This is a last resort though, so we won’t cover this here. If you need to do a lot, a good option is to ask to become a co-maintainer.
• Creating a new module from scratch is undesirable, either because it’s too expensive or because your business has decided not to spend time on writing basic software infrastructure.

Read the rest on code.foo.no!