That’s unworkable. If MDG ran it, then the money they receive from ‘donations’ would be viewed as income. Meaning, they would have to pay taxes on it before the developer even sees it. If they hire a FTE, then well you just lost more money due to benefits.
Now there’s nothing to say that MDG can’t suggest capable individual(s) to the community who the crowdsourcing project should contract. They just can’t have their hand on the money.
It still gets you what you want, it’s just a framework.
I think The issue here is whether we can get an “official” statement saying we are okay with so & so working on this & that they will actively “guide” that endeavour with the promise of accepting the pull requests.
Which payment gateway the individual dev/s will use is just trivial. There are tons of them.
Good point, I agree.
This is certainly a true fact.
That should satisfy all concerns from your OP and could be done in a few short days.
Plenty of someone else’s cash!
I think this is the core issue here - MDG needs to guide people to understand what the priorities are, and allocate a certain amount of time to only reviewing and guiding community contributions. Right now we don’t have that time allocation but we’re actively working on figuring out how to budget a significant chunk of time for this.
But to be clear, that unfortunately doesn’t translate into unlimited engineering resources.
The mythical man month and other classics 
I think it needs to be as simple as someone stepping up and saying “I’ll do X if Y people pay $Z for this period of time,” and if it sounds good we’ll do it. Or, if someone is willing to take a risk, just do it and sell it.
The problem for most community driven and community payed developments is to find the right price. As I took from other communities I am working with, this is often something what split the groups.
If someone say I do it for 2K and the next does it for 1K what is the right procedure? Should workload be defined by hours of effort or as all-in price? I am pretty sure that everyone here in that forum have its own (hourly) price - coming up from everybody’s needs.
It would be very difficult IMHO to coordinate something like this in matter of transparency, fairness, quality, expectations, commitment …
“MDG would supervise the funding process because ultimately they would need to supervise the development process”
…which is not cost free either - technically or adminstratively - which rather begs the question
Commercially and technically MDG are being rational wrt Blaze. Its great for prototyping and brilliant for new coders…until it isn’t…but joining the great FE framework race brings little ROCE and much risk.
More tellingly, it’s open source anyway - so if the community saw the benefit, it would be helping drive it,. Or no? I think the crux here is that not enough agencies/companies are on board with the stack, for their teams to contribute back
-addendum. Having just seen vue.js, I think there no real cause for concern. Some great choices available for front end
If it were to be crowdsourced and Blaze brought up to par, what then? We then need Blaze Native. We then need maintenance. We then need Blaze Android. You have to repeat the whole shebang every few months as technology evolves.
And all the efforts should not be destroyed by MDG changing directions. And there is the biggest issue with this kind of things. MDG can throw away the investment the community makes. That’s what is not going to work out here. Better is that MDG iterates on it’s own. You see the same with packages now which become incompatible.
@waldgeist Yep, this is the first thing that came to my mind. If I recall from previous blog posts, MDG has received multiple millions of dollars to build Meteor so it would be interesting to know how community funding would work alongside commercial interests. Personally, I’d like to see this work funded from the VC - but there must be reasons why that is not already happening.
Using something like Patreon would be potentially helpful. A community member could make quite a bit releasing things based on what the community wants. It could be an alternative monetization strategy to something like @msavin’s meteor.toys if it is not the type of package that is appropriate for licensing.
I think at the level of partitioning being suggested, at a certain point, the question becomes why does Meteor, not just MDG, need to be at the center of the platform at all? If we’re using different templateing, different model, different motif… why not just use feather.js or MEAN or any other approach?
My point here isn’t to say that this is a good idea, but to bring the discussion back to what started it, which is that many of us simply liked the core technologies that got us excited about meteor, and it’s frustrating to see them get cast aside. Frankly, if I have free time in an upcoming project, I might very well move away from meteor, because if they’re asking me to learn angular now to keep up with the trend, then I might as well invest a bit more time and detach myself from the meteor framework all together.
I haven’t been keeping up with this thread (final exams week), so excuse me if I’m bringing up things that have already been said. It strikes me that everyone was perfectly happy to finance MDG through paying entry-level prices for galaxy, so this whole alternative financing approach seems a bit ad hoc, when the real issue that catalyzed this entire phase of outcry was when galaxy dropped. Most people just want to pay for a reliable product.
As a personal opinion, managing community development is a well-intentioned nightmare for making something production-ready.
TL;DR if Meteor begins to deviate any further from the plug-and-play ease that got me interested in it in the first place, the “full stack solution” becomes moot.