As discussed in the community Slack, @mitar is willing to distribute funds from the Blaze OpenCollective and get things moving as he said before but we need your help guys.
5 Likes
I like @jkuester idea of giving the money into a bounty program for Blaze, but I also think that people who have made contributions to Blaze in the past few years should get something out of the pot.
2 Likes
I don’t mind either decisions as long we get new ownership/maintainers of Blaze OpenCollective so current funds can be made useful and further consolidate Blaze future.
I compiled a very basic list of recent community members who are either current contributors to Blaze/Blaze-related packages or are about to undertake serious work like @znewsham Blaze Standalone. You can comment whom you also think should be on this list and I’ll add them in, so we can later decide who gets what.
can you please pin this thread @robfallows ?
1 Like
There is 1,093.83 USD in Blaze OpenCollective.
2 Likes
Right now, We have two goals.
First, add people who are already involved with Blaze. Everybody can help with this, please comment any contributor you see fit and I’ll add them to list.
Second, for those on the list if they think they would appreciate getting something, write the amount you would like. So, for those currently on the list:
cc @zodern @jkuester @znewsham @pouyae @dr.dimitru @matteodem @arggh
Any remaining amounts will be set as bounties for future work.
4 Likes
Thank you for bringing this into my attention.
I see next options:
- Bidding on open tasks;
- Have base hourly rate (my guess something between 45-65$/h should be fare), then estimate tasks in hours;
- Distribute funds according to % of contributions;
How to estimate tasks in $$$
- Bidding per task
- Estimate in hours with hourly rate
- Distribute funds between contributors based on %
0 voters
2 Likes
I’m honoured to be on this list, but I donate 100% of my share for future work & improvements to be done 
3 Likes
Thank you @arggh
I’d like to clarify that there hasn’t been much progress since we’re currently awaiting an action from @mitar.
He wanted the community to decide on the matter without no interference, but I let him know that the community has already decided according to @dr.dimitru poll.
A considerable amount of the contributors I listed in the google sheet didn’t respond so it’s reasonable to assume they want nothing out of the current pot. And as the poll states the community would like to have bidding moving forward so it’s all set, I guess.
Last interaction I had with him was between 16-18 of March but I haven’t heard from him since.
It occurs to me that while I voted, I never actually responded to this - I also don’t want anything from the current pot. My only concern with continuing the work of moving Blaze to NPM is that it requires some of the other core packages to be moved over too - there are already two other un-maintained versions of these sets of packages in NPM that work in different ways. We should probably decide how we want to do things.
My personal opinion is that meteor should create the @meteor namespace within NPM, and move/replicate the packages that could be standaloned there, and then maintain them (tracker, random, ejson, etc)
2 Likes
@jkuester and I working on migrating some of those underling packages as commented here and once it’s done migrating to the @meteor namespace wouldn’t be much of a problem.
1 Like
This is excellent! How are you handling package global’s and exports? So long as these things get tied to a meteor namespace eventually, I think this is fine - I resisted doing the same as you as there are already two other sets of these packages that are unmaintained, I didn’t want to add to the noise :(.
I can probably put together a comprehensive list of the packages that blaze (compiler and runtime) require - I’m happy to help with the migration effort, as long as they do eventually go into a meteor namespace - otherwise they’re indistinguishable from the other out of date packages that exist.
This is excellent! How are you handling package global’s and exports? So long as these things get tied to a meteor namespace eventually, I think this is fine - I resisted doing the same as you as there are already two other sets of these packages that are unmaintained, I didn’t want to add to the noise :(.
We started with the lowest common denominator being Tracker and start working our way up, so we’re not reliant upon any Meteor package and thus manage imports/exports just like you would do in any NPM package. I hope understood your question correctly. 
As for the noise part, I mean people can check the code and decide for themselves what to use, it’s how things are and there’s nothing wrong with that.
I can probably put together a comprehensive list of the packages that blaze (compiler and runtime) require - I’m happy to help with the migration effort, as long as they do eventually go into a meteor namespace - otherwise they’re indistinguishable from the other out of date packages that exist.
We welcome all helping efforts that the community can offer. We’ll be surely to eventually ask for them to be included under @meteor namespace but we shouldn’t wait for that namepsace to be around to start working too. It’s about making sure everything is running smoothly and backwards/meteor compatible then the migration step will come naturally as the standalone version becomes production worthy.
2 Likes
In an ideal world the packages can be used inside a Meteor app as well as a Plain node app. If you have something to Test please try them and open an issue on anything that is not working
3 Likes