On Wed, 4 Sep 2019, Doug Hellmann wrote:
I would take this a step further, and remind everyone in leadership positions that your job is not to do things *for* anyone, but to enable others to do things *for themselves*. Open source is based on collaboration, and ensuring there is a healthy space for that collaboration is your responsibility. You are neither a free workforce nor a charity. By all means, you should help people to achieve their goals in a reasonable way by reducing barriers, simplifying processes, and making tools reusable. But do not for a minute believe that you have to do it all for them, even if you think they have a great idea. Make sure you say “yes, you should do that” more often than “yes, I will do that."
This is very true, but I think it underestimates the many different forces that are involved in "doing work in OpenStack". These are, of course, very different from person to person, but I've got some observations (of course I do, everyone should). I suspect some of these are unique to my experience, but I suspect some of them are not. It would be useful (to me at least) to know where some of us have had similar experiences. Most people work on OpenStack because it is their job or is closely related to their job. But because it is "open source" and "a community" and "collaborative" doing what people ask for and helping others achieve what they need is but one small piece of the motivation and action calculus. Making "it" (various things: code, community, product, experiences of various kinds) "better" (again, very subjective and multi-dimensional) is very complicated. And it is further complicated by the roadblocks that can come up in the community. In the other thread that started this Sean said: the reason that the investment that was been made was reducing was not driven by the lack of hype but by how slow adding some feature that really mattered [1] One aspect of burn out comes from the combination of weathering these roadblocks and having a kind of optimism that says "I can, somehow change this or overcome this." Another is simply a dedication to quality, no matter the obstacles. This is tightly coupled with Sean's comments above. Improving the "developer experience" is rarely a priority and gets pushed on the back burner unless you dedicate the time to being core or PTL, which grants some license to "getting code merged". For some projects that is a _huge_ undertaking. My relatively good success at overcoming the obstacles but limited (that is, constrained to a small domain) at changing the root causes is why I'm now advocating chilling out. This is risky because the latency between code and related work done now and any feedback is insanely high. The improvements we've made recently to placement won't be in common use for 6 months to 3 years, depending on how we measure "common". Detaching or chilling out now doesn't have an impact for some time. That feedback latency also means figuring out what "better" or "quality" mean for a project is a guessing game. Making cycles longer will make that worse. A year ago when we started extracting placement I tried to make real the idea that full time cores should rarely write feature code and primarily be involved in helping "people to achieve their goals in a reasonable way by reducing barriers, simplifying processes, and making tools reusable". This only sort of worked. There were issues: * There were feature goals, but few people to do the work. * Our (OpenStack's) long term standards for what is or is not a barrier, good process and tooling are historically so low that bring them up to spec requires a vast amount of work. To me, the Placement changes made in Train were needed so that Placement could make a respectable claim to being "good". 75% of the changes (counting by commit) were made by 4 people. 43% by one. [2] The large amount of time required to be core, PTL or "get their code merged pretty easily" (in some projects) is a big portion of any job and given the contraction of interest in the community (but not in the product) from plenty of companies, there is lurking fear that the luxury of making that commitment, of being a "unicorn 100% upstream", will go away at any time. This increases the need to do all those "make it better" things _now_. Which, obviously, is a trap, and people who feel like that would be better off if they chilled out, but I would guess that people who feel that way do so because making it better (whatever it is) is important in and of itself. Especially when the lack of commitment from enterprises is waning: they don't care, so I must, because I care. In other projects, there's simply no one there to become core or a reluctance to get into leadership because it is perceived to be too time consuming (because for many people in leadership, the time consumption is very visible). Similarly, when there's a sense of waning interest, the guessing game described above for determining what matters is pressurized. "If I get this wrong, the risk of our irrelevance or even demise is increased, don't mess this up!". Also a trap. But both traps are compelling. I think we need to investigate changing our governance and leadership structures. We should have evolved away from them, but we haven't because power always strives to maintain itself even when it is no longer fit for purpose. TC, PTL, Core and even "projects" all need rigorous review and reconsideration to see if they are really supporting us ("us" in this case is "the people who make OpenStack") the way they should. If we are unable or unwilling to do that, then we need to enforce "contributing" enterprises to contribute sufficient resources to prop up the old power structures. [3] [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009123... [2] That is, assuming stackalytics is correct today, it often isn't. [3] Perversely, I think this option (companies paying up) is the fundamentally right one from an economic standpoint, but that is because I don't believe that OpenStack is (currently and through the peak of its history) open source. It is collaborative inter-enterprise development that allows large companies to have a market in which they make a load of money. That takes money and people. If OpenStack were simpler and more contained and tried less hard to satisfy everyone, it could operate as an underlay (much like Linux) to some other market but for now it is the market. The pains we are having now may be the signs of a need for a shift to being an underlay (k8s and others are the new keen market now). If that's the case we can accelerate that shift by narrowing what we do. Trimming the fat. Making OpenStack much more turnkey with far fewer choices. But again, the current batch of engaged enterprises have not shown signs of wanting that narrowing. So they either need to change what they want or cough up the resources to support what they want in a healthy fashion. What we should do is strive to be healthy, whatever else happens. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent