And those tokens could also be extended to other community contributions: answers on StackOverflow, engagement on forums, writing blog posts about Meteor, teaching Meteor in schools, etc.
What you just described is exactly why we aren’t able to invest in a program today that let’s any self-described hobbyist contributor have access to free resources. However, I agree with the need to separate recognition of indiv packages from the authors; this is why we’re focusing on community members themselves and starting with top contributors first vs. bottoms-up and building new operations to audit/rank/track abuse, not to mention any associated technology costs.
This is a very short-sighted view.
Again, you should empower community to manage community. You are not doing that. You (as MDG) are again trying to put managing community and their work on yourself. And then complain how you do not have enough resources. You were talking the same thing about code contributions ('we do not have people to review pull requests", instead of opening repositories to community people with commit bit) and now a similar argument I hear here.
By providing tokens to the community, and maybe a way to move tokens between people, then community can effectively vote (or vouch) for community. Imagine that somebody posts on a forum that they created this new package, but they are a new person in the community. Then maybe somebody else can say, that this is a great package and vouch for them to get access to Galaxy to deploy demos and other stuff.
Again, if you do not have enough resources yourself, then ask community.
That could go even as far as asking for people to pay for packages they care to be able to be hosted on Galaxy.
4 Likes
The most important resource our community invests every day is their time. And we absolutely want to recognize professional developers that have invested their time in making major contributions to Meteor by amplifying their impact, starting with growing a one-to-few program first.
I’m sorry you feel this is disappointing but without full context of all priorities at MDG I suppose it’s understandable. What you suggested seems like a no-brainer/easy solution in isolation but doesn’t really scale when it actually needs to be built, operated, marketed, and maintained. A token-based community recognition and reward system rapidly becomes a standalone startup company - not including the programs elements!
2 Likes
Exactly. So delegate it to the community. You say: we are willing to provide $1000 per month of Galaxy resources to the community. Community, you come up with a system which packages/developers should get a piece of that and in which way.
Again: you are not trusting the community to be capable of doing such things and then it looks to you as something you cannot put on yourself, so you take shortcuts and short-term solutions.
It’s not only about packages, it’s about the huge loss of community resources and implied discouragment in showcasing meteor related work.
And @marktrang, what is your reply to “free, meteor deploy is never going away” from a few months ago?
The credibility hit is really what let’s even me look like a fool as a consultant who eagerly advocated MDGs accountability!
Just provide free, limited open source hosting by providing the deploy from a public github repo url.
I suspect the community would rather spend their time contributing to Meteor through commits, creating great content, organizing events, etc. or simply sharpening their Meteor skills in a professional setting vs. building a SaaS system to attract Galaxy credits. But you’re welcome to prove me wrong - you’re welcome to request access to MDG marketing resources or Galaxy credits if you have a great idea that MDG has overlooked or can’t execute themselves. We work with a network of over 100 official Meteor partner companies worldwide that frequently do this. Feel free to PM me and share your ideas/proposal.
Your suggestion of “just provide free, limited open source hosting” turns out to be really hard/expensive which is why there aren’t many PaaS free forever options available. It’s unfortunate we weren’t able to fulfill our promise and we’ll do our best to identify the community resources that need a free home. The only explanation I have right now is that markets change and we are no different than any other business making tradeoffs. This decision wasn’t easy and actually demonstrates our accountability beyond those currently using the free service or the vocal group here on forums. If it’s technically and financially feasible in the future, we’ll explore it. In the meantime, we’re focused on the needs of professional developers using Galaxy.
If relying on free Meteor hosting is really damaging your reputation as a consultant, I recommend exploring alternative free options as suggested (Heroku + Mongolab) and highlighting all the things we are delivering. Also, I definitely encourage you to become an official Meteor partner if you’re part of an agency or prof services firm.
3 Likes
Let’s do a survey and get data?
A survey of how our community spends their time when contributing to Meteor? Or whether they’d like to join forces with you to build a token/credits-based community rewards program?
A survey of how community would like to see limited resources utilized. In some way, maybe Meteor should engage in participatory budgeting: http://www.participatorybudgeting.org/
So being transparent with limited resources and then asking community for (nonbinding) input into how they would allocate them. As you explained above, we do not know everything, so for us something seems a non-brainer, but maybe there are much harder questions. But there were also good comments in this discussion about if you would have to choose between SQL support and free hosting, people would choose SQL support.
So maybe the survey should be just asking people to rank various things Meteor/MDG can provide and let see what happens. If you get most people rank free hosting as important, you know that this is something people care about over other things. If most people do not care about free hosting, but you find 5 for whom this is the most important stuff, then you know that MDG does not have to provide such free hosting, that community is OK with that, but you can reach to those 5 and ask if they would want to engage in working on something to address the free hosting issue (like tokens mentioned above, just as an example).
What I am trying to say is that nobody really knows what the community wants. We are not doing any systemic approach to really know that. All parts of the community: partners, enterprise users, package developers, hobbyist. So a survey where we could rank various features + gather some information about demographics of community (which part are they from) could be beneficial for everyone. Also, it helps the rest of community see what quiet voices think as well.
I have to speak out a bit in MDG defense here.
First, yes, they went back on their word when they claimed free hosting was here to stay and then it went away. I am disappointed by this just like everyone else. What is interesting to me though is that I never thought to use *.meteor.com as anything other than a package demo. When I was making projects for my own demo, running locally was more than enough! And when I needed to actually put it online and demo, I use digital ocean. I turn it on for the half hour or so I need for a demo (up to a couple of hours) and then turn it off.
I of course am a professional developer working full time with meteor in an enterprise environment. This makes things much much different for me than it does for parts of the community. Ultimately though, that is what MDG (and every other SaaS provider out there) is targeting. Hype among hobbyists and enthusiasts doesn’t actually help MDG or even the meteor platform. I’m sorry, but there are enough hobbyists attached to each and every platform out there that are nothing more than hype. Meteor has, in my opinion, moved beyond hype.
Some points to that end:
- No longer regularly referring to any aspect of meteor platform as “magic”
- Serious attention to the tools that large applications need in order to stay functional.
- Moving away from “flavor of the month” and community driven and moving towards enterprise and customer driven road maps.
Now, a lot of people are going to have issue with my next point, but it needs to be made. Meteor is not a toy. Say it with me now, “Meteor is not a toy.” The MDG is not treating meteor as a toy, and I don’t either. It is a tool. A really freaking fun tool but just a tool! And that is important. What has made the big frameworks of the past work? They have treated enterprise with respect and deference. Getting meteor going at an enterprise level has been hard for us. I live and work in the midwest, and our target market is regional (midwest) so I can’t just throw stuff on AWS or Heroku or Digital Ocean as all of these services are aimed at the coasts. Understandable, but that’s reality. That means that I had to build a deployment solution (prior to the existance of MUP) on bare metal. I built our servers up from scratch. I didn’t have meteor deploy to hold my hand while I did this. I had to really understand meteor to pull this off, even with community documentation. But I have, and my company now has 2 ecommerce applications (previously 3 but we took one down because of lack of traffic) with another one on the way. We have three internal meteor applications running on our own VM stack internally. These are the things I’ve accomplished with meteor. During all of this time I ended up at two sites on *.meteor.com
- viewmodel.meteor.com A site that I honestly recommend people stay away from. It promises to be a powerful bi-directional binding but it really doesn’t handle blaze well at all. You basically have to replace blaze with it, and at that point, I’ll just go back to knockout.
- I don’t even remember the site, but it was some microscope demo which led me to discover meteor a book which was far more helpful than anything on *.meteor.com
Now, at this point, I’ve been rambling quite a bit. The point is, the free tier doesn’t help meteor all that much when targeting professionals and enterprise. Their decision to take it down makes sense. Poorly executed? hell yes! But it is a sensible decision.
To the end of demo sites. I really could care less if meteor worked out demo sites. The reality is that I can easily make a demo package if I see the need. Then anyone can just meteor add lassombra:whatever-demo and when they start their app they’ll find that in addition to whatever they’ve got going on, they have my demo. I could even do some fancy blaze manipulation to make sure that the default boilerplate doesn’t render. I don’t need the free hosting to demo a package, and neither do you (though I appreciate that you have made packages and demos for them).
I don’t believe that MDG owes this community a free tier even for package demos. I will of course not argue with them if they decide to have them, but they do not owe us anything. Yes, the community packages are nice, but honestly, other than routing, they don’t make or break meteor. Meteor is special on it’s own because it does a lot to make developers happy, and I mean professional, full time developers, not community hackers and hobbyists.
I don’t think that the community meteor should be listening to is the one on this forum. I think the community they should be listening to is the one paying for service.[quote=“mitar, post:36, topic:18949”]
What I am trying to say is that nobody really knows what the community wants. We are not doing any systemic approach to really know that. All parts of the community: partners, enterprise users, package developers, hobbyist. So a survey where we could rank various features + gather some information about demographics of community (which part are they from) could be beneficial for everyone. Also, it helps the rest of community see what quiet voices think as well.
[/quote]
The problem with this statement is that it is wrong. Meteor does know what the paying portion of the community wants. They are using systemic approaches to ensure they know what the paying community wants. They are leaving out the forums and the hobbyists.
As a professional developer working full time with meteor, my only criticism is time. Meteor moves very slowly on some things, and very quickly on others. I think they try to get too much into each major release, and as a result major updates and changes are slow to get out. Modules were promised in June, but we were told we would have to wait for 1.3. That has taken forever. It’s frustrating to wait for this, and I hesitate to use community packages that hack this feature in as they are surely going to break in 1.3. And therein lies the problem with community contributions.
@mitar, you are very very vocal, and while I tend to sympathize with most of your points you are a broken record. You are constantly pointing out what meteor is doing wrong (in your mind). You bring the same complaints across multiple threads (Let the community police the community, let the community police the code, let the community run your company) and they are starting to get in the way of productive discussions.
If meteor decides to continue to provide hosting space for package demos, I will take advantage of it, of course. However, if meteor decides not to do so, I will instead turn my attention to making demo packages of my packages, which will be a relatively simple proposition.
4 Likes
This is entirely reasonable position, with one caveat: Meteor hasn’t successfully entered all markets yet. Case in point: education, healthcare, and finance, which have various regulatory burdens.
They’re also leaving out certain segments of professional programers who work in industries where it’s commonplace to have one’s own datacenters, and have no need for hosting services. Private universities, such as where Mitar or Mizzao work, are going to be slow to purchase a Galaxy subscription. But if/when they do, they’ll do it for a Virtual Private Cloud and an enterprise license.
Same with healthcare. Until MDG is ready to sign a HIPAA Business Associate Agreement with clients, there’s a segment of professional programmers who aren’t paying customers, but who are part of the Meteor ecosystem, and who’s only interaction with MDG is through these forums.
So, your overall point is well taken; although there are some caveats.
3 Likes
I appreciate the attention you bring to these areas. I also am “outside” as I put it the group that meteor is listening to. The company I work for has had to figure this meteor stuff out entirely on our own. We haven’t had access to MUP or Galaxy or even Meteor Developer subscriptions, as those are all too new for us. We had things pretty much figured out when those came along. Sure, each one does things a little more perfectly than we did, but our solution works, and will continue to work because it’s a good solution, just a bit more tailored.
So while I agree there are caveats, I would suggest that those caveats don’t change what I’m referring to where meteor needs to focus on enterprise (perhaps expanding to accomodate medical and academia at some point soon). The point is that by listening specifically to the paying customers, meteor is listening to a significant portion, and a relatively representative portion, of the enterprise development world. This means that they can entrench themselves in enterprise, and once they’ve done that, the rest will follow. As far as strategic decisions, they are doing it right, in my opinion. There’s a reason React and Angular are so strong, and it’s not the hobby or niche communities.
Additionally, [quote=“awatson1978, post:38, topic:18949”]
Private universities, such as where Mitar or Mizzao work
[/quote]
I had forgotten this detail and in reading this, I realize that in my original post I made some inferrences to certain people being hobbyists who may or may not be. I also somewhat hinted that people who don’t think like me on this obviously are not professionals, and I’d like to correct that right now. I am sure there are professionals in this community who strongly disagree with me. And I am sure that there are people who look like hobbyists who are professionals, and vice versa. My statement of being a professional was intended to frame my opinion as coming from a particular perspective, and in no way was meant to be against anyone.
Finally, I do think that meteor needs to be more transparent. I am happy with what I see on the roadmap myself, but I’m sure that others are far less happy. I suspect that most “standard enterprise developers” are more in line with my thinking. We are chomping at the bit for Apollo, we are happy to see galaxy. We would love to see galaxy include mongo soon or to see meteor decoupled from mongo (perhaps with Apollo). I know for myself I can’t wait for 1.3 (and have been using the betas at length) because I’ve been wanting proper modules since they were finalized almost 2 years ago. As an enterprise developer, I find that meteor continues to be moving in exactly the direction I want them to, and that makes me happy, and considering their clear market right now is mid-size enterprise and startups, I feel like they are hitting the mark, which is a statement you don’t see much on these boards anymore. Everything seems to be about where they are missing the mark, but I literally can’t agree with these sentiments, and when this thread got derailed into yet another “let the community drive,” I had to speak up.
1 Like
Just to be clear. I am not saying that community should drive at all. But that the community should be part of decision making. What I proposed is to gain more data for everyone involved what is the state of the community (where for me community means everyone including professionals and hobbyist). So, I am saying that there should be more involvement of the community, but not that it should be just community.
I am pointing out that there are hidden community members MDG does not know about. For example, see what happened once community was invited to work on porting Blaze to NPM, it was found out that this has already been done. Not in MDG perfect way, but still, there is some knowledge and experience and work already been added to the mix.
So, what I am saying is that when MDG is planing things and is looking into which resources they have at their disposal, they should also count the community in.
OK so there are a gazillion free apps on Apple’s App Store. Apple has to store these somewhere, and dedicate CPU and bandwidth to manage their transfer, installation and analytics. How can Apple afford to do this? Because they realize that every app is a vote for the iOS ecosystem. The more apps there are, the more reasons there are to own an iOS device. The same is true with Github. Somehow they manage to store and process requests for the codebase of a gazillion open source projects for free. I guess they feel it’s good advertising.
Isn’t it the same true for Meteor/Galaxy? The more package demos there are, the more reasons there are to get started with Meteor (and hopefully host those creations on Galaxy.)
I guess the problem is that MDG just isn’t making enough money from hosting. So that the cost of hosting Meteor apps for free is just not sustainable. But what if cutting funding for the free hosting tier makes the situation worst? You might end up with less reasons for people to get started with Meteor if they can’t easily preview package demos or enjoy the ease with which their app sample apps can be deployed.
The Galaxy sales team aren’t engineers and are business strategists, so it’s probably beyond their resources to come up with any real solutions. What kinds of solutions can the community suggest?
Is there someway for me to “run” an app on the pay-as-you-go service, but force it to spin-down when there has been no activity for 5 minutes, and spin it up again on demand (like the free tier)? That way someone could pay to host their package demo on pay-as-you-go without incurring the full 730 hours per month billing costs if the usage was not very high?
I guess worst comes to worst, people can always download the package demo and run it locally. How about one-click deploy to launch a package demo from one’s own pay-as-you-go container? For example, I visit some page for package X and click to run the demo on my own container. then kill it when I’m done. Could MDG make that as easy as possible for us?
1 Like
except that:
disagree, and those are from this thread. You have similar posts all over this forum, and are even advocating a community fork, which I think is a bad idea.
Now that I agree with. Honestly though that is not the tone of your posts on these subjects. Your posts have been very aggressive to the tone of “let the community drive” and I see far too much sentiment (not just from you) in line with pulling an “io.js” on this framework, and I think that is a huge mistake.
I believe that you are turning into a broken record and asking MDG to basically turn over control of their product to a group of people who will be contributing to it with only their own goals in mind. MDG has painstakingly focused on their actual customers, and hope that by extension their potential customers are supported. I appreciate that, and would like to point out that many of the most successful frameworks are that way (Spring, Zend, Rails, ASP.Net, etc). They all offer the framework for free, and allow you to self host if you want, but they also offer paid services to fund continued development, and continue to develop with their paid users in mind.
3 Likes
???
How those quotes you made disagree with a statement that there should be more community involvement, but of course not that community should have complete control? I am repeating that MDG should try to empower the community, use the community, work with the community. Yes, I do repeat myself. Sadly.
And of course there are trade-offs to be made. And I think MDG is realizing this and is moving in this direction with some great steps recently. And I wanted to point out that here in this particular situation there might be a new opportunity for something like this.
And now I think enough about me, and let’s refocus conversation back to Meteor.
The market requirements you’ve raised are exact the reasons why Meteor/Galaxy can’t be a perfect solution for all markets right out of the gate. Remember, Galaxy has been in market <6 months! Don’t confuse the fact that we don’t immediately ship solutions for all markets as a proof point of our ignorance or lack of understanding of those markets; there’s a fairly good pattern of highly successful companies are those who are willing to say no before they say yes. So rest assured, we are well-aware of the growing popularity of Meteor pros in the life science/health care space and their specific requirements. We know this because we have direct product feedback loops with a substantial number of commercial customers (ranging from startups to large enterprises). But delivering VPC or on-premise support is not trivial, especially when we haven’t even delivered support for Galaxy outside of AWS US-East or a number of other features that solve horizontal needs for big swaths of professional Meteor devs like @lassombra who is a rare breed in this particular forum.
3 Likes
@lassombra Brian, you’re spot on when you conclude “that most “standard enterprise developers” are more in line with my thinking”. Can you PM me so we can chat further about your requirements and expectations?