It seems like it should be possible to scrape the atmosphere description pages for url’s that link to .meteor.com sites and then keep all that sites for projects that have over x many downloads in the last year? Or something like that?
(I feel safe in suggesting that as I have none of the skills actually required to achieve it…)
Edit: I appreciate that won’t save all that should be saved, but it might save some important stuff that otherwise would be missed.
I have two demo-sites with corresponding GitHub repository
Phone layout demo using Meteor + Framework7 + React + TrackerReact + Webpack
Nobody in the MDG thought about all the demo sites linked to the meteor packages? Really?
@poliuk there are two MDG members confirming that this will be taken care of at the very top of this thread. 
…we’re definitely open to doing this. In fact, we’re putting together a
program to recognize and support top technical content contributions
(e.g. tutorials, docs) from the community. Can you please help us
identify more of these must-have resources that currently exist on
meteor.com hosting?
forums.meteor.com
but maybe that one can go
The only thing this thread really illustrates is a premature management decision. Hurting both community engagement and credibility.
Maybe it’s time now to put this decision on hold?
Going out now to scrape community pages to save them for reference. Madness.
I think MDG has severely underestimated the role of *.meteor.com demos and documentation in promoting and generating excitement about Meteor. Once this is taken down, essentially a lot of the documentation of community packages will disappear and I don’t think the ramifications were well considered.
It’s like the one-child policy in China: aimed at population control, but created side-effects of an elderly society with too few young to take care of their two parents and four grandparents, and many “little emperor” members of society that are very self-centered due to having no siblings.
Slack has resulted in wide adoption by providing a free tier that allows a critical mass of core users bring in the rest of the organization and justify paying for a higher tier. Let’s hope this decision doesn’t cause huge repercussions around the Meteor community by destroying the excited base of developers that feeds into the paid services.
@brajt Yes, to reaffirm our commitment to the community, we’ve already been working on a program (unannounced) that recognizes top community members who have a track record of publishing great content (e.g. tutorials, demos). This program will include top package contributors and offer limited Galaxy hosting for package-related demos. Unfortunately we cannot offer free hosting for demos of any public package (there are 10,000+ packages on Atmosphere!). Instead, we’ll use a combination of criteria (e.g. author activity, popularity/usage trends, peer nominations) to identify a subset of top packages and make sure their demos have a new home on Galaxy.
@marktrang: Hm, what about each developer can get some tokens and then they can or delegate those tokens to projects they care about, or use for their packages. What I worry is that you will create a form of inefficient central government deciding who can host demos for free, instead of having a way for authors of packages decide what they prefer and care about. So maybe they want to create something new, which is not yet visible to people. How could they direct resources towards this?
So the question is not just how to handle current top packages, but how to handle future ones?
@marktrang it sounds like that policy will make it really hard for new (but potentially good) packages to gain traction because they won’t have any demo space allocated to them. I don’t think that each of the 10,000 packages will create a demo site, either. The hosting load would definitely be orders of magnitude lower than it is now.
@mitar just simultaneously mentioned the same concern.
As I mentioned, it won’t be purely a quantitative process; there will be a peer nomination element to how emerging demos will receive a hosting subsidy.
See above response to @mitar. We’ve already considered the option you suggested. If we made Galaxy publicly available for any package author like *meteor.com hosting today, the administrative burden alone to regularly audit “appropriate use of Galaxy to support a Meteor package” usage makes it unfeasible. It isn’t just about the raw underlying infrastructure costs. As we’re a small company, our team’s limited time and focus is as important as the hosting costs. Instead, we’re focusing our limited programs resources on a smaller set of top professional contributors.
No, it could be in fact very simple. Every package author gets credits for use of Galaxy for one instance per package on Atmosphere. No need to check if they are really using that instance for a package. You can also see it in some way as them contributing to the ecosystem and getting something back for this. If they want to instead use those credits for some other thing on Galaxy, this is also OK, they are contributing with packages.
Then the only question is how you decide what counts as a package on Atmosphere. Probably just registration could be misused too much. But having for example a sum of stars on GitHub, commutative downloads, downloads in last month, maybe even visits on the Atmosphere page.
What I am saying is that in my opinion it is important to separate tokens for packages from packages themselves, so that authors can use them in the way they see best. Maybe they have 5 active packages, but only 1 one of those needs multiple sites: demo, documentation, some background instance to support package releases, and so on.
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.
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!
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.