My view on this is, that working alone is probably quicker than working as a group, because forming a group that works well together and achieves a lot with aligned goals would probably be difficult. But working alone is only going to go so far, in particular it does nothing to address the bus factor issue, not to mention the bottle-neck issue.
I created elm-janitor, starting out as a solo endeavour, but also right from the start tried to follow best practice of working in the open. Posting about what I was doing, seeking advice from others on how to do things I didn’t know how to do (how to review/test/merge GitHub PRs with git), documenting my working process, and also creating a channel where people can participate in a group effort to evaluate the patches. The predictable thing has happened though, and that is that people now see me as “the janitor”. My intention was really to create a framework that allows all of us to be “the janitors”. I should also mention Marc Walter, who wrote the apply-patches script for it, because without any prompting and completely by his own initiative he did precisely that.
elm-janitor is limited in the scope of what it is trying to achieve. It aims to be forward and fully backward compatible with Elm. It also has a major piece missing from it currently, which is the ability to publish kernel packages and have the compiler pick them up - this can be done actually, but it involves setting up MITM proxy to trick the compiler into using an alternative package site; that requires messing with the certificate authorities whitelist in a way that would be unnaceptable to commercial users building their CI systems - you might do it on your own work computer just to try it out.
By forward compatible, I mean forward compatible to a reasonable interpretation of intention. By that I mean that if you write Elm code and use elm-janitor, since you will get bug fixes that cause different runtime behaviour to the official Elm packages, you will not have perfect forward compatability. But we tried to fix the bugs in line with our best interpretation of what the correct behaviour should be - so that is what I mean by forward compatible to intention.
For me, backwards compatible evolution of Elm is essential. I think it is likely also to be quite essential to most of the people that are making big contributions around Elm packages and tooling. Simply put, we have made a significant investment of time into Elm, and would not want to lose that. Not without some easy way of upgrading anyway. Backwards compatability is the reason that I have not explored Roc or Gren, despite them being worthy and interesting projects.
Also note that backwards compatible can mean adding new kernel APIs and functions, so long as they leave the existing ones alone… 
But for now, I have declared that the roadmap for elm-janitor is to not do that. The reasons for that are:
- I think it should come after all the existing PRs have been reviewed (pretty much there at the current time).
- I think it should come after a period of reviewing and creating PRs for existing issues that do not already have fixes.
- It is a little more controversial, because forward compatability is now being discarded - there would now exist a one way valve through which people could move off of Elm and not come back.
- There is no package system yet to make this work available.
- and It is probably the correct time to declare a fork when this does happen.
But if you are serious about evolving Elm, and accept that the only way to do it is to avoid being blocked on Elm, and that the only proper way to do it that carries the existing community along for the ride is backwards compatability and creating a structure that allows the community to participate - I think it is likely that you will come to the same conclusions as I have.
What I have tried to do is map out how I think those conclusions could be turned into a roadmap for continued evolution of Elm that best meets the needs of its current users, and would open up growth and progress that would likely attract many new users.
My personal motivation is that if we can get there, Elm will become more viable for commercial adoption - so time invested towards these goals now, will pay me back in life later by making more enjoyable and profitable work available to me.
As I say, I am not actively working on elm-janitor right now, because I am not the janitor. I would be very happy to set up and support people if they do want to take it further. I also anticipate that there will be some future time, when I am between contracts and sitting on a small (but rapidly diminishing) pile of money, that I am able to pick it and run with it again.
