Huh, interesting. It sounds like you and the Hammerspoon devs are on good terms, so it's not clear why this couldn't have been resolved in the Mjolnir project. Does this have anything to do with <http://sdegutis.github.io/2016-05-30/why-i-dont-side-program...? Did you actually prefer to have other people take over the project?
Nope, that has nothing to do with what I said in that blog post. In fact, the point in that blog post was that I enjoy making things like Mjolnir, and specifically prefer it over building apps like, well, anything you'd see on the front page of the Mac App Store any day of the week.
They forked it because of a difference of opinion: I believe that separation of the core app and the modules into separate projects is ultimately better, and they don't.
When they're separate projects, there's a lot of potential for really interesting tools to be built around them, between them, or bridging them together.
Imagine having a GUI app that manages third party modules for you, installing and loading them at a single click. Or a plugin that centralizes plugin settings into a unified single GUI window. These are the kinds of things that this separation was meant to allow and encourage.
But when it's a batteries-included app, every single aspect of it needs to be built into the app. It becomes monolithic. Every feature anyone could ever want needs to be bundled into it, and even though this is more convenient at first, it ends up bloated. It also doesn't allow for any competition between features in the same domain.
The authors behind Hammerspoon prefer the batteries-included approach. They're not wrong, it's not a matter of right or wrong. It's just a difference of opinion. People who want that approach will prefer Hammerspoon. People who want to build tools around their existing tools will probably prefer Mjolnir.
Sounds like the distro problem. Yes, a lean, mean, linux machine is great, but when you have to hunt around for all the tools you want, it becomes a pain to manage. Far nicer to have a curated set of tools that most people can agree upon.
In this case, mjolnir, the lean mean core, then the various subprojects, and finally the "distro", containing a curated set of popular modules that people can download as a turnkey system. Then, if you want your own custom setup, minus the bloat, you can set up your own distro. If you just want to use the damn thing and don't care about how the sausage is made, use the "recommended" distro.
Have a centralized repository containing pointers to all available modules. Module creators can publish to this repository. Cocoapods does this rather nicely, and uses github for the centralized repo.
Then have a tool inside mjolnir that allows administration of the repo (request adding your module, publish a new version of your module, etc).
Then have a "distro" format that lists what modules are included in your distro. This is doubly cool because if you have to install another machine, you just call upon your distro, it installs everything and you're good to go. It also makes upgrading to the latest and greatest modules a breeze.
I guarantee that 90% of your users will just go with the "recommended" distro, but the developers will love you for making it a lot easier to contribute. It's all about lowering friction, for users, power users, and devs.
