Hi @elithrar 👋, I would love to volunteer here. Though I have not worked much on Go side but would love to quickly pull up my socks. I get enough time everyday to work on OSS. At least min 2 hours almost everyday. So I can plan accordingly.

If you have doubt that about me a stranger to this project. We can get this running for a couple of months. I will contribute and try to be regular and based on that you are free to take decision.

At last, my area of interest would be handlers and sessions.

Looking forward to hearing from you.
Have a great day ahead 😄

@amustaque97 - great! The best thing you can do is actively contribute - both repositories have a number of open issues that need review, as well as PRs that need review, rebasing, and/or in many cases, to incorporate comments.

Mark issues as "close this" (I will close them), and using GitHub's review tools and @-replying me to merge. I'm still expecting some sense of design review - if the goal was to just merge every PR, I would have done that already 😉

A note for others reading this: Others who are interested should still reply, or better: get actively involved! Unfortunately, I've yet to see "net new" maintainers stick it out - most projects survive through existing community members who were already engaged. This is not a reflection upon @amustaque97, but a very real observation.

I am "actively" (in quotes because my situation is similar to yours, yet I stilll have some free time) maintaining a project here that relies on the toolkit quite a bit. I had considered switching frameworks, but I can poke around and see if I am able to offer my services here and turn this into something mutually beneficial.

Hello, I am interested in being a maintainer of the libraries.

I have been working with Go full-time for more than 2 years. I have used the gorilla projects (namely mux and handlers) both in my personal projects (used directly) and in my job (using them via an wrapper, e.g. echo framework which uses gorilla/mux under the hood).

I am willing to take the necessary time to get more in-depth on-boarding with all projects and have my contributions reviewed by you in that time.

Hello, I'm interested in maintain the project. I've been working with go for last half a year actively in work where mux is one of main libraries. Although not sure if I'd be able to contribute in the next few weeks to a month because I'm in a middle of country move I'd want to do some contributions when I'm setup.

Hi, I am not volunteering. I just wanted to thank you for your time and effort thus far is maintaining gorilla.

I taught myself go during lockdown and one of the first packages I made use of in one of my toy projects was mux.

So thank you for the hard work and happy holidays!!

I'll volunteer. Maintainer or not, if someone else gets the job and wants to toss me a few bug tickets here and there, go for it. I've used this library a LOT and have no problem giving back to the community.

To re-state - the best way to contribute is to jump in!

I don't have the time to actively assign or triage issues. Folks interested in getting involved and getting a "commit bit" need to demonstrate by doing.

Hi!
I’d be more than happy to look into issues and help!

In the interest of helping the project find new maintainers, I would like to ask if it is possible to expand on the requirements and succession process perhaps codifying it into a protocol. There's a risk, whether perceived or real, that maintainer(s) might make contributions for 3-6 months but that for whatever reason the process stalls and the project is archived all the same.

This is a valuable opportunity to figure out how best situations like this can be handled to minimize disruption to users, developers and the broader open source community. Ideally, the project after this succession process is protected against a repeat and can be held up as an example of how to do it right.

@weex I specifically want to keep the barrier to entry low here: otherwise we risk finding no one at all. The most likely maintainer is someone who is already engaged in the project.

I am also stretched for time: I care a lot about this project, but don't have infinite time to define a protocol to validate a new maintainer against. If I did have the time, I probably wouldn't be looking for a maintainer.

Candidly, your response is absolutely one of the reasons being a maintainer is hard. The expectation that we here have a duty to define some long-lived protocol for finding and validating new maintainers that reaches across projects beyond this one, with the implication that not doing so disrupts users, looks reasonable at face value but is a pretty tall ask. That I'm trying to find a maintainer, and allowing several months to do so, should be enough.

@elithrar I fully appreciate the situation and did not want to single you or the project out or give the impression that any more work is expected. I'm interested in problems like this one because I feel it's not talked about enough and at the risk of going off topic, it's only during times like these that, people want to take the time. For anyone who's interested to discuss this more I've created a sort of meta-issue.

It seems there's been a good response but if none of the candidates pan out, there's a site called Adoptoposs that seems to be a matchmaker for maintainers and I think it would be neat if maintainer-swap arrangements became more common.

Hello @elithrar

I'm really interested in becoming a maintainer, specifically for @gorilla/mux. However, It seems I need to brush up on my Go skills since I've been out of touch with the language lately. Nonetheless, I can actively contribute and close issues periodically as I have a lot of time out of the day.

Hello @elithrar

I am interested in gorilla/mux maintainer. I usually use gorilla/mux to implement web server in golang, so I would be very happy if I can be of any help.

I'd like to start with code reading and checking issues and pull requests.

Thank you so much for mux. It's very widely used as you may know.

What's the story with your websockets library? Is it the same situation?

@alexellis I mention websocket in the opening post ;-)

Thanks so much for all your contributions @elithrar!

When a new maintainer is found we'd be very happy to work with them and provide significant financial support for the maintainership, or even (if it makes sense for us both) to employ them full-time to maintain the toolkit. We're a fully remote company, headquartered in London, so location is very flexible.

I'm the CTO at Banked, we're a fintech who has a lot of interest in maintaining and expanding the gorilla eco-system.

This is obviously @elithrar's ball-game, but I'd really like to talk to anyone who takes over maintainership of the toolkit. We want to put our money where our mouth is and support the community.

Thank you so much for your work @elithrar
I Would love to volunteer :)

I'm interested with gorilla toolkits, What am I doing to become a maintainer?

👋 @truyetnm , please go through this comment. #659 (comment)

It explains everything. If still there is something. Feel free to ask.

At Motiv Solutions we maintain the Janus project which is a GO API Gateway. Our entire SASS project is built in Go.
We would be interested and use Mux in over 30 microservices

I am the CTO of Motiv FWIW

@jtesser as mentioned in the previous comments and replies we need to start contributing to the project. Using mux for almost 30 microservices is not a small thing. I’m sure you/your team can contribute really well in terms of raising issues, submitting PR, triaging issues and reviewing others code n a lot of other things 🙂🙂

Hi @elithrar 😄, I would love to volunteer here. I have professional experience with Go for 2 years in my previous company (but now still use go as a side project).
At least min 2 hours almost every day. So I can plan accordingly.

Looking forward to hearing from you.
Have a good day

I'd like to offer at least some services. I really miss the website, which doesn't appear to be operating. I'd like to offer to host the site at no expense. I will readily admit I probably don't have the open source contribution history that is being requested, but I can provide my professional qualifications with references. Feel free to PM me to have a conversation.

hosting the site was never a problem, github pages can be used for this purpose

The Gorilla Toolkit is looking for a new maintainer (or maintainers, plural). As the last standing maintainer of the project, I no longer have time to fully dedicate to maintaining the libraries across this project.

The major libraries — mux (https://github.com/gorilla/mux), schema (https://github.com/gorilla/schema), handlers (https://github.com/gorilla/handlers), and sessions (https://github.com/gorilla/sessions) — are all reasonably mature libraries, but ongoing stewardship around bug triage, feature enhancements, and potential "version 2.0s" are all possibilities.

The core asks of any new maintainers:

• Have a demonstrated history of OSS contributions. This is important, as you need to be trustworthy: no maintainer is better than an adversarial maintainer!
• Ideally, you actively contribute for 3-6 months, I merge after you review, and you gain the commit bit on the relevant repos after that period and/or active engagement on your part.
• I transition you to admin of the project.

Note: I don't expect this to be quick or easy - the websocket library, with 16k stars & 15k unique clones per week, has been looking for a new maintainer 3.5+ years, and has yet to have anyone reliably stick.

If I don't have any luck finding new maintainer(s) in the next 6 months or so, it's likely I'll mark these projects as in maintenance mode only and archive the repos.

Please keep the replies on-topic.

dude i just started writing golang so if there is small stuff i could help with lmk, i actually do use mux so i'd love to help where i can 🖖

Hi @elithrar I would love to be part of Gorilla, I am an active Go developer for the last 4.5 years and a user for the Gorilla toolkit. I do not have a lot of exp in OSS but I do have experience doing and maintaining in-house libraries in my job.

Hi, I will volunteer.

Hi folks — never an easy decision, but we've decided to archive the Gorilla repositories. You can read more about this here: https://github.com/gorilla/#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

For those finding this issue. Gorilla has been reverted from archive mode in #713.

more details in this blog post: https://gorilla.github.io/blog/2023-07-17-project-status-update/