Maybe it is time for Meteor Foundation.
3 Likes
Too short. Maybe something like the Meteor Community Development Technical Oversight and Steering Committee Foundation Group. Now we’re talking … or typing.
6 Likes
See https://nodejs.org/en/foundation/ as a resolution about similar struggle in node.js community. They also had similar issues. Community wanted features company was too slow to integrate. And lack of space for community participation in the project’s governance. First fork happened, but then a foundation was established which merged projects back together.
4 Likes
At this point it would only be time for Meteor Foundation If MDG wanted it to go that way. Otherwise you gots to go through the standard motions.
- Convince a critical mass of community members to help develop a sustainable fork of Meteor
- Convince enough developers to switch to the fork such that MDG sees it as a real threat (they embrace choices so much I’m not even sure they would)
- Everyone agrees to merge back with mainline Meteor as long as its driven by a foundation
Not exactly a desirable process especially since I think there is still hope that MDG can turn the ship on engaging with the community properly. @sashko has been very frank in his assessment of the community contribution issues. I do tend to believe that solving them is still a somewhat low priority within MDG but there is evidence of traction. I see the proposed solutions (creating committees, splitting up the code better, leaning on more testing) as being more akin to pointing a finger in the direction everyone agrees we want to go rather than starting to actually turn the wheel.
I think the focus should be on the little things that turn the wheel even just a little bit. Can the DDP and this.unblock issues actually get closed in the next week or two. Can the community identify the 1 or 2 highest priority pull requests they would like to get accepted in the shorter term? And can MDG dedicate the developers needed to make that happen?
If we can accomplish those small goals and get into a rhythm then the rest may very well fall into place naturally. If those small goals can’t be accomplished what is the point of even talking about the rest?
2 Likes
I was responding to @mitar who used “Meteor Foundation” and linked to https://nodejs.org/en/foundation/. Foundation in that context certainly implies moving towards a development model that is not controlled by MDG. I said fork only because I believe it would be the fastest, and perhaps only, way for that that type of Meteor Foundation to occur. He may not have directly said a fork should occur but he certainly was implying something more than MDG playing nice with a community based committee as you described.
All that said, the above is somewhat moot because I really do agree with you that a fork is definitely not the right approach.
The point of mine that I think most warrants discussion is on what the shortest term goals or metrics should be for community engagement. Even if MDG responded to your list of questions (which they probably won’t) and said yes to every one, it would just leave us with more questions to ask, which would more than likely lead to non-binding promises of future improvements.
What can happen in the next few days or weeks to turn this conversation into something more than a plan for a community committee, that would be made up of some TBD community members, and some TBD MDG developers, discussing some TBD strategies, for improving some TBD process for accepting community contributions? (all occuring sometime after MDG has hired more developers, finished splitting up the code, and improved the testing)
1 Like
About Meteor having open source code but not being an open source project:
2 Likes
It’s not a black and white choice, it’s 50 shades of grey. Complete openess would mean anyone can do whatever he wants to the source code. I don’t know any project that works like that. They’re all somewhat in between, having a select group of people making decisions. This doesn’t seem to be so different with Meteor. The open or closed nature of Meteor seems quite irrelevant to the problem being discussed: PR’s getting forgotten about. The cause seems to be that the select group making the decisions is maybe understaffed and lacks a bit organization/discipline towards handling the PR’s.
6 Likes
People have experimented with open source projects for 25 years, using many different governance models, from the most authoritarian to the most anarchist one. A governance model is what defines who can do what and why, which group decides what, how to promote individuals in the various groups, and so on. Until MDG chooses a governance model, shout it to the world and implement it, Meteor is not an open source project.
Now about my opinion: after the first innovation, there is no way a group of 4 programmers can keep pace with the development of a platform. So Meteor needs either to raise more funds and hire many more developers, or to become an open source project.
10 Likes
@sashko and I had a cornerstone show talking about this forum post. @mitar thank you for starting it! Check out the TRANSMISSION show on Apple podcasts, Overcast or direct https://transmission.simplecast.fm/3
3 Likes
Really great! Thanks for doing this, @benstr and @sashko.
After listening to that and thinking again about this topic, I think it really boils down just to one thing: Meteor does not have any community people with commit bits. It would be really interesting to compare company-based open source projects on how many people outside the company have commit bits. @joshowens, could you check this somehow?
I think GitHub now provides nice tool to allow this: protected branches. So one can give commit bits and know nobody will really destroy anything. You have version control to assure that.
2 Likes
Yeah, that’s one of the top points. I hope to make this happen as soon as possible, but can’t promise any deadline since it would be a pretty big shift which needs a lot of people on board.
The hidden assumption here is that the only people who can understand Meteor are people from MDG. In radio show you are talking about how some parts of the project nobody at MDG understands anymore. But maybe there are community members who do. Or who at least had time and motivation to go and understand that one piece of good enough to improve something.
BTW, splitting into multiple repositories might even make things worse. The issue for contribution is not if the code is in one or multiple repositories. It is if code depends on other packages in ways which can break it. Even if Blaze is in its own package, I could still break Meteor by making some changes which would still pass tests, but break some assumption outside. There will always be cases like this. The only way to prevent this is that more people can look at the code and more people can test stuff. Beta versions and so on.
So I think you should really not wait with any of this. Splitting packages so that it is clear what pull requests are about vs. checking in the pull request which files the pull request touches and label the pull request accordingly has very little difference. But it will make easier for people with commit bits to really help over the whole project. We are doing full stack stuff. Also imagine the issues if change would require changes to Blaze and one small change outside. How hard would that to get in when repositories are split.
I think with git commit bits you want responsible people. People who know when they know something and when they do not know and leave it be. Also, you can always also remove the bit if it is ever misused. You have git history to validate that.
Splitting into repositories might add extra coordination costs.
So I do not think addressing closeness of contributors has anything to do with any changes. It is just a mental shift which is necessary. And it is not rocket science. Open source has been around for long enough.
I would propose that you simply organize elections. And community can nominate people and then vote on top 3 people from the community who can get commit bit for the whole Meteor repository. (Nominees can still decline it.) And let’s see how far it goes. If it does not work, you can always revert it. But start doing something simple and easy. Only mental shift is necessary here.
Perfect should not be the enemy of the good.
(I am all for splitting into packages, but from different reasons. It is easier to git submodule them.)
4 Likes
I think this point is really just talking about unit testing vs integration testing. Rails pulls this off without having to split out code base into separate repos. I tend to agree that splitting the repo doesn’t feel necessary. @sashko, aside from feeling more comfortable to hand out commit rights on a smaller repo, what do we gain by splitting it out?
It’s not up to me personally. Meteor is an organization with many people, each with their own opinions about how best to grow the platform.
I think a monorepo encourages making changes to multiple packages at once, which means it’s much easier to introduce and maintain hidden dependencies between those packages. If they were in separate repos, it would be much easier to ensure that there are no hidden APIs between them, and people would be more worried about breaking those APIs since it would be impossible to find all of the uses.
1 Like
Now you brought the real issues out. That the issues is not that Meteor is not more open to outside contributors because it is hard to do it or there are no infrastructure or resources in place to do so, but because there is not even clear and shared motivation inside MDG to really do so.
In this case it is clear that Meteor then is not an open source project, but just a company project which happens to have code open.
What I would say is that all those things are not conflicting though. If somebody else thinks some other way is better, try both ways.
What exactly do you have to loose by:
- organizing nominations
- organizing elections
- giving commit bits with clear rules (maybe one rule could be, you cannot merge your own pull request)
- if it turns out bad, remove the commit bit, because you have git history you can clearly show out why
How does this interfere with any other way to grow the platform? It does not. It can only add to it.
4 Likes
Ok, I am just going to put this out here then. We’ve certainly heard this type of conversation before. Is there some learning or knowledge that the team has now that will make this time succeed where other attempts haven’t? The conversation on the podcast and in here just feels a little like trying to revise previous history to pretend these things haven’t been attempted before. I sat and watched @dgreensp give a talk introducing Blaze to a bunch of people and talked about how it would be open sourced and they wanted to build a community around it.
I am all for it, but I am not sure splitting repos is a silver bullet here. I would love to hear @sashko’s thoughts on what exactly will make splitting work this time around, if it happens.
4 Likes
I think it’s clear that things were this way in the past, but change like this cannot happen instantly. Organizations can change, and I’m pushing for this.
Well, the first problem with the meteor/blaze repo was that the blaze package in meteor/meteor still existed, and was the canonical version. So I think that was a misguided attempt that didn’t go the whole distance.
4 Likes
Some more comments on the show.
People like that Meteor has a clear vision? But you are changing that vision all the time. 
(Which is probably called development.)
Foundation does not mean companies pushing in various ways, it means that you have some people from MDG and some people from community at the same table who can make decisions. It can also be just 1 person from community and majority people from MDG. But just to have a common stewardship of the project.
From the talk I see that this is really pretty standard geeky problem. You think that issues are just technological. Lack of testing, lack of splitting projects, lack of documentation, lack of resources. No, problems are structural and societal. You do not want to be a community project because you do not want to give even slightly open control to others. Even if it would not be really giving up a control, because you can always revert commits and you are still ones who decide what gets released as Meteor.
This is the only issue. Everything else would be solved by itself (or community would solve) if there would be less wanting to control everything. People would create their own hacks around all the technical issues. Technical parts do not have to be perfect.
But there is lack of real open source culture in MDG and this cannot be solved with any technical solution. It has to be done in heads of MDG people.
14 Likes
I believe I clearly challenged @sashko about this and mentioned how a negative culture has formed in the community around PRs. Sashko also responded clearly by recognizing that issue, owning it (where he could personally) and laid out his opinion on how to fix it. I straight out asked him if he will give repo commit rights to community members and he said yes… Again in the context of where he has the power to do it.
To me I see a new leaf being turned at MDG and Sashko is one of the first making the needed changes. With our support and encouragement I hope Sashko’s attempts to open up more to the community will become a cultural norm at MDG across all the teams.
Do not shoot the messenger… he might be bringing you good news!
14 Likes
They are trying to be transparent with us. Yet, our first assumption is they aren’t doing anything about it. Things won’t change over night. @mitar i do like your idea of elections though.
Here’s what it boils down to. Who here cares enough about Meteor outside of their OWN work to push the community forward/project forward. Or, maybe you have no other work outside Meteor. In that case, I hear they’re hiring.