laike9m's blog

Software Maintainer Commitment

The Heat around PyPI "critical" Packages

Recently, PyPI mandates 2FA for critical projects, but got many push backs from developers (1, 2). Many people (assuming open source project maintainers) don't like the idea of being forced to put more work into projects they don't get paid to work on.

Armin Ronacher (creator of Flask, Sentry) discussed this in more detail, suggesting there's a better way like cargo-vet than putting more burden on maintainers. Donald Stufft (Python core dev, pip/PyPI maintainer) on the other hand, believes that maintainers do have certain responsibilities.

While almost all people agree that enforcing 2FA is a sensible move, I think the real problem is still about the responsibility of open source software (OSS) maintainers, or, does it even exist?

The Responsibility of OSS Maintainers

Many OSS maintainers complained on Twitter that they've been seen by users and big companies as "free labor", like the one Daniel Stenberg (creator of curl) posted.

Despite all the posts, it seems like we're entering a dead end: users keep asking, and maintainers keep clarifying. The OSS community has wasted so much time and energy on this, and it makes me wonder whether we're trying to solve the right problem. "How many responsibilities do OSS maintainers have?", it doesn't even feel possible to have a right answer, because projects are so different by themselves.

I think, the question we need to answer is:
For a specific project, how to get its maintainers and users to reach a consensus on the responsibilities of maintainers?

The differences with the original question are:

  • Target projects individually, instead of viewing them as a whole.
  • Involves both sides, instead of only one.
  • Building an understanding is always the foundation towards more actions.

A Possible Solution

Naturally, we think of a similar thing: open-source licenses. It's answering the opposite question: what are OSS users allowed to do? What if, we have something similar for maintainers, and let's just call it "software maintainer commitment", or SMC. Suppose we have something like this, what will it look like?

  • For 90% of the projects, they will remain as is, i.e. no commitment. This means maintainers have absolutely no responsibility.
  • For some, they're willing to enable 2FA to provide the least assurance. Some may be willing to ensure compatibility with the latest version of the language it's written in.

For projects maintained by big companies, that's a whole different story. I can imagine big companies have the resources to provide a long list of commitments, and they're willing to do so to attract more users. This is certainly unfair for maintainers working in their free time, but on the other hand, by making the distinction clear that there are different levels of commitment, users will no longer assume that each project can provide the support that they imagine, which is the whole point of SMC.

Though the idea comes from OSS licenses, implementation wise, SMC will be different in many ways:

  • There will no longer be pre-defined commitments like MIT, GPL, except "no commitment", which is like WTFPL.
  • Commitments need to:
    • Be fine-grained: support the attributes that maintainers may need to specify, and allow expansion.
    • Be configurable: commitment is often more than just "yes" or "no". For example, one might say I guarantee to fix security issues in x days, and x can be an arbitrary integer greater than 0.
    • Allow anti-commitment: since all we want is to bring more clarity, anti-commitment makes total sense. An extreme case would be: as a maintainer, I will not fix any issues, and it's the users' responsibility to do so.
    • Allow conditional commitment: Often times, financial support is critical to keeping a project alive. Things like GitHub sponsors and Open Collective have helped many developers and made many projects better maintained. SMC should allow developers to state "if you pay me $500, I will respond to your bug in x days and make it a higher priority."

In short, commitments need to be a lot more flexible than licenses, because maintainers have different needs.

A Beautiful Future and a Bumpy Road

So what can we do with software maintainer commitment (assuming it's widely adopted and recognized)?

  • It makes maintainers happier, and users less confused.
  • It saves people's time, for both maintainers and users: less questioning, arguing, clarifying, complaining. We're talking about the time people spend on communication, and that's a lot of time.
  • It helps users select the projects to depend on.
  • It helps identify the risk in your supply chain. Remember this graph?
    But how are we going to analyze all these arbitrary commitments, you might ask? Well, that's where machine learning can help.

The future sounds fantastic, but to get there we need to go through a bumpy road, and I'm not even sure we can.

  • Unlike a license that is backed by legal precedent, SMC doesn't really "enforce" anything. Stating a high support level doesn't mean a project is actually supported. On the contrary, if somehow it is enforced by law, then maintainers will not use commitment for sure because the risk is too high.
  • Most maintainers probably just don't care about having such a thing.
  • Creating commitments by themselves is not enough, having them widely recognized and respected is as important. This is really hard and will probably take decades.

With all the difficulties, I never doubt the value of transparency and clarity. Again, it's worth noting that the purpose of software maintainer commitment is not to encourage maintainers to do more things, but to resolve the confusion around responsibility. I can imagine that personal maintainers tend to have mostly anti-commitments, while corporations will have more commitments. This is fine, and if we get there, the world of open source will be a lot better than today.

The World Is Different Now

The world has become very different. In 2011, it's still Why Software Is Eating the World. Today, can you imagine an article like this that does not even mention open source? Open source is not new, but in the past, it was not as critical as it is today that affects almost every aspect of human beings. The scale of users has made OSS beyond just a topic among hackers. The atmosphere also changed with it, there's no "common sense" any more. With the explosive expansion of OSS, the management and ideology of open source is falling behind.

With or without software maintainer commitment, the issue of maintainer responsibility has to be solved. I have faith in human, and we'll get there eventually.

Appendix

James Bennett wrote an article that mentions similar ideas.

comments powered by Disqus

top