I want to…

…report a problem, ask a question, propose a feature…

Do so normally, on the project’s issue tracker, or as detailed in their documentation and/or contribution guidelines.

…contribute some code, documentation, art, time…

Do so normally, by submitting a pull request or however the project accepts contributions. Make sure to follow their guidelines!

…get features, fixes, my own or others’ contributions merged and released


Wait for the project’s maintainers to do so. They cannot be rushed, and will do it at their pace. That might be days, weeks, months, or even years, but you won’t have to do anything.


Propose a release, and become a temporary releaser. If accepted, you will be responsible for getting the release ready and publishing it, and you will be given rights to do it. Follow the release proposal process.

…become a caretaker

Read this website and consult the project’s own documentation and guidelines. The project may have its own process, but if it doesn't, here's a template you can follow.

…use this for my own work

Include a blurb in your readme explaining that you use the Caretaker Model, with a link to this website. And of course apply its processes and principles! You may also want to set up automation.

The Caretaker Model


An open software project — that is, a software project conducted in the open, without attaching it to either of the two dominant ideologies, “free software” and “open source” — might be started for many reasons, but the most basic of these is that someone, a developer or designer or someone with another skillset entirely but willing to experiment and muddle their way through… had an idea, and brought it into the world, and was willing and able to share it. To open it up.

A vast majority of open software works thereafter see no use beyond their creator’s. A small portion see some occasional use, and an even smaller percentage see more than that. That last category has a tendency to grow. People will find the project, and some will use it. Through social propagation, be that word of mouth, github stars, blog posts, bone fide social media, or stumbling upon it via a google search, more and more people find and use it. And eventually, it happens:


That comes in many forms. I want to distinguish four families: reporting, helping, submitting, and supporting.

In small to medium open software projects, the traditional way work is organised is stratified between three main roles: Maintainers or Owners, Contributors, and Everyone Else.

I want to emphasise that there are no codified rules, no formal document laying out the “traditional” way open projects function. What I describe as such is informal etiquette and culture, and by very nature, is subjective to how I see and have experienced it. That said, some of that way is codified, through the tools we use: GitHub and GitLab both more or less tacitly encode many aspects, as two prominent examples.

With this caveat out of the way, in the traditional way:

The balance of responsibility and effort is heavily skewed up, onto maintainers. In a way, this is organic: projects grow from one idea by one person (or a handful of people), and at that point they do do everything. But when others start using and then contributing to the project, all the overhead also gets added on to that one person.

At the same time, the responsibility grows, as more people use the software. There can be a real feeling of duty that builds. As the creator and now maintainer of the work, you become responsible if or when it breaks. It is very easy for boundaries to blur: users of your software become “your” users, and it can feel like mistakes are a personal failing. As the user base grows, so do their expectations, especially as they start using your work in their production environments. Having that happen is not awful: indeed, it’s a great feeling, of pride, of achievement. But the pressure mounts.

It is completely unsurprising that people burn out. That they have meltdowns. That they feel overwhelmed by what seems like simple, enthusiastic feedback. That some quit open work, or even tech or the internet entirely.

The Caretaker Model is a limited re-organisation of responsibilities and expectations in an open software project, specifically imagined to reduce burnout of maintainers as well as frustration of contributors and users.


The model is built around the concept of releases.

This comes from what the motivation of each external person interested in the work boils down to:

The way the software is consumed is via releases. In between releases, the software may be unstable or incomplete. This is true regardless of the development methodology: even if you have a policy that “the main branch always builds”, what that means is that commits on that main branch may be releases, albeit informally so. And even if the build passes, other aspects may not be ready.

Internally to the project, there is a lot of work left beyond contributions to get to a releasable state. Tidying up, checking work, updating documentation, packaging, recording changes, and more. As seen above, in the traditional way this work is mostly done by maintainers.

In Caretaker, release work is done by “releasers”.

A releaser is a transient role, which only exists for the purpose and for the duration of preparing, making, and publishing one release.

The role of releaser can be assumed freely by a “more permanent” member of the project, or can be assigned, after a proposal, and for a single release, to an external contributor, who then becomes a temporary releaser.

The releaser then owns the release process, and drives it to completion. The project will define a particular process and have its requirements, but in general this may involve any, all, or more of:

Once all that work is done, and the release is out in the world, the releaser’s role is over, and the project returns to a dormant or idle state, awaiting the next releaser to step up, if and when needed.

The “more permanent” members who can assign releasership mentioned above are caretakers.

Caretaking responsibilities are to:

That’s it.

Of course, people who are caretakers may also do many other things, or indeed all other things. Coding, documenting, fixing bugs, answering queries, arbitrating disputes, making decisions, triage, promotion, making art, investigating bugs, thinking about design… being a caretaker is a role, not an identity.

But the core, mandatory responsibilities of the caretaker role are those three things, and only those. As long as a caretaker fulfills those three duties, the project can survive, develop, evolve, grow. Thus, a caretaker’s mandatory duties are kept light, such that even someone who has very little time can achieve them.

The rest of this document delves deeper into how release proposals work, the lifecycle of a release from the perspective of the model, the duties and expectations placed upon both caretakers and releasers, how to become a caretaker, discussions about audience (who should not use the model), scope (what the model doesn’t cover), scaling up, normal and failure scenarios, and automation.


The Caretaker model’s scope only extends to codifying two new roles in the management of an open software project, and the processes these two roles support and require. It is intentionally limited thus, to allow for the wide variety of project strategies and cultures that exist to use the model without compromising on their existing practices beyond what is needed for the model to work.

To avoid any confusion (not an exhaustive list):

Additionally, anything written in this document can be overriden, added on to, or discarded by a project’s own rules. (If sufficient differences occur, it is encouraged that the project instead codifies their own model and doesn’t use the “Caretaker” name, to avoid confusion. See also the meta section.)


From the onset, the Caretaker model positions itself as being for “small to medium” projects.

There is no defined upper bound on “how large” a project can be before it stops being appropriate to use the model: besides the difficulty of measuring “largeness” of a project in discrete terms, the decision to leave Caretaker behind or adapt it for large-scale use must be made by the project itself, for its own well-being, and to achieve its own goals.

There is however a lower bound, which is “one”: a project must have at least one caretaker who responds to requests for the model to work. If the project is abandoned, or if none of the established caretakers respond to and act on requests (within reasonable time), then the model by definition cannot work.

Beyond size, there are other reasons why the model may be unsuitable for a project:

There may be other reasons not stated here: the model makes no claim of universality. Use it if, and only as long as, it fits.

The caretaker role

At the core of the Caretaker model is the eponymous caretaker role.

The role’s sole responsibility is to facilitate the model’s release process. In practice, caretakers will likely also be maintainers, leaders, triagers, or any of the various other roles that projects have, but critically, they don’t have to for the project to function.

The point of the Caretaker model is to enable a way for the project to function when maintainers are mostly away. There is little need for external contributors to go through a release proposal and the entire process when the project’s maintainer or team is active enough to pick up features and cut releases on their own. But when they’re busy elsewhere, be that on other projects, life, or hard at work on tougher features such that they let the release-making fall by the wayside, the Caretaker model offers a low-cost (to them) way for the project to keep evolving.

Additionally, if a user wants a feature right now or a fix to be backported to an old version but the team doesn’t have the time for that, the model allows for the user to get involved directly to achieve their goal.

A caretaker acts as a guide for prospective releasers submitting a proposal, a gatekeeper in only allowing proposals that correspond to the project’s goals, as well as keeping out known bad actors, and an observer-slash-monitor for activity by releasers to catch and mitigate malicious activity.

A caretaker still needs to be available to answer queries and proposals within reasonable time, as defined either by the project or by the default timings in the release proposals section. This is to maintain clear expectations and thus reduce everyone’s frustration.

The caretaker role is a good choice when looking for backup or additional maintainers: instead of taking on a large role upfront, people can take on the much smaller role of being a caretaker, and ease into other roles, while still always providing the assurance of someone else being there for the project in case you turn away from active duty on the project for whatever reason.

It’s important that people consent to becoming caretakers, though, and it should not be made a compulsory step in becoming a titled contributor or maintainer. Besides that this scales poorly, the requirements of being a caretaker may be taxing for some people, or in some situations. This is open software and open development: most likely, you’re all doing this for free. Let roles be voluntary, especially this one.

Detail on the actual duties of the role are in the release proposals and release lifecycle sections, alongside the corresponding responsibilities by releasers.

Becoming a caretaker is a process left to the discretion of the project. A template for prospective caretakers is provided on this site, and if that works for the project no further action is required beyond considering these requests. Otherwise, add a section to your contributing guide (the website’s action header as well as the template itself do instruct people to look there as a first step).

The releaser role

While the caretaker role is the core of the model, releasers do the bulk of the work (in regard to what the model deals with).

Releasers… release. But before they get to the releasing, they also have to become a releaser.

The releaser role is special in that it is transient: it only exists for the purpose of releasing a single release. When that one release is done, the role dismisses itself.

The other way in which it is special is who can wear the role. Most roles get assigned to or taken by members of the project. The releaser role can be like that, but it also can be obtained by a non-member, someone just passing through, an “external contributor,” via a formal process.

The project temporarily gains a temporary member, there to do one thing and one thing only, until that one thing is done, at which time they automatically leave the project again. Even while they’re acting a releaser, they’re not responsible for, not expected to do, and indeed expected not to do, any other task or role covered by the rest of the project’s members.

This process is based in affording trust to fellow developers. There is one obvious security hole here: that someone malicious becomes releaser, adds malicious code, and pushes it out. The Caretaker model is a bet that our trust is warranted and that this failure scenario will not happen enough to warrant not giving strangers that trust in the first place.

This is not a radical step: most projects routinely grant prolific or even just willing contributors more rights (fancy “member” hats, commit bits, release permissions), so a dedicated person can quite easily obtain rights on many projects simply by being helpful, and then turn around and wreak havoc. It happens. It just does not happen enough to put everyone off.

The Caretaker model formalises that process (to establish expectations and reduce frustration) and limits it to a very specific interaction with a clear, well-defined goal (to encourage participation) which has an evident and effective result benefitting both the releaser and the project (to make it appealing for everyone).

To become a releaser under the Caretaker model, a person needs to file a release proposal, which is described in the next section. Then, the project’s caretakers, after reviewing and discussing and possibly asking for more or pushing back on the proposal, either deny or approve it, after which the person becomes a releaser, tasked with accomplishing what their proposal was about. They’re given all the rights necessary for them to achieve that. When they’re done, they relinquish those rights and walk away.

Release proposals