⚠️ The Gorilla Toolkit is Looking for a New Maintainer
elithrar opened this issue · 49 comments
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.
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.
Hi @amustaque97,
I'm interesting with web server technology, somethings like mux, session, handler and websocket. Currently I'm working on go framework go-kratos, it used gorilla mux for http server so I want contribute gorilla toolkit to make it better.
Hi Folks, I wouldn't mind lending a hand on here a a few hours a week and help fix bugs or write tests for some GO code. I've been practicing and learning about GO and would like to get immersed a little more into OSS more. This seems like a great opportunity. I plan on actually trying to implement mux for personal use.
I will check back later for any responses and help out with any open issues.
Cheers!
Hello everyone, I have submitted a PR to the schema project gorilla/schema#183 for a while now. Anybody would be interested to review and give feedback. This could be the opportunity to show project maintainers our collaboration, team skills, and maybe we could be chosen as project maintainers.
I am interested in schema project because it looks like approachable and likely to not very time consuming to maintain.
@elithrar Hi, brother, I am the maintainer of the micro service framework Kratos. In Kratos, transport/http is based on mux, and mux based HTTP declaration code can be generated through the proto-gen-go-http tool. The Kratos open source community is willing to participate in mux future maintenance tasks.
@elithrar mux is a very good project. If it can, it will be maintained by Kratos open source community, not myself. Drive project maintenance through the open source community.
@elithrar I am the author of go-doudou microservice framework. Its http part is heavily relying on gorilla/mux library. I love gorilla Toolkit and want to be its maintainer. It's my honor and dream. Here is go-doudou repo: https://github.com/unionj-cloud/go-doudou for your reference.
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.
@elithrar Hey, I just wanted to say 'thank you!' These packages have been around since nearly the beginning, and it's pleasure to see them in use because they're easy and fast to use. I personally don't have time to dedicate to being a maintainer or contributing in a serious way. I just want to reassure you and whoever else that does/will manage this collection of code that it is much appreciated. If there are ways to contribute that don't require a big time commitment, I'd love to help.
Hi, Please consider some help from my side, ... volunteering, of course.
Not having plenty of time, but anyway :-)
Hi bro, first thanks for your time and project, I think I can’t match the requirement for the maintainer status, really in OSS since 1 months but I slice in 👀 and if any want help or support, I’m here !
Lot of my private project use mux, and my first OS project too, have a good day !
I'd also like to help out when/where I can. I'll start going through open issues and hopefully open some PRs. I would also happily close out all the bogus issues too. (i.e. issues with a question that has been answered answered, random opinions, someone reporting a non-bug as a bug, etc.)
I don't have a ton of OSS contributing experience but I've done some FOSS contributing over the last 8 years (that's how long I've been writing software professionally). The two main projects I contributed for were for first, hospital run (this was like 5-6 years ago probably), and then more recently (~ 2 years ago) faker. I'm happy to start out with whatever you feel comfortable letting me work on.
Is there anyone currently helping with gorilla/csrf?
I have spent a lot of time in the code recently in order to create working example code, but the issue and my PR to solve it have not been touched.
I am happy to help where I can on that project as I have spent a lot of time with it, but I am not a CSRF/web security expert by any means
Just a general question for me and some people commenting here that seem to be on the same "state" with go as I am - are you looking for someone to
actively work on the project as someone who is an expert in go
or
is it rather a matter of "this PR is upvoted by 20 people and downvoted by 2 people with only one comment that's rather off-topic so I will merge"?
If it's the latter I think you will have a few candidates here (me included). The project seems to be very advanced already and looks stable to me so I suppose there is no foundation work to be done anymore anyways
Understandable, that's the most I could offer but fingers crossed you will find someone that fits for this due the impact as you call it, 15k+ stars really is a lot
Someone that can actively take over - but given the impact of this library, that needs to be someone with a proven track record. I can’t just pass the library over to a stranger (supply chain risk), nor someone who is just going to merge anything based on “upvotes”. It’d be better for the community to make it read-only.
I would still prefer to give myself a second chance here. I still believe we can maintain and improvise. Previously, I got a bit busy with Gutenberg because there were multiple things happing around it. I was added as an OSS team member. In gutenberg I triage issues, review PRs, join weekly meetings (most of the time) and work as a regular contributor. I can continue same with the Gorilla projects.
Just for everyone (including me as well 😅 ), I had few interactions with the maintainer @elithrar , when I initially started with the handler project, what I understand so far is that he is looking for someone who is decent enough with the technical concepts and fundamentals. Also mature enough to take right decisions for the project.
For extra clarity, many people have offered to contribute, but the number of open issues and PRs remains almost the same.
Demonstrating "an active history of contributions" is not going well. The only place I need to step in right now is to merge, after someone else has explicitly reviewed. That's just not happening.
(I think about 4-5 PRs were triaged by others since this first post across all Gorilla projects)
Hi @elithrar 👋, Firstly I would say, a big thank you for keeping these projects around for developers. I can understand your situation and would love to volunteer for the Websocket, Mux, and Handlers library.
I can contribute to reviewing PRs, fixing issues, and adding documentation. I can give on average 2 hours daily for maintaining the project.
PS: Shoutout to @amustaque97 for talking me through the maintainer requirement 🔥
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/