Meteor Community-Driven Fork

[rozzzly]

This thread has a lot of overlap with one from last week, MDG as two separate organisations - would it be good idea?

I definitely suggest reading that thread..

I think forking meteor would be beyond counterproductive. Especially now amid all this uncertainty, fragmenting the meteor community could be catastrophic.

The aforementioned thread discusses the possibility of MDG devoting itself to meteor as a platform and having that seperate from the team focusing on meteor as a PaaS, Galaxy. There I make the following point:

@rozzzly

MDG doesn’t get paid directly for advancing Meteor as platform. Their success is dependant on Galaxy’s usage, which is in turn depends on the web’s/business community’s perception of meteor’s worthiness for adoption. That concept might seem superfluous/silly, but it is a profound distinction.

What’s best for MDG isn’t always whats best for Meteor.

That’s just the way it is.

I’m glad to see that several other people (looking at you @aadams ;P) here are cognisant of the reality of MDG’s motivations. That being said, I think a community fork is the same sentiment, just on the other end of the spectrum. Really the question in both of these threads is, who should be in charge?

 MDG              ???           Community
  !________________!________________!
                   ^
                  /_\

Can’t we find a happy medium? Here’s my proposal:

@rozzzly

[…] I think MDG should deliberately, explicitly get the community involved in planning the road map. My suggestion:

a. break down design choices/into specific chunks that need to be addressed, design questions we need an answer to e.g. Blaze, Modules, Bundling/Lazy Loading, data(what do we do about tracker, mergebox, etc? adopt GraphQL? ditch hard dependency on mongo? AnyDB? {two dozen other suggestions}?

b. have community vote on solution, this does not have to be 100% democratic, but I think more people considering a problem results in a better solution.IMO the most important part is having a explicitly structured presentation of suggested approaches, have OP’s main post/whathaveyou summarize proposals, have literal poll widget (maybe reddit style rankings)

c. have community vote on priority. Do we get on LTS before we address GraphQL? Can we all agree that Blaze2 should come after we figure out {INSERT HURDLE}? Let’s rank them. collaborate on a road map

TL;DR

• Community fork is bad idea, too likely to fizzle out
• We shouldn’t rely on MDG or any other entity to be the sole decision makers. But, we still need that group, a group to be actively working of meteor, organizing collaboration, and making the final decisions
• MDG should democratize meteor’s roadmap.

---

And please don’t mistake my sentiment: MDG isn’t tyrannical-far from it, nor would a mutiny be a good idea. But some things ought to change.