3 ms·

Building your own thing is great, but one unintended consequence is that if your thing actually becomes popular, you'll be expected to maintain it forever. If y

by ericyd 2y ago

Building your own thing is great, but one unintended consequence is that if your thing actually becomes popular, you'll be expected to maintain it forever. If your interests or preferred tech stack change, you are stuck with a mountain of your own tech debt. Chances are no one will ever rescue you. For juniors who barely even know that their own preferences are, much less their long term career goals, this can be a serious downside. When I was just starting, I had a side project that got reasonably popular but I never expected to be maintaining it years later, and it became a serious mental burden. I think the author is correct that you know you're doing it right when it feels like a chore, but it is kind of a bummer if a junior gets sucked into this maintenance burden without understanding the consequences. As a more senior developer, I think long and hard before seriously committing to a new open source project, and ask myself if I want to be maintaining it in several years before I write a line of code.

supernikio2 2y ago
Doesn't the very nature of open-source mean you can just abandon it and have someone else take up the torch when you're done maintaining it?
- ericyd 2y ago
  Absolutely, but it does feel bad when you know your negligence is impacting real people.
  - krab 2y ago
    If they really need it, they'll fork it.
cjpearson 2y ago
This is a good point and thanks for sharing. I would add that in my experience the bar for "reasonably popular" is much lower than people would typically expect. One or two issues a month may not be much if you're actively using and maintaining the project, but it can easily become a burden if you've moved on from the project. You either spend a few hours a month keeping it up to date, or feel like you're letting someone down. There isn't really a good solution to escape. Someone may submit patches on their own or offer to take over maintenance, but I'm not willing to ship code that I haven't reviewed or tested and would not risk transferring it to someone unknown. (We've seen what can happen there.) Deleting the project is an option, but that also negatively impacts existing users in a drastic way. The best approach I think is to clearly indicate that the project is no longer maintained and suggest creating a fork if they need to make changes.
rikroots 2y ago
It's not just the code base that needs to be maintained. I'm about to do a big release for my (not at all popular) JS canvas library and I've spent the best part of a week just updating the documentation surrounding the library: it is mind-numbing boredom, and far more (non-?) technical debt than I ever wanted to deal with. But I have to do it - it's like a "pride" thing now; I'd feel ashamed of myself if I did a breaking release and left the surrounding documentation to rot.

by ericyd 2y ago

supernikio2 2y ago

Doesn't the very nature of open-source mean you can just abandon it and have someone else take up the torch when you're done maintaining it?

ericyd 2y ago
Absolutely, but it does feel bad when you know your negligence is impacting real people.
- krab 2y ago
  If they really need it, they'll fork it.

cjpearson 2y ago

This is a good point and thanks for sharing. I would add that in my experience the bar for "reasonably popular" is much lower than people would typically expect. One or two issues a month may not be much if you're actively using and maintaining the project, but it can easily become a burden if you've moved on from the project. You either spend a few hours a month keeping it up to date, or feel like you're letting someone down. There isn't really a good solution to escape. Someone may submit patches on their own or offer to take over maintenance, but I'm not willing to ship code that I haven't reviewed or tested and would not risk transferring it to someone unknown. (We've seen what can happen there.) Deleting the project is an option, but that also negatively impacts existing users in a drastic way. The best approach I think is to clearly indicate that the project is no longer maintained and suggest creating a fork if they need to make changes.

rikroots 2y ago

It's not just the code base that needs to be maintained. I'm about to do a big release for my (not at all popular) JS canvas library and I've spent the best part of a week just updating the documentation surrounding the library: it is mind-numbing boredom, and far more (non-?) technical debt than I ever wanted to deal with. But I have to do it - it's like a "pride" thing now; I'd feel ashamed of myself if I did a breaking release and left the surrounding documentation to rot.