One of my ongoing projects has been working towards expanding the possibilities for development models in free-software. Many projects in this space are by nature noncommercial (or commercially infeasible) and subject to tight constraints which render the traditional hobbyist and grant-based forms of support infeasible.

It goes without saying that development is inherently a matter of labor and trying to coordinate labor without a steady financial stream is an incredibly tall order. However, as I have previously argued¹, I don’t think this is impossible. In theory, there should be ways to design institutions that can aid these projects in balancing both the demands of mobility with the incredibly low room for overhead costs. By thinking outside of the box and with enough finesse, there just might be a way to find that sweet spot.

Trying to engineer a solution to this problem led me to draft a proposal for a new pillar of project support: software guilds. In short, guilds essentially act as “guerilla development units” which focus on providing short-term support to projects which either need an urgent bug fix or a feature added. They’re designed to help get key features across the finish line in a timely fashion, pack up, and then move onto the next project as needed.

Shortly after laying out my initial pitch for these (then unnamed) units, I was brought on by the Social Coding Movement to pilot the concept, as it mirrored an idea they also happened to be drafting up. The following is a retrospective on how the guilds idea panned out in practice, the lessons we took away from it, and what the next steps should be towards ensuring its success.

The Plan

What I was working on with Social Coding was Guild Alpha, a real-world experiment in seeing if we could assemble a team, get it off the ground, and actually provide aid to free-software projects in a timely fashion. Guild Alpha was established with maximum flexibility and minimum commitments in mind, using low-stakes trial-and-error as a way to quickly learn what does and does not work.

The short-term goal was simply to see if we could get any work done: taking a project, setting a timeline, meeting that timeline, and then delivering meaningful results.

To accomplish this, we divided the work up into “sprints”². Each “sprint” lasted 10 weeks including a 2-week “intersprint” period for offboarding, project planning, and giving the members enough time to rest.³ The goal of each sprint would be to identify an appropriately sized task to tackle, reach out to the devs for onboarding, and do the work to actually complete it.

We went back and forth on whether to do fixed or flexible timetables for starting sprints and dictating their length. At the time, I was more in favor of fixed timetables. I figured, in theory, that having a fixed schedule would keep us more accountable and force us to put more emphasis on modesty in scope.

We defined two roles within the organization: that of the Editors⁴ and that of the Members. The Editors are a small subset of members who take on a custodial role: following up with other members, maintaining documentation, and setting the schedule. In other words, they volunteer to handle all the administrative duties so the other members don’t have to. During our trial, we were getting about 8-12 members who would register and had three editors to maintain the load.

Members draft and submit proposals, vote on which proposal to advance, and work from there. Every week, editors checked in with members to see how they were doing and helped keep everyone on the same page by posting progress logs.

In the background of all this, we were making sure to take detailed notes of what was and wasn’t working and in what ways we could tweak things for the better. All of this is intended to build towards the eventual creation of a Guild Manual. This manual would act as a compendium of guidelines, suggested governance structure, and best practices which anyone can refer to when starting their own guild. We wanted to make sure others could reap the fruits of our experience, ensuring that the guild initiative doesn’t end up anchored to Social Coding. But in order to accomplish this, we needed to be proactive in disseminating institutional knowledge right as we build it up.

Points of Contention

Because of how small the team we were working with was, most of our decisions (with some exceptions) were made via informal consensus among the Editors. While we were able to find compromises to tide things over, some topics did spark debate among us⁵.

The big topics were the rate at which the guild should go through the steps of institutionalization and the extent of democratic decisionmaking. Some key questions included:

• Should Editors be elected at the end of each sprint?
• Should Members be financially compensated for their time?
• Should the Guild establish fundraising venues (donations, grants, charges)?
• Should either a formal council or a registered organization be formed in order to handle questions of fundraising and coordination with other projects?

On all of these issues, I lobbied for a more conservative approach. It seemed to me like these questions were putting the cart before the horse when the focus should be on showing we can even consistently deliver results in the first place. In addition, I worried that adding on so many layers could risk undermining the informality and lightness that gave us the flexibility to quickly try and fail things without cost.

As we were establishing the guild and seeing it work in real-time, I tried to keep a laser-focus on proving the basic, core concept first and punting other questions to later.

What Happened

We put out an announcement on the Social Coding forum with an application form asking people what they wanted to do, what their skills are, and how much time they could contribute. We kept track of this data on a spreadsheet so it would give us an idea of what kind of skills and bandwidth we’d have for a given project.

From there, we invited people to the Matrix room and gave them a couple days to get to know each other. From there, we each drafted our proposals for the first sprint and put them to a vote. Eventually, we ended up choosing to work on adding account export functionality to BookWyrm. Seeing as how important account portability is to maintaining a long-term presence on the Fediverse and removing barriers to joining smaller instances, we figured it would be right up our alley.

We began by reviewing the code and getting a better understanding of its structure and dependencies. We each tasked ourselves with researching a different section of it and placing our notes into a common wiki for us to collectively understand. During this time, we were considering our options and what the best approach to implementing this feature would be.

From there, we set up a dev environment and got to work. We touched base with the lead developer of the project and ended up meeting another Bookwyrm contributor who was tackling this issue in parallel to us. After talking with him, we all decided to pool our efforts. The process from there was really just a matter of playing things by ear. As we worked, we’d locate bugs and identify intermediate steps, continuing to progress.

With each week, we’d check up on members and see if they still planned to continue. We made sure to ask this in a way where it was clear we weren’t pressuring them, but simply collecting metrics to better plan out our capacity for the remaining weeks.

What we found was that for each sprint we’d usually net around ten applications and out of those ten, we’d retain about three or four as active members who participate throughout the sprint period.

By end of the sprint (despite cutting it very close), things seemed to be generally going well. Bugs were fixed, testing seemed to pass, and the features were being implemented. However, it wasn’t long before we ran into our first hiccup: others testing seemed to run into bugs right before our PR got merged upstream. It would take a couple more weeks before those merge issues were resolved and the project could be wrapped up⁶. We took some slack to go a couple days past our development deadline and it led to us having to push things back to have enough time to deal with issues in merge.

This would end up eating through the entire intersprint period and into the early weeks of the next sprint. Adding to the issues, we selected a project very early in development (LibRate) as our next target for assistance. Lack of codebase maturity has its risks, and the one we had to grapple with was that the process to set up a developer environment was unclear and creating a lot of bugs. We spent so much time on getting the dev environment set up that we weren’t getting to the work itself, and eventually it became clear we had to call it off.

Given both the burnout we were facing from an overly ambitious timetable and various other issues popping up in our personal lives, we agreed to put the project on hiatus as we sorted out our own problems and pledged to return at a better time.

The Lessons

Looking back on the experience, I still don’t think I was wrong to say it’s not an impossible mission, just an incredibly difficult one. But I very much did have to come face to face with what difficult means.

If the purpose of Guild Alpha was to serve as a learning experience and a testbed for how to structure such an organization, it definitely did do that. Reflecting on everything, there’s a ton of lessons I’ve been able to take away.

First and foremost, it became abundantly clear to us that fixed time tables were not working. We took for granted our own abilities to accurately estimate project scope, but there was no reason to assume this given our (relative) inexperience. The one week we gave ourselves to merge and address issues probably wasn’t forgiving enough, and two-week breaks didn’t really mean much when us Editors were spending that time catching up on administrative work for the guild itself (setting up the website, drafting documentation, etc.). The proposal stage also being rather short contributed to problems as it discouraged us from thoroughly vetting the project to ensure it’d be viable.

When designing the schedule, I was only concerned about the value of breaks for Member retention, and didn’t take seriously enough the needs of the Editors too. In these early stages the Editors are the ones who are likely going to be committing over the longest term and having the most asked of them: if they burn out, the entire operation goes down. Running a guild is a marathon, – not a sprint – and more forgiving schedules are critical towards ensuring we scale in a sustainable fashion.

While I think “call a sprint whenever, finish stuff whenever” (like we tried to do after the second sprint) led us to drift apart way too easily, a middle ground can be found. An overly defined structure can be restricting, while an undefined structure can leave members feeling rudderless. Instead, I think we can have a “default” timetable like before (albeit over a longer period), but give significantly more leeway in terms of extending and rescheduling them⁷. If a project looks like it might not be done in time, hold a vote on whether or not to extend. At the end of each sprint, Editors should come together to decide on what they think is an appropriate date to follow up for the next sprint, or if they want to put things on pause to focus on administrative work. This sort of “structured but loose” approach I think would give enough definition without being suffocating.

If we were to ever start this up again, I’d also think it’d be wise to dedicate more time at the beginning to hashing out the administrative work. This means setting up the website, drafting up documentation, and more explicitly defining the limits on our scope and our overarching milestones and goals we want to hit as a guild. And instead of letting this run for an indefinite number of sprints, commit only to doing a couple before taking time to reflect on our experiences. Because once you’re in the saddle, you don’t really get much time to really think these things over.

We spun up relatively quickly, and that had both its benefits and drawbacks. The benefit was that we quickly were able to get our hands dirty and actually figure out what problems we’d need to iron out. The downside was that we did risk dragging potential recruits into an initiative that was still in its infancy. Given how retention outside of a handful of core members was relatively poor anyways, I think it’s worthwhile keeping the small circle early on, as their commitment makes them more forgiving when we run into hiccups.

Keeping the initial circle small also helps in that it minimizes the extent to which timezone coordination is a problem – which it absolutely was. We weren’t always able to meet with everyone and even among the editors, we all lived in very different timezones and had to meet at odd hours in order to ensure we were keeping up to date. Relying on asynchronous communication and only doing calls for more important topics was how we mitigated a lot of that.

I do still think there’s value in eventually establishing a wider community, even if maybe not in the immediate term. Directly participating in one of these sprints is a massive commitment, and there needs to be less committal outlets whereby sympathetic people can still remain invested in the community from the benches. We’d probably need to have a room or forum whereby people can simply follow news and chat is key to maintaining and building a rolodex to call on between sprints. In addition, having regular casual discussions members can return to helps as a “communal glue” to ensure members don’t drift apart whenever work is not actively going on.

The real question (and what I was unable to figure out in time) was exactly how you build such a community. Typically these kinds of communities are born out of people pariticpating in the work itself or through the production of public-facing content for people to follow. Obviously we can’t expect everyone to participate in the work all the time, and producing public-facing content is a lot of additional work in and of itself. While communities can maintain themselves off of simple topic-level discussion, this usually comes only after the community has matured. The initial stages of getting a community off the ground and ensuring discussion is regular enough to feed itself and create a culture is a whole challenge of its own that I still don’t have a good answer to.

But for all the talk of things we could have done better, there were a lot of positives too. For many of the members who did participate, it was their first time working with a team and they reported enjoying the experience. We also saw a mix of people with different interests and skills: some preferred coding, others administrative work, some front-end, others backend. Those representing the projects we partnered with reported having benefitted from our help, with us being able to assist with parts of implementation they had a harder time with.

Things may not have gone perfectly and there’s a lot of ways in which we could have improved, but that’s to be expected. The concept we have here looks promising and the results we’ve seen come out of a rag-tag, first-time team with no financial backing are nothing to sneeze at. Our members had fun and learned a lot, meaning that the work was able to deliver value to them without having to turn to direct compensation.

Where From Here? (4/18/2025)

I happened to take upon this responsibility during a less-than-ideal time in my life and ended up biting off way more than I could chew. I was going through my final round of classes in university (which were all incredibly demanding) and then in the span of only a few months had to transition to working a full-time job and adjusting to independent living, all while this was going on.

In the years since, I’d say I’ve adjusted to the new routine, become more relaxed but also more productive, and have matured both as a developer and as a person.

But at that time, I was stretched incredibly thin and was coming out of college with a rather unhealthy work-ethic. All of this really came together to make running the guild feel like a lot more of an intimidating and high-stakes job than it really had any right to be.

While I was handling the administrative work, planning, and coordinating perfectly fine, the technical side of things was a lot rougher. Throughout the sprint, I found myself quickly falling behind and struggling to really contribute much to the projects at hand. It became immediately clear to me afterwards that I needed to get back to the basics: just focus on honing my skills and being comfortable working on large codebases.

Over the next two years, I would turn my focus to solo projects (such as the PoliTree) and built up a great deal of both confidence and knowledge as I went through the process of seeing the project from start to finish.

In the coming year or two, I might look into spinning up Guild Alpha again, but I would be looking to learn from the mistakes we made last time and adjust accordingly. I’d want to make sure we thoroughly get the administrative work out of the way ahead of time, avoid overcommitting, and keep our focus to a specific set of goals and a narrow set of people.

By taking it small and steady, I think we can avoid a lot of the pitfalls we ran into the last time. I’m keeping touch with the people involved still and there’s still interest from Social Coding about rebooting eventually. But I’m currently being careful not to rush things as doing things right should take precedence over doing things fast.