Learning In Public
Part 1 of this series introduced the joyous software economy, one of the two economies that produces software. I discussed the lack of sustainability that threatens both the joyous software economy and the commercial software economy. The cause is a simple one: toxicity creates a miserable environment for those within the joyous economy.
An obvious question to ask is what causes this toxicity? But before we can answer that question we need to answer a more fundamental one: can we buy our way out of this problem?1
Money seems like an obvious solution to this problem. The commercial software economy has for decades dealt with toxicity levels far higher than those currently within the joyous economy. There are books about the subject and a universal experience of the "technical genius" who's a complete jerk and makes those around them miserable. If you've spent time developing software professionally, you've run into at least a few people who fit the archetype.
There's also a general sense that it feels wrong when software produced by the joyous economy is used by commercial economy players to make a profit. In the view of many, those companies should be paying some of those profits to the joyous economy projects who produced the software.
Most notably, many joyous economy participants are actively asking for monetary support. And there are several companies, like Tidelift, Polar, and GitHub, that provide methods of supporting these projects.
There are existing models for financial support, like foundations and companies that produce freely available software. These hybrid organizations, ones that exist within both economies, have done well for large software projects. Linux, Kubernetes, a plethora of databases, and countless other projects are maintained with this approach. The main problem is that with money comes expectations. With large amounts of money comes politics. It's difficult enough to run a small community with a small group of people, but when you attempt to lead a large group of people, larger problems occur.2
The problem is that the joyous economy operates with different rules, and expectations, than the commercial economy. When you fuse the two together you risk the worst of both: not enough joy and not enough money. If you can acquire enough money, the commercial economy tends to consume the joyous economy. With foundations you have to deal with politics and what the big players want, even when it's disconnected from the community. With companies, profit must be prioritized: when a company need is at conflict with a community need, most often the company will choose self preservation. If they don't, the entire project winds up in limbo, perhaps with a larger company taking over until an internal reorganization results in the project being flung back into limbo.3
Path dependency is also a problem. At what point does a project become eligible for funding? A viable method for funding joyous economy projects will leave many crucially important software projects with too little funding.4 The joyous economy enables people to create software without regard for financial viability. It can produce software that will never be financial viable. Most joyous economy projects begin as hobbies and slowly grow over time. When you need to make money from building software5, there has to be some part that people will actually pay for, which winds up shifting incentives.
Taking a step back, there's a macro question we need to answer. Why is it that participants in this economy, the one they entered knowing money was not part of the compensation package, are now asking for money? Instead of being a problem that needs solving, we should see this as a symptom of something larger. In fact, toxicity is also a symptom of this larger issue.
In the commercial software economy, a project usually requires four primary roles: software engineering, project management, product management, and product ownership. Within software engineering there are also sub-roles of testing and security. When we look at joyous economy projects, they usually have a single primary role: project maintainer. This singular role is required to perform all the duties of the six aforementioned roles. While it makes sense that a project maintainer would handle product ownership and software engineering (since most projects are started by programmers), there are still four remaining roles, each which require specialized knowledge. Even projects that have several maintainers usually don't have any that are specifically trained in project management, product management, testing, or security. There are exceptions, like testing or security focused projects, but there is still this singular role for all tasks.
The joyous economy projects require additional roles that commercial economy projects can do without. These include leadership, logistics, and reference work. The latter two roles are of crucial importance when hiring more people isn't an option. A project that has a constrained contributor base has to improve their logistics and reference capabilities if they wish to thrive.6
Both economies suffer because those in these roles lack adequate training or, more often, these roles remain vacant. For small projects that are straightforward to implement, one can get away with just having a software engineer write some code. But even moderate size projects need several of these roles. Without project management, there's an upper bound on how many contributors can participate. Without product management, a project can only grow to a certain size. Without testing and security, quality of a project becomes difficult to maintain. Without leadership, a community is difficult to develop. Without reference work, documentation is sub-par and the issue queue fills with questions that should be answered with documentation.
Competency is important here. We cannot solve this problem by simply assigning these roles to individuals. Calling someone a project manager does not make them one. They need to have knowledge and experience in the tasks the roles require.
Even if we could provide every maintainer with enough funds to justify the continued maintenance of their projects, it wouldn't fix the problem. Because maintainers are facing a lack of funds and a lack of assistance. The bulk of people who decide to build something in the joyous economy are doing it because of the joy they get from the process. The reason why so many of these roles are unfulfilled in projects is because that work does not bring joy to the maintainers.
By giving them money they have a different incentive to do that work. But they still don't have the necessary training. While paying people might work for testing or security related tasks, without knowledge of project or product management, one will at best do a mediocre job. It's even worse for leadership, logistics, and reference roles, where a lack of knowledge can destroy a project or cause a community to abandon it.
To be clear: the argument isn't that we shouldn't fund joyous economy projects with money. The reality is that many joyous economy projects should exist in the hybrid economy. The same is true of the commercial economy, where joy plays a part in the compensation for individuals even if it goes unrecognized. If two roles provide a similar monetary compensation package, but one will provide more joy to an individual, they are more likely to take that role.
The argument, instead, is that we cannot use money to fix the sustainability problems. Just as there are spaces within the commercial software economy that provide no joy, there will always be spaces within the joyous software economy that provide no money. Projects need to be sustainable whether they are funded with money or purely with joy.
The solution is to fill the missing roles. Volunteering isn't something that's specific to software engineers. There's little reason why project managers and product managers couldn't also be compensated in joy. The same goes for people within leadership, logistics, and reference roles.
To illustrate the need for these roles, let's think about how a project might handle a security vulnerability. If all of the roles were filled:
A whole team would spring into action. If the only role we have is that of a maintainer, then they need to do all of these things. Even paid maintainers wouldn't make enough to justify performing nine roles worth of duties.7
We need these roles and most of them already exist within the commercial economy. So why aren't these roles filled with well trained individuals? After all, there is no reason why people who enjoy doing the work of these roles wouldn't want to join the joyous software economy. Being compensated in joy isn't exclusive to software engineers, it's something that humans in any profession can have.
So why aren't they participating? The short answer is toxicity. The longer answer is the subject of the next entry in this series.
Fundamental because regardless of the reason for the toxicity, buying our way out of this problem is a likely suggestion. ↩︎
This, dear reader, is called foreshadowing. ↩︎
Usually after that happens, the project is placed into a foundation, which as mentioned, has its own problems. ↩︎
Funding also allows those with money to sap resources from better projects in favor of projects they can control. ↩︎
Having to prove one's worth is also a form of "making money" in this case. That is, if you have to continually prove to whatever entity is funding you that you are worth funding, the effects are the same. ↩︎
Leadership, logistics, and reference work will be covered in more detail in subsequent entries in this series. ↩︎
There might be maintainers who are capable of performing nine roles worth of duties, but that shouldn't be the default. Exceptional humans can handle exceptional tasks, but we shouldn't require every human who wants to be a maintainer to be exceptional. It would be reckless to do so. ↩︎