[trboyden]

I can't help but think this is self-inflicted. If we really are to apply the spirit of open-source, wouldn't the community-pro action here be to open the project up to additional maintainers to pick up the slack and delegate out the work? Isn't that how popular projects grow? And when they do get really big, isn't that the time they should be transitioned to an organization like Apache or Canonical to manage the day-to-day management efforts of a large project?

I think the idea that a founder of a project is responsible to maintain it into infinity and beyond is missing the whole point of open-sourcing code. That founder is putting unfounded pressure on themselves rather than letting the project grow and evolve in an organic way. Much like a helicopter-parent that micro-manages their children's lives, rather than letting them make mistakes, learn, and mature into independent adults.

Obviously, there are a number of open-source project methods for handling this, forking being a common one that the community itself can apply. But I would think it would be beneficial to the project community to have an honest discussion about it an entertain offers to take the project over rather than breaking the community spirit of contribution that is core to the ideals of open-source programming. If there comes a time when no one is willing to step up, the community and more importantly repository providers, should offer a way to put a project into maintenance mode, and allow someone to come along and take over maintenance of code that has the time and willingness to do so.

This comment is not an effort to criticize the founders of the mentioned projects, but an open-ended question to the community at-large to ponder and reflect upon how we manage and grow the spirit of open-source, while taking care of the maintainers/contributors that help keep it going.

[alkonaut]

> spirit of open-source

> whole point of open-sourcing code

I don't think there is a single "spirit" or that open source in any way must necessarily include any collaboration at all. Perhaps a maintainer/project owner feels the work of even approaching other maintainers or delegating even a single unit of work to be unwanted. It's their choice. Putting code on github isn't an automatic invitation for contribution or collaboration, it's merely making it public. Top reasons I put code on github (I can't know, but I think this is pretty common):

1) To make it searchable and readable by others 2) To use the issue management tools (usually by myself, as TODOs) 3) To make what's built from the code usable by others who can build it themselves or download binaries. 4) To back up the code 5) To use CI tools 6) To get feedback like bug reports from users 7) As a portfolio

[bovermyer]

My Iron Arachne projects are open source and closed to contributions.

They're closed to contributions because they're my personal projects. They serve a very specific purpose - my playground, my mental space.

But they're open source, because if others are curious about how they were built, I don't mind if they want to see the source.

[trboyden]

I think that is totally fine! Especially if it is organized that way from the start.

But as soon as you allow contributions, is the project really yours anymore? Is it fair to the community that has contributed to your project, all of a sudden to be locked out from it, and forced to fork it to continue it's evolution? Why not hand it over to the community and start your own fork for personal development? I think that is the larger debate to be had.

[bovermyer]

In my case, I've never allowed contributions to the current iteration (which has a completely new code base), so that question doesn't apply.

For others, though... I don't see a reason why forking a project would be a bad thing. Yes, it fragments the community, but it also means different ideas can be tested and implemented by the people that care about them.

[bgpl10]

There aren't enough competent people around, and even fewer who prefer the same workflow as the original author.

What really happens if you open up the code base: Mediocre people who want something for their resume flock to it, work on unimportant issues, add bloat, CoCs and generally make your life hell.

[trboyden]

I believe that is anti-community in spirit and non-conductive to solving the issue you claim exists. Many developers breath of knowledge extends only to that they have experience with personally. Maybe they joined the project because they want to learn something which you can only do by diving in, making mistakes, and learning as you gain experience. How many developers that could evolve into great developers have been stunted because someone denied them the opportunity to become competent? Once you open something up to contributors, it becomes everyone's responsibility to learn how to work together effectively and productively and changes should be discussed and adopted based on what is best for everyone. I am certain it would be possible to establish mentorship and technical review committees that can both ensure the quality of the end product and encourage growth in the particular specialty area the project addresses.

[johnr2]

> How many developers that could evolve into great developers have been stunted because someone denied them the opportunity to become competent?

Nobody is denying anyone. The code is there to read as an example. If an aspiring developer hasn't got the initiative to develop at least a basic level of competence on their own, that's their problem. What happened to self-reliance?

[clellan]

I think your reply makes he same mistakes as some popular ideologies in the last century. They look good on paper, but fail to acknowledge reality and human nature.

If you think mentorship and technical review committees can solve anything: They cannot. People who are warming the chairs in those committees never do any actual work on the issue trackers and try to bully the real workers.

[johnr2]

> I believe that is anti-community in spirit and non-conductive to solving the issue you claim exists.

You presumably haven't encountered this issue with your own open-source projects, but that doesn't mean the problem doesn't exist.

[loup-vaillant]

> If we really are to apply the spirit of open-source, wouldn't the community-pro action here be to open the project up to additional maintainers to pick up the slack and delegate out the work?

That requires people the original maintainer can trust. They have to be competent enough, honest enough, easy enough to work with, and the maintainer has to know that.

Moreover, many project shouldn't grow big to begin with. Sometimes much of their value comes from their small size: they're easier to learn, easier to deploy, easier to port, and most of all easier to maintain.