Gorilla Toolkit Open Source Project Becomes Abandonware
Well, that’s annoying!
For years, the Gorilla Web Toolkit was a popular, open source Go toolkit for web-based applications. It consists of packages that augment Go’s base libraries to add important features such as parameterized routing and session management. In particular, mux, its web request router, has been very popular. How popular? Try mux is used in over 90,000 repositories. It’s called in for duty on such top projects as Cilium, Istio, and Open Policy Agent. Indeed, Gorilla’s WebSocket library is even used in Kubernetes. And, with all that, the project has now been abandoned.
How could this happen to such an important project? Easy. The project maintainers called for new blood, and no one answered.
Bodies Needed
And, boy, were new maintainers needed. As the last maintainer Matt Silverlock, said, “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. … we just never seemed to get anyone to stick.”
True, they wouldn’t take just anyone. “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.”
About the Money
Like so many important, but unappreciated open source projects, Gorilla was about the money. There wasn’t any. It was a passion project. Silverberg added, “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.” Besides, Gorilla never had any cash. There was never an effort made to monetize Gorilla.
So, after almost a year of attempting to find someone who could responsibly take over the libraries. They gave up.
Project Archival
The remaining supporters have decided to archive the project at 2022’s end. That means the repositories go into “read-only” mode. You can still clone them, get them, and build projects against them just as you always have. But there will be no future development. Oh, and security patches? Please! Get real.
You can, of course, fork the project or its libraries. All of the Gorilla libraries are permissively licensed under the MIT, BSD-3, and Apache 2.0 licenses.
But, while forking a project is easy, forking one and building around it is much harder.
As Dan Luhring and Eddie Zaneski, software supply chain security company Chainguard software engineers, put it, the Gorilla collapse underlined two problems. The first was that Gorilla was unable to find trustworthy maintainers. If you let any Tom, Dick, or Harry become a maintainer, you could end up with a situation such as Chrome’s “The Great Suspender” plugin. There the legitimate project was sold to an unscrupulous company that used the plugin to spread malware. No one wants a mess like that.
The other problem is we all too often believe that an open source project will magically keep improving and fixing security holes as they emerge. Often, they will. But there’s no guarantee, and there’s certainly no magic.
Provide Support
To keep open source software working properly, the Chainguard crew said, “Companies need to be providing their teams with work time to contribute back to projects they rely on. While money was not cited as a concern here, we should be financially supporting and hiring open-source maintainers. We can promote the work they do, and we can highlight when the work of open-source maintainers makes the world a more secure place.”
Exactly so. Open source only works well when everyone in its community gives it real support in terms of developer time and sweat. And, money doesn’t hurt, either.
In this specific case, Chainguard suggests you identify which of your projects rely on Gorilla Toolkit libraries. Sure, Gorilla is battle-tested, and there’s no reason to believe anything’s going to go wrong with it any time soon. Still, it’s best not to depend on any unmaintained software for the long term. It’s just asking for trouble.
Another library you might want to consider is Gin. This is a more full-featured Go web framework.
Unfortunately, if you need gorilla/websocket replacement, you may be looking for a while. Chainguard hasn’t been able to find one yet.
Hey, if Gorilla is critical for you, here’s a thought: Fork the code. Take proper care of it, assign a programmer or two and a maintainer to it, and being aware of the fate that befell the original, make long-term plans to keep the project going for years to come.
Don’t think it will be easy, though. All too often, as the Gorilla team found out, people will say the right things, but they won’t do the right things. Successful open source projects require a sustained effort to maintain their code. The days when you could use abandonware code without worry are long over.
