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.
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.
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
Two things. First, if they wanted it or not, theyâve built a framework. They seem to be reversing course and dismantle it to the dismay of many. Second, some in the MDC were/are super productive in the current framework, donât want to see it dismantled, and would like to remove bugs and enhance what we have.
I donât think this is what MDG is saying. Itâs simple, MDG wants to grow Galaxy and Developer Support Services. In order to do this MDG thinks they must grow Meteor. In order to grow Meteor, MDG wants to dismantle the current framework (as fast as they can within the resource limits they have) and instead build a distribution made up of the most popular (and secondarily best) JS tech at any given time.
How viable/feasible do you think a Community-Driven Meteor Fork would be?
Actually, itâs not hard to fork Meteor. Just create some good packages to solve different problems.
But the problem is finding users and maintaining it. So, if you wanna use Blaze, I think itâs not about doing a fork. Just try to improve Blaze or templating, if MDG is not going to do that. Eventually, you (and the team) will take the lead of that development and everyone wins.
Itâs much better starting something now rather than commenting here and there.
Try posting some agenda and user will join and help to fine tune it.
If there is not enough users, either they are with the React move or not trust you guys. If thatâs 1st. Try to do something else. If thatâs 2nd, convince them. Do blog posts. (You canât identify if itâs 1st easily, so follow 2nd)
On the subject of our business plan, and what the VCs want: as MDG CEO, I can speak authoritatively here
They want to see Meteor be used as widely as possible, and eventually become the industry standard for writing the user-facing parts of apps. Theyâre hoping that more and more people will choose JS for their apps (as opposed to, or alongside, ObjC/Swift/Java); they hope that more and more of those people will choose an pre-integrated platform rather than building their own from pieces; and they hope that Meteor will be the standard for that.
They want us to sell commercial products, ideally SaaS services, that are complementary to Meteor and that are so compelling that anyone using Meteor would want them. And they want us to bundle up those services into a variety of packages or plans, targeted at developers just getting started (free), up to comprehensive platform packages with 24/7/15 minute support targeted at the enterprise. We plan to build these offerings piece by piece, with Galaxy as centerpiece or hub. For now, weâre focused on rolling Galaxy out to everyone.
They want us to become more open and work more closely with, and communicate more openly with, the community. (And they want us to balance conversation in forums like this, with 1:1 conversations with top production customers, and with people who arenât using Meteor but should be.)
They want us to focus on professional web developers, and helping to enable them to build the next generation of applications.
We have really great VCs who are in for the long haul and have a lot of open source platform experience. Rod Johnson built Spring. David Skok was instrumental in JBoss. Dan Scholnick was one of the first investors in what became Docker. They get it. Iâve learned a lot from them and I have a lot still left to learn. And they understand that they will get the best return on their investment first and foremost through building a healthy ecosystem and providing value to it.
Weâre really fortunate that, thanks to the support from all of you, weâve been able to attract these particular investors, because there are also a lot of investor out there who donât understand open source app platforms and would push us to monetize aggressively in the enterprise as early as possible.
Happy to answer any questions about any of this or go into it in more detail. We need to be much more transparent about this, not just in conversations with paying customers but with the whole community. It has not been a desire for secrecy, but a perceived lack of time, thatâs prevented us from sharing this kind of information in the past, and thatâs a priority that needs to change for us in 2016.
Question / Concern #1: Meteor Guide, Alternate Stacks, and MDGâs maintenance of parts of the current Meteor stack.
Will the current Meteor become a stack (Blaze, Tracker) be available in the future? The Meteor Guide recommends it.
Will the entire Meteor stack be completely decommissioned (aka handed to the open source community without MDG maintenance)? Pub/Sub, Tracker, DDP? I
Which parts of the current stack can we expect to have support moving forward?
Will the Meteor Guide recommended best practices for different kinds of stacks? Can there be more starter apps that follow the Meteor Guide for a particular stack.
Question #2: Will there be some kind of relational database support directly by MDG soon? I ask this both open ended and specifically regarding the existing stackâreactivity, accounts package, etc.
Question #3: How will Atmosphere (also recommended by the Meteor Guide) play along with NPM packages?
These are one of the most positive statements about Meteor. The goals are consistent to the community and most of Meteor users. The arguments can be resolved under the flag of same goals and principles.
Itâs already happening, to some degree, with the Clinical Meteor release. So far, weâve:
prototyped probably ~20+ apps over the course of its design
included ~30 community packages into distro âcoreâ
developed a guide with 1500+ stars (Meteor Cookbook)
created our own fork of the meteor-tool package
identified and staged 2 dozen community-requested tools in the StarryNight utility, in preparation of migration to the meteor tool
are in the process of developing 3 industry-specific reference apps
have a roadmap with 100+ additional objects that are planned to be added to the API
Theyâve already done this before with D3, which was a major motivation for starting on the Clinical distro. It wasnât the end of the world. Kinda sucked for us; but things are fine now that D3 is back in the Clinical distro. Weâre excited about moving forward and doing a lot more with D3 and the map/reduce/aggregation pipelines.
Has MDG considered to what extent itâs in the Bay Area Echo Chamber? Speaking as someone who organized the NY Meteor Meetup for quite a while, and whoâs now out here on the West Coast, my sense is that the definition of âbestâ that MDG is working with is disproportionately skewed/amplified by the startup / tech industry.
For example⌠React is probably the best technology to create a Facebook or Flipboard style app, or an Angry Birds style game. Lots and lots of Bay Area startups are trying to create such apps.
But there are completely other kinds of webapps out there in the world⌠the one that I and many of my clients are particular interested in is the web kiosk. Think airline check-in terminal. Yeah, you could use React for such a web kiosk; but the fact of the matter is that itâs a fairly old architecture, well understood, and Blaze works perfectly for it. Weâd far rather have the ubiquity of Blaze and be able to pull in the occasional Nurse or Rad Tech to work on a project, than squeeze every last bit of performance optimization out of the UI layer.
Also, if it were true that inclusion into core was simply a JS popularity contest, then D3 with 45K stars would be there instead of React with 34K stars.
The first inkling of Clinical Meteor distro/fork began when I was working at a NFC advertising company, and we had a problem with the account Id generation and integrating our Meteor app with a legacy Mongo database. Instead of complaining, we put together a fully-tested pull-request, and it got shot down. Over $100K of work was eventually scrapped on that project, in large part because we couldnât get that PR accepted. That was the first hint that MDG was going to do itâs own thing, and we couldnât rely on getting mission-critical patches accepted into core as a matter-of-course.
Since then, Iâve been involved in maybe two dozen projects in the healthcare industry, and the following goals are some of the underlying motivations for the work thatâs been going on with the Clinical track:
We want long-term stable releases
We need a slower rate of change; and to be able to âleap-frogâ unstable versions
We have industry specific legal requirements we are obligated to meet (FDA, HIPAA)
We have industry specific standards (HL7) that are informed more by standards committees than the success of any particular company
We need to know that when a critical patch is created (that may likely affects patient care), there is a transparent process to get it accepted into the distro
We need ensure a continued clean API that wonât raise eyebrows during audits or training sessions
Excellent advice. Iâve forked meteor/meteor probably four or five times now, and it got difficult each time. Thereâs a lot of ancillary technology and processes needed to support the fork.
Having clear distro goals, well defined example apps, a suite of packages we wanted to include, a âpracticeâ utility to tinker with, clear legal standards to work with, and funding from clients⌠they were all necessary to get to where Clinical Meteor is today.
Excellent question. The real issue (in my opinion) is the package manager and build pipeline. To the extent that the fork is using Atmosphere and the same version of the isopack/isobuild system; then a release track (aka distro) will suffice, without needing an actual fork.
If people just want to keep Blaze and Tracker and continue developing them, then just release Blaze to the community like D3 was, somebody can take clinical:METEOR as an example, and all they need to do is create blaze:METEOR or react:METEOR or whatever.
If, however, people want to include webpack and rewrite parts of the build pipeline; then things become way more tricky. In that case, they may need to start deploying their own package catalogs and other infrastructure.
This boggles the mind, and on first blush makes it seem like MDG doesnât understand what the most used assets are from the day-to-day programmerâs perspective. On the other hand, if MDG is serious about getting out of the framework business, and is seeing projects like clinical-docs.meteor.com spring up, maybe it makes sense. Maybe this is part of handing things off to the rest of the community.
Exactly. For those people stepping up and willing to manage distros/forks/frameworks, it would really help to have an idea of what the âPlatform APIâ is. Is it simply going to be the command line tools? The package.js format? The ecosystem of environment variables?
Oh. Is that all thatâs being suggested? Then no complaints here. Sort of sounded like the docs.meteor.com site was getting decommissioned.
To use an analogy, I was just trying to say that having a copy of the Chicago Manual of Style doesnât mean an author doesnât still need a copy of the Oxford Unabridged Dictionary.
A community fork can keep Meteor packages from being dissolved by using npm modules. It is convenient to add packages from Meteor app instead of using import inside the source code files. These relations can be complicated.
A ultra stable Meteor and a fast change Meteor are target different developer groups. There.are no reasons to adapt one and exclude another completely. A platform should contain as many kinds of apps as possible.
Hey man, I will pay whatever the price for Galaxy if it means being part of these conversations! I have about 5 consumer apps that I plan to build this year, and more in the next 5 years, and Iâm leaning towards Meteor as my go-to tool, but sometimes itâs not clear whatâs happening and that pushes me away from it. Itâs good to know that there are thoughtful investors behind Meteor, and I hope to hear more from you on what the future of Meteor looks like.
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:
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:
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.
Iâd agree to some extent. Weâve seen splits in other open source projects in the past and⌠I hope it doesnât happen to Meteor.
However, MDG should definitely stay in total charge. Without someone leading the project, it can stagnate. Not because nobody wants to do anything, but because discussions might never come to a solution that satisfies everyone (as is the case right now). I believe in MDG and they know themselves that if they mess up Meteor, there will be no MDG anymore either.
And honestly, Meteor is doing everything that it should be doing. When I first used it, I felt like everyone not using it is behind the times. This is what Meteor promised and it delivered. Currently, the Javascript ecosystem is evolving fast and Iâd rather see Meteor keep up with it rather than stay behind it. Itâs a bit painful but part of the world of Javascript right now.
I agree with everything you say, except for this small distinctionâŚ
Yes, MDG should be in charge. There needs to be an authoritative arbiter; some someone/thing to say, âOkay you do A. And letâs do Z in X way,â someone to keep the ball rolling, and have foresight to make the right decisions despite the publicâs âfleeting passionsâ (shout out to Hamilton, Madison).
Example: Should meteor embrace GraphQL?
Is that going to pay off in the long run? or is it just going to be superseded in a year?
How does that fit in with the rest of the platform?
How would its adoption affect future decisions? ie: Tracker?
Would it lock meteor into a certain path for the future?
Those questions are not simple ones to answer. That is not something where a bunch of random, disparate people on the internet are going to make the best decision on. There has to be someone to make that decision, or else the community is going to end up with 10 different solutions that donât work as well as one Official solution, and 1 or 2 minor community alternatives.
Meteorâs just not in a position to be community lead, but it should be community driven. So when you say, âtotal charge,â that irks me. I know itâs just phrasing⌠semantics⌠yet, words do matter. I want MDG to lead us, but I donât want to mean be towed along in their wake.
lmfao. But it all seriousness, considering how things stand now, that wouldnât be a wise move IMO. If I were into blaze, Iâd certainly want to see how things played out before I made my move.
Exactly the point I made in an earlier comment! A fork is not necessarily a mutiny, a lot depends on the mission statement and its execution. But for the reasons presented by @aadams, it seems a bit premature to go down that path now.
@awatson1978âs âClinical Meteor Trackâ seems to be a good example of agreeing to disagree in harmony. @aadams, does it look like something that could address your concerns? Iâd urge you to strongly consider that possibility before starting a new fork.
But it all seriousness, considering how things stand now, that wouldnât be a wise move IMO. If I were into blaze, Iâd certainly want to see how things played out before I made my move.