Had I started with a plain node.js project, I would have certainly invested more time upfront choosing the technologies that go in to my stack (I’m not saying that MDG has not done this – however, it’s something I should have done personally). Choosing something like Meteor is a choice that basically says, ‘these guys are the experts, I’ll offshore those decisions of what needs to go into my stack’. As my development resources are currently tight, it pains me to continue writing Blaze code. I didn’t anticipate needing a more stable stack like I do now. Sure it will work, but I’m knowingly using dead tech. And if I wrap it in a blaze-to-react integration, then I’m just including both technologies in my initial page load JS, further slowing down my site’s initial load time. I feel caught in a bind, and my gut tells me it isn’t going to get better soon. Maybe I made the mistake of viewing Meteor too much as a silver bullet (I can’t be the only person who viewed Meteor a little too zealously-- your marketing efforts were too good :p). What Meteor looked like when I bought into it looks different from where it is now, and with time that will diverge further. I still believe in the core principles of the Meteor project, maybe just not on how it was delivered.
If the plan was never for Meteor to be so opinionated, why did it start that way? Had you only provided ddp and minimongo, and developers focused on the rest ourselves, we wouldn’t be having the blaze -> react migration discussion. I guess the answer would be ‘to get Meteor to market sooner’ and ‘nothing like blaze existed at the time’, but that came at the expense of a good developer experience. Managing a project as it grows is part of the developer experience.
I guess what I’m saying is that it’s equally likely that whatever technologies you picked that weren’t Meteor could also be changing dramatically. For example, if you had built your app using Angular 1, you’d be in a very similar position when migrating to Angular 2.
I can only speak to my personal experience with Meteor, but when I was initially getting started with it last year, I feel as though if all you got out-of-the-box with Meteor was ddp and minimongo, it would have been tough to sell me on adopting the tech.
Part of what has made Meteor sticky for me (and countless others) is the rapid dev/prototype cycle. Piecing together a boilerplate stack for projects takes time, and while you may ultimately end up with exactly what you want, when swapping elements in and out on a per project basis, you end up cutting into your actual dev time.
Every tech/stack has its pros and cons. I always find it interesting here that in spite of the obvious pros, the cons always end up being at the forefront of discussions…
I’m not sure I agree that the score is a bad choice for ranking packages, I’m just saying it wasn’t necessarily useful to display a timeseries of it over a week for a single package.
All the other metrics would suffer from issues that the synthetic metric aims to ameliorate. Basically all of the examples you quoted wouldn’t be very interesting, the top packages would just always stay at the top even if they weren’t being updated ever (for example IR). Basically the whole site would be the Most Used list.
Have you seen specific issues with the “trending packages” list or the ordering of search results in terms of popularity? I usually feel pretty OK about the order things are presented to me.
I agree here. A quick glance at the install count, 30 seconds on github looking at resolved issues and commits, and I can say with confidence whether a package has been vetted and whether or not it’s being maintained. I honestly don’t think I’ve ever relied too heavily on the actual timeseries score, because of the sorting and metrics I relied on before atmosphere…
Not at all. And that’s exactly the point. Meteor started with the value proposition of providing a perfect developer’s experience. Maintaining a puzzle that’s constantly changing in core areas is the opposite, if you ask me. It wouldn’t if there was a smooth transition path and a considerable “grace period” / long term support for outdated parts of the tech stack, but as far as I can tell MDG is not really keen on this. Just to give you some insight in the feelings of a developer who wants to focus on delivering business value: When I first came in touch with Meteor, I was not very comfortable with the proprietary packaging system it has and wished it would be more integrated in NPM. But now, as I have developed a decent amount of private Meteor packages, the first thing I thought when I heard rumors about switching to NPM was: Hell no, please don’t force me to re-work everything again, as it is in the Blaze case. This might not be true; but that’s the spontaneous feelings I get when I hear about these changes. And at least for me, that’s a clear sign of losing trust in the framework. And no, I am not generally reluctant to learning new tech (on the contrary), but I don’t want to be forced to change fundamental parts of my app in short timeframes.
You’re right. You basically need to define some scoring for sorting purposes and you can’t escape it.
Probably I didn’t state it clearly enough, but what I was referring to is the unusability of the timeseries graph. Maybe displaying a set of different metrics would be a better choice?
First off, I want to give a shout out and thanks to @aldeed, @arunoda, @awatson1978, @samhatoum, @stubailo, @raix and other excellent package developers for all the hard work. Would be great to hear from them on this thread.
I want to reintroduce to the original question: What can MDG do to motivate core package maintainers?
@slava how do we measure aliveness? Good question, take a look at Velocity, Iron Router, Houston Admin, CollectionFS, PowerQueue. These are all very good ideas, great initial implementations and are so far the best-in-class solutions. But notice that they have very few releases this year and, many (serious) issues 1+ years old. From afar it appears that the developers are de-motivated. But I’d like to hear directly from them.
@glasser@debergalis@benjamin and others. The times I have reached out to MDG to point out a catastrophic security failure in a core package, I was met with a resistance (refusal?) of MDG to engage with the package or even message the package maintainer (“I’m afraid there’s nothing we can do as the maintainers of Meteor itself.”). That was personally demotivating, but worse, it made me very concerned for MDG’s approach to building the ecosystem.
I myself am skeptical about contributing code to a for-profit venture-backed company. So, I can definitely see how terrific developers would not be motivated to keep up issue fixes year-over-year.
So I ask MDG again, what can be done to support and motivate package maintainers?
I appreciate your point but have a somewhat different take on it. This came out longer than it probably has to be but TL;DR Meteor is a curated tech stack and is fantastically easier and better than DIY.
If I’m assembling my own stack and evolving it with my business, then I’m spending a bunch of time up front to evaluate different options, and over the life of the product responding reactively to changes in the ecosystem. We’ve all done this. It can be fun/educational but ultimately a waste of time I should be spending to improve my product.
With Meteor, the ground is still shifting beneath my feet – it has to be, to some extent, if I want my stack to evolve. However, instead of having to sort through a dozen different options when a core piece of the system changes, full-time curator/integrators [edit: and an awesome community!!] who are smarter than me and/or care more about the specific aspects of the system are keeping abreast of the broader changes, making concrete recommendations, and providing solutions that work out of the box. And everybody who is using Meteor is trusting them to do a great job of it. Of course they have to earn that trust and work to keep it. They are certainly struggling with trust issues as evidenced by this thread and others like it. But they seem to be adapting to stay on top of the game.
We also don’t have enough data about how MDG will handle issues around deprecation and transition paths. It’s prudent that everybody is raising hell about it so that they know how important this is to the community, but I also feel like there’s a “guilty until proven innocent” tone to a lot of these complaints. I assume that Blaze will still work for quite some time even if it’s not actively developed, as will Meteor packages, and so on.
At any rate, for me the premise remains fantastic and the evolutionary steps welcome. I think there are lots of technical details that may be worth debating. And there are absolutely some communications issues. But “smartly curated” tech stack is what I signed up for, and I believe that’s what I got and am still getting.
That’s certainly true. Maybe this is also a side-effect of fundamental changes in a product that has just reached version 1.2, together with breaking changes in a minor update?
Time changes quickly in the javascript world, Meteor have to keep up. Everybody is talking about react, soon they will talk about angular 2 and perhaps in a year or two we will start coding swift on ios/android/wm/linux etc. without being stuck in dom and cordova - having a proper test suite, debug tools, a stable package system and native performance.
I think the idea of Meteor is good but it feels like focus haven’t been there for some time.
I think that’s basically it - we all like Meteor and don’t want it to change, we want it to be refined, and we were never looking for something that would integrate with every new thing.
I’ve got a great solution for the graph. Just turn it upside down and it will show nice results that people still won’t understand but will be much more happy with.
This is what drew me in too. However, since working with Meteor since 0.4, i’ve came to the conclusion that Meteor gets you started very quickly and then slows you down when maintaining your software. Atrophy has hit a 2yr old Meteor app really hard. I can only fault myself but Meteor doesn’t (currently) help you out any with that.
However, with front-ends like Angular & React becoming first class citizens, maintaining a large app is now much easier. With GraphQL integration coming soon (by Arunoda or MDG), maintaining the data layer will be that much easier to maintain (simple-schema only takes you so far).
If this does happen it’s worth noting a a couple sites like React Parts do just this by gathering up React specific components by convention of a react keyword.
[quote="msavin, post:57, topic:14967"]
I think that's basically it - we all like Meteor and don't want it to change, we want it to be refined, and we were never looking for something that would integrate with every new thing.
[/quote]
I think most of this is because Meteor is a company that wants to be ‘the’ fullstack JS framework that everyone uses. It’s also the largest target audience to monetize from (as opposed to the verticals below).
If it would be polished and not changing with the JS ecosystem (which moves quickly) then they would have to instead target two verticals…
people who want realtime apps and want a one stop shop and can live with the restraints (view, db, scaling)
prototyping apps that are short lived or throw-away experiments to gain business information
