The recent discussion about Blaze as well as about testing has the community arguing vociferously with each other about the best way for MDG to use its limited resources. What is interesting to note is that the fundamental issue is really about the best way to split up a limited size pie, not about the technologies in question (no one seems to think that testing should not be well supported, nor that it wouldn’t be nice to have both Blaze and React as options.)
So, instead of fighting over a too small pie, why not try to figure out how to make the pie bigger?
To that end, I propose the idea of “line item, community-based funding” for certain aspects of Meteor core development. Let’s imagine that every six months to a year, there are a set of “core” projects (specific enhancements to Blaze, specific testing enhancements) that MDG cannot support with its current resources but which MDG could implement using short-term employees if they were funded by the community. Then, the community has a limited time to “pledge” money toward whichever development projects they are passionate about.
I pay $10/month for Spotify. I just paid $29 for the Meteor Testing Book, primarily in hopes that it would help fund improved testing support. I pay nothing for Meteor. I could easily see myself “pledging” $100/year if I knew it would yield significantly better testing capabilities. If there were 999 other individuals like myself, that would yield $100K, seemingly enough to fund a skilled Meteor dev for a year or so to work almost exclusively on testing. If we take into account corporate funding, getting to the $100K level might take only a few hundred individuals.
The React vs. Blaze controversy is even more amenable to this approach. There appear to be a substantial number of developers with significant sunk costs into Blaze. It’s way cheaper for them to finance maintenance and simple upgrades to Blaze than to convert to React. Let’s say maintaining Blaze requires a .5 FTE developer; let’s say that’s roughly $75K. I do not think that would be difficult to raise from the community.
It would be cool to have some sort of online application that would support the development of projects, cost estimation, community voting, and funding pledges. It would be nice if one could pledge but only have their credit card charged if the goal was met. MDG would supervise the funding process because ultimately they would need to supervise the development process, and they would need to cost out each proposal.
Note that this has a positive feedback effect: if the community can guide and fund development of core features of interest to themselves, it will increase the size of the community. A bigger community creates more donors for the next round of enhancements.
Line-item funding has advantages over traditional “subscription” models, where you pay some money but don’t have control over where it goes.
Finally, it changes the nature of some discussions on the forum. Instead of complaining about or lobbying to change MDG’s strategic decisions, the community can instead focus on how it can generate additional resources to support technologies it finds important.
Philip
