From 09bfaea0faa9e11e3c2a0d2555f80a531e9b98fc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Ber=C3=A1nek?= Date: Sat, 20 Dec 2025 17:28:11 +0100 Subject: [PATCH 01/16] Add a post about what is maintenance --- .../inside-rust/what-is-maintenance-anyway.md | 41 +++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 content/inside-rust/what-is-maintenance-anyway.md diff --git a/content/inside-rust/what-is-maintenance-anyway.md b/content/inside-rust/what-is-maintenance-anyway.md new file mode 100644 index 000000000..6d2d0e11c --- /dev/null +++ b/content/inside-rust/what-is-maintenance-anyway.md @@ -0,0 +1,41 @@ ++++ +path = "inside-rust/9999/12/31/what-is-maintenance-anyway" +title = "What is maintenance, anyway?" +authors = ["Jakub Beránek"] ++++ + +Recently, the Rust Foundation has announced the [Rust Foundation Maintainer Fund][rfmf], whose goal is to support Rust Project maintainers. We are currently cooperating with the Foundation to define the [guidelines][rfmf-doc] of this Fund, such as what kind of work to fund, how to select maintainers to fund and others. One of the questions that keeps coming up is this: *Who exactly is a maintainer, and what work can be considered as being maintenance?* This post provides some observations that might help answer these questions. + +Wikipedia defines software maintenance as "modification of software after delivery", but that does not correspond very well to how maintenance works in open-source or in Rust. There is no single delivery of Rust after which it would switch to "maintenance mode"; we deliver a new nightly version of Rust every day. And if someone contributes a pull request to the compiler, they clearly modify it, but that does not immediately make them a maintainer. Instead, let us try to define maintenance by describing how it usually works in the Rust Project. + +## Keeping the lights on + +We could interpret the word "maintain" literally, in the sense of keeping something in a specific (hopefully working) state over a long time period. And that is indeed a large part of what maintainers do: they ensure that things that work today will still continue working tomorrow. There are many ways in which a software project might stop working properly, so this work is naturally very diverse. It includes activities such as issue triaging, investigating and fixing bugs, dealing with CI failures, responding to security incidents, resolving performance regressions, updating dependencies, making sure that documentation is up-to-date, and many others. + +This kind of "janitorial" work is quite challenging for several reasons: + +- It can be difficult to demonstrate the positive effects of this work on a given software project. Users sometimes assume that if something works now, it will keep working indefinitely. Furthermore, Rust has a very high bar for being reliable (in many aspects of that word), so people are used to the fact that the compiler works correctly, that critical bugs are resolved as quickly as possible, that new releases are published every six weeks, etc. But all that takes considerable effort, even without considering shipping any new features. Therefore, a successful report of maintenance work can be simply "things still work as they used to". +- It can be very unpredictable, because it is hard to estimate in advance what things will break next. This also makes it difficult to plan this work ahead and make promises about what kind of work will get done in a given time period. +- Finding motivation for performing a lot of maintenance work can be a struggle. It is often not work that someone *wants* to do, but work that *has to be done*. That can be draining, especially if that work is done by volunteers. + +## Enabling evolution + +The maintenance activities described above are required to keep a software project working. However, usually that's not *all* we want. Most software projects have a tendency to *evolve* over time, which usually means adding new features and making improvements. Improving the language, compiler, standard library, tooling, etc. might unblock some Rust users, which is great. But what might not be so obvious is that we often need to unblock the contributors who implement these new features in the first place! + +Before someone even starts to implement a new feature, they often want to get a vibe check from someone else knowledgeable with the corresponding part of the codebase, to consult how best to approach the implementation. Furthermore, certain features require complex refactorings to be performed before they can be implemented. Then, once a pull request with a new feature is submitted, someone has to review it. And even once a pull request lands, it can introduce new tech debt, which eventually has to be paid by future refactorings. + +However, it's not only refactoring and code reviews that help make progress on various improvements. Even implementing a new feature can unblock many other contributors, who might want to add other features that depend on it. + +And all of that is another part of what maintainers do. They continuously improve the codebase so that it is easier to land new changes, they review pull requests, and they communicate with and mentor other contributors. This work is crucial to ensure the long-term health of constantly evolving codebases. And it also has a strong second-order effect. By unblocking other Rust contributors, new features and improvements can be landed quicker and more frequently, which in turns unblocks and improves the lives of Rust users. That is a multiplicative effect that strongly benefits everyone! + +However, this work requires a deep expertise in the codebase, which can take a lot of time to gain, continuous time investment so that the maintainer can focus on complex refactorings and also having grit to continuously manage to review tons of pull requests. Yet again, all that can be draining if it has to be performed by volunteers. + +## Conclusion +Based on the observations presented above, we could define a maintainer as someone who ensures that a software project continuously keeps working, but who also does a lot of hard (and often invisible) work to enable other contributors to evolve and improve the project. + +Being a maintainer is challenging, and maybe that is one of the reasons why there seems to be a perpetual imbalance. There are often many people who want to contribute to open-source, by making improvements and implementing new features, as it is often seen as being fun, and implementing a new feature is also a very visible achievement that people can brag about. But there are way fewer people who want to continuously maintain a codebase (especially if they are not paid for it!), as the results of good maintenance are much more difficult to demonstrate, and it more often than not resembles work than pure fun. + +When the burden of maintenance falls on volunteers, it can lead to burnout, and that is something that we want to prevent. Open-source maintenance is hard work, and people who do it deserve to be supported and rewarded for it. And that is where maintainer funding comes in. We are currently trying to find ways to support people who maintain various Rust Project codebases, and how to publicize their great work, which is otherwise often near invisible. + +[rfmf]: https://rustfoundation.org/media/announcing-the-rust-foundation-maintainers-fund/ +[rfmf-doc]: https://github.com/rust-lang/funding/blob/main/design-docs/exploration.md From cbd8026c454f1c7d69829ca82db9635587a4a00f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Ber=C3=A1nek?= Date: Sun, 21 Dec 2025 12:46:08 +0100 Subject: [PATCH 02/16] Extend conclusion --- content/inside-rust/what-is-maintenance-anyway.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/content/inside-rust/what-is-maintenance-anyway.md b/content/inside-rust/what-is-maintenance-anyway.md index 6d2d0e11c..b9c6d5ca5 100644 --- a/content/inside-rust/what-is-maintenance-anyway.md +++ b/content/inside-rust/what-is-maintenance-anyway.md @@ -28,14 +28,19 @@ However, it's not only refactoring and code reviews that help make progress on v And all of that is another part of what maintainers do. They continuously improve the codebase so that it is easier to land new changes, they review pull requests, and they communicate with and mentor other contributors. This work is crucial to ensure the long-term health of constantly evolving codebases. And it also has a strong second-order effect. By unblocking other Rust contributors, new features and improvements can be landed quicker and more frequently, which in turns unblocks and improves the lives of Rust users. That is a multiplicative effect that strongly benefits everyone! -However, this work requires a deep expertise in the codebase, which can take a lot of time to gain, continuous time investment so that the maintainer can focus on complex refactorings and also having grit to continuously manage to review tons of pull requests. Yet again, all that can be draining if it has to be performed by volunteers. +This enablement work of course requires having a deep knowledge of the codebase, but also a long-term focus to perform complex refactorings and grit to continuously review tons of pull requests. ## Conclusion -Based on the observations presented above, we could define a maintainer as someone who ensures that a software project continuously keeps working, but who also does a lot of hard (and often invisible) work to enable other contributors to evolve and improve the project. -Being a maintainer is challenging, and maybe that is one of the reasons why there seems to be a perpetual imbalance. There are often many people who want to contribute to open-source, by making improvements and implementing new features, as it is often seen as being fun, and implementing a new feature is also a very visible achievement that people can brag about. But there are way fewer people who want to continuously maintain a codebase (especially if they are not paid for it!), as the results of good maintenance are much more difficult to demonstrate, and it more often than not resembles work than pure fun. +Based on the observations presented above, we could define a maintainer as someone who continuously ensures that a software project keeps working, but who also does a lot of hard (and often invisible) work to enable other contributors to evolve and improve the project. -When the burden of maintenance falls on volunteers, it can lead to burnout, and that is something that we want to prevent. Open-source maintenance is hard work, and people who do it deserve to be supported and rewarded for it. And that is where maintainer funding comes in. We are currently trying to find ways to support people who maintain various Rust Project codebases, and how to publicize their great work, which is otherwise often near invisible. +You probably already guessed that maintenance work is not easy, and maybe that is one of the reasons why there seems to be a perpetual imbalance. There are often many people who want to contribute to open-source, by making improvements and implementing new features, as it is often seen as being fun, and implementing a new feature is also a very visible achievement that people can brag about. But there are way fewer people who want to continuously maintain a codebase (especially if they are not paid for it!), as the results of good maintenance are much more difficult to demonstrate, and it more often than not resembles work than pure fun. + +While being a maintainer can be challenging, *becoming* one is even more difficult. It is not really possible to become a maintainer overnight, as it takes time to gain deep expertise in a certain part of a codebase, but also to gain trust of other maintainers and contributors. All while continuously doing work that no one else wants to do, as it is often not very exciting. + +We are incredibly happy that we have so many awesome maintainers in the Rust Project, who pour their souls into ensuring that Rust becomes better every day, and who invested enormous amounts of time into becoming experts in certain Rust projects so that they could effectively maintain them. However, many of those maintainers are volunteers, and when so much maintenance burden falls on someone who still has to work another job to pay the bills, it can lead to burnout. And that is something that we want to prevent. + +People who do open-source maintenance deserve to be supported and rewarded for it, and that is where maintainer funding comes in. We are currently trying to find mechanisms for supporting people who maintain various Rust Project codebases, in a way that provides stability and enables them to focus on what they do best: improving Rust. We also want to publicize their great work, which is otherwise often near invisible. With the Rust Foundation Maintainer Fund and other similar initiatives we hope to improve the long-term sustainability of Rust maintainability. Stay tuned for more updates. [rfmf]: https://rustfoundation.org/media/announcing-the-rust-foundation-maintainers-fund/ [rfmf-doc]: https://github.com/rust-lang/funding/blob/main/design-docs/exploration.md From 62bae71ba314143c9c4b0f191d04e385197f953c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Ber=C3=A1nek?= Date: Mon, 5 Jan 2026 20:47:21 +0100 Subject: [PATCH 03/16] Apply Josh's suggestions Co-authored-by: Josh Triplett --- content/inside-rust/what-is-maintenance-anyway.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/content/inside-rust/what-is-maintenance-anyway.md b/content/inside-rust/what-is-maintenance-anyway.md index b9c6d5ca5..620930ec0 100644 --- a/content/inside-rust/what-is-maintenance-anyway.md +++ b/content/inside-rust/what-is-maintenance-anyway.md @@ -14,17 +14,18 @@ We could interpret the word "maintain" literally, in the sense of keeping someth This kind of "janitorial" work is quite challenging for several reasons: -- It can be difficult to demonstrate the positive effects of this work on a given software project. Users sometimes assume that if something works now, it will keep working indefinitely. Furthermore, Rust has a very high bar for being reliable (in many aspects of that word), so people are used to the fact that the compiler works correctly, that critical bugs are resolved as quickly as possible, that new releases are published every six weeks, etc. But all that takes considerable effort, even without considering shipping any new features. Therefore, a successful report of maintenance work can be simply "things still work as they used to". +- It can be difficult to demonstrate the positive effects of this work on a given software project. Users sometimes assume that if something works now, it will keep working indefinitely. Furthermore, Rust has a very high bar for being reliable (in many aspects of that word), so people are used to the fact that the compiler works correctly, that critical bugs are resolved as quickly as possible, that new releases are published every six weeks, etc. But all that takes considerable effort, even without considering shipping any new features. Therefore, a successful report of maintenance work can be simply "things still work as they used to", and consistent maintenance over time manifests as an *absence* of noteworthy incidents. - It can be very unpredictable, because it is hard to estimate in advance what things will break next. This also makes it difficult to plan this work ahead and make promises about what kind of work will get done in a given time period. - Finding motivation for performing a lot of maintenance work can be a struggle. It is often not work that someone *wants* to do, but work that *has to be done*. That can be draining, especially if that work is done by volunteers. +- Maintenance is often not on a roadmap, and often not viewed as high-status work that gets someone recognized or promoted. (This relates to it being characterized by an absence of noteworthy incidents.) ## Enabling evolution -The maintenance activities described above are required to keep a software project working. However, usually that's not *all* we want. Most software projects have a tendency to *evolve* over time, which usually means adding new features and making improvements. Improving the language, compiler, standard library, tooling, etc. might unblock some Rust users, which is great. But what might not be so obvious is that we often need to unblock the contributors who implement these new features in the first place! +The maintenance activities described above are required to keep a software project working. However, usually that's not *all* we need. Most software projects need to *evolve* over time, and Rust is no exception; this usually means adding new features and making improvements. Improving the language, compiler, standard library, tooling, etc. might unblock some Rust users, which is great. But what might not be so obvious is that we often need to unblock the contributors who implement these new features in the first place! -Before someone even starts to implement a new feature, they often want to get a vibe check from someone else knowledgeable with the corresponding part of the codebase, to consult how best to approach the implementation. Furthermore, certain features require complex refactorings to be performed before they can be implemented. Then, once a pull request with a new feature is submitted, someone has to review it. And even once a pull request lands, it can introduce new tech debt, which eventually has to be paid by future refactorings. +Before someone even starts to implement a new feature, they often want to get a vibe check from someone else knowledgeable with the corresponding part of the codebase, or advice on how best to approach the implementation. Furthermore, certain features require complex refactorings to be performed before they can be implemented. Then, once a pull request with a new feature is submitted, someone has to review it. And even once a pull request lands, it may introduce new [technical debt](https://en.wikipedia.org/wiki/Technical_debt), which will eventually need cleaning up. -However, it's not only refactoring and code reviews that help make progress on various improvements. Even implementing a new feature can unblock many other contributors, who might want to add other features that depend on it. +However, it's not only refactoring and code reviews that help make progress on various improvements. Even implementing a new feature can unblock many other contributors, who might want to add other features that depend on it. Implementing a new feature may also unblock new use cases for many Rust users, who can then give us valuable feedback on other fixes or improvements for the future. And all of that is another part of what maintainers do. They continuously improve the codebase so that it is easier to land new changes, they review pull requests, and they communicate with and mentor other contributors. This work is crucial to ensure the long-term health of constantly evolving codebases. And it also has a strong second-order effect. By unblocking other Rust contributors, new features and improvements can be landed quicker and more frequently, which in turns unblocks and improves the lives of Rust users. That is a multiplicative effect that strongly benefits everyone! From dfc695fb084a5ebb270b428033ba84e8582a4ec4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Ber=C3=A1nek?= Date: Mon, 5 Jan 2026 20:47:52 +0100 Subject: [PATCH 04/16] Update content/inside-rust/what-is-maintenance-anyway.md Co-authored-by: Josh Triplett --- content/inside-rust/what-is-maintenance-anyway.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/inside-rust/what-is-maintenance-anyway.md b/content/inside-rust/what-is-maintenance-anyway.md index 620930ec0..7e42bffed 100644 --- a/content/inside-rust/what-is-maintenance-anyway.md +++ b/content/inside-rust/what-is-maintenance-anyway.md @@ -6,7 +6,7 @@ authors = ["Jakub Beránek"] Recently, the Rust Foundation has announced the [Rust Foundation Maintainer Fund][rfmf], whose goal is to support Rust Project maintainers. We are currently cooperating with the Foundation to define the [guidelines][rfmf-doc] of this Fund, such as what kind of work to fund, how to select maintainers to fund and others. One of the questions that keeps coming up is this: *Who exactly is a maintainer, and what work can be considered as being maintenance?* This post provides some observations that might help answer these questions. -Wikipedia defines software maintenance as "modification of software after delivery", but that does not correspond very well to how maintenance works in open-source or in Rust. There is no single delivery of Rust after which it would switch to "maintenance mode"; we deliver a new nightly version of Rust every day. And if someone contributes a pull request to the compiler, they clearly modify it, but that does not immediately make them a maintainer. Instead, let us try to define maintenance by describing how it usually works in the Rust Project. +Wikipedia defines [software maintenance](https://en.wikipedia.org/wiki/Software_maintenance) as "modification of software after delivery", but that does not correspond very well to how maintenance works in open-source or in Rust. There is no single delivery of Rust after which it would switch to "maintenance mode"; we deliver a new nightly version of Rust every day, and a new stable version every six weeks. And if someone contributes a pull request to the compiler, they clearly modify it, but as much as we treasure contributions to Rust, that does not immediately make them a maintainer. Instead, let us try to define maintenance by describing how it usually works in the Rust Project. ## Keeping the lights on From 6a4a5b765a21128cad3987841438a44ceee64f6d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Ber=C3=A1nek?= Date: Tue, 6 Jan 2026 09:32:37 +0100 Subject: [PATCH 05/16] Update content/inside-rust/what-is-maintenance-anyway.md Co-authored-by: Josh Triplett --- content/inside-rust/what-is-maintenance-anyway.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/inside-rust/what-is-maintenance-anyway.md b/content/inside-rust/what-is-maintenance-anyway.md index 7e42bffed..adcd67560 100644 --- a/content/inside-rust/what-is-maintenance-anyway.md +++ b/content/inside-rust/what-is-maintenance-anyway.md @@ -27,7 +27,7 @@ Before someone even starts to implement a new feature, they often want to get a However, it's not only refactoring and code reviews that help make progress on various improvements. Even implementing a new feature can unblock many other contributors, who might want to add other features that depend on it. Implementing a new feature may also unblock new use cases for many Rust users, who can then give us valuable feedback on other fixes or improvements for the future. -And all of that is another part of what maintainers do. They continuously improve the codebase so that it is easier to land new changes, they review pull requests, and they communicate with and mentor other contributors. This work is crucial to ensure the long-term health of constantly evolving codebases. And it also has a strong second-order effect. By unblocking other Rust contributors, new features and improvements can be landed quicker and more frequently, which in turns unblocks and improves the lives of Rust users. That is a multiplicative effect that strongly benefits everyone! +And all of that is another part of what maintainers do. They continuously improve the codebase so that it is easier to land new changes, they review pull requests, and they communicate with and mentor other contributors. This work is crucial to ensure the long-term health of constantly evolving codebases. And it also has a strong second-order effect. By unblocking other Rust contributors, new features and improvements can be landed quicker and more frequently, which in turns unblocks and improves the lives of Rust users, which results in a positive feedback cycle. This is a multiplicative effect that strongly benefits everyone! This enablement work of course requires having a deep knowledge of the codebase, but also a long-term focus to perform complex refactorings and grit to continuously review tons of pull requests. From bae051882b2f88f4e0d7c35635c4c8e6002e916b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Ber=C3=A1nek?= Date: Tue, 6 Jan 2026 09:33:27 +0100 Subject: [PATCH 06/16] Update content/inside-rust/what-is-maintenance-anyway.md Co-authored-by: Josh Triplett --- content/inside-rust/what-is-maintenance-anyway.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/inside-rust/what-is-maintenance-anyway.md b/content/inside-rust/what-is-maintenance-anyway.md index adcd67560..e18d7aba1 100644 --- a/content/inside-rust/what-is-maintenance-anyway.md +++ b/content/inside-rust/what-is-maintenance-anyway.md @@ -35,7 +35,7 @@ This enablement work of course requires having a deep knowledge of the codebase, Based on the observations presented above, we could define a maintainer as someone who continuously ensures that a software project keeps working, but who also does a lot of hard (and often invisible) work to enable other contributors to evolve and improve the project. -You probably already guessed that maintenance work is not easy, and maybe that is one of the reasons why there seems to be a perpetual imbalance. There are often many people who want to contribute to open-source, by making improvements and implementing new features, as it is often seen as being fun, and implementing a new feature is also a very visible achievement that people can brag about. But there are way fewer people who want to continuously maintain a codebase (especially if they are not paid for it!), as the results of good maintenance are much more difficult to demonstrate, and it more often than not resembles work than pure fun. +You probably already guessed that maintenance work is not easy, and maybe that is one of the reasons why there seems to be a perpetual imbalance. There are often many people who want to contribute to open source, by making improvements and implementing new features, as it is often seen as being fun, and implementing a new feature is also a very visible achievement that may help meet someone's needs or give them something obvious to be proud of. But there are far fewer people who want to continuously maintain a codebase (especially if they are not paid for it!), as the results of good maintenance are much more difficult to demonstrate, and it often more closely resembles work rather than pure fun. While being a maintainer can be challenging, *becoming* one is even more difficult. It is not really possible to become a maintainer overnight, as it takes time to gain deep expertise in a certain part of a codebase, but also to gain trust of other maintainers and contributors. All while continuously doing work that no one else wants to do, as it is often not very exciting. From b47f5e552d56d7eee150309f803515032b0254f5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Ber=C3=A1nek?= Date: Tue, 6 Jan 2026 09:33:57 +0100 Subject: [PATCH 07/16] Update content/inside-rust/what-is-maintenance-anyway.md Co-authored-by: Josh Triplett --- content/inside-rust/what-is-maintenance-anyway.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/inside-rust/what-is-maintenance-anyway.md b/content/inside-rust/what-is-maintenance-anyway.md index e18d7aba1..77f9ad337 100644 --- a/content/inside-rust/what-is-maintenance-anyway.md +++ b/content/inside-rust/what-is-maintenance-anyway.md @@ -37,7 +37,7 @@ Based on the observations presented above, we could define a maintainer as someo You probably already guessed that maintenance work is not easy, and maybe that is one of the reasons why there seems to be a perpetual imbalance. There are often many people who want to contribute to open source, by making improvements and implementing new features, as it is often seen as being fun, and implementing a new feature is also a very visible achievement that may help meet someone's needs or give them something obvious to be proud of. But there are far fewer people who want to continuously maintain a codebase (especially if they are not paid for it!), as the results of good maintenance are much more difficult to demonstrate, and it often more closely resembles work rather than pure fun. -While being a maintainer can be challenging, *becoming* one is even more difficult. It is not really possible to become a maintainer overnight, as it takes time to gain deep expertise in a certain part of a codebase, but also to gain trust of other maintainers and contributors. All while continuously doing work that no one else wants to do, as it is often not very exciting. +While being a maintainer can be challenging, *becoming* one is even more difficult. It is not really possible to become a maintainer overnight, as it takes time to not only gain deep expertise in parts of a codebase, but also to gain trust of other maintainers and contributors. All while regularly doing work that many others aren't enthusiastic about doing. We are incredibly happy that we have so many awesome maintainers in the Rust Project, who pour their souls into ensuring that Rust becomes better every day, and who invested enormous amounts of time into becoming experts in certain Rust projects so that they could effectively maintain them. However, many of those maintainers are volunteers, and when so much maintenance burden falls on someone who still has to work another job to pay the bills, it can lead to burnout. And that is something that we want to prevent. From 3eda1ebb476a07c3c2a0f61981b76bc3ebaa85cd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Ber=C3=A1nek?= Date: Tue, 6 Jan 2026 09:34:17 +0100 Subject: [PATCH 08/16] Update content/inside-rust/what-is-maintenance-anyway.md Co-authored-by: Josh Triplett --- content/inside-rust/what-is-maintenance-anyway.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/inside-rust/what-is-maintenance-anyway.md b/content/inside-rust/what-is-maintenance-anyway.md index 77f9ad337..4e722755d 100644 --- a/content/inside-rust/what-is-maintenance-anyway.md +++ b/content/inside-rust/what-is-maintenance-anyway.md @@ -39,7 +39,7 @@ You probably already guessed that maintenance work is not easy, and maybe that i While being a maintainer can be challenging, *becoming* one is even more difficult. It is not really possible to become a maintainer overnight, as it takes time to not only gain deep expertise in parts of a codebase, but also to gain trust of other maintainers and contributors. All while regularly doing work that many others aren't enthusiastic about doing. -We are incredibly happy that we have so many awesome maintainers in the Rust Project, who pour their souls into ensuring that Rust becomes better every day, and who invested enormous amounts of time into becoming experts in certain Rust projects so that they could effectively maintain them. However, many of those maintainers are volunteers, and when so much maintenance burden falls on someone who still has to work another job to pay the bills, it can lead to burnout. And that is something that we want to prevent. +We are incredibly happy that we have so many awesome maintainers in the Rust Project, who pour their souls into ensuring that Rust becomes better every day, and who invest enormous amounts of time into becoming experts in certain Rust projects so that they can effectively maintain them. However, many of those maintainers are volunteers, and when so much maintenance burden falls on someone who still has to work another job to pay the bills, it can lead to burnout. This is something that we want to prevent. People who do open-source maintenance deserve to be supported and rewarded for it, and that is where maintainer funding comes in. We are currently trying to find mechanisms for supporting people who maintain various Rust Project codebases, in a way that provides stability and enables them to focus on what they do best: improving Rust. We also want to publicize their great work, which is otherwise often near invisible. With the Rust Foundation Maintainer Fund and other similar initiatives we hope to improve the long-term sustainability of Rust maintainability. Stay tuned for more updates. From 82e5119066f69f60d8a21bcec425edd7edfc2be3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Ber=C3=A1nek?= Date: Tue, 6 Jan 2026 09:35:03 +0100 Subject: [PATCH 09/16] Update content/inside-rust/what-is-maintenance-anyway.md Co-authored-by: Josh Triplett --- content/inside-rust/what-is-maintenance-anyway.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/inside-rust/what-is-maintenance-anyway.md b/content/inside-rust/what-is-maintenance-anyway.md index 4e722755d..490242da9 100644 --- a/content/inside-rust/what-is-maintenance-anyway.md +++ b/content/inside-rust/what-is-maintenance-anyway.md @@ -41,7 +41,7 @@ While being a maintainer can be challenging, *becoming* one is even more difficu We are incredibly happy that we have so many awesome maintainers in the Rust Project, who pour their souls into ensuring that Rust becomes better every day, and who invest enormous amounts of time into becoming experts in certain Rust projects so that they can effectively maintain them. However, many of those maintainers are volunteers, and when so much maintenance burden falls on someone who still has to work another job to pay the bills, it can lead to burnout. This is something that we want to prevent. -People who do open-source maintenance deserve to be supported and rewarded for it, and that is where maintainer funding comes in. We are currently trying to find mechanisms for supporting people who maintain various Rust Project codebases, in a way that provides stability and enables them to focus on what they do best: improving Rust. We also want to publicize their great work, which is otherwise often near invisible. With the Rust Foundation Maintainer Fund and other similar initiatives we hope to improve the long-term sustainability of Rust maintainability. Stay tuned for more updates. +People who do open-source maintenance deserve to be supported and rewarded for it, which is where maintainer funding comes in. We are currently seeking mechanisms for supporting people who maintain various Rust Project codebases, in a way that provides stability and enables them to focus on what they do best: improving Rust. We also want to publicize their great work—which is otherwise often near-invisible—both to give them something to be proud of, and to attract more support and funding for this critical work. With the Rust Foundation Maintainer Fund and other similar initiatives, we hope to improve the long-term sustainability of Rust maintainership. Stay tuned for more updates. [rfmf]: https://rustfoundation.org/media/announcing-the-rust-foundation-maintainers-fund/ [rfmf-doc]: https://github.com/rust-lang/funding/blob/main/design-docs/exploration.md From a4ca8ee12957eb4e2a491712208aee8afdad8404 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Ber=C3=A1nek?= Date: Tue, 6 Jan 2026 09:37:35 +0100 Subject: [PATCH 10/16] Remove the mention of us defining maintenance --- content/inside-rust/what-is-maintenance-anyway.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/inside-rust/what-is-maintenance-anyway.md b/content/inside-rust/what-is-maintenance-anyway.md index 490242da9..bd211692b 100644 --- a/content/inside-rust/what-is-maintenance-anyway.md +++ b/content/inside-rust/what-is-maintenance-anyway.md @@ -6,7 +6,7 @@ authors = ["Jakub Beránek"] Recently, the Rust Foundation has announced the [Rust Foundation Maintainer Fund][rfmf], whose goal is to support Rust Project maintainers. We are currently cooperating with the Foundation to define the [guidelines][rfmf-doc] of this Fund, such as what kind of work to fund, how to select maintainers to fund and others. One of the questions that keeps coming up is this: *Who exactly is a maintainer, and what work can be considered as being maintenance?* This post provides some observations that might help answer these questions. -Wikipedia defines [software maintenance](https://en.wikipedia.org/wiki/Software_maintenance) as "modification of software after delivery", but that does not correspond very well to how maintenance works in open-source or in Rust. There is no single delivery of Rust after which it would switch to "maintenance mode"; we deliver a new nightly version of Rust every day, and a new stable version every six weeks. And if someone contributes a pull request to the compiler, they clearly modify it, but as much as we treasure contributions to Rust, that does not immediately make them a maintainer. Instead, let us try to define maintenance by describing how it usually works in the Rust Project. +Wikipedia defines [software maintenance](https://en.wikipedia.org/wiki/Software_maintenance) as "modification of software after delivery", but that does not correspond very well to how maintenance works in open-source or in Rust. There is no single delivery of Rust after which it would switch to "maintenance mode"; we deliver a new nightly version of Rust every day, and a new stable version every six weeks. And if someone contributes a pull request to the compiler, they clearly modify it, but as much as we treasure contributions to Rust, that does not immediately make them a maintainer. Instead, let us try to describe how we understand maintenance in the Rust Project. ## Keeping the lights on From 17b0f4636aeff42ae000b80140c936f09fae6e48 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Ber=C3=A1nek?= Date: Wed, 7 Jan 2026 10:02:25 +0100 Subject: [PATCH 11/16] Remove note in parentheses and fix grammar --- content/inside-rust/what-is-maintenance-anyway.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/inside-rust/what-is-maintenance-anyway.md b/content/inside-rust/what-is-maintenance-anyway.md index bd211692b..7eb666f07 100644 --- a/content/inside-rust/what-is-maintenance-anyway.md +++ b/content/inside-rust/what-is-maintenance-anyway.md @@ -3,21 +3,21 @@ path = "inside-rust/9999/12/31/what-is-maintenance-anyway" title = "What is maintenance, anyway?" authors = ["Jakub Beránek"] +++ - + Recently, the Rust Foundation has announced the [Rust Foundation Maintainer Fund][rfmf], whose goal is to support Rust Project maintainers. We are currently cooperating with the Foundation to define the [guidelines][rfmf-doc] of this Fund, such as what kind of work to fund, how to select maintainers to fund and others. One of the questions that keeps coming up is this: *Who exactly is a maintainer, and what work can be considered as being maintenance?* This post provides some observations that might help answer these questions. Wikipedia defines [software maintenance](https://en.wikipedia.org/wiki/Software_maintenance) as "modification of software after delivery", but that does not correspond very well to how maintenance works in open-source or in Rust. There is no single delivery of Rust after which it would switch to "maintenance mode"; we deliver a new nightly version of Rust every day, and a new stable version every six weeks. And if someone contributes a pull request to the compiler, they clearly modify it, but as much as we treasure contributions to Rust, that does not immediately make them a maintainer. Instead, let us try to describe how we understand maintenance in the Rust Project. ## Keeping the lights on -We could interpret the word "maintain" literally, in the sense of keeping something in a specific (hopefully working) state over a long time period. And that is indeed a large part of what maintainers do: they ensure that things that work today will still continue working tomorrow. There are many ways in which a software project might stop working properly, so this work is naturally very diverse. It includes activities such as issue triaging, investigating and fixing bugs, dealing with CI failures, responding to security incidents, resolving performance regressions, updating dependencies, making sure that documentation is up-to-date, and many others. +We could interpret the word "maintain" literally, in the sense of keeping something in a specific (hopefully working) state over a long time period. And that is indeed a large part of what maintainers do: they ensure that things that work today will still continue working tomorrow. There are many ways in which a software project might stop working properly, so this work is naturally very diverse. It includes activities such as issue triaging, investigating and fixing bugs, dealing with CI failures, responding to security incidents, resolving performance regressions, updating dependencies, making sure that documentation is up to date, and many others. This kind of "janitorial" work is quite challenging for several reasons: - It can be difficult to demonstrate the positive effects of this work on a given software project. Users sometimes assume that if something works now, it will keep working indefinitely. Furthermore, Rust has a very high bar for being reliable (in many aspects of that word), so people are used to the fact that the compiler works correctly, that critical bugs are resolved as quickly as possible, that new releases are published every six weeks, etc. But all that takes considerable effort, even without considering shipping any new features. Therefore, a successful report of maintenance work can be simply "things still work as they used to", and consistent maintenance over time manifests as an *absence* of noteworthy incidents. - It can be very unpredictable, because it is hard to estimate in advance what things will break next. This also makes it difficult to plan this work ahead and make promises about what kind of work will get done in a given time period. - Finding motivation for performing a lot of maintenance work can be a struggle. It is often not work that someone *wants* to do, but work that *has to be done*. That can be draining, especially if that work is done by volunteers. -- Maintenance is often not on a roadmap, and often not viewed as high-status work that gets someone recognized or promoted. (This relates to it being characterized by an absence of noteworthy incidents.) +- Maintenance is often not on a roadmap, and often not viewed as high-status work that gets someone recognized or promoted. ## Enabling evolution From 2639047470da5a6608c9c9e19fb3b4c8a3b34875 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Ber=C3=A1nek?= Date: Wed, 7 Jan 2026 10:07:30 +0100 Subject: [PATCH 12/16] Add publish date for next Monday and the RFMF committee link --- content/inside-rust/what-is-maintenance-anyway.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/content/inside-rust/what-is-maintenance-anyway.md b/content/inside-rust/what-is-maintenance-anyway.md index 7eb666f07..5fc5f2d11 100644 --- a/content/inside-rust/what-is-maintenance-anyway.md +++ b/content/inside-rust/what-is-maintenance-anyway.md @@ -1,9 +1,13 @@ +++ -path = "inside-rust/9999/12/31/what-is-maintenance-anyway" +path = "inside-rust/2026/01/12/what-is-maintenance-anyway" title = "What is maintenance, anyway?" authors = ["Jakub Beránek"] + +[extra] +team = "the Rust Foundation Maintainer Fund Design Committee" +team_url = "https://github.com/rust-lang/leadership-council/blob/main/committees/maintainer-fund-design-group.md" +++ - + Recently, the Rust Foundation has announced the [Rust Foundation Maintainer Fund][rfmf], whose goal is to support Rust Project maintainers. We are currently cooperating with the Foundation to define the [guidelines][rfmf-doc] of this Fund, such as what kind of work to fund, how to select maintainers to fund and others. One of the questions that keeps coming up is this: *Who exactly is a maintainer, and what work can be considered as being maintenance?* This post provides some observations that might help answer these questions. Wikipedia defines [software maintenance](https://en.wikipedia.org/wiki/Software_maintenance) as "modification of software after delivery", but that does not correspond very well to how maintenance works in open-source or in Rust. There is no single delivery of Rust after which it would switch to "maintenance mode"; we deliver a new nightly version of Rust every day, and a new stable version every six weeks. And if someone contributes a pull request to the compiler, they clearly modify it, but as much as we treasure contributions to Rust, that does not immediately make them a maintainer. Instead, let us try to describe how we understand maintenance in the Rust Project. From 5a5c09a97830d7e277c4a4136291e8a50a6d8633 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Ber=C3=A1nek?= Date: Wed, 7 Jan 2026 10:10:48 +0100 Subject: [PATCH 13/16] Add link to the funding page and remove the word "define" --- content/inside-rust/what-is-maintenance-anyway.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/inside-rust/what-is-maintenance-anyway.md b/content/inside-rust/what-is-maintenance-anyway.md index 5fc5f2d11..d4f90edf6 100644 --- a/content/inside-rust/what-is-maintenance-anyway.md +++ b/content/inside-rust/what-is-maintenance-anyway.md @@ -37,7 +37,7 @@ This enablement work of course requires having a deep knowledge of the codebase, ## Conclusion -Based on the observations presented above, we could define a maintainer as someone who continuously ensures that a software project keeps working, but who also does a lot of hard (and often invisible) work to enable other contributors to evolve and improve the project. +Based on the observations presented above, we could say that a maintainer is someone who continuously ensures that a software project keeps working, but who also does a lot of hard (and often invisible) work to enable other contributors to evolve and improve the project. You probably already guessed that maintenance work is not easy, and maybe that is one of the reasons why there seems to be a perpetual imbalance. There are often many people who want to contribute to open source, by making improvements and implementing new features, as it is often seen as being fun, and implementing a new feature is also a very visible achievement that may help meet someone's needs or give them something obvious to be proud of. But there are far fewer people who want to continuously maintain a codebase (especially if they are not paid for it!), as the results of good maintenance are much more difficult to demonstrate, and it often more closely resembles work rather than pure fun. @@ -45,7 +45,7 @@ While being a maintainer can be challenging, *becoming* one is even more difficu We are incredibly happy that we have so many awesome maintainers in the Rust Project, who pour their souls into ensuring that Rust becomes better every day, and who invest enormous amounts of time into becoming experts in certain Rust projects so that they can effectively maintain them. However, many of those maintainers are volunteers, and when so much maintenance burden falls on someone who still has to work another job to pay the bills, it can lead to burnout. This is something that we want to prevent. -People who do open-source maintenance deserve to be supported and rewarded for it, which is where maintainer funding comes in. We are currently seeking mechanisms for supporting people who maintain various Rust Project codebases, in a way that provides stability and enables them to focus on what they do best: improving Rust. We also want to publicize their great work—which is otherwise often near-invisible—both to give them something to be proud of, and to attract more support and funding for this critical work. With the Rust Foundation Maintainer Fund and other similar initiatives, we hope to improve the long-term sustainability of Rust maintainership. Stay tuned for more updates. +People who do open-source maintenance deserve to be [supported](https://rust-lang.org/funding/) and rewarded for it, which is where maintainer funding comes in. We are currently seeking mechanisms for supporting people who maintain various Rust Project codebases, in a way that provides stability and enables them to focus on what they do best: improving Rust. We also want to publicize their great work—which is otherwise often near-invisible—both to give them something to be proud of, and to attract more support and funding for this critical work. With the Rust Foundation Maintainer Fund and other similar initiatives, we hope to improve the long-term sustainability of Rust maintainership. Stay tuned for more updates. [rfmf]: https://rustfoundation.org/media/announcing-the-rust-foundation-maintainers-fund/ [rfmf-doc]: https://github.com/rust-lang/funding/blob/main/design-docs/exploration.md From 08b98e865c37c580e7a0149993c6910df21af1c0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Ber=C3=A1nek?= Date: Thu, 8 Jan 2026 20:30:17 +0100 Subject: [PATCH 14/16] Remove sentence --- content/inside-rust/what-is-maintenance-anyway.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/inside-rust/what-is-maintenance-anyway.md b/content/inside-rust/what-is-maintenance-anyway.md index d4f90edf6..2b6cea6d9 100644 --- a/content/inside-rust/what-is-maintenance-anyway.md +++ b/content/inside-rust/what-is-maintenance-anyway.md @@ -29,7 +29,7 @@ The maintenance activities described above are required to keep a software proje Before someone even starts to implement a new feature, they often want to get a vibe check from someone else knowledgeable with the corresponding part of the codebase, or advice on how best to approach the implementation. Furthermore, certain features require complex refactorings to be performed before they can be implemented. Then, once a pull request with a new feature is submitted, someone has to review it. And even once a pull request lands, it may introduce new [technical debt](https://en.wikipedia.org/wiki/Technical_debt), which will eventually need cleaning up. -However, it's not only refactoring and code reviews that help make progress on various improvements. Even implementing a new feature can unblock many other contributors, who might want to add other features that depend on it. Implementing a new feature may also unblock new use cases for many Rust users, who can then give us valuable feedback on other fixes or improvements for the future. +However, it's not only refactoring and code reviews that help make progress on various improvements. Even implementing a new feature can unblock many other contributors, who might want to add other features that depend on it. And all of that is another part of what maintainers do. They continuously improve the codebase so that it is easier to land new changes, they review pull requests, and they communicate with and mentor other contributors. This work is crucial to ensure the long-term health of constantly evolving codebases. And it also has a strong second-order effect. By unblocking other Rust contributors, new features and improvements can be landed quicker and more frequently, which in turns unblocks and improves the lives of Rust users, which results in a positive feedback cycle. This is a multiplicative effect that strongly benefits everyone! From 71f37b3d61941f61cb768055e66edfa533b0fd71 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Ber=C3=A1nek?= Date: Thu, 8 Jan 2026 21:30:41 +0100 Subject: [PATCH 15/16] Add quote Co-authored-by: Josh Triplett --- content/inside-rust/what-is-maintenance-anyway.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/content/inside-rust/what-is-maintenance-anyway.md b/content/inside-rust/what-is-maintenance-anyway.md index 2b6cea6d9..5cdc82d92 100644 --- a/content/inside-rust/what-is-maintenance-anyway.md +++ b/content/inside-rust/what-is-maintenance-anyway.md @@ -39,6 +39,15 @@ This enablement work of course requires having a deep knowledge of the codebase, Based on the observations presented above, we could say that a maintainer is someone who continuously ensures that a software project keeps working, but who also does a lot of hard (and often invisible) work to enable other contributors to evolve and improve the project. + + +These are some examples of the kinds of things we see as needing additional support, including from efforts like the proposed Rust Foundation Maintainers' Fund. We see the work of maintainers as work that has a multiplicative effect on the Rust Project. We have an interest in supporting other types of work with a similar multiplicative effect. + You probably already guessed that maintenance work is not easy, and maybe that is one of the reasons why there seems to be a perpetual imbalance. There are often many people who want to contribute to open source, by making improvements and implementing new features, as it is often seen as being fun, and implementing a new feature is also a very visible achievement that may help meet someone's needs or give them something obvious to be proud of. But there are far fewer people who want to continuously maintain a codebase (especially if they are not paid for it!), as the results of good maintenance are much more difficult to demonstrate, and it often more closely resembles work rather than pure fun. While being a maintainer can be challenging, *becoming* one is even more difficult. It is not really possible to become a maintainer overnight, as it takes time to not only gain deep expertise in parts of a codebase, but also to gain trust of other maintainers and contributors. All while regularly doing work that many others aren't enthusiastic about doing. From 605fba106a45463ebd20cbc2c367d6cf88f73b9a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Ber=C3=A1nek?= Date: Thu, 8 Jan 2026 21:46:37 +0100 Subject: [PATCH 16/16] Tweak styling --- content/inside-rust/what-is-maintenance-anyway.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/inside-rust/what-is-maintenance-anyway.md b/content/inside-rust/what-is-maintenance-anyway.md index 5cdc82d92..af2c520e2 100644 --- a/content/inside-rust/what-is-maintenance-anyway.md +++ b/content/inside-rust/what-is-maintenance-anyway.md @@ -39,7 +39,7 @@ This enablement work of course requires having a deep knowledge of the codebase, Based on the observations presented above, we could say that a maintainer is someone who continuously ensures that a software project keeps working, but who also does a lot of hard (and often invisible) work to enable other contributors to evolve and improve the project. -