Is this repo dead? Any successor?

[EugenMayer]

It seems / has been stated, github has abandoned boxen in general - so things become pretty quiet nowdays.

How to think about our-boxen here and the general project, are there any successors?

[jacobbednarz]

Hi @eugenemayer 👋🏼

The Boxen project has been discontinued at GitHub however there are still a bunch of companies using and supporting this project so it's definitely not dead. Something to keep in mind is that this project consists of 313 other repositories which need maintenance and some of them require more love and attention than this repository.

I've been heading up a bunch of larger intiatives outlined via boxen/boxen (feel free to chime in if you have any thoughts!) to clean up maintenance and really focus on integrations and what issues Boxen is best placed to solve. I.e. deprecating a bunch of modules that Homebrew now manages better upstream instead of us vendoring.

Please let me know if you have any more questions!

[EugenMayer]

Thats a great answer @jacobbednarz, thank you a lot.

The problem with the maintenance is, that is forks without an upstream merge, since people learned, thinks are not going to be merged anyway.

the problem is the governance model - its build so that some Leutnants can oversee a pull into the main repos / modules, which suits well and can be stated as good quality. But even in the days when github was active, they rather were very unresponsive due to the work load.

Things become even worse nowdays and people learned that contributions are just not worth the effort, its firing into the ether. Thats how most modules look like, a lot of LTS forks, without any attempt to merge back. Most of the forks do add real value and are successors of their base repo in mostly any way.

So i suggest to overthing the Leutnant model and rather pull in much more contributors with access to merge - things will improve first, then it gets unstable due to the higher speed and then new rules can be applied to this bigger-mass governance - a much more open process.

The other way is, very few, core people, will drive the project, in very slow speed, dropping out one by one, never getting anybody near them to support them, so their will be no replacement, its just "as long as they are there" - and then its over.

I personaly looked at kitchenplan, ansible and chef in general to replace boxen and happened to understand, that the build in OSX support of boxen is far superior to any of those, and thats basically what matters. so i think boxenh as unique USPs which can be seen as worth "saving the old blue whale".

Thanks for actually doing so much work across the modules, i have seen your name popping up quite often.

[jacobbednarz]

the problem is the governance model - its build so that some Leutnants can oversee a pull into the main repos / modules, which suits well and can be stated as good quality.

I only partially agree with this since community contributed modules have always been maintained by people outside of the core maintainers and they have been fully in control of who can merge or approve changes. The way a new module used to come about was that it would be forked into the Boxen organisation and then a new GitHub team was created with the name " maintainers" (see boxen/our-boxen#803 for an example of this process). The only repositories that have been slightly more strict have been some of the core ones due to lack of automated testing and knowledge of how it all hangs together. This is something that has been eased since adding CI to boxen/our-boxen and tests can be added against existing and new functionality.

I am happy to chat to anyone that is looking to step into a maintainer role to get some more eyes on these changes and remove any single points of failure for this project. In the past I have reached out to a couple of potential candidates however they weren't able to allocate much time to it due to other commitments or they no longer used Boxen internally so they were out of touch with it's setup.

Things become even worse nowdays and people learned that contributions are just not worth the effort, its firing into the ether. Thats how most modules look like, a lot of LTS forks, without any attempt to merge back. Most of the forks do add real value and are successors of their base repo in mostly any way.

I would love to pick the brains of anyone who has experienced this so that we can find out the reasoning behind not attempting to merge back as I suspect there are other reasons than just "not worth it". For example, we forked a couple of modules internally to use that we never committed back but that was because our production environment and attempting to merge that back in would have caused everyone else using the module lots of issues.