It seems like there are many great but unmaintained or splintered packages out there.
Sometimes I want patches from both.
I used to be part of the Plone CMS community and they put together a collective to own community packages which helps important packages from becoming unmaintained.
Seems like it instead of all of us maintaining our own forks of each package it would be great to have a “Meteor Collective” that would own and maintain various packages of interest to the community.
For example fast-render. There’s two forks that have several bug fixes I’d love to have.
Anyone else think this is a good idea?
What other packages would be great to be adopted by the community at large?
I love this idea!
The real question is, who has the time to manage the community?
I would gladly make the occasional PR, and help with some initial forking and merging, but that’s all I would have time for.
This sounds good because there are plenty of old unmaintained packages with forks that have patches or new features. The same problem with unmaintained packages would happen with a community-owned collective of packages though: Who owns the collective? What happens when they’re gone? How does access or control get passed along when owners change?
MDG has made it clear that they want more things owned by the community instead of them, so I don’t see MDG realistically taking ownership of a big collection of packages. There are only a few people who work on the Meteor codebase full time as it is. But without their ownerships or at least part-ownership, I think it would eventually lose traction and become unmaintained like anything else.
I think this is a cool idea, but like @efrancis said, there is the problem of ownership.
I see this coming into play perfectly in the veliovgroup maintained version of flow-router, where they chose to implement some of the data layer strategies from iron router. I’d say there would likely be a heated debate if there were multiple maintainers working on that project about including those features, and those debates take time and resources, that may be better spent on a personal fork.
Not to say there couldn’t be multiple, maintained forks of a repo like that, each with different goals. I do think there are at least a dozen or so packages in use by a lot of us that could benefit from more consistent updates, ones that come from different sources to help address different issues.
I’m as much a perpetrator of the developer’s optimism as the next, and would love to see something like this get traction, but I think the value proposition has to be very clear and understandable to get people on board.
I may be wrong, but I think was when meteorite packages were migrated to atmosphere. If the author of a meteorite package could not be identified it was set to a generic “mrt”.
OK so just some random musing: I find the major issue is package abandonment or just being too busy to ever review (and merge) anything.
So the role of the Collective would be to have ownership of the package repository (but not the code itself) and to ensure that, given community interest, there are competent and responsive maintainers for that package.
If a package becomes stale there is a process for transition.
I can anticipate that “competent” is a subjective term that it could be gnarly but I also believe that people can get together and hash things out.
I went ahead and snagged a meteor-collective organization in github. This could serve as the umbrella. I did notice that someone already has the Meteor organization collective so maybe there’s a better name that could be used.