I think all the Meteor community needs urgent feedback from Tiny about where Meteor is going to go in the future. Most of us spent the past years on this platform and understand what directions Tiny will take is fundamental to understand if we’ll keep investing on Meteor or not.
This is very important for all of us.
I don’t think it’s urgent. I would suggest for them to take their time and plan properly. They just took over. Furthermore, they stated that it’s in their intention to continue and improve the Meteor ecosystem, so that’s good enough for now.
In my opinion, it is a pressing issue. There are at least 2 strategic directions that Meteor could take in the future:
Improve the original concept of Meteor with mini mongo and DDP making building applications fun and easy. In this case, a monolith approach is probably necessary at least for the back-end.
The point is that Meteor original competitive advantage was simplicity, hiding all the complexity needed to config and deploy a Nodejs/REST project. It was a Ruby on Rails on steroids, less flexible but much more simple and powerful for projects that needed live-update capabilities. Like Rails, Meteor failed to be adopted by the big enterprise for obvious reasons, but it is perfect for small and medium companies and mid-range applications in general—even in the big enterprise.
Now, the Meteor community suffered during the years but its initial adoption was amazing. What we need to know is if Tiny is going to take option #1 or option #2 — maybe there’s a third option, but I can’t figure it out right now.
Well, I think we should give them a bit more time. Of course, I am also caring for the future direction of Meteor, having built my most recent startup (partly) on top of it. But I am confident the acquisition was in favour of Meteor as a whole.
I think the answer to your specific question is going to be both, at least it has been. You can still whip together a Meteor pre-1.2-style app using Minimongo, DDP, LiveQuery etc. and then there is meteor create --minimal that gives you a minimal starting point with pretty much endless possibilities. And Vulcan of course is built on top of Meteor as it is.
Exactly, I believe that’s why many people took issue with @sacha article because it required the next step to go all in on one of the two ways to use Meteor. Matter of fact, they share a lot in common and Meteor doesn’t have to discard the needs of one of them to satisfy the other.
I think that no matter what the plan is moving forward, Tiny should make a highly publicized announcement of what it is. The sooner that happens the better ( i think we all agree on that )
But we should give them the time they need to get things in order and to come up with their own vision. Then once that vision is articulated to the community we should help them to see it through. I think in the end that is how we will end up with the best framework possible. We need strong leadership from them to help instill confidence in Meteor and then we should be willing to support them in their efforts to make their plan a reality
An announcement would be really helpful. I’m sure Tiny had some ideas or plans when buying Meteor, so sharing even a basic outline of their future plans would be nice. Even just a timeline of when they’ll have a timeline.
Tiny barely acquired Meteor, and Ben’s told us he’s still working on 1.8.2 and 1.9, which means there already is a short term plan, which is good. Tiny now must reach out to the community more and more widely in the coming weeks / months to have further discussion with us developpers about what could be prioritized. And that takes times.
Beside, I agree a large scale, even early, communication from Tiny about the acquiring of Meteor would be beneficial to draw a wider attention asap.
@massimosgrelli : both options are not excludind one another. Actually, what’s really interesting is to have both and keep the possibility for us developpers to move the cursor as we need.
Great ! There are two points that I think are essential.
The first is to know the strategic vision of Tiny to know how to guide our work.
The second is to know what is the business model on which Tiny will build the development of Meteor.
From there, personally, and I think I’m not the only one, I’ll make arrangements to continue or, at worst, move to another direction (refactor?) if I consider that I do not share that vision or if I think that the chosen development model is not viable.
The main idea is to keep improving things and we don’t see any reason for breaking changes in the next releases.
See that 1.9.0 is already under development, 1.8.2 was just released last week.
So far the business model is keep generating revenue with Galaxy, we want to introduce new features on it and we are going to do this based on community / clients feedback. Premium support for Galaxy and for Meteor applications in general is also in our plans.