Gorilla, the popular open source web toolkit for the Go language, has announced that it has officially archived,Currently in read-only mode. “It sends a signal that there will be no future development of these libraries.“

According to the introduction, Gorilla Web Toolkit is a popular open source Go toolkit for web-based applications,Consists of packages that enhance the Go base library to add important features such as parameterized routing and session management.Among them, especiallyIts web request router mux has been quite popular; used in over 90,000 software repositories, and invoked to perform tasks in top projects such as Cilium, Istio, and Open Policy Agent. Gorilla’s WebSocket library is even used in Kubernetes.

gorilla/mux first commit It was in October 2012, a few months after Go reached version 1.0. gorilla/websocket started in October 2013, and some other packages that form the “Gorilla Toolkit”, alsoemerged around the same time.

The main maintainer of the project Matt Silverlock existThe announcement states that the main reason for project archiving is the lack of maintainers.

The original author and maintainer moraes left a long time ago. Kisielk and garyburd have worked the longest, maintaining the HTTP library and the gorilla/websocket combo, respectively. I got involved around 2014 when I noticed that kisielk was doing a lot of heavy lifting and wanted to help contribute back to a library that I used in some personal projects. Since 2018 or so, I’ve been the (mostly) sole maintainer of all projects except websockets.At about the same time,garyburd put out an (actually unsuccessful) call for new maintainers.

Matt Silverlock think theyPotential new maintainers are given a fair chance to participate, and the barrier to entry is not set too high. The two main problems are:

• Not even an active contributor to triage the issue. We made it clear when we called for maintainers that we would help merge and do the final review for anyone who wanted to start contributing. However, many raised their hands (read: commented on the thread) and were never seen again. Many OSS projects have a few casual maintainers: we never seem to get anyone to stick around. Maybe the “utilitarian” nature of these libraries doesn’t help, or maybe writing your own is more appealing?
• These are widely used libraries. As we said in our original call for maintainers: “No maintainer is better than a naysayer!” — handing over a package (mux) with 3k unique clones per week to someone else to manage is not All I can take. This tends to behave badly in other projects.

The original timeframe for recruiting maintainers was 6 months, but after far exceeding this timeframe, it still failed to find an individual/organization that could responsibly take over the warehouse, which led to the current situation of project archiving. “I do believe that open source software has a life cycle—a beginning, a middle, and an end—and that no project needs to live forever. It might not make everyone happy, but that’s life.”

Matt Silverlock He also said that the maintenance of Gorilla Toolkit by these people is out of love and has no monetary purpose.neverNo one has attempted to exploit the Gorilla comegain monetary benefits. “We don’t want it to be a job. It’s not a dig at maintainers who want to get paid, it’s a reminder that not everyone is in it for the money.”