Governance

[StorytellerCZ]

Now, since now we have operated in a bit of an anarchic way. But I think if we want to keep this going, get more direction and handle money (there are already people/organizations interested in donating to the cause).
I would like to discuss how to manage the organization going forward and to sustain it in the long term from the point of view of governance.

Also looking for people who would like to step up and volunteer to do a bit more.

PS: Don't expect any radical changes soon, but feel free to include your ultimate vision and what steps to take to get there.

[mitar]

For Blaze, we have: https://opencollective.com/blaze But have never used what we collected. But I think it might be a good way to collect donations and disperse then.

[StorytellerCZ]

So my ultimate vision would be an organization that works closely with Tiny (or what ever the new Meteor company is going to be named) on events and other relevant stuff, but mostly focusing on community packages and supporting community efforts (be them part of Meteor core or not).

From the matter of governance we already have confusion about decision making and hence taking responsibility (be it from admitting new packages, making decisions on new releases, etc.).

So I roughly envision the following structure:

Each package/repository or collection of them (ie. hooks team) would consist of maintainers that can be added or removed (will have to have clear rules so that it isn't abused). Once a year all the maintainers vote on a chief maintainer that would have the ultimate decision making power when there is a dispute or uncertainty about stuff like releases, etc. Where possible a vote should be called by the maintainers to resolve issue. Most of the time though I expect things to be very loose.
The important point is that the Chief Maintainer would become a the representative of the project for contact purposes and would become a member on a council (or something along those lines).

This council would have all the Chief Maintainers and heads of additional committees outside of the technical sphere (like newsletters and podcasts initiatives). The council would then vote additional members of the council to handle extra roles for the organization (like treasurer, president, vice-presidents, etc.). Any member of the organization could stand for these extra roles and in some cases people from outside the organization (for non-technical positions for example).

For handling finances we should probably use Open Collective and distribute on the following basis:

1. Payment for technical needs (hosting, CI, etc.)
2. Org related stuff (for example marketing)
3. Live events (One can dream right 😆 )
4. Donations to individual developers (bug bounties, reward programs, etc.) <= as much as I would like to pay devs for their contribution it is really hard to figure out system that would be "fair".

[sebakerckhof]

Donations to individual developers (bug bounties, reward programs, etc.) <= as much as I would like to pay devs for their contribution it is really hard to figure out system that would be "fair".

I would leave this out. It's going to be very difficult to get any meaningful reward program at the rate most of us work, while complicating matters, adding friction and points of discussion. Of course people are free to contact individual developers for bounties on specific bugs themselves. But I'd leave it out of the organization.

[StorytellerCZ]

@sebakerckhof I'm fine with that. It might then be a good practice to also recommend on our donation page to list all the devs in the org and a way to donate to them. But I'm getting ahead of myself. 🏃‍♂️

[mitar]

I would leave this out. It's going to be very difficult to get any meaningful reward program at the rate most of us work, while complicating matters, adding friction and points of discussion.

I agree with that. I think this is also the reason why Blaze money is not being used. It is too little to pay for any work really at market rate. So it is unclear how to spend it.

Edit: But to have some budget for random other stuff (hosting, domains, running example apps as live apps, swag, etc.) might be useful.

[CaptainN]

One idea I've been playing with (in my head - need to get through this backlog to apply any of it) is the idea that I change from the traditional "open source is free" (as in beer) position to open source is not free (still libre), but you can pay what you want (or what you can) to use it. The idea is to make it clear that folks work hard on this stuff, and they should be compensated.

I got this idea from Elementary OS which wasn't without controversy: https://www.infoworld.com/article/2883114/should-you-pay-for-elementary-os.html

Broadly speaking, this organization is well positions to create and set standards and recommendations (and maybe some tooling/organizational help), that individual maintainers could implement themselves. Coders like coding, but aren't necessarily geniuses at the organization/funding stuff.

(Or put in E-Myth terms, this org can manage a franchise prototype. Anyone read that?)

(There's also a bunch of neat org stuff happening in co-ops - I have a lot of thoughts on this stuff.)

[mitar]

@CaptainN I think what you are describing is mostly what Tidelift is going for. So maybe we could just adopt them and then use them for funding. They work with maintainers that packages are up to good standards and they help distribute the funding.

[CaptainN]

@mitar They look interesting as a model to follow. They are focused on enterprise though - does that match our efforts here?

[mitar]

Enterprise is where the funding comes from. But maintainers are generally individuals, which is all very aligned with what we are doing here.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[StorytellerCZ]

@mitar That is the problem. I have seen a great reluctance of companies to donate/support individual developers. It is as how Open Collective shows in their intro video: https://youtu.be/IBU5fSILAe8

[mitar]

What about GitHub sponsorship for organizations? This might be the simplest then for organizations? GitHub does not take a cut, while Open Collective does. I think Open Collective is useful if we care about transparency or donors care about transparency of how donations are used.

I also proposed in the past that we would rename/transfer Blaze Open Collective to this organization. We should check with existing donors if this is OK, but generally I do not believe that funds will ever be used there.

[mitar]

Should we rename this issue to "funding" or "donations" and not governance?

[StorytellerCZ]

GitHub sponsorship for organizations, still requires fiscal host like OpenCollective and that requires at least some sort of agreed upon organization.
We can probably agree to designate a triumvirate or something that is going to have control over the finances to start with, but we should probably have some governance rules set around this.

[mitar]

Maybe let's keep it simple for now:

• Everyone can submit a reimbursement form on Open Collective.
• Once this is done, one of admins decides for or against reimbursement and reports the decision and claim to a dedicated Slack channel.
• If nobody objects in 3 days, the decision goes into effect.
• Otherwise there is a discussion in that channel by anyone who wants to discuss it.

[aogaili]

I think we can borrow a lot from how condos are governed and apply some of its best-practices with regards to how the meetings/decisions get conducted (Robert's Rules of Order) to the way they report and allocate finances.

We can establish a reserve fund similar to that of the condos which can be allocated to specific projects/tasks and I'm willing to invest in this pool fund. We can also offer paid premium memberships (and/or sponsors support) and those will get higher influence in the direction of the community, etc which would go to the reserve fund.

There is a lot of interest and potential here.

[juliomac]

Is is possible to add a section about deprecated packages and their replacements?

For instance... I just saw here on one comment that aldeed:simple-schema has been replaced by npm version simpl-schema.

That is a extremely useful information.

Could we have somewhere a section with a table such as:

Deprecated Package	Replacement	npm Replacement
aldeed:simple-schema	none	simpl-schema

What do you think about this idea?

[juliomac]

I just saw your presentation ate Meteo Impact. Unfortunately however, only the recorded video, not the live section. Many thanks for IT !!!

I would like to suggest an approach for updating low-hanging fruits packages first. What do I mean by that... Update those packages that are popular and require minimum changes for it to work. Changes like updating their coffescript dependencies, Jquery dependencies, etc..., or those that require just one or two lines of codes here and there and that the community already solved through forks but the package owner never had the time to look at it.

I think there are MANY packages that fall in this category.

Meteor has done a great job in terms of backward compatibility. My application, for instance, was first developed when Meteor was still at version 1.2 or less and it still works at version 1.11. The only changes I had to do so far was to replace some few packages no longer maintained. But I feel I wouldn't even have to do it if only a few minor changes were done to them.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.