4 ms·

This "project dead?" question pops up on many open source projects on github. One recent one: https://github.com/axios/axios/issues/1965 https://github.com/axio

This "project dead?" question pops up on many open source projects on github. One recent one: https://github.com/axios/axios/issues/1965 https://github.com/axios/axios/issues/1965 The issue seems to be similar to one that we programmers regularly encounter in our day jobs: failing to consider maintenance and/or make a plan for what happens to a project in one, two, or three years. I don't mean to say "the authors of this project failed to consider maintenance" I mean "we, the whole community, including maintainers and consumers of the project, took maintenance for granted or were not concerned about it." Anyone who installed the tool without reading the project's governance model and maintenance plan signed up for "whatever happens happens," the governance model of most small projects. I myself do this all the time, I'm not saying I'm better by any means. To participate in the JavaScript/Python/etc. ecosystem generally requires being OK with this. To me this isn't a question of one project, it's a question of OSS project governance in general. Is there a succession plan? How do you know when more maintainers are needed? How do you promote someone from contributor to committer to releaser? We went around adding CoCs to everything a few years ago, perhaps a similar effort could be made with governance plans? Like a boilerplate plan projects could use, hopefully leading to a new community norm of "if you are using a project with no governance plan, that's up to you, but don't say you weren't warned!"

JulianMorrison 7y ago
Broadly, "a project is being actively developed and makes releases reliably often" is a fairly tolerable maintenance plan. It's only when that implicit contract breaks down that you get "is X dead?"
bluGill 7y ago
Can you suggest something a little more concrete? What should I add to my project so that if I die tomorrow the project can continue without me? I work on a small project. I didn't add a CoC when the big push came about because I concluded that it was if I say it is bad it is bad, otherwise it is good - that is no CoC and so there is no point. (I did consider asking some large project - KDE for example - to be arbitrator, but I didn't bother)
- sequoia 7y ago
  I haven't thought about it much and I'm not a project maintainer. As for your bus factor of 1: a) it only matters when there's actually a large group relying on your project and b) the answer is "have multiple maintainers with commit bits." To take a shot at something "more concrete": * New releases will be cut at least on a quarterly schedule * When the number of open issues passes 25, a new maintainer shall be added (if not sooner) * Maintainers may leave a project at any time and are encouraged to do so if they need to move on to other things * Maintainers may return when they have time * Once per year, maintainers shall either reaffirm their desire to continue maintaining the project or step back from maintaining * After 2 merged PRs, a contributor is promoted to a maintainer The main functions here are 1) add clarity to whether anyone is actually maintaining the project & who 2) Clarify that maintaining the project is an ongoing commitment & it's perfectly fine to step back from that 3) Create a mechanism to add maintainers & to signal when new maintainers are needed and 4) Create some general guidelines around releases, so people know what to expect (and know when things are no longer happening). This is certainly not a good governance plan for everyone, some may find it too prescriptive, but it seems like it could be a good start for projects like axios & pipenv. The idea is to prevent "is this project dead" type issues before they arise. When a project is losing maintainers & no one wants to step, it's clear that the project is waning. Of course it's also perfectly reasonable to say "that's too much work" or "f*ck off, it's my project." This convention would help people make more informed decisions when adopting a project for use. Some will be fine with "whatever", some will want a clearer plan, both are OK.
- medmunds 7y ago
  I’m in a similar situation, maintaining a project that’s used widely enough it should probably have a continuity plan, but not enough that it’s developed a robust community of other contributors who could step in. Jazzband [0] seems meant to address exactly this: “a collaborative community to share the responsibility of maintaining Python-based projects.” And it looked promising, but it’s not entirely clear that the Jazzband project itself is all that active (only news status update is the launch announcement from 2015; last public Twitter activity was in 2017). [0]: https://jazzband.co/ https://jazzband.co/
isthisreality 7y ago
The axios example is an interesting one, because there are tons of people saying they're willing to help, but how many of those people will actually contribute anything without guidance of any kind? When the current maintainers are too busy to even provide guidance, you need to be a special kind of developer to even have a chance of becoming a real maintainer, and those kinds of developers are few and far between.
Reedx 7y ago
Maintenance is something I've come to appreciate more and more every year. It's so easy to install dependencies, but it comes with a large hidden cost and painful lessons down the line.
- cogman10 7y ago
  Yup. Further, I do a lot more research in the dependencies I bring in (if I can help it). Does this thing also bring in 1000x sub dependencies? How much am I REALLY going to use this. What's the actual added value here. I've seen people bring in libraries for simply the dumbest things. The worst offender I've seen is lombok brought in for a @Logger annotation on one class. That stopped our java 6->8 migration because the version of lombok they brought in was old and for highly used library (so upgrading wasn't simple). If you can write the used functionality in 10 minutes, you should not bring it in as a dependency.
  - nitrogen 7y ago
    If you can write the used functionality in 10 minutes, you should not bring it in as a dependency. I disagree with this; it depends on the size of the dependency, plus the risk of a problem with the dependency vs the risk of making a mistake vs the risk of code drift when the same 10-min thing gets written a dozen different ways across an org.
    - nwallin 7y ago
      I think you are dramatically underestimating the cost of a dependency. The dependency may change in surprising ways in the future. The dependency may not change in expected ways in the future. (ie, now you're trapped in an old version of the language, or another one of your dependencies) The problematic part with reinventing the wheel or NIH is that you add a fixed cost of doing business to any given change. The problem with importing the world is that you add a dynamic cost to simply existing without change. It's a tradeoff, and it's not a tradeoff that's consistent across organizations. For some orgs it's really important to be first to market. In other orgs it's important to not break shit for your existing customers. My org is well established in our field. Nothing matters more than retaining our existing customers. Importing a new lib requires approval from legal, which requires about a personweek. In other words, if one developer could implement the same thing in less than 40 hours, the developer should implement it themself. For us, a slow moving org, I think we're at the right place. For a startup, obviously not.

JulianMorrison 7y ago

Broadly, "a project is being actively developed and makes releases reliably often" is a fairly tolerable maintenance plan. It's only when that implicit contract breaks down that you get "is X dead?"

bluGill 7y ago

Can you suggest something a little more concrete? What should I add to my project so that if I die tomorrow the project can continue without me? I work on a small project. I didn't add a CoC when the big push came about because I concluded that it was if I say it is bad it is bad, otherwise it is good - that is no CoC and so there is no point. (I did consider asking some large project - KDE for example - to be arbitrator, but I didn't bother)

sequoia 7y ago
I haven't thought about it much and I'm not a project maintainer. As for your bus factor of 1: a) it only matters when there's actually a large group relying on your project and b) the answer is "have multiple maintainers with commit bits." To take a shot at something "more concrete": * New releases will be cut at least on a quarterly schedule * When the number of open issues passes 25, a new maintainer shall be added (if not sooner) * Maintainers may leave a project at any time and are encouraged to do so if they need to move on to other things * Maintainers may return when they have time * Once per year, maintainers shall either reaffirm their desire to continue maintaining the project or step back from maintaining * After 2 merged PRs, a contributor is promoted to a maintainer The main functions here are 1) add clarity to whether anyone is actually maintaining the project & who 2) Clarify that maintaining the project is an ongoing commitment & it's perfectly fine to step back from that 3) Create a mechanism to add maintainers & to signal when new maintainers are needed and 4) Create some general guidelines around releases, so people know what to expect (and know when things are no longer happening). This is certainly not a good governance plan for everyone, some may find it too prescriptive, but it seems like it could be a good start for projects like axios & pipenv. The idea is to prevent "is this project dead" type issues before they arise. When a project is losing maintainers & no one wants to step, it's clear that the project is waning. Of course it's also perfectly reasonable to say "that's too much work" or "f*ck off, it's my project." This convention would help people make more informed decisions when adopting a project for use. Some will be fine with "whatever", some will want a clearer plan, both are OK.
medmunds 7y ago
I’m in a similar situation, maintaining a project that’s used widely enough it should probably have a continuity plan, but not enough that it’s developed a robust community of other contributors who could step in. Jazzband [0] seems meant to address exactly this: “a collaborative community to share the responsibility of maintaining Python-based projects.” And it looked promising, but it’s not entirely clear that the Jazzband project itself is all that active (only news status update is the launch announcement from 2015; last public Twitter activity was in 2017). [0]: https://jazzband.co/ https://jazzband.co/

isthisreality 7y ago

The axios example is an interesting one, because there are tons of people saying they're willing to help, but how many of those people will actually contribute anything without guidance of any kind? When the current maintainers are too busy to even provide guidance, you need to be a special kind of developer to even have a chance of becoming a real maintainer, and those kinds of developers are few and far between.

Reedx 7y ago

Maintenance is something I've come to appreciate more and more every year. It's so easy to install dependencies, but it comes with a large hidden cost and painful lessons down the line.

cogman10 7y ago
Yup. Further, I do a lot more research in the dependencies I bring in (if I can help it). Does this thing also bring in 1000x sub dependencies? How much am I REALLY going to use this. What's the actual added value here. I've seen people bring in libraries for simply the dumbest things. The worst offender I've seen is lombok brought in for a @Logger annotation on one class. That stopped our java 6->8 migration because the version of lombok they brought in was old and for highly used library (so upgrading wasn't simple). If you can write the used functionality in 10 minutes, you should not bring it in as a dependency.
- nitrogen 7y ago
  If you can write the used functionality in 10 minutes, you should not bring it in as a dependency. I disagree with this; it depends on the size of the dependency, plus the risk of a problem with the dependency vs the risk of making a mistake vs the risk of code drift when the same 10-min thing gets written a dozen different ways across an org.
  - nwallin 7y ago
    I think you are dramatically underestimating the cost of a dependency. The dependency may change in surprising ways in the future. The dependency may not change in expected ways in the future. (ie, now you're trapped in an old version of the language, or another one of your dependencies) The problematic part with reinventing the wheel or NIH is that you add a fixed cost of doing business to any given change. The problem with importing the world is that you add a dynamic cost to simply existing without change. It's a tradeoff, and it's not a tradeoff that's consistent across organizations. For some orgs it's really important to be first to market. In other orgs it's important to not break shit for your existing customers. My org is well established in our field. Nothing matters more than retaining our existing customers. Importing a new lib requires approval from legal, which requires about a personweek. In other words, if one developer could implement the same thing in less than 40 hours, the developer should implement it themself. For us, a slow moving org, I think we're at the right place. For a startup, obviously not.