During the talk I gave at LibrePlanet this year, I stressed the need for thinking outside of the box and developing new pillars of support for the kinds of development going on in emerging free-software niches (specifically the Fediverse).

Laid out below is a proposal for Software Guilds, a specific form of organization that I believe would suit the constraints and environment many free-software devs work under.

Problem: Non-Commercial Development Models Struggle to Scale

Traditionally, projects in the free-software space tended to be spun up and maintained as hobbyist endeavors either by an individual or a small team of loyal contributors. While having the source code open allows for the possibility of forks, bugfixes, and features to be added by the community, the heavy lifting for these projects tends to be disproportionately borne by that initial small circle of committed devs. As the infamous development cycle of GNU/HURD shows, even the best supported of these models can struggle to effectively scale, prioritize, and respond to problems at a regular speed.

While this approach might work for something relatively small like a minor C++ library, these projects run the risk of being absolutely crushed as they grow. What might’ve initially started as a casual side-project can find itself overnight facing the load, popularity, and expectations of a full-on commercial product. The story of a once-great free-software project which has to shut its doors once developing it becomes too much of a burden is, unfortunately, a very common one.

This is a problem that has long been recognized in the community, and various venues to “fund” or commercialize FOSS development have been established. Some projects (most famously Red Hat) provide a free product but will sell enterprise-level support as a way of making their money back. Others, such as Blender, benefit from netting grants to fund their development. But not every project has these options available to them: often times being able to sell service (while retaining software freedom) or net grants requires both a large enough presence but also direct relevance to the interests of the biggest backers (often corporations).

This means that commercial and grant-based open-source models tend to be stacked in favor of infrastructural programs, such as Apache or Python. These programs usually tend to run on the back-end and have a good amount of their overall value derived from industrial use as opposed to what end-users directly use. Companies (and by extent the non-profits that get their funding from companies usually) don’t just contribute as an act of charity, they’re usually targeting their investments in a fashion that will benefit them and their ends. Now, of course, it goes without saying that there’s inadverdent social benefits to having that infrastructure be open. But we can’t let that detract from the other issue at hand: there’s an entire class of programs (often applications) which are left with a drought in support. What good is a free Apache if it exists to enable a world built on non-free cloud applications?

Making the most of the situation facing us requires us to start seriously grappling with not just how we “generally” support open-source, but how we can target our efforts in the sectors where they’re presently most needed? How do we patch the holes in the most underserved levels of the tech stack?

The Fediverse provides a very interesting window into this phenomenon, as it lands on a cross-section of factors that make it an excellent case study:

• The roots of the community are within an explicitly anti-commercial, grassroots, free-software tradition
• A lot of these projects (apart from the largest ones) are usually spun up by individual hobbyists
• These projects fall within the realm of social media networks, which is a use-case that stresses the limits of infrastructural scale and development speed
• Adoption cycles aren’t gradual but come in sudden bursts, growing overnight can leave devs unprepared to adjust and overwhelmed by traffic
• The space is relatively new, still with a lot of room to influence things and make a mark

One very stark example of this is what happened with Kbin. Kbin is an incredibly niche Reddit alternative, getting overshadowed by even other Fediverse projects such as Lemmy. It had its users, but for quite a while it was small-scale enough that the load was manageable enough for him.

Then came the Reddit migrations. The controversy over Reddit’s API lockdown led to a surge of registrations across not just Lemmy, but also Kbin by extent. While those on the sidelines saw this as a great opportunity to capitalize on, for the Kbin dev (Ernst) it was quickly becoming a major source of stress. Having to deal with a flood of users suddenly rushing into your instance, stressing your servers, moderation policy, requesting features, and finding bugs is way too much for any one person to deal with. Eventually things hit a breaking point: development of Kbin entirely ground to a halt and the flagship instance was shut down. The platform got killed by its own growth: what should have been a beginning for Kbin’s rise was instead the beginning of its demise.

What really made this so killer was that the growth was unexpected and sudden: that’s how these make-or-break moments usually come. He didn’t get much time to prepare, onboard other developers, or find someone to take over. The dedicated resources of projects alone are not sufficient to build out the Fediverse as a network: in key moments like this, we need to be able to quickly provide support from outside in a fashion that can temporarily offload some of the burden from the devs as they re-adjust.

Solution: Employing Guerilla Development Tactics

If we’re going to come up with a proper development model for the Fediverse, we’re going to have to survey the unique strengths and weaknesses provided by the terrain¹. Free-software development usually tends to be rather small and localized, but this isn’t always a bad thing. Where you lose in institutional backing, you also gain in the potential for mobility and responsiveness. The freedom of these devs to experiment, steer, and just focus on developing without being bogged down by bloat is not an advantage to take for granted.

The culture of these communities has produced a high concentration of ideologically motivated actors who can be convinced to work towards common goals – if they have sufficient reason to believe it will meaningfully benefit the ecosystem as a whole. These developers have a very personal stake in seeing these platforms improve, as they also happen to be the very same people using them on a day-to-day basis.

This is important because FOSS development isn’t a democracy, it’s a do-ocracy. “Benevolent dictators” only retain their crown insofar as they continue to provide value to the project and regularly contribute. That very same uneven distribution of workload on most smaller projects inadverdently opens a window for opportunity: it doesn’t take that many committed people to make a difference.

If you’re able to come up with a structure that can mobilize even a handful of people to start contributing, not only do you ease the burden for a lot of these solo devs, you also gain the ability to “vote with your contributions”. Features which the devs may not see as a priority but the community does can be shunted up the completion list by having third-parties volunteer to spend the time themsleves. This creates a development structure that’s more able to be responsive to public opinion, as the ones doing the work are continously pulled out and sampled from the community.

But what should this structure look like? Sketched out below is a framework for a type of unit me and some others I have worked with have dubbed the “software guild”. In principle, a software guild is an informally governed, tight-knit team of devs united by a common interest in the broader infrastructure and ecosystem linking these various free-software projects.

They don’t tie themselves to only one project, but are designed with the flexibility to go around from project to project patching up holes as deemed fit. This means committing only a couple months at a time to each project, proposing and voting on different possible tasks to pool their efforts towards. They communicate with the original devs, coming up with effective onboarding/offboarding plans to ensure their work can be handed off when the window comes to a close.They set their timelines and pick an appropriately small-but-high-priority item that fits their resources, skill level, interests, and needs. The tasks are relatively small scale and frequent enough that these guilds can learn from their mistakes, steer their course, and adapt as they go.

To be clear, guilds aren’t intended to be one central group of roaming devs doing the work. Instead what I’m proposing is a decentralized network of different circles each with their own members, cultures, and priorities. Spinning up, maintaining, and splintering these groups should be as cost-free and riskless as possible, in order to minimize any possible friction. To help smooth over the process even further, developing a manual (based on experience) suggesting how to best run and structure a guild for the uninitiated would go a very long way towards ensuring the institutional knowledge gets spread and preserved to those who otherwise would have no experience or reference to go off of.

But even past that, as they do the work, they’ll naturally find themselves having to analyze the terrain in order to figure out where each next best investment is. As they debate, discuss, work together, and follow news, they may be able to form their own community (not unlike that of many group-chats).

Community in turn can provide its intrinsic benefits: social connection, allowing people to complete tasks they wouldn’t be able to do on their own, and acting as a hub to incubate talent. This principle holds true elsewhere: many animators get their start on collaborative reanimations, many game developers find game jams as a good entry point. It’s worth studying these examples and the principles which make them work for inspiration. These guilds act a low-barrier way to provide the experience of working in a team to new/prospective free-software devs.

On top of that, these guilds can help to network the larger FOSS community: guild members end up building connections with maintainers, developers, UX designers, activists, and researchers all begin to have a common bridge whereby they can discuss and link their activities. The discussions surrounding priorities go from isolated incidents in Github issues to a more unified discourse.

This sort of “guerilla development” model is based on the recognition that bigger isn’t always better. Whether we’re talking about guerilla marketing or even guerilla warfare, there’s plenty of examples throughout history of moments where a small circle of actors deploying their resources tactically can outmaneuver a bulkier force.

Rather than lamenting our weaknesses or trying to seek out institutional support so we can one day match the size of our competitors, why not start thinking outside of the box? Small Tech is not Big Tech, so why don’t we apply the same principles that dictate our software design to the very processes whereby we organize and work?