This is a followup to some of the thoughts about being a "maintainer" raised in OpenStack Denver Summit Reflection.

Of the work that I've done in OpenStack, what has felt most relevant to me is the work that has not been related to feature development. In the context of being a "professional maintainer" raised in the post linked above, this makes a lot of sense.

The work that has felt relevant has improved or optimized either the existing aspects of the systems themselves, or the process of creating those systems. For example, Gabbi was created because it was too difficult to test and understand API changes in the Telemetry project. Adding support for environment variables in oslo.config was driven by the placement container playground series which was essentially an exercise in making sure Placement was easy to test and painless to use in experiments.

The playing around that drove that work has exposed (and fixed) more bugs and performance issues in Placement, in advance of common use, than real world use.

More than a year ago I wrote a draft of how I wanted the culture of the Placement project to be different, once it was extracted from Nova. Extraction happened near the start of this year. It's interesting to look back at that draft now.

In it, I discussed why the historical culture of Nova sometimes seemed "mean in at least three senses of the word: unkind, miserly, and poor in quality":

There are many factors that have led to this, but one of them is the way in which the responsibilities of core reviewers have evolved to defend stability and limit change while simultaneously being responsible for creating much of the design and code.

If placement, once extracted, wants to have a different culture it needs to shrug off this history and actively work to do things differently. While becoming a core reviewer will probably be partly the result of creating (and reviewing) features, working on features should be low down on the priority list once someone is a core. Priorities should be:

1. Review changes (from others, primarily users)
2. Fix existing code and tech debt
3. Refactor and refresh code and documentation

Being oriented towards improving existing code rather than creating features has a few effects:

• It leaves a clear and inviting doorway for others to participate.
• It codifies regular refactoring.
• It provides clear safety for incoming new changes to be accepted based on being "good enough" because there's awareness that fixing existing code is part of the process.

That sounds a great deal like what I wrote last week, despite having completely forgotten about the draft from last year: "It probably means writing less code for features and more code (and docs) to enable other people to write features."

For that to be possible, a maintenance-oriented person needs significant amounts of time available for reflection and experimentation. Headspace in which to be able to think. In my too long experience as a software professional, very few software development and/or support teams have recognized the value of headspace, requiring those who want to reflect and experiment to do it outside their normal eight hours or not at all. Hours which are often over-packed with adherence to bastardized and misunderstood versions of agility, despite clear evidence of the value that comes from space to think and discover.