It has been over a year since Meteor Community Packages has been established. So what is this ad hoc group of Meteor developers about and what are their goals?
In JavaScript and in any development ecosystem in general there is the never ending problem of deprecated, abandoned and discontinued packages and projects. That is normal, life happens, people and technology move on. The problem however occurs when a said package or a project is central to the ecosystem or community. A few years ago the left pad fiasco showed us how interconnected packages can get and removing one building block can have a disastrous consequences (thankfully the same thing can't happen on Atmosphere).
Like on NPM, Atmosphere also has a history of abandoned important packages like iron:router and pretty much everything that Arunoda made under organizations like meteorhacks. When such a crucial pieces become abandoned by their maintainers it isn't an immediate tragedy as they will keep on working for quiet a while and eventually from the many people who submit pull request someone will come and either take over the project or create a fork to continue the work (then the issue is letting everyone know about it and switching to it). In essence that is what MCP (Meteor Community Packages) is about, but I'm jumping ahead.
In early 2019 this issue has become a pressing topic on the Meteor Forums and via other channels as well. Eventually it was decided that a community organization should be established that would take over or fork the important packages and keep on maintaining them or at least make sure that if there was anyone who wanted to take care of a package there was a way that they can take over the management without much hustle in case that even the new maintainers move on.
In March 2019 things started to take shape. A GitHub and Atmosphere organization was created by Kelly Copley and some initial packages from other involved developers were moved over.
For myself I have create a community survey to get an idea on which packages we needed to focus on and to spread the word. This lead to initial on-boarding of the most commonly used packages that needed help with maintenance and allowed people who were proposing PRs to them to become maintainers.
We have established a GitHub organization to have a central location for code. Then we have also established Atmosphere and NPM organizations through which to control releases. We are (at the moment of this writing) maintaining 30 repositories overseen by 16 teams.
The best part is that if the original maintainer is contactable and willing to transfer the repository to our care you won't have to change anything in your apps which is one of the main points that we are trying to achieve. Sadly that is not always possible and in that case we fork the repository or transfer over some other maintained fork from a willing maintainer.
Structure
There is no strict hierarchy and there is only a loose structure. Each project is pretty much its own universe and we are only slowly moving towards unifying things like testing, CI and code standards. What is common is that each project is under some team and there is at least one overseer present to address organizational needs and to ensure that new maintainers can take over if needed. In most cases that person is me.
When it comes to publishing that either happens through CI, original maintainers who still retain access or via one of the developers that are part of the communitypackages organization on Atmosphere or on NPM, depending on where you are publishing. Right now this is limited to 4 developers, me, Kelly Copley, Mitar and Seba Kerckhof.
On GitHub, everything is located under the Meteor Community Packges organization. As mentioned everything is divided into teams. Originally it was one team per repository, but that has changed as certain projects have related repositories and some are thematically so close that it was better to unify them and then have sub-teams like in the case of the Blaze team.
The central decision location is in the organization repository where we accept requests for packages and address anything else that requires attention.
Projects
At the moment we are more strict on what we take on. This is primarily so that we don't overextend and so that we can establish best practices. To start with, we have a package template which, after we figure out the best practice, we will transfer some of that to the default Meteor created settings so that everyone can benefit.
As expected the biggest is the Blaze team which takes care of Blaze related projects, most notably the Autoform project which is scheduled for a new major version release soon.
Beyond Blaze you will find some of the most often used packages like aldeed:collection2, alanning:roles, matb33:collection-hooks, reywood:publish-composite, bozhao:link-accounts, seba:method-hooks.
Or classics like meteorhacks:picker being updated and published under the organization namespace.
If there is enough interest, then even less known and used packages have a chance for second life.
Community newsletter
One of the first efforts outside of coding was a community newsletter that I maintain with feedback and contributions from the community. This is an occasional newsletter that comes out when a new version of Meteor is released or something important in the community happens.
Funnily enough the special event was for the first newsletter which was announcing of the acquisition of Meteor by Tiny Capital.
Beside the main news the newsletter also includes updates from Meteor Community Packages, links to official blog posts & announcements and selected news from the forums or elsewhere in the community.
Slack
Probably the second most popular communication method in the community has become community Slack. This is where most of the MCP talk happens and is also frequented by Meteor Software employees. At the current moment it is one of the best ways to connect with the community.
Join the Meteor Community Slack
Meteor Impact
The newest addition to the mix is Meteor Impact. This is an online conference taking place in the second half of October to coincide with Hacktoberfest. Meteor Impact 2020 is the first year and it was born out of a long standing desire to have once again a conference for Meteor developers and enthusiasts.
Future
While much has been achieved already, there is still much to do. Many decisions still need to be made.
On the development front we need to properly establish standards by which all packages will abide. This includes code style, testing and CI. The more of the process we automate the better. With that also comes the unification of peripherals like changelog and documentation.
Outside of coding there is even more to do. A proper website to act as a crossroad for all community efforts is desired. A great goal for next year.
Currently we are lacking designers the most to help us craft logos for projects and help with efforts in designing websites. Having a unified look would certainly help.
Speaking of unification the question of governance needs to be resolved. We have came this far without any official organization and command structure, but even though in general we like the loose structure it has its limits, especially when it comes to the next big issue, funding.
Finances is a never ending issue in the FOSS community in general. With the onset of GitHub Sponsors it has never been easier though to support developers. Still this is very much lacking, and I plan to explore this issue in a future article, part of it might be that companies find it easier to support other organizations rather than individuals. The question remains if these recent developments will lead to institutionalization of part of the community in some form or something else less will be agreed upon.
Barely two years old the community effort around MCP, together with new leadership in Meteor has re-energized the entire ecosystem. While we still have a long way to go to reach the levels of what many would consider the golden age of Meteor in 2015. I think we are well on our way and the foundations we are building today will allow us to reach even greater heights.
If you like my work, please consider supporting me on GitHub Sponsors ❤️.
Top comments (3)
Thanks so much @storytellercz for the hard work on this, Meteor is really being revived.
What is the requirement for joining the slack workspace, is it only for maintainers ? I got this when I tried to follow the slack link in the post.
I think it is just a wrong link, I used the one from here github.com/Meteor-Community-Packag... and it worked.
Thank you
Thanks for the notice, I thought those were the same links. Fixing.