@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.
@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 …
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!
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.
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.
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.
Yeah, this whole conversation started because it was going to be such a hassle to refactor components to React…now we are talking about a full on fork of Meteor
(It’s obviously more complex than that but still a bit of truth there)
I agree with @benstr here - I’ve heard such stories as well. Rejecting a candidate is one thing, doing it respectfully and professionally, is another. I also agree with @hwillson that it is really, really hard to find the right people for the long run. Even the most talented people can be a pain and even the most fun people can be unproductive.
GraphQL isn’t designed for real-time. Meteor’s solution is. GraphQL can be overkill for some apps–REST can do the job just fine.
GraphQL is home grown too. Also, this notion that a multi-billion dollar company is behind something has little merit. Google has killed countless projects. Just because its backed by a giant doesn’t it (or the giant itself) won’t fall. FB earns revenues in a manner less sustainable than Google or Apple. I don’t use FB, like ever. No problem. Its a huge time sink with little return. On the other hand, not using Google services would be a challenge for me; because it is often better and very useful. Apple too offer the best choice for a set of actual problems.
I believe Meteor should split its projects into a series of approachable open-source projects. One reason its solutions are overlook is because they are all so tightly bundled together. In one sense, the tight coupling has earned Meteor a lot of stars for a single repository; yet another result is that it is unapproachable. For example, the meteor-tool should be its own forkable thing on Github so I can use all standard Meteor stuff with my own modified meteor-tool if I want.
@gschmidt Mr Schmidt, Thank you for taking time out to engage the community.
This thread was meant as a way to gauge the mood for a fork of Meteor. Based on the feedback so far I think most believe a fork of Meteor at this point doesn’t have the community support it will need to be maintained and more importantly be successful.
Having said this, an idea seemed to surface over and over, and it resonated we me as well. A near future in which both Blaze and Tracker become first class citizens in this new Meteor era. Where both Blaze and Tracker become stand-alone fully open-source projects supported and driven, however so much, by the community. Where both Blaze and Tracker will available for install via NPM and used seamlessly just as is the plan for React.
It is my firm belief that this action will benefit long-time, heavy invested MDC members and keep Meteor as accessible as it is today for all sizes of developers.
It is my hope @gschmidt, that you will take this proposal into current consideration and announce a plan of action in this regard.
Thank you for building what has become an amazing framework that I enjoy using every day.
Thank you for sharing this. We always strive to give a thoughtful and candid response to anyone who takes the time to apply for a job at MDG. There are a lot of reasons, but at the end of the day the most important one is it’s just the right thing to do. And yet we can always do better and need to keep working at it every day.
Thank you @gschmidt for laying out the bus plan so clearly. Some of it was expected, but a couple of points are interesting.
Here are some thoughts for you based on your plan. I do see some things you are doing that are aligned, but I also see some misalignments.
This means Meteor will have to be less opinionated. Blaze is a good templating engine, but you will have to support others (support does not mean supersede). Angular, React and more as they come along. This is where community comes into play. You shouldn’t have to support everything. Same for DB’s (SQL is a must, you may build it internally, or have it outsourced). Which means you need a clear coding guidelines document and maybe some boilerplates.
It also means you have to accept pull-requests into your repos and encourage community packages. Again … same point as before, letting go
How about a committee that represents the community? Forums are great, but a debate may mean more focused brainpower. It also means there are more touch points for the community, and less touch points for you to handle.
Professional web developers and App developers are not the same thing. Web developers use Twig, PHPTemplate (i.e. Blaze-like templating engines) while App developers use Obj-C / Cordova / Java (also, App developers are more likely to use React). This statement also means a clearer App workflow is needed.
Thanks again @gschmidt, look forward to more great progress on the best full-stack platform.
PS: Why not look at the Acquia - Drupal model? Acquia is the foremost Drupal agency and Drupal is the open source project. The founder of Drupal is the (co?) owner of Acquia and manages both with clear separation of projects.
I suppose it comes down to whether or not a Community Based Fork can stay focused. MDG failed last year by letting atmosphere slip into dead-ended Meteor blasted fractions. As a side note: this is THE definition of a meteor: when a meteor enters the atmosphere it for 99% evaporates to dust. So, nobody can say that we have not been warned
Seriously: If the Fork can be a complete starter-ready development environment: simple in its core and with a librarys of “preferred” add ons to focus the developers, it could very well succeed. However, this comes down to “the board” deciding what’s in and what’s out and a team of “hero’s” - real strong dev’s that are highly regarded.
I think it is even in the interest of MDG to let the code flow more freely. Looking at Geoff’s worried face during his late 2015 presentations, MDG is clearly pressured in a certain direction. MDG seems to aim to make money with hosting, support, service, training but most certainly not with the code itself. For MDG to succeed, they need lots of clients with lots of traffic, questions and problems. While for the Fork to succeed we need a clear landing spot, size and gravity.
Guys, not to hijack this tread but I think there is much better to address the issue here rather forking. And I believe in there are multiple correct ways to build a great app.
But, there is no one way we can satisfy all. That’s why we need to start working on application architectures for Meteor.
We’ve already working on one called Mantra. It’s based on modern React to build future proof Meteor apps. You could unit test every part of your app.
And we need few more, specially for the people who like to use template(Blaze/Vue) based app development.
And this is something golden for Meteor (and for MDG). There will be focus groups inside Meteor work on these app architectures while collaborating together for some areas.
There will be more apps. More jobs. More hosting/service opportunities for MDG. And more customers for Kadira
Everyone wins.
Interesting and tempting to follow. However, not given the unfortunate 2015 decisions of MDG that leads to this mess, but given the way these decisions came up, it seems certain unpredictable deviations will happen again.
How do you control Mantra knowing that MDG is zig-zagging ?
Thanks for taking the initiative. Not sure we need a formal architecture for Apps. The proposed one is simply a collection of FB packages (granted with some solid thinking built-in). In real-life, many of us are constrained by what technology to use (DB’s, login mechanisms etc.), and the different coding styles. For one, I know we would unlikely use React due to the lack of separation of display / logic. It’s not because FB is doing it that it’s right (at least not for everyone). Regardless, your framework could be one of many within Meteor ecosystem.
I would recommend we keep this thread focused on talking big picture.
; 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 (
