Why?

[StorytellerCZ]

I'm utterly confused by the purpose of this repository, so I hope that you can enlighten me. Most of these packages are maintained by MCP and we are desperate for help and are happy to merge and publish on existing namespace. Why then is Quave forking these under your own namespace without any contribution back to the community? Are you specifically adjusting these for Quave purposes which is not compatible with the community version of the packages, or is this just a testing ground or something else?

[alisnic]

I can add my 5 cents as a person that is not affiliated with Quave in any way.

With all due respect and empathy, I think is the main reason is that the pace at which MCP are updated is disappointing. From the outside, it seems that they changes are ready they are in PRs, they are just not being merged for no immediately apparent reason.

Example in case - https://github.com/Meteor-Community-Packages/meteor-collection-hooks/pull/306. The PR is open is from January and still not merged. You have to understand that there is little point that RC Meteor 3 versions are released, when the package ecosystem is not ready for it. I cannot test anything if packages don't install

If you need help with these PRs, maybe being more upfront in the discussions there whould help? I would gladly contribute

Don't get me wrong, I understand it's open source, and I'm not entitled to anything. While it is sad that we have this situation right now, Quave packages allowed me to prepare and test Meteor 3 with maintaining a bunch of forks from open PRs from MCP. Frankly, at the end of the day, I'm grateful that this exists in the open during this transition period. Otherwise a bunch of companies would have to do that themselves many times over

[StorytellerCZ]

Fair point on the not being fast enough. It is partially why I asked the question here, so that I can understand what this is all about. More help at MCP is always wanted, I say that every time I mention MCP and we even have an automated response bot on issues that asks for help.

@alisnic what gave you the impression that we don't need help or that PRs are not welcome at MCP? Is it something in the readmes, comments or other communication? We need to know so that we can fix that misunderstanding.

The reason why most PRs are not merged most often is that the actions and checks are not passing (the one that was mentioned is red as well) and even for those PRs often we have beta releases so that people can get them early if they need them. Sometimes it is just about pinging me or other maintainers to remind us.

[alisnic]

what gave you the impression that we don't need help or that PRs are not welcome at MCP

In the sample of PRs that I was watching it's not immediately obvious if an external contributor can help and how. When things are stalling, I don't feel comfortable pinging and applying pressure to maintainers knowing that they are mainly doing it in their free time. At the same time, I don't feel OK opening another PR myself, being afraid to offend the person that opened the original PR and their effort.

One potential solution to this situation is to be upfront in such PRs and comment something in the lines of - "hey things are stalling/don't have the time/etc. If someone wants to pick this up, here are some starting points for you"

Again, my comment comes from the humblest of places, and the intent was to shed some light into the issue from my perspective.

Writing this, I realize this is more of broad discussion about open source in general and what's the efficient way of collaborating. From my side, I guess I should pitch at my job to allocate budget to sponsorships

[StorytellerCZ]

Asking about the status of a PR is not a bad thing. Sometimes that ping might get things moving on its own. Don't be afraid to ask.

[manueltimita]

@alisnic, I understand where you're coming from. Until the big overhaul that is the migration to v3.0, my organisation has made minimal code contributions to the Meteor community.

Whereas late last year and in 2024 we pushed a multitude of changes to both Meteor Community Packages and Meteor Compat, as well as to packages outside these organisations, communicating with maintainers who, in some cases, have long stopped developing with Meteor.

For some of the packages which we helped migrate, see this post: https://forums.meteor.com/t/looking-for-help-migrating-packages-to-meteor-3-0/60985/29. I had no trouble having those merged.

The point is that few maintainers, if any, will complain if you open a "competing" PR, especially when their own looks like has stalled. Here is an example where a new PR was merged into an existing one that has been waiting for a while: https://github.com/Meteor-Community-Packages/meteor-publish-composite/pull/176.

What I can say for sure is that I rarely felt our PRs are waiting for too long. Some contributions, like the migration of meteor-publish-composite, required a fair amount of back and forth, and all I can say is that we had a good experience communicating with the maintainers.

Now, at no point I remember anyone from Quave asking on the forums where to contribute, or suggesting they have PRs queued up and waiting for reviews. I would honestly ask them the same very thing, why this repo?

[filipenevola]

Hi there,

I understand your concern and the confusion around this repository.

Here's some clarity based on a recent Slack conversation:

We at Quave work with clients who often can't wait for the community package maintenance process. The community is open to our changes, but the release cycles are too slow for our clients and have caused problems in the past.

We are part of the community and want to contribute directly. However, we don't have access to publish updates within community packages, and reviews can take months. We always wait for at least one review, but delays are common.

Our changes meet our clients' specific needs. Pushing these changes without community review might not be suitable. For example, we’ve been adjusting the redis-oplog package, focusing on areas important to our clients.

Our goal is to avoid fragmenting the package ecosystem. With the delay of Meteor 3, our clients need compatible packages urgently. We hope to consolidate our work and align with community efforts later or when our deadlines allow.

If you have problems with specific packages or changes ready to be merged with community packages, let us know.

This is how open-source works: If unhappy or with different needs, you can duplicate the code and proceed (if the license permits). This is common and happens all the time. Nobody is required to use Quave packages. We often make decisions based on client needs, which may not benefit all users. We aim to minimize this and eventually integrate changes more broadly, but we have restrictions and deadlines to meet.

---

This repository isn't just for copies. It includes many Quave-created packages with more to come. Quave uses a mono repo approach, which is why this is a mono repo.

---

To be clear, we have no issues with @StorytellerCZ or any other MCP contributor. The issue is timing. MCP members don't get paid enough (if at all) to work full time, so they have other commitments. That’s understandable.

---

I'd prefer to talk about specific cases. Which features or compatibility versions are you missing? Which packages are your clients or projects waiting on that our copies might help with?