Meteor Community-Driven Fork

announce
26

Thank you @gschmidt for acknowledging some of the frustration in the community. As a CEO of a similarly sized high-growth startup to another, I feel your challenges.

First, you need to to make money, and you need to make it fast. Understood. Guess what, we WANT you to make money. A platform needs a good custodian. See below for how I think you should make money (and BTW, telling us how you plan on making money, makes us trust you more – and help you).

Second, what is your strength? Is it code, is it JS … I believe it’s the community that you built and the goodwill of all of us. That is what will make you profitable. This means you need to consciously let go. The community will support you naturally. By letting go I mean the ‘We did not come to this decision lightly’ messages. It’s not your decision. Sorry to bring it to you. It’s the community’s. The bigger and the stronger we are, the happier (and richer you are).

Third, MDG is facing a challenge of indie / startup vs enterprise. Needs are different. Enterprise wants security, SQL, integrations and so on. But startups (who want simple / fast) keep you going, challenge you and your team, and quite often, help you pay the bills. Dropping Blaze is telling startups, ‘we are going corporate’, thanks for being here for the ride (and BTW, corporate will only adopt you once you have full stack of integrations AND solid security).

Lastly, I don’t think a fork is going to be all that hard (we are all conscious that a large portion of the latest round of funding is for bus dev – not technical dev). And I do think it will be detrimental to MDG and maybe to Meteor. We shouldn’t be fighting internally. We should be a happy family (ffmpeg suffered for a long time because of infighting).

Back to making money. You left a lot on the table and it should not be the community that picks it up. So many people out there selling Meteor courses and services, why is Modulus even in your space! You are playing catch up.

  1. Consulting services – you started, good … now accelerate this. Including, migration: help us migrate from Drupal and Wordpress
  2. Training services, videos, etc.
  3. Hosting, load balancing, etc. – accelerate this (we for one don’t want to spin up a VM, we WANT to use Galaxy - the new pricing model makes sense)
  4. Analytics and reporting
  5. Testing and debugging – why is an external dev doing this on your behalf?
  6. CMS – you NEED one to compete with Ghost and Wordpress – then you branch into themes, customizations etc.
  7. Integrations (e.g. with CRM’s and other third-party including Microsoft, IBM, AWS, Oracle etc.) – there HAS to be a way to sell paid packages / solutions to enterprise, or maybe support packages
5 Likes
27

but, I was so excited about an answer? :smiley:

29

I think most understand, that almost by definition, the feasibility depends on how motivated people will be to work on the fork. I think we can get a hint from the number of PR on Blaze and the like for example.

And of course as the community grows, in theory so should the number of contributors.

I’d like to get a feel for the mood towards a project like this. And if the mood is right, talk about the next steps.

I’m not sure a project like this will need a dedicated development team per-say. It might need a community-team of some sort or way and some process for PR approvals. A community-team for setting goals (short and long term), agendas, strategies.

But how does anything in this world get accomplished if not by some reasonable process where differences in opinion get sorted out? Just because people are of different opinions, does not mean we cannot come together to accomplish something larger than ourselves.

I understand. But what about long term, when Tracker is depreciated, when fundamental components of the system are depreciated? What about when Meteor has changed so fundamentally and drastically to accommodate the Facebook stack, that it is simply unattainable to maintain the link?

But we could go back and forth with this. I don’t want to get into if it’s right or wrong to fork, I’m only asking the feasibility of a community driven Meteor fork.

No one has suggested this. The community-driven Meteor fork will be supported by the community, not necessarily MDG. That is not to say they will not have a hand in fork in some way, either by contributions or compatibility, with Galaxy for example.

Blaze is just the start, this is change in strategy that will change everything about Meteor. I think there could be another way. We grow the Meteor packages organically, incorporating new ideas from the outside JS community. But looking at Blaze in isolation, yes, as a community I think we want to keep it going, make it bug free and as feature rich as possible along with Tracker.

Thanks for the feedback @ramez, do you have any suggestions/advice on how to get started?

30

If you really want to do something like this, I’d suggest starting small - for example, fork only Blaze and Tracker, and see how it goes. If step 1 of the project is forking meteor/meteor, I think things are going to get very difficult very fast.

7 Likes
31

I consider what makes Meteor unique – IOW, who is it uniquely for? Is it for a team of 1 hacker-extraordinaire? Or is it for multi-department, cross-disciplinary groups the size of Facebook, Google, Apple and SAP? It can’t be equally good for both, and I think Meteor was originally designed for the former.

But if those are the two poles, somewhere in the spectrum there is a sweet spot. The sweet spot is a team of 2-6 people that includes a focused designer and developers with a variable amount of overlap – separation of model, view and controller layers and clean connection between them to enable efficient small team dynamics, fast, flexible prototyping that can be quickly purposed for production. These are the teams that typically compose successful startups – the ones that go on to create great products and become the next big thing. Because 1 person is usually too few, and 50 are too many to execute on a new, simple, awesome product idea and develop it with top-notch UX and deliver performance to delight users.

If ReactJS works well for Facebook, it may be because they have crap loads of $$$ and legions of developers to manage a complex, multi-tiered framework. Human resources are no issue for a company the size of Facebook. They can get tons of the best and brightest to make up their own HR stack with loose connection between the technology parts. At large, wealthy companies inefficiencies are compensated for with people. But this approach is not realistic for small teams – which probably accounts for 90%+ of the population of software teams in existence. There are only a handful of teams with the kind of resources of Facebook, and they have already chosen a development framework that does NOT include Meteor.

In choosing ReactJS, Meteor may be feeling financial pressures and grooming itself to appeal to Facebook in hopes of an acquisition. But I think Meteor’s best path to becoming the framework of a company as successful as Facebook is to appeal to the sweet spot now. That is something they have not even done really well yet.

I am wistfully wishing that MDG would focus itself on the sweet spot and not cave just yet. This is my viewpoint as a full-stack designer.

3 Likes
32

Looks like people have already considered it: https://github.com/MeteorCommunity/discussions/issues/44 :smile:

How divergent would the fork be? Looking at the number of open PRs and issues, as of today MDG doesn’t seem to be making the most of the community as a whole, in terms of code contribution. I think that should be the first thing to be solved! Splitting the community through a fork might make it even worse. Well, actually it depends on the answer to my question. In general, if the fork’s goal is to keep in sync with the upstream, that might even be a solution to the community participation problem – that would be a way to prove to the upstream maintainers that those PRs do make sense!

I personally feel it’s too soon to go for a fork, at least for the reasons you mentioned. As of today they’re mere speculations. My suggestion is to decide based on more concrete facts – code commits and definite announcements from MDG related to the “new view layer” (and not some vague high level idea like in that monster thread), that will actually tell you the real direction taken by the framework and/or its components (err parts ;))

That will help you decide the scope of the fork better (maybe only a couple of packages need to be forked!), which in turn will help you to agree on a definite roadmap of the fork, hopefully with other like-minded people. And that, will truly help you determine the feasibility, which is so very dependent on who all you can find to commit to the idea!

2 Likes
33

Blaze and React are two different patterns to develop web apps. Blaze allows to split functions of designers and programmers. React mixed UI and logic design. Designers have strong skills of HTML and CSS but weak skills in JavaScript programming. Designers are hard to work on React pattern.

6 Likes
34

Actually, canceling the whole stack (no more blaze, no more tracker, no more pub/sub…) is not making it grow.

During the first years of Meteor, people were making fun of other developers asking how to embed Angular in Meteor. The joke was “you want to drive a Porsche in a Mercedes”. I didn’t make any sense at the time, it still doesn’t today.

No more Blaze, no more Tracker, no more pub/sub, Meteor has just cancelled the development of their JS Framework but won’t sayt it clearly.

It’s their call to make, and they don’t owe us anything. But don’t pretend their are “growing” the technology when all they intend to grow are the potential customers of their hosting solution.

7 Likes
35

Thanks for your feedback @vjau. 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?

36

From a distance it seems that Meteor aims to be the best way to build a Javascript app. A tool to pull in the assets you want for you Javascript app for client, server, or both. It not their intention to be to be a framework.

With Blaze, Tracker, pub/sub, etc. Meteor was straight trailblazing. It was brilliant but the wider Javascript community saw it as an all or nothing thing. It seemed like an independent stack made to work with specific components not a platform to build a Javascript app.

To be fair, I liked that stack just fine. Unfortunately a small team can’t compete with the world; and they don’t want to. It’s would be a difficult decision if it is indeed that decision. I imagine that the current Meteor will exist in the new Meteor as a stack choice of many. They’re just saying that they can’t maintain all of the pieces of that stack while building out a really amazing platform. So rather than form the platform the community might be wise to support their favorite parts of the existing stack (or all of it). After all Vue and RiotJS don’t have a corporation backing them so it is feasible for Blaze to be backed by the community that loves it.

So what’s the conflict?

3 Likes
37

Hit the nail on the head. meteor lost its identity it seems sry phone

2 Likes
38

I do miss how much more opinionated the Meteor “framework” used to be. When you make opinions, it let’s you do some really cool things (like donejs), even if the end result looks like garbage to some people (like donejs) :wink: .

1 Like
39

We’re going to publicize it more soon, but what do you think of the Meteor Guide, a completely opinionated official take on Meteor?

1 Like
40

Testing

@sashko Yes please. I can only test so much with ChimpJS.

I’ve also started working on a CLI tool for generating Meteor projects, so hopefully I’ll be able to use this guide to improve the decisions I am making for that project (called Space Kitty, still a WIP).

1 Like
41

That’s one of the main goals! Very excited to have a consistent set of generators, tutorials, videos, packages, etc etc.

I don’t think the way to achieve “opinionated” is to lock out other options… you just need to write down some opinions. So that’s what we have done.

42

Agreed, but it is nice to have documentation or baked in features that state “this is how we do this here.” Developers can always do things their own way.

I think Laravel for PHP is a good example of how to enforce opinions. Taylor Otwell took PHP, slapped some opinions on top of it and made it really easy to create applications around these opinions. If you didn’t like some of the opinions he added (like Elixir as a build tool), you didn’t have to use it, but Elixir was baked-in to your project from the start.

43

Yes, the plan is to de-emphasize docs.meteor.com, which will become just a low-level API reference, in favor of the Meteor Guide, which is an opinionated application-focused resource.

3 Likes
44

This isn’t a bad idea… it could go really well. Node.js vs io.js comes to mind. If I am understanding the history correctly, io.js was a very popular fork, and its success basically forced Joyent to push responsibility of the node.js codebase to an open source foundation. I wasn’t following that drama too closely, but I understand that there is fairly universal agreement that it has been a hugely beneficial move for node.

Alternatively, a fork could just fizzle and die or worse lead to confusion.

@aadams from watching the forums, it certainly seems that most of the meteor heartache stems from the impending deprecation of blaze. What do you think about forking blaze (and/or other packages that may be retired) to make sure they stay alive in future? Or even moving it to an NPM package so that it could be used with generic node projects? Just thinking out loud here. It might be a stupid idea.

[quote=“aadams, post:7, topic:15932”][quote=“sacha, post:5, topic:15932”]
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?
[/quote]
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.
[/quote]

I see what you are saying, but I would be careful with this line of reasoning. For example, politicians (for the most part) have the best interest of the citizens in mind. But they have wildly different philosophies on WHAT is best. Point being, because someone or some group claims to have the best interest of another group in mind, it simply does not follow that they will make better decisions. Intentions count for something, but not much in the tyranny of the masses.

All in all, pretty interesting idea. Not sold either way, but I wouldn’t ignore it if someone did it.

2 Likes
45

Sorry, but if MDG says that React is better than blaze, so be it, i won’t write Blaze code anymore.
I doubt very much that a Meteor fork would be sucessful, as some have said there are two many agendas which are not compatible.

2 Likes
46

now that is not a stupid idea, and a direction I’d assume it would take anyways, so blaze is at the same level of react, angular, polymer etc which are sourced from npm. then from there it can be maintained in a node js community style fashion, and can be used in apps with a distribution like meteor or other integration stacks, builders and bundlers

1 Like