Time for a Meteor Collective for community packages?


#1

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?


Maintenance for Meteor packages
#2

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.


#3

This sounds a lot like Apache. I think it would be nice.


#4

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.


#5

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.


#6

There was an effort once long ago along these lines: https://atmospherejs.com/mrt


#7

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”.


#8

Reading this topic, so far we have two packages:

  • fast-render
  • flow-router

Are there more? I know Iron-Router had the same issue; but are there people still using that?

Also, is it even worth the trouble, now we can use npm, and everyone seems to be moving to a react based eco-system?


#9

@robfallows, ahh, you’re right of course. I was thinking of the effort long ago to bring in old forks of 3rd party libraries: https://github.com/MeteorPackaging.


#10

I’d totally forgotten about that initiative.


#11

Would love to see tap:i18n on the list. This package is nearly unmaintained and still recommended as the go-to solution for i18n in the Meteor guide.

Plus:

  • blaze-layout
  • fourseven:scss
  • raix:push
  • mup

Not all of them are unmaintained, but quite vital.


#12

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.


#13

Another package that comes to my mind is autoform from aldeed. He isn’t answering in opened issues since a while. Maybe he is out of time to do so.


#14

Great idea! Some packages that are pretty useful to me and almost abandoned:

Didn’t find any alternative or fork worth migrating to.


#15

This PR reminded me of this thread:

Another important but small part of the Meteor ecosystem that is no longer maintained.

Is there still interest in doing this?