Meteor Community-Driven Fork

announce
1

Almost one month ago @gschmidt announce the future of Meteor’s view layer. The fate of Blaze seems to be decided. Blaze will be depreciated and in its place Facebook’s React will be the new rising star for a time.

Of course there’s still a question about truly integrating React with Meteor, and further what this integration mean for Meteor general.

We know that React, and the other tech from Facebook that complements it, like Flux, Redux, Relay, and GraphQL et al function in a fundamentally different way that Meteor today. React specifically is geared more towards a functional style of programming, which is very different way of solving development problems. Further, it seems reasonable to conclude that MDG will integrate tech that complements React into Meteor too at some point.

There seem to be many tradeoffs moving from Blaze to React: better component support, yet more complicated, less accessibility, yet more maintainability, etc. I won’t get into the merit of the arguments for or against here, and I think this thread should refrain likewise.

The bottom line is Meteor as we know it, could drastically and fundamentally change in a way that little resembles what we see today. This means the Meteor we all love and are very productive in today, could be lost.

How viable/feasible do you think a Community-Driven Meteor Fork would be?

Would you fork everything or just Blaze/Tracker to start?

Do you have advice on how to get started, how to organize?

Please share your thoughts and opinion.

Thanks,

Aaron

12 Likes
2

Sometimes I get the feeling that MDG is shifting to doing what’s best for JS developers and not what’s best for Meteor developers. Does that make sense?

NPM support comes to mind, yes it opens the floodgates but it also makes things harder for Meteor devs. Where before I could just reference a package, now with NPM I have to npm install something something who cares then import X from Y and other stuff I don’t really care about. Before it used Just Work™

I’m curious to see what people think about it here.

4

I’m much too green on Meteor internals to comment on that. I don’t know what it would take.

1 Like
5

Why would a community-driven fork be any more successful at accomplishing the goals you have in mind than MDG was with dozens of employees and millions in funding?

People act like MDG suddenly woke up one day and decided to change course for no reason, but the reality is that they tried a strategy for over three years, and it didn’t work so they’re now pivoting to a new, hopefully better one.

11 Likes
6

It is a good solution to have a Community-Driven Fork of Meteor.

This is a B plan when no more new developers are interested in React-based Meteor. It is waste resources: time and money to convert codes of Blaze-based Meteor into React-based Meteor. And there are few tech and business benefits to learn Blaze-base Meteor first and then learn React-based Meteor again. There are fundamental conflicts between two groups. The best way is natural competition instead of extinction of entire Meteor community.

2 Likes
7

Simple, because by definition a community driven fork will have the Meteor Development Community’s (MDC) best interests always at the forefront – not the VCs.

Simple, because a true broad community-driven open-source approach is the great leveler and equalizer that no corporation, with all its $$, can match when critical mass has been reached.

We know MDG has a reason, yet we don’t know what that is because we are not privy to the inner-circle-discussions of MDG and their VCs. And for some at least it seems the course might not be fully aligned with the MDC.

What wasn’t “working”? For whom didn’t it “work” for? MDG’s VCs? We simply do not know MDG’s true strategy, but we do know based on what @gschmidt showed in this graph in his December video, an ever increasing number of new Meteor developers thought something was “working” based on the recent uptake.

So, what do you think about the feasibility of a community driven Meteor fork?

7 Likes
8

This isn’t about VC this is just about better tech stack, better flexibility and more better options to choose :wink: But of course I whish you luck guys :stuck_out_tongue:

5 Likes
10

I’m 100% onboard with MDG’s decision to shift away from the “monolithic platform” approach, and embrace the rest of the JavaScript community more.

That being said, Blaze and the ‘old way’ isn’t gone, and will probably be supported for a long time… but what does a long time exactly mean? Well, I guess a logical point to drop backwards-compatability would be when shifting to a new major version… As in Meteor 2.0? I guess only MDG can say

I don’t find the community-driven approach feasible, and think you should just stick to a specific version of Meteor, or trust in backwards-compatability.

3 Likes
11

Agreed 100%. Sometimes the obvious, surface-level explanation is the right one.

4 Likes
12

I think a fork would cause more confusion. If the main source of friction is not having the “one true Meteor way” anymore or having too many conflating options, I don’t think a fork would solve that; it would just create more options and eliminate the “one true way” anyways.

What I think would be really nice is that if MDG decides to deprecate something (like Blaze), they open up that part of stack to the community. Since they no longer have to officially support it after a certain point, they can be more lenient and take more risks with it. I’m sure there are many people that would love to get their hands on the Blaze project.

5 Likes
13

MDG is a corporation that has a fiduciary responsibility to make a return on investment for their current VCs – they are beholden to them and whatever strategies MDG and their VCs have come up with to make a return.

This is not to say that whatever strategy they’ve come up with is good or bad. But maybe their strategy is not inline with what some think is best for the community for example.

Don’t kid yourself, everything MDG does is about executing a strategy to make a return on investment. Now we just don’t know truly why MDG has decided to gut the current tech and replace it with the Facebook stack. We can speculate, but that’s not what this thread is about.

@juliancwirko, what do you think about the feasibility of a community driven Meteor fork?

Yet, isn’t the surface-level (not the PR level) explanation to grow the Meteor community in order to feed the for-profit Galaxy and Developer Subscription business? Not to build the best tech stack, but to adopt/co-op/embrace the most popular, the FB tech stack, in order to achieve that said goal.

But hey, this thread isn’t about MDG strategy per-say, this is about the feasibility of a Community-Driven Fork of Meteor. What do you think about that @sacha?

Thanks for the feedback @goatic. By the way, I’m curious, why don’t you find the community-driven open-source Meteor approach feasible?

Thanks @moberegger. If/When Meteor switches to become a best-most-popular-JS-distribution the “one true Meteor way” will no longer apply. I mean, MDG opinions on what to use one month to the next could possibly change drastically and turbulently (like the Blaze to React situation). As MDG stops developing core tech and starts adopting the tech of the day, we could all see more confusion than we’re use to.

On the other hand, having a community-driven open-source Meteor fork will allow us to take ownership of the core tech we use and grow it organically. Taking the best from the wider JS community and applying it to core tech internally. We could create the “one true community-driven Meteor way”. Just a though to consider.

1 Like
15

Hi everyone,

Since the post about the view layer strategy, we’ve gotten a ton of feedback. Beyond an incredibly epic forum thread, we’ve had conversations both online and offline, with teams both large and small, about where they’d like to see the view layer go.

The feedback has been super helpful but digesting it has taken some time because there’s just been so much of it. It’s clear that we didn’t get it 100% right in the post, but now I think we have a much better idea of what people like about Blaze and what different groups are thinking about the future of the view layer in their projects. I’m aiming to post today or tomorrow with an update on what we learned and where I think we should go.

Beyond that, I just want to add that I think that forks are a very powerful part of open source and part of why open source platforms so frequently end up being better than proprietary platforms. So I appreciate and value this thread, and welcome the conversation.

Geoff

27 Likes
16

I think it’s not feasible. Meteor’s scope is too large to be handled by a community-driven fork.

2 Likes
17

In my mind, “best” for technology doesn’t mean anything at all. It doesn’t matter what is the “best”, because even that is a subjective measure. We can only look at what is popular among lots of people, and also what is successful in terms of building apps that create impact. Most of what we are doing is in line with what we are hearing from (1) the wider JS community, which is the “popular” aspect, and (2) people building serious Meteor apps in production, who are running into the exact problems we are working on right now.

I wonder what definition of “best” we are working with here.

Anyway, I urge you to consider what your specific goals are. Is it:

  1. You don’t want your development platform to change over time
  2. You want to keep using Blaze specifically
  3. You want a Meteor that accepts every PR from the community just to see where it goes
  4. You want a Meteor that optimizes solely for your own development needs and people similar to you

Perhaps there is a different reason, but it would be interesting to hear.

10 Likes
18

I couldn’t agree more. I included “best” in the sentence you quoted simply because everyone takes it as gospel that MDG is aiming for best and I don’t want to get into a flame war here. The bottom line is, in order to appeal to the most (for reasons I stated in above posts), you have to incorporate what most are using off the shelf – today the tech is weighted heavily in favor of the Facebook stack.

On topic, this is about the feasibility of a Community Fork of Meteor.

1 Like
19

Feasibility mostly depends on how motivated people would be to work on it, and I bet that depends on the mission statement/motivation, especially of the person proposing the project.

20

I think that for the reason that a community-driven fork is even a thought would be the very reason that it would likely fail: attachment issues.

Of course, every individual, group, team, etc. is going to have an agenda, and MDG is no different. And as users of the fruits of their labor, in a sense we have to trust that they are making decisions based on an agenda that is in the best interests of the user base. We don’t pay for meteor, there’s no contract, etc., so it’s really in good faith that things are operating here…

But back to the topic: I will be the first to admit that I love blaze and will continue to love it for prototyping, but familiarity isn’t a valid argument for keeping a tech. And ultimately, the “community-forked” version of meteor will be confronted with similar issues. Be it the view layer, node implementation, deployment strategies, or any of the other topic churns we see here. And it will again be a question of agenda and arguments will arise about familiarity versus progress.

A project of this size needs a team. Teams are composed of individuals with different ideas about agendas, and compromise is a necessity. I just don’t think that a community-driven fork of meteor will have a team that is able to compromise on these exact topics…

5 Likes
21

I don’t think you would need to create a community driven fork of Meteor. If the issue is that there are people out there that want to use Blaze, then it’s simple… separate Blaze into it’s own project / package and allow community development on that.

But, I personally don’t think it should be officially supported. In terms of the platform itself, Meteor has other places that need improvement over which view layer to support. The view layer is arguably one of the easiest parts to swap out from the entire stack.

I figured it should be almost as simple as:

  1. Remove React-based packages
  2. Add Blaze View layer
  3. Add X package to integrate with newer changes to Meteor
5 Likes
23

Meteor isn’t just about who is using it now. It’s about who MDG brings into the community. I was sold on Meteor and if they keep moving toward integration, the. It would have been an even easier sale. People with legacy systems are rightfully concerned but I don’t think early adopters should start bailing ship. The same thinking lead Angular off track, and even Node faced similar challenges only to find the deserters coming back online. I’d say chill and trust that Meteor can be better but not if early adopters won’t let it grow. It would surely be a death blow. If you have out grown Meteor, that’s fine but no need to champion others to switch and no need to predict meteor’s demise. Losing blaze is not a big setback to those who switched to meteor because it supports react.

1 Like
25

Tracker should also be it’s own package. It hasn’t been changed much since Meteor has been around. It does its job well and doesn’t need changes to work with Blaze.

I still don’t think these two libraries make it so you need an entire fork of Meteor.