After a lot of thought and reading on the future state of Meteor (including on this forum), it became obvious that the freemium model may not be serving us all well. Corporate / Enterprise customers have different needs than many of us tech companies / startups / devs who are happy with the ‘classic’ Meteor.
Specifically, the pace of development of Meteor has slowed down dramatically in favor of Apollo.
We have already cloned the main Meteor repo and were able to solve the main struggles we see on the forum, namely DBs:
Replace Mongo with RethinkDB (95% ready some quirks to solve before going to production)
Both of these included the use of Mongo-syntax on server and client-side – so almost straight replacement of collection declaration and you are good to (in #1 above we even got the accounts / password of Meteor to fully use RethinkDB)
We also like (very much) Blaze [i.e. HTML-based templating] AND pub/sub – GraphQL looks great … for someone else (again corporate / enterprise interfacing with many other API’s).
Given the slowness of MDG in pushing in changes to their repos, and their refocusing on Apollo, is it worthwhile at this point for the community to step in or should we just watch it slowly change / whither away.
PS: If you are skeptical about this post, just know that we are actually running Meteor off our own fork already. So this is not pie in the sky. We just can’t support everyone else’s needs on our own. Nothing of course stopping us from keeping pulling from the main repo to include GraphQL and other updates, so we are still in sync with the main direction.
I think this is great, but I’m not sure why it needs to be a fork? Couldn’t these things be made available as part of the “normal” Meteor? Or is this about giving the community more control?
And assuming you did fork Meteor, are you planning on running your own package server? And what about the build tool, would you also be working on that? What about documentation, support, etc.?
I just feel like it’s important to point out that if you fork Meteor, then you become responsible for all these things. Not “the community”.
If MDG allows more community control over its repo, than sure, but it seems they are reticent and community has very little control.
We can publish the repo publicly on github, so it’s no longer us but US (i.e. community). We had to start somewhere, play with it and be comfortable with it.
Buid tool is already part of the main Meteor package, documentation can be ‘Look at main documentation and below are the additional packages’.
As I look at what we are doing, we are slowly removing packages (unmaintained, obsolete), we could have as part of this fork an official router, admin page, db support, and anything extra can be pulled in either from NPM (so technically don’t need a package manager) or you clone a github repo into your packages folder (we can later build a tool for that, but don’t think we need it given how easy it is) … don’t forget that atmosphere is going away soon.
Which part do you need control over to implement this? Is this doable as a package? Does it require major rewrites of large parts of things?
Happy to make this happen, as we said a lot of times before, we’re actively looking for people to take on this kind of work, but not many have stepped up yet.
Personally I think you’ll very rapidly discover that for a community-oriented project, having stuff like an official router inside the same repository is not great. I feel like package systems exist for a reason.
I think putting that router on npm if you really don’t want to use Atmosphere would be a pretty good choice. But there are also a lot of great routers out there already.
Try to add a new package in and ask for a pull and you’ll see. I understand them, they bear responsibility and have other worries as an organization. Also, Blaze has been waiting for access for a while.
Important: This is not a fork AGAINST MDG, not at all. This helps the entire ecosystem. You are still encouraged to deploy on Galaxy and I wouldn’t advocate removing the deploy function from the main meteor binary.
Meteor 1.4 is the last release to include an MDG-published Blaze. Future releases are managed by Mitar, as far as I know. I understand it took a long time, but it’s really happening.
Glad to hear it - if you think it’s better to work together on it rather than fork, I’m all ears about how we could set that up.
Can you prove it works, and that there’s a complete design that considers a reasonable range of edge cases?
We actually were investigating refactoring accounts for other databases already, so if there’s a good plan that sounds great - I’d be happy to take a look.
BTW, I’m not saying you shouldn’t try to maintain your own fork - I’m just saying it’s quite hard work, and it’s a bummer that I’m hearing about this from a forum post, when we’re trying so hard to give more responsibility to the community and not heard much back.
Sorry @sashko, I was under the impression that MDG would like this so they can focus on Apollo.
I would say that there is another aspect. Before a package is pushed onto your repo, it needs to go through extensive testing for edge cases, but for many of us, having a clear warning that some things don’t work well, is good enough as current features many suffice. That slows down things too I am sure. If there is a way to shift responsibility over to package maintainers, maybe that would solve things.
Most of the stuff you’re talking about, with database support, seems 100% like package territory - we could easily move all of the DB adapters and Accounts stuff into a separate repo that’s versioned independently and give people autonomy to work on it.
I’m going to sleep now because it’s 2 am here, but let’s talk more later.
Taking nothing away from @mitar and his accomplishments, one concern I have with the current state of Blaze is that only one person seemed to be in control of Blaze – and it seems to be moving *very slowly over their. This has made me think it might be best to just suck it up and make the move to React.
With all due respect to MDG and in particular@sashko:
MDG is all-in on Apollo, and eventually doesn’t want to maintain or develop Meteor-classic or it’s parts.
Yet you are suggesting there’s *considerable man hours within MDG to allocate to helping @ramez and his team maintain and develop Meteor-classic into the future? That’s really surprising.
@ramez - Have you considered maintaining a release track? It’s like a linux distro; but for Meteor. It’s a half-way step between maintaining a package and a maintaining a fork. We’ve had some pretty good success with it on the Clinical Track:
My concern with a community fork would be the package server. How are you going to coordinate package downloads? We wound up bypassing the Atmosphere server for a lot of things, using git clone commands and custom git manifests (similar to the v0.5 and v0.6 era smart.json file). Are you going to add commands to the meteor tool to support NPM or Git? Going to run your own package server?
Whether or not you want to sponsor the resources for running a package server is probably related to whether it’s a good idea to run a separate fork vs running a release track.
Totally hard work.
Regarding not hearing much back from the community about accepting responsibility for parts of Meteor, could we do a write up on that? Is that simply a matter of the various packages having been broken out into separate repositories and/or published to NPM? I remember hearing about that a version or two ago; circa 1.2.3 or so; but even I’m not clear on what the status of that is. What other steps have been made / are available?
I am surprised at the community. Didn’t realize there were so many free-riders – before anyone hits, that’s a (kinda’) joke!
So I like your idea of splitting out the packages into a separate repo, and we can be part of that. Things like tracker, pub/sub can in the future go there as well.
