I've had "write a summary of ptg and summit" in my todo system for weeks. The summit was more than a month ago, at the end of April. I've been waiting for inspiration, some sense that I have something useful to say about the event. It hasn't come, I don't have anything noteworthy to report, but there has been change.

I started working in the OpenStack community five years ago. I'm on my third employer. The first two I quit, in large part, because of friction between two things: the community's subtextual insistence that if you wanted to be relevant (whatever that really means) you needed to be present at mid-cycles, PTGs, and summits and; employers being unwilling to support my attendance and continuous attention.

There's a great deal wrong with both sides of that situation. Both highlight some of the ways in which despite being an extremely successful (by some measures) open source project, OpenStack has also inspired a degree of toxicity and exclusivity that is anathema to some other measures of open source success.

Over the years, I think I've managed to become pretty relevant in the community, but up until very recently that has come at the (mostly self-imposed, because of a perverse sense of loyalty) cost of 60-80 hour weeks for most of those five years and never once being able to consider myself any of user, operator or deployer of OpenStack. That's not how open source ought to work. There is a boundary between me (a paid labourer creating a ton of value for corporations) and the true users, operators and deployers. In fact my obsessive occupation (and similar occupation by my peers) of any available contribution-space has made it harder for those people to participate. I've helped to solidify a profession or priesthood, but I'm thankfully a vanishing breed.

That profession, perhaps appropriate in 2015 or thereabouts, is now actively damaging to the matured OpenStack community. Because it pushes people out. We don't need professional developers, we need contributors. If we need professionals (and I think we do), those professional should be maintainers: the people who facilitate and make contributors effective.

People have been saying things like that for years (I remember explicit statements about needing to switch to a maintainership model as early as the Barcelona summit, but I'm sure it was said much earlier than that) but it is a hard change to make: Systems of privilege work hard to maintain themselves and their members.

When I got myself elected to the TC two years ago, in addition to wanting to help the community (especially with regard to keeping the TC visible) it was also a gambit to ensure a) my employability, b) attendance at summits so that I could continue to be influential in decisions (such as extracting placement from nova, which, shamefully, would have been even more glacial had I not been present-in-person).

In Denver, several people said I seemed more relaxed and less angry than they were accustomed. This was by design. "I've limited my sphere of concern", I said. I quit the API-SIG. I quit the TC. I'm now committed to making the placement project something that people will be able to contribute to when they need or want to. I'm trying to become a maintainer. A stressed-out, angry dude who more often than not wants to yell at someone for creating arbitrary roadblocks to improvement or the flow of information (my native state since birth) does not a maintainer make.

To keep to that, I'm focused on placement. Not just in the specific project, but in any project that wants to use it (in or out of OpenStack).

And I set a timer each day. For eight hours. When that timer gets to 0, I'm done for the day. Because this is still a job — I'm still a labourer helping to create a ton of value for many corporations, not just the one that pays me — and despite the superficial trends, all this automation we're so busily creating should be enabling more leisure time, not less. I'd like my health back.

Here I am contemplating being a professional maintainer. What does that mean? It probably means writing less code for features and more code (and docs) to enable other people to write features.

But more relevant to the opening of this post: it probably also means limiting required attendance to events like PTGs and summits. If not all contributors are going, then some contributors going can create an exclusive club of those in the know, those who are relevant. Those of us who have a history of being relevant in that sense have a very bad record with regard to keeping others in the info loop and decision making process (see above about anger at arbitrary info roadblocks). We need to explicitly compensate.

So: I'm wondering if it is time to stop attending the PTG and the summit. Nothing would have been significantly different if I hadn't been at Denver, despite being the PTL, the "pre-PTG" that we did was a success. If I didn't go, we'd probably do that again. We'd be inclusive of anyone with access to email, and save a ton of carbon in the process.

Would it work?