Skip to content
This repository has been archived by the owner. It is now read-only.

GitHub no longer maintains Boxen #197

Closed
MikeMcQuaid opened this issue Nov 17, 2015 · 9 comments

Comments

@MikeMcQuaid
Copy link
Contributor

commented Nov 17, 2015

Hello non-GitHub Boxen maintainers (@createdbypete @fromonesrc @grosser @jhaals @lucasmazza @rafaelfranca @seanknox @tarebyte)!

As you have probably noticed: GitHub has not been active in the development in Boxen for a while. I'm the only person maintaining and supporting it internally and it's never really been part of my actual job there. I did some porting and bug fixing to make sure Boxen worked (at least in some form) on OS X 10.11 but when OS X 10.12 is released I will not be doing any additional work to fix it up. Internally, some people are still using Boxen but others have moved to using Strap, Homebrew Versions, Homebrew Bundle and Homebrew Cask (which I realise don't provide 100% of the functionality of Boxen and never will). I'm an active maintainer and contributor in all those projects so I'm dedicating my energy there, long-term.

What I'm wanting to know from you all is: what (if anything) do you need/need to know to be able to maintain Boxen without GitHub? I'm hoping to address this in this issue so that when I close it I can personally stop feeling bad about abandoning you folks.

Finally: thanks for all you do keeping Boxen running and for you work here and elsewhere in open-source. It's admirable and it keeps the software development community running ❤️ 💚.

@patrickod

This comment has been minimized.

Copy link

commented Nov 17, 2015

@MikeMcQuaid would be very curious to know the reasons for moving away from Boxen @ Github. Were there specific pain points that you viewed insurmountable in Boxen? Was the maintenance cost just too high?

Asking as we use it at Intercom w/ approximately 60+ engineers and it comes with a non-trivial maintenance cost, especially during major OS upgrades. We're interested to hear what issues you all had with a larger team and how you've addressed them.

@MikeMcQuaid

This comment has been minimized.

Copy link
Contributor Author

commented Nov 18, 2015

This is my personal opinion as an open-source maintainer and user of Boxen rather than as being the view of GitHub the organisation:

For me the stuff I think Boxen does well:

  • full system management and project setup for large numbers of developers on OS X
  • keeping package versions stable despite upstream (e.g. Homebrew) changes
  • unifying bootstrap code between projects
  • allowing heavy user customisation

For me the stuff I think Boxen does not so well:

  • it requires large amounts of time to maintain software and essentially ends up duplicating a lot of the work Homebrew does to fix/update/upgrade things. As a result software tends to sit on old versions that have known security vulnerabilities, bugs or break on newer OS X releases.
  • Puppet solves some problems and creates others: the output is hard for end-users to read, the dependency graph means it's hard to handle/retry intermittent errors (or hard for me, at least), it does not handle well when users manually install software outside of Boxen
  • it's not very Unixy: a single tool does system bootstrap, project configuration and user configuration. As a result it's hard to debug, modify and support reliably.
  • it's pretty opinionated about what it installs, where and how it installs them. If users disagree they either need to deal with Boxen's regular errors or just quietly stop using Boxen and sort out all issues themselves. When users do this they are unlikely to enable all the security features that Boxen does.
  • it was not built with CI in mind

I personally tried to address a bunch of these with various pull requests to make Boxen automatically rerun on failures (a nasty hack but reduced my support load), make Boxen support and then default to a /usr/local Homebrew, move away from Puppet modules in favour of upstream Homebrew/Homebrew Cask packages when possible and use binary packages to reduce the changes of build errors. Unfortunately even with all these changes these errors keep popping up due to the inherent entropy of engineers having to install all the random things they do to get their job done (something I'm strongly in favour of).

Ultimately my chosen solution of these other components are based on wanting to create software that can be used independently with or without each other to solve these sort of problems. Most of the things that Boxen did around Homebrew are arguably working around usability smells in Homebrew itself and I'm personally more interested in fixing these for all Homebrew users than working around then for Boxen ones.

I hope that provides some clarity. Feel free to ask any more questions you may have.

@ocxo

This comment has been minimized.

Copy link
Contributor

commented Nov 18, 2015

Thanks for making this official, @MikeMcQuaid. It was apparent for some time that GitHub was not interested in maintaining Boxen. We stopped using it at my organization about a year ago after encountering many of the pain points you described here. Another point of pain for us was we use Chef in production rather than Puppet which meant dev would never possibly have anything close to parity with production no matter how hard we tried. There were not any tools as fully featured as Boxen in the Chef world so we ended up building a tool that was better adapted to our needs, using a combination of Chef and Vagrant. We are now using a container approach which we think will solve some of the remaining local dev pain. If you can share, what sort of tooling is GitHub using for local development nowadays?

Thanks for all the 📦, :octocat:.

@MikeMcQuaid

This comment has been minimized.

Copy link
Contributor Author

commented Nov 18, 2015

If you can share, what sort of tooling is GitHub using for local development nowadays?

Most people are still using Boxen while we figure out exactly how we're moving forward but I (and various others) are using a combination of Strap, Homebrew Versions, Homebrew Bundle and Homebrew Cask. For project setup Homebrew Bundle and Scripts To Rule Them All mean that a single script/bootstrap should be all that's necessary (after running Strap) to set up any project internally.

@MikeMcQuaid

This comment has been minimized.

Copy link
Contributor Author

commented Nov 22, 2015

I'm closing this out because it seems I've answered at least some of the questions. Feel free to keep them coming, though.

@MikeMcQuaid

This comment has been minimized.

Copy link
Contributor Author

commented Nov 24, 2015

@rafaelfranca As the person doing a lot of the work in the Boxen org now: do you have any more questions here?

@rafaelfranca

This comment has been minimized.

Copy link
Member

commented Nov 24, 2015

@MikeMcQuaid hey! Thank you for asking. I don't have any question, you already gave me all permissions that I need to keep maintaining Boxen, but I'm also not using Boxen anymore in my current job so I'm only trying to keep the things going and helping as much I can. I'll continue to help the other maintainers if they need something.

Thank you for letting us know.

@MikeMcQuaid

This comment has been minimized.

Copy link
Contributor Author

commented Nov 25, 2015

@rafaelfranca My pleasure 👍

@MikeMcQuaid

This comment has been minimized.

Copy link
Contributor Author

commented May 17, 2016

For anyone interested: GitHub has now migrated everyone using Boxen to using Strap, Homebrew Versions, Homebrew Bundle and Homebrew Cask. It's been fun but I'm going to leave the Boxen organisation today. Good luck 👋

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
4 participants
You can’t perform that action at this time.