Relying on @chris48s for maintenance is deprecated and will be removed in a future release

[chris48s]

Often maintainers kind of drift away from a project. They lose interest, stop responding to issues, etc. It looks like this:

I ain't going down like that. But also, I do need to stop doing this.

Having worked on shields since the end of 2017, I have reached a stage where I am no longer really motivated to work on the project anymore. I can force myself to do a chunk of work on it. I am still getting things done, but it has become a chore rather than a hobby. I'm just doing it because I feel obligated. So it is time to stop. I've taken this thing as far as I want to.

In open source, we often deprecate a feature for some period of time before we remove it. I am going to handle this the same way: As of today, relying on @chris48s to maintain shields is deprecated. It will still kinda work for a bit, but you need to be making plans to migrate away from it. On 31 July 2025 this "feature" will be removed completely.

I want to give the community some time to plan where next and I feel like that is a reasonable amount of time to allow that to happen. What I am doing is imperfect, but stepping down in an orderly fashion feels better than just gradually losing interest and drifting away from the project without explanation. This is often the way maintainers exit a project.

There are three areas that are high priority for me to continue staying on top of over the next ~2 months:

• Security: Highest priority will be any security issues reported in accordance with our security policy. This is not an invitation to submit standard bug reports as security issues :)
• Availability and incident response: Anything related to service availability and uptime will remain high priority for me over the deprecation period.
• Handover: Anything that is related to helping other maintainers or contributors to take over tasks which are currently handled by me is high priority for ensuring the continued success of the project.

Beyond that, I plan to wind down gradually. There are certain tasks I have which are already in-flight, and I aim to see them through before disappearing where possible. I will also continue to review some contributions where I can. Bug fixes and PRs relating to maintaining the existing functionality and keeping the lights on will take higher priority. PRs adding new features and new badges will take lower priority.

So.. where next for shields?

For some time I have been the most active maintainer of the project by quite a margin. I am aware this will have an impact and does present some problems to solve. That said, shields is not "my" project. Shields existed for many years before I started contributing and in principle it can continue to exist without me. However if this is going to happen, it will require the remaining maintainers (and/or some new ones) to take responsibility for some of the things that I have been doing. I'm happy to do what I can to try and ease that transition.

/cc @calebcartwright @jNullj @paulmelnikow @PyvesB

Happy to talk about next steps here or by other channels (Discord, Zoom, etc), but I did want to post this on the repo so that some of this discussion can take place in public. I think it is beneficial to be transparent.

[PyvesB]

First of all, thank you for all the work you’ve put into Shields.io and your ongoing maintenance efforts. I’ve genuinely enjoyed working with you and collaborating on this project over the years.

Our biggest challenge has been attracting new maintainers. Looking back, most of us—platan, RedSparr0w, calebcartwright, paulmelnikow, chris48s, and myself—joined the project between 2017 and 2018. Since then, only jNullj has joined as a team member, with a relatively modest number of contributions so far. Meanwhile, of those who were active between 2013 and 2018, only the two of us have continued contributing code in recent years. Most others have become inactive, which, as you mentioned, is understandable—people lose interest, move on to other projects, or have other priorities in life, and that’s perfectly fine.

Personally, my involvement in recent years has been cyclical—I’ve had periods of activity and periods of stepping back. Right now, I’m in a pause phase. With significant travel and other commitments planned until the end of July, I won’t be able to increase my involvement sizeably for now, even though I still enjoy working on the project.

Looking ahead, bringing in new contributors in the coming months is essential—otherwise, we may eventually have to consider sunsetting the project.

[chris48s]

Thanks

With significant travel and other commitments planned until the end of July, I won’t be able to increase my involvement sizeably for now

This is useful info.
I put a date on this because I think it is important to set some kind of finite timescale and a deadline to work towards. That said, my choice of July 31st is a bit arbitrary. I wanted to pick a date far enough away that there is some warning and ability to get some things done in the "deprecation" period, but near enough that there is some sense of urgency. However there is not a concrete thing happening on August 1st. If I were to move that date a few weeks into August, would that allow us to do useful handover that is not otherwise possible? If it meaningfully changes the game, I'm happy to push this date out a bit, but I do want to set a defined cutoff point we are working towards.

[calebcartwright]

Relatedly, I've got some bandwidth but I'll also be out doing summer holiday things through the majority of July and first week or two of August. Should be able to page things back into memory and help a bit more the back half of August

[calebcartwright]

I find myself having several thoughts and reactions to this, and anticipate articulating them in a manner that won't be anywhere near as thoughtful and well structured as your initial post so apologies in advance for the scattered and rambling response.

First, I wholeheartedly echo P-Y's sentiments: thank you so much for everything you've been doing Chris. I've had the recurring thought "Chris is having to do way too much on his own, that's not fair, I should at least check in with him on a personal level" but repeatedly failed to do so. I feel like I left you hanging on your own, and for that I'm truly sorry.

Second, I've seen other open source projects have a policy (even informally) where if the number of active members on a maintainer team drops below a previously agreed upon threshold, then the top priority for that team (above anything and everything else) is to find enough new members to get back above that threshold.

I feel like Shields hit this scenario years ago, and we recognized it and at various points spoke of the need to try to get new maintainers. However, I do not think growing the maintainer team to some target number was ever explicitly a top priority and it's just been gradual (and as you noted quiet) attrition ever since.

Third, I think a key aspect of maintenance for "Shields" that's likely overlooked by many is the operational burden. It's not just a library, it's not just a codebase, it's also the shields.io service that comes with a very, very significant time and effort demand to keep running due to the sheer scale and breadth of consumption. The fact that a disproportionate amount of this work fell on the shoulders of one person is all the more reason to celebrate and thank Chris for his work, and to validate this entire post.

Fourth, On a personal note, I'm just no longer able to allocate the same amount of my personal bandwidth to open source as I was in years past. Due to employment constraints, my ceiling for open source work has always been limited to nights and weekends and with life changes over the past couple years that bandwidth has reduced significantly. Shields is one of a small number projects on which I try to keep a pulse check, with varying degrees of success, but I rarely even get a chance to look at notifications for others. I've been able to maintain availability for meetings, some discussion and decision making, and occasionally code reviews, but it's exceptionally uncommon for me to have time to get some coding done (something I find disappointing and occasionally frustrating for many reasons).

Reflecting fully, I also have to consider the possibility that some level of emotional drain has been a factor that unconsciously hinders motivation as well. I can't help but feel that over the years the dynamic of open source has evolved and that maintainers today have to navigate dealing with a greater number of entitled users and unpleasant interactions than in years past (at least anecdotally I find I see this more frequently than I did a decade ago). It's challenging enough to begin with to sacrifice your spare time to support an open source project, even more so when it feels like it's become an obligation that's going to including some draining unpleasantness.

Realistically, I don't see any massive changes in my bandwidth for the foreseeable future. I believe I could make more time for Shields and have some level of availability approximating a decent percentage of what I was able to do in the past, but there's no way I could make the type of sacrifice that you've been making Chris, nor do I think any one person should have to.

Finally, the prior comments and thoughts around moving ahead make sense to me. I think a "call to action", publicly and loudly, was warranted and I think this will serve that purpose. I fully agree that growing the maintainer team is crucial, I'd go so far as to argue for it being a top priority, and I'm happy to do whatever I can to support that.

I still fully believe in Shields, both as a project and in purpose. I've long postulated that it's transitively had a positive effect on software quality at a massive scale, as I suspect the culture of projects having badges played some part (however small) in motivating projects (however small) to use tools and systems that help facilitate best practices, e.g. continuous integration, automated testing and coverage tracking, etc.

I hope we can find a good path forward

[jNullj]

I can't thank @chris48s enough for growing & maintaining the project, not just because it keeps alive an open and useful tool, but also for letting me learn and grow in the open source space. It's a delight to work with you.

As @PyvesB rightly pointed out, my contributions have been modest, and managing time remains a consistent challenge, a sentiment I believe resonates with many in the open-source space. While I am motivated, my current professional commitments, particularly an unpredictable load in a project at work and some lingering responsibilities from my previous employer, significantly impact my ability to forecast my available bandwidth. I hope this info provides some insight into my current capacity constraints.

To make better use of that little time i have, and due to the upcoming change, I think that i should focus more on maintenance and operations, my latest work focused around making changes and adding features rather then improving the project's health so we can better response and reduce stress where we can.
For me code (and electronics) is like "toys", I sometimes lose track of the impotent of project goals, so this does serve like a reminder to be a bit more responsible project management wise.

I think we should estimate the project's health so we can set a goal, it doesn't have to be a hard goal but rather a guideline so we know how to move forward. What I fear might limit us in the end is our ability to attract maintainers/the number of available potential maintainers who are willing to contribute regular.

I will probably learn some operations related skills/responsibilities up to the deprecation date, so looking forward for that, looking forward for that.

Hope we can grow stronger while safely deprecating a grate feature.

[paulmelnikow]

Wanted to let you know I've read your post Chris, and the team's responses. I so appreciate your work on the project and admire how much you carried on your own.

Shields feels like important infrastructure, both for open-source and otherwise, and I'm interested in ensuring it continues to operate if it can. I'm offline through Monday but have a few thoughts, including my historical perspective, which I'll try to share within a few days of getting back on Tuesday. (I've also got a separate half-drafted note about the bookkeping.)

I wonder if it's worth making a separate post looking for core maintainers – people who may want to step in and dedicate a meaningful chunk of time to this project. Maybe 6+ hours per month – I imagine that's the minimum?

While I don't know how likely it is, seems clear that finding 1 or 2 such people would have a big impact on the next chapter.

[chris48s]

First of all, thanks to everyone for your kind and supportive words.

Before doing this, I thought quite carefully about what I wanted to do, and the words I wanted to say to explain it. I was unable to predict ahead of time what the responses would be though. So it has taken a little while to digest them. There are a few specific points that I want to pull out (from multiple authors) and respond to or expand on.

a key aspect of maintenance for "Shields" that's likely overlooked by many is the operational burden. It's not just a library, it's not just a codebase, it's also the shields.io service that comes with a very, very significant time and effort demand to keep running due to the sheer scale and breadth of consumption

Yes. The way I would frame this is: The work that I've been doing over the last few years really involves wearing two quite differently shaped hats. We've tended to think of them as a single role, but I think it is probably useful to develop this point more explicitly as people start to think about how to grow the team.

What we refer to as "shields" is really three things:

1. The badge-maker NPM library
2. The shields docker image (consumed by both shields.io and users who self-host their own instance)
3. The Shields.io service (which we can view as the docker image deployed to some infrastructure)

If we just think about the first two, what we're fundamentally maintaining there is a codebase. The process of maintaining them looks pretty much like maintaining any other open source library or product. You write code, you review PRs, you put out releases (either to NPM or DockerHub). This part of the work tends not to throw up too many super-urgent issues. They happen from time to time, but a lot of this stuff is not time-sensitive. You can get away with dipping in and out of it a bit. It is also possible to put certain guard rails on this. For example you can give someone push access to the repo, but still say you must have a review from another maintainer before you can merge stuff. We've also separated permission for "push to the repo" from "deploy the app to production", for example.

The third part of this (maintaining the shields.io service) looks a bit different. This can involve deployments, incident response, etc, but also things like right-sizing our infra in response to traffic levels and the available income we have from donations.

The good news about this is that we've designed our infrastructure to be simple and low maintenance as far as possible. In a typical week, I actually spend ~zero hours worrying about this.
The bad news is: It will sometimes require someone to spend a chunk of time on it urgently. This might happen at a convenient time. It might happen at an inconvenient time, and it is basically impossible to plan around it. When that happens, it tends to fall into two categories:

• Some kind of outage, downtime, or incident
• We need to respond to some kind of upstream platform change (for example: fly requires us to migrate from fly apps v1 to fly apps v2, or is introducing throttling for shared-CPU instances, or whatever)

This kind of work often needs urgent attention, or has some kind of hard deadline associated with it. It can sometimes look more like an "on call" role than an "open source maintainer" role. It is also not like most open source work in that it is sometimes invisible. It often doesn't result in a pull request or a commit - you don't get any little green squares on your GitHub profile for doing it. This work also requires quite a high level of trust with very few guard rails. To meaningfully work on this stuff you do really need the keys to the kingdom. Once you've got the ability to deploy an image to fly, you can deploy any old docker image. Doesn't necessarily have to be one from https://hub.docker.com/r/shieldsio/shields/ . Once you have access to CloudFlare, you can point shields.io anywhere, etc. In order for someone to help with this, we've got to have a high level of trust in them. With the codebase, sometimes we can lean on the community to contribute fixes but it is harder to "crowdsource" this kind of infra maintenance in the same way.

As I say, a lot of the time this actually just hums away looking after itself with no intervention, but sometimes this will throw up a problem at you to solve at a completely arbitrary point in time. This makes it hard to frame the commitment needed in terms of "hours per week/month".

---

I can't help but feel that over the years the dynamic of open source has evolved and that maintainers today have to navigate dealing with a greater number of entitled users and unpleasant interactions than in years past (at least anecdotally I find I see this more frequently than I did a decade ago)

Yes. I think at the time we first got involved in this, the prevailing mood in open source was something like "hey if we all just chip in and do our bit then we can make this thing work together". That is not really the vibe anymore. There are still some really positive interactions and fruitful collaborations to be had on GitHub. Nice people acting in good-faith still make up the majority of interactions. At the same time, being a maintainer of a large open contribution bazaar style project involves dealing with a larger number of spammers and scammers than it once did. This is one of the contributing factors that has lead to this becoming a less rewarding thing to spend my time on. It is not the whole thing, but it is a factor.

---

Our biggest challenge has been attracting new maintainers

Looking ahead, bringing in new contributors in the coming months is essential

growing the maintainer team is crucial

etc

I fully agree in principle, but I am not sure I have much of a plan to offer. My attempts at community building over the last few years have mostly come up short.

---

otherwise, we may eventually have to consider sunsetting the project.

This is an outcome I don't want to see, and I'm trying to approach this in a way that avoids that outcome if possible. However, I accept it is a possible future. I guess the thing that has changed is how committed I am to preventing it.

There is probably an interesting duality here:

I expect a call for new contributors and maintainers while the project still ostensibly "works" may not move the needle much. The many eyes of the bazaar will temporarily avert their gaze.

However, if we (you? we?) go completely nuclear and there is suddenly a row of at the top of every README on GitHub, I expect someone pops up wanting to fill that space in one way or another.

[CorentinChauvin]

Hello Chris, and all.

I am a random user, and just stumbled upon this post. Regarding looking for new contributors, have you tried advertising your project on some open source forums? For example the subreddit r/opensource is quite active, and there are occasionally people looking for projects to contribute to there.

In any case, good luck for what comes next.
Corentin

[LitoMore]

Are you looking for the new maintainer? I'm the maintainer of the Simple Icons project. Some Shields.io logo-related features and fixes were contributed by me. I should be able to help maintain some (review PRs, solve issues). And I am also interested in the infrastructure part.

[calebcartwright]

@LitoMore - indeed, and I think it's good to look at the need across two dimensions.

On one dimension, the project itself (the codebase & the artifacts we produce like the npm package and badge server docker image) needs more maintainers to provide typical open source project support in the form of triaging, PR reviews, user support, etc. On the other dimension, we've got a real operational bandwidth issue for the Shields.io service which is the defacto centralized instance of the badge server utilized globally to the tune of around 50M requests per day.

You've been a very supportive member of our community with some very substantive contributions and we've enjoyed our collaboration with you through Simple Icons as well, so I think you'd be a great candidate for getting more involved and we'd be happy to chat more (either here or in Discord)

[LitoMore]

@calebcartwright Our Simple Icons CDN is using the same cloud service (Fly.io) as Shields.io and is maintained by me. It receives approximately 50M requests per month.

I've sent you a friend request on Discord. Feel free to DM me if you'd like to discuss anything in detail.

[calebcartwright]

I'll publicly recap a few points from some recent offline conversations, but the tl;dr would be:

the bigger concern/issue is the operational burden of running the main Shields.io instance (particularly the on-call aspects), we probably need to do an intentional temporary brownout to highlight the issue, and if we don't find a viable solution then we'll be forced to consider more drastic actions.

additional points that have been discussed (sharing for awareness, not implying consensus/categorical agreement):

• we feel pretty confident we can rally enough new people alongside some existing maintainers to help with general project maintainership
• operating the main centralized instance is very concerning, and the current model of a very small group of volunteers maintaining a single, centralized badge server with the volume of traffic shields.io instance serves, is is not a model we believe to be tenable
  • replacing Chris with another 1-2 volunteers doesn't fundamentally solve the problem
  • shifting the traffic to any other single centralized instance supported by a couple volunteers (e.g. badgen) doesn't fundamentally solve the problem
• the shields.io instance has in a sense become an element of "developer infrastructure"
  • it's adoption and usage is broad (~50M requests per day)
  • outages have widespread impact, even though that impact is less "severe" compared to other broadly used tools/services (a shields.io outage doesn't prevent code nor dependencies from being downloaded/updated, doesn't block compilation/testing/packaging/deployment/etc.)
• more operational/on-call support is critically needed
  • for a purely volunteer model to work, there would need to be a large number of trusted volunteers (no precise number estimated yet, just would need to be substantial based on what we've seen)
  • perhaps some foundation or non-profit would be able to offer some fiscal support that could make the operational roles more viable and tenable for a team
  • perhaps some entity with adequate financing could fully take over the operational burden of running the defacto centralized badge server instance
  • perhaps we need to separate the project/codebase from the centralized instance and shift to a more decentralized model where individual groups/communities run their own instance of the badge server
• we'll likely need to do a brownout for some number of days to highlight the issue to the community at large
  • exact duration TBD
  • we'd have communications prepped and ready before flipping any brownout switch
  • brownout would do something like converting all badges to some sort of notice pointing to the announcement (e.g. all badges display shields brownout | see issue 12345 instead of the usual things like build | passing )
  • alternative could be to just disable/refuse to return badges, although this would result in some massive traffic spikes on the cluster when end the brownout

[paulmelnikow]

Chris, wanted to applaud you for taking such a deliberate approach to departing the project. I’ve been on both sides of the typical departure mode, and how tough it feels, so I really appreciate your making the effort to consciously wrap up and force a conversation. It’s extra true given the outsize impact your leaving has on the project.

---

I appreciate the idea of dividing the operation and general maintenance roles to the extent possible. When we first set up the ops team we had discussed this approach then too – though I think in practice the division didn’t hold up. Of course some issues overlap, such as the need to decline badge contributions which have a heavy system burden. But the main reason I think is that the same people were doing both roles. Dividing maintainership and operations into separate roles feels like a positive direction, because when you’re wearing all the hats at once, it’s so easy to get burned out or stop having fun.

One approach that comes to mind is to professionalize the critical ops layer, while continuing to rely on volunteers for the codebase.

The way my business is set up, I have a lot of experience managing part-time contract resources. I could imagine trying that here: that is, bringing on one (or two) trusted people on retainer with an hourly rate for overage, and engaging another trusted resource to provide technical oversight and relief coverage.

Shields is a public service. Our users are developers, who are relatively well off, and also software teams who theoretically have deep pockets. Free-riding will always be huge for a project like this. However I’d observe that this is a very inexpensive project to operate relative to the scale of its impact. Even if 99.5% of our users never donate, a few of them making modest contributions could easily bring in some cash.

I think this is especially true if we were to introduce intermittent sponsorship requests – brownouts, as Caleb has described them. These could be really targeted – for example, during 30 minutes per week, the badge server could serve a small fraction of the non-static badges saying shields.io needs your support | please donate or similar, with a short TTL. The frequency of the “begware” displays could be tied to some metric, like the number of months of operational runway on hand.

This is a bit like the way public radio and television are funded in the United States. Compared to such ventures Shields is way cheaper to operate, so I’d expect we’d have to do less nagging than they do. Wikipedia does this too – with some regularity, they put up donation banners requesting support. A good thing about begware is it simply wouldn’t be triggered if we have enough cash, so if some large future cashflows manifested less nagging would happen.

Our developer users have valuable eyeballs. If you have been to San Francisco you know how much the city and its transit system are just plastered with tech-company ads. Selling ads is another approach we could take – on shields.io. This could be done directly, or as Chris has mentioned, with a carefully chosen partner like EthicalAds.

It goes without saying that I’m really fond of Shields, and don’t want to see it sunset. Sure, I could imagine trying to get a big company to take it over, or another OSS project like the PSF. Though my preference would be to see it continue to function as an independent community project, so I’m inclined to “get creative” thinking about how to set up a modest administrative infrastructure to sustain it.

If we can work out the parameters wisely, I might be open to carrying the management work for an ops contractor.

[chris48s]

One approach that comes to mind is to professionalize the critical ops layer

Currently shields generates beer money.
To pay a professional, you need rent money.

Selling ads is another approach we could take – on shields.io. This could be done directly, or as Chris has mentioned, with a carefully chosen partner like EthicalAds.

It is a bit of an unknown, but I think if Shields went down the route of serving ads on the frontend via a network, the project would probably generate tens of additional dollars in income per month. Perhaps even hundreds. That could be useful and give the project a bit more breathing room on hosting costs, but I don't think it pushes you into the realm of "rent money".

I actually wrote up a bit more on this but I never ended up posting it anywhere because I knew I didn't really have it in me to carry this forward, but at this point it is pretty unambiguous that I'm not going to take on a project like this now. Fundamentally, if the project even wants to experiment with this, someone needs to commit the time to take it forward and make it happen. I may as well at least share my research.

Note: For this section, turn your ad blocker off. Otherwise it will make no sense. You'll be following links thinking "wtf - there's no ads on this page" 😀

If shields did want to go down this route, I think the most promising ad network to look at first would be Ethical Ads https://www.ethicalads.io/

Ethical Ads is an ad network spun out of the ReadTheDocs project. There are several important points to note about Ethical Ads:

1. It is a non-tracking ad network. The ads the user views are tailored based on the content of the page the ad is embedded in, not data about the user who is viewing the ad
2. It is an ad network specifically advertising developer-focused products on developer-focused sites
3. They can pay out directly into OpenCollective

You'll see Ethical Ads on https://eslint.org/ and projects that use ReadTheDocs like https://tomlkit.readthedocs.io/en/latest/ and https://bandit.readthedocs.io/en/latest/ (remember - adblocker off to see them)

There are obviously some tradeoffs to consider with this approach:

1. Everyone hates ads
2. Although Ethical Ads is a non-tracking ad network and does not set cookies, they do require some minimal data to be shared. They have to determine what is a valid "view" etc. This would require some updates to the privacy policy. There would possibly be some backlash from a subset of the userbase if the project does this.
3. We don't really know how much traffic we get. Ethical Ads are looking for developer-focused sites that get over 50,000 pageviews per month. Obviously shields serves a crap-ton of requests, but most of our traffic is not on the shields.io frontend. It is badges embedded in other people's READMEs. Based on stats from CloudFlare, my best estimate is we get around 60k pageviews/month on the frontend . You can probably reasonably claim to be in the 50-100k band at signup time. Crucially, this also means we don’t really know how much ad revenue the project might actually generate without trying it. It depends where our actual traffic on the frontend is. Ad revenue might represent a small boost to donations or fully fund the project's hosting costs. You can get some idea from plugging numbers into https://www.ethicalads.io/publishers/calculator/

The other ad network worth mentioning here would be https://www.carbonads.net/ At some point in the past they actually proactively contacted @PyvesB about advertising on shields.io. This comparison obviously cherry-picks criteria, but the points are compelling in favour of EthicalAds nonetheless https://www.ethicalads.io/alternative-to-carbon-ads/

I think there are a few reasons why serving ads is an appealing approach:

1. It represents a "business model" of sorts. There's a transaction going on: Shields shows ads, network gives the project money. The project would be not completely reliant on the kindness of others for ad income so it should be a less volatile source of income than donations.
2. On some level, revenue should scale with the userbase. At least more people using the site --> More ads get served.
3. With Ethical Ads specifically, they can pay into OpenCollective

[calebcartwright]

Took me a while to find the link but just wanted to share this as a (successful) example of a split of project/maintainership and service operational roles with a foundation providing the needed support for that on-call element

https://rustfoundation.org/media/adios-pagers-new-developments-on-crates-io/

[chris48s]

We are now around halfway through the deprecation period, so I thought it would be good to post a bit of an update on what has happened so far and what happens next.

Handover

@jNullj has requested to take on some additional responsibilities. One of the things I've been working on is helping him to do that.

@jNullj now has access to deploy the shields.io application to production, push the badge-maker package to NPM, etc. We'll continue to work on this stuff over the next few weeks.

It has been really awesome working with him on this, and we're making good progress.

Permissions and Access Controls

There are quite a large number of systems and resources I have access to. I'd like to make sure there are not any important things where I am the only person who has access to them over the next few weeks. That said, I don't plan to completely scorch the earth on permissions at the end of July. It is probably useful (at least in the short term) if I've still got the ability to give people permission to access things as the project onboards new people. That said, in the slightly longer term I would encourage the team to keep this under review and revoke my access to things if and when it becomes more of a risk than a help for me to have access to anything. Removing permissions from people who no longer need them is good security practice and I'm not going to be precious about it.

What happens at the end of July

I realise I have not really quantified precisely what I mean by "stepping down". Here's what I am actually planning to do:

• Unsubscribe from github notifications for repos under the badges org. When I say this, I'm not going to block them. If you want to specifically mention me in an issue or PR I will still get a ping and do my best to help out if I can, but I'm going to stop getting notifications about every new PR and issue.
• Unsubscribe from fly email notifications
• Stop checking in on discord regularly
• I'd also like @paulmelnikow to remove me from the list of people who receive [email protected] emails (side note: Who else receives these, and would anyone else be willing to step up?)

That said, my position after that point isn't going to become "I am never willing to do anything to help this project or team ever again". I plan to exit the day to day grind of it but if there is a specific situation where I'm the person who has the knowledge you need, you can mention or tag me and I'll do my best to answer questions or help.

[paulmelnikow]

It is indeed rent money that we need, not beer money. Thanks for sharing that article, Caleb. Fortunately Shields is a much simpler project than Crates! It also does not have the same uptime requirements. Given that I imagine it could be possible to work with a budget in the range of $500–1000/month.

I suggest I step up and serve as an operations director for the time being. I’d start with 1:1 conversations with folks in and beyond my network to get advice on organizing a business effort, and consider whether the project is best served by plugging into a foundation, raising the money on its own, or a combination. I’d want to explore all three options discussed here: ad network, self-sold sponsorship, and nagware.

Since I can’t carry the operational burden myself it may make sense to seek a shared resource from a foundation to keep the lights on. If that can't be done easily, then bring in an interim resource. Thanks to your work, Chris, Shields has very low operating costs. And a healthy runway on its side. Though paying for ops support would deplete it quickly.

Since I stepped back from the project one of the big open items on my mind has been getting the governance on sure footing. This seems like the opportune time to set up a governance committee, responsible for stewarding the project at a high level, including overseeing what I’m doing, approving financial decisions, and major questions like whether to become part of a foundation.

Chris, would you consider sitting a term on the governance committee? I’d guess it's a commitment on the order of 5–10 hours over 12 months.

Also, would you be up for recording an ops overview video with me? Basically I’d like you to teach me, on video, everything you can about the hosting. It’d be similar to the ones I created when we set up the ops team.

[email protected]: Currently these messages go to Caleb, Chris, Paul, and PY. (I’ve just removed Marcin.)

@jNullj I’d love to connect with you on Zoom sometime! Would you be up for it? Could you shoot a message (paul at shields.io)?

One question about the stats. Do sub-pages hit the CDN with a page view, or is it only when the first page is loaded? I’m wondering if that page view count includes all the pages, or essentially one per visit. I also imagine that the home page is cached, and that counting the cached page views would generate higher numbers.