Gorilla Toolkit
⚠️ The Gorilla Toolkit is now in archive-mode, and is no longer actively maintained. You can read more below.
We’ll be putting the Gorilla project’s repositories into “archive mode” by the end of 2022.
It’s been a long run. The first commit on gorilla/mux was back in October 2012, just a few months after Go itself reached 1.0. gorilla/websocket started back in October 2013, and a number of other packages — forming the “Gorilla Toolkit” — sprung up around the same time.
The original author and maintainer, moraes, had moved on a long time ago. kisielk and garyburd had the longest run, maintaining a mix of the HTTP libraries and gorilla/websocket respectively. I (elithrar) got involved sometime in 2014 or so, when I noticed kisielk doing a lot of the heavy lifting and wanted to help contribute back to the libraries I was using for a number of personal projects. Since about ~2018 or so, I was the (mostly) sole maintainer of everything but websocket, which is about the same time garyburd put out an (effectively unsuccessful) call for new maintainers there too.
Some of you might be reading this and thinking that we didn’t give a fair shot to potential new maintainers, or that the bar for new maintainers was too high. The problem there is two-fold:
- There were no active contributors even triaging issues. The call for maintainers made it clear we’d help merge and do a final review for anyone wanting to start contributing. Instead, a number of folks raised their hands (read: commented in the thread) and then were never seen again. Many OSS projects have a number of casual maintainers: we just never seemed to get anyone to stick. Maybe the “utilitarian” nature of the libraries didn’t help, or maybe it was more compelling to author your own?
- These are widely used libraries. As we said in the original call for maintainers: “no maintainer is better than an adversarial maintainer!” — just handing the reins of even a single software package that has north of 13k unique clones a week (mux) is just not something I’d ever be comfortable with. This has tended to play out poorly with other projects.
The call for maintainers lived well beyond the original 6 month window in an attempt to find someone who could responsibly take over the libraries. We didn’t find that person, people, or company, and here we are today.
I do believe that open source software is entitled to a lifecycle — a beginning, a middle, and an end — and that no project is required to live on forever. That may not make everyone happy, but such is life.
Was it about money?
No. I don’t think any of us were after money here. The Gorilla Toolkit was, looking back at the most active maintainers, a passion project. We didn’t want it to be a job.
This isn’t a dig at maintainers who do want to be paid for their efforts, but a reminder that not everyone does things for money.
What does “archiving” mean?
It means the repositories go into “read-only” mode (read more here). Anyone still using them can still clone them, go get them, and continue to build projects against them. In effect, there’s really no change here from the last 12 months, and it won’t break existing projects.
What it does signal is that there will be no future development on these libraries.
Folks are welcome to (as they always have been) fork them: all of the Gorilla libraries are permissively licensed (MIT, BSD-3, and Apache 2.0).
Thanks for all the fish, Matt and Gary
Projects
A few of the most popular libraries:
- mux, a powerful request router for web applications
- sessions, making cookies and session management easy
- websocket, a standards-compliant and widely used websocket library
- handlers, a collection of useful middleware for Go HTTP applications.
Help
Open an issue on the relevant project. For security issues, see SECURITY.md.
