What part of this will suffer if docs.meteor.com becomes an API reference and loses the “concepts” section?
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.
2 Likes
Sorry, I should have been more specific - my mistake!
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.
10 Likes
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:
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.
4 Likes
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.
For me, I’ll just trust MDG right now.
1 Like
Lol you see, if people actually needed blaze that much they would have forked it already.
And then we get people ranting on the forum instead of taking action.
If you think you can fork it and make it better, then do it.
3 Likes
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.
1 Like
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.
If you came in today with a fresh mind, with no prior Meteor experience, would you rather use GraphQL, which is widely praised both inside and outside of the Meteor community and might very well become one of the most important building blocks of web apps, or Meteor’s current homegrown system?
We need to keep in mind that there currently are a lot more of non-Meteor developers than Meteor developers. So it makes perfect sense for MDG to pick the best solution to attract all these developers who aren’t currently using Meteor. Even if that’s not the solution that we, the existing Meteor community, prefer.
In other words, if we truly love Meteor, we need to set it free!
9 Likes
Blaze has been virtually forked by @arunoda and others with extension packages. Arunoda has been the life support for it over the past few years, adding things like caching, props, etc. I think an actual fork would be improper, and would only happen if MDG officially dropped support for Blaze.
5 Likes
@gschmidt Thank you for the thoughtful and detailed reply. I am excited for Meteor’s future with MDG at the wheel. You guys have a great team in place… But as we all know your time is limited and say you are looking to hire/grow the team so the many bottlenecks can be fixed.
My concern comes from knowledge of a handful of very talented Engineers with CS degrees who have applied to MDG and did not even receive an initial interview but instead got an arrogant reply basically saying “Sorry but MDG is looking for top level engineers”… implying these engineers (whom did not receive any kind of interview) are not good enough.
I have not personally applied but have heard these experiences from multiple and independent job seekers. People I believe are amazing developers, who I would be honored to work with and have very innovative and popular Atmosphere packages.
Can I ask that 2016 Q1 your team re-evaluate your hiring workflow. Maybe start accepting more initial phone interviews or possibly evaluate the HR person deciding who gets an initial interview is properly qualified to judge or possibly has set the bar too high? You guys need more engineering manpower and I see you passing up some amazing candidates.
P.S. You need to hire some knowledgable evangelists (brand managers) pronto. All these emotional forum posts communicate to me that the community feels left out and not heard. And on the other side I feel the community does not appreciate you as much as they should. A team of developer evangelists who’s job it bridge the gap between the community and MDG is needed… right now that position (in the eyes of the community) is MIA. This is a cornerstone of any large OSS project.
Thanks again Geoff for the reply.
10 Likes
@benstr I get what you’re saying, and completely understand, but just wanted to add the following: hiring is really, really, really hard. To be honest I’m completely amazed that MDG has managed to hire and more importantly retain the amazing engineers they have. We all know what a competitive market we’re working in, and I can guarantee that attempts to poach MDG employees are happening every minute. I really think the fact that MDG has been such a cohesive unit (with very little employee churn) over the past few years, speaks volumes about how their hiring process has been working out …
1 Like
I would have agreed with you if the stories I heard included an initial interview.
Yes, that’s true 
; maybe that will get better as they grow. I will say though that one particular part of their hiring process that has been working really well, is to watch who’s doing the best work in a certain area they want to get into, then go get them (@Urigo, @martijnwalraven, @tmeasday, etc.). They just have to wait for people who are doing awesome Meteor work to shine, then scoop them up - sounds like hiring nirvana!
1 Like
This, Geoff, is a post that you should kill a tree for, print on that dead tree, frame it and hang it in your office with a label - “Awesome Post”. Even if I do not like the Salesforce strategy 
It is the first time I actually get what the roadmap is for MDG and its business model.
4 Likes
I couldn’t agree more - it’s time to replace the pinned Welcome to the Meteor Forum thread with Meteor: Our Plan, No BS.
5 Likes
Yes, @hwillson I totally agree on that point. MDG has done a great job on acquire-hires. I’m not knocking MDG, I think they are doing amazing things. I am offering a suggestion on hiring from a point of view that Geoff may not be aware of. Bottom line is they need more talented bodies in their office… not so much rock stars… they just need more people producing. But this is typical for any successful startup. I feel for Geoff, he has his work cut out for him. There are HR, management, brand and executive bottlenecks that all need to grow at once.
1 Like
I’m not trying to troll but wouldn’t it be easier to just learn Angular/React/Ember and get on with it? I really don’t see what’s that great about Blaze. It’s better than Backbone but it’s not that great.
[quote="moberegger, post:12, topic:15932"] 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. [/quote]
I agree 100%. I don’t think Meteor has ever had one ‘meteor way’. Certainly not to the extent of Rails or even Ember.
There are simple examples in the docs that sometimes work for production apps but they’re essentially giving you low level pieces to build your own internal ‘framework’.
The upcoming Meteor guides may help solve this.
[quote="sergiotapia, post:2, topic:15932"] NPM support comes to mind, yes it opens the floodgates but it also makes things harder for Meteor devs. [/quote]
Honestly if you break it down… it only affects intermediate Meteor developers who are close minded enough to not learn the greater JS ecosystem.
Devs that want to learn JavaScript already know how or will take the day to learn NPM. Experienced devs will prefer it.
Brand new developers won’t mind doing it because they haven’t learned another way. Eg… no one has an issue with gem install hairball.
8 Likes