A sustainable Guild: A discussion of Finance, Mental Health, Democracy and Institutionalization

[CSDUMMI]

With the conclusion of the first Guild Alpha sprint and beginning of the second, a new way of developing free software is starting to take shape.

We are trying to innovate on the basic structure of free software development defined by often uncoordinated work of individuals with a collective and democratic approach.

Every sprint a group of people comes together to vote on a project to work. Goals are set, development takes place for eight to ten weeks and then the sprint ends and results are either proposed to an upstream project or handed over to a maintainer to continue development in a smaller team.

All work is voluntary. More detail about the structure and progress can be found in the links above and on the website.

We are still iterating on the format of the Guild itself.

The following is my personal opinion on the future of the Guild and not a position of the Guild or the Editors of the Guild. I hope for a constructive discussion on the future of the Guild and invite everyone on this forum to join in the debate.

Finance

A direct link exists between the sustainability and accessibility of the Guild and it’s financing.

At present, all members are volunteers and receive no compensation, either for their time or for the expenses they incur during their work (e.g. server costs).

@Tomat0 and I initiated the Guild with 0 starting capital, making it possible to experiment with the format freely and granting us the liberty to fail.

But this also puts a burden on members and restricts the potential pool of members considerably. A sprint can consume quite significant amounts of time that members could spend earning a living. The ability not to do so is a luxury and we must never forget that!

By expecting members to have this luxury, we are excluding large demographics unintentionally from participating in a sprint, foremost including the poor, national and global.

Computing and programming is an activity that has been turned into a place dominated by certain demographics: white, western, male and we are no exception to that.

To counteract this does not just require a declaration of “openness”, as as @Tomat0 and I have made in the first and now in the second sprint. It requires providing members without the luxury of time the ability to participate in exchange for compensation.

For what should compensation be possible?
First of all, I think, we should be able to provide certain infrastructure to members, e.g. a server for testing purposes. It should be possible to compensate members for such expenses, which they have to incur to effectively work on a sprint. Whether this includes only those costs that were exclusively incurred for the sprint (e.g. registering a domain) or also more general purpose expenses that made participation possible (e.g. a computer) is debatable and I’d only compensate those more general expenses in special circumstances.

On the other hand, compensating a member’s time should be a goal of Guild Alpha. Developing free software is a highly skilled profession and should be compensated as such. While this is at the moment unattainable, I believe we should aim to allow members to be compensated for their time fully in the future and never argue that the Guild is an endeavor that people should simply be happy to work on during their free time. Doing so would mean the Guild had failed in it’s purpose - to make free software development sustainable. Currently we can only make it more sustainable by providing support in a team, learning from each other and organizing. But we should also aim to make it sustainable financially for members to participate.

To make any such compensation possible, whether for expenses or for labor, we have to explore different avenues. I’ll consider these three for now, but am open for alternatives:

1. Donations (OpenCollective, Patreon, etc.)
2. Grants (NLnet, Prototypefund, etc.)
3. Charges

Donations

There is a spectrum between these three options: from easy to difficult to implement.

Donations might be called the minimum viable income source. While donations create no obligations between the donor and the Guild, they do require a basic institutional setup for the Guild to be able to receive donations.

The Guild will need some sort of permanent representative to be able to receive donations, possibly even a legal entity to receive it through.

This in turn requires a means of appointing such a representative. Which, if done by a vote of the active membership, requires a list of all active members at a given time.

How is an active member defined? Who maintains the list of all active members? When is a member no longer active? How are the answers to these questions changed?

All of these questions need to be answered in order to accept any sort of income, including donations. The other income streams, require this as well, but donations are possible with by far the least public profile of Guild Alpha.

Grants

Foundations, governments and the EU regularly provide grants to free and open source software projects.

The way most grants work is very incompatible with the Guild Alpha concept. They expect the maintainer or a lead developer on a FOSS project to apply for the grant and they then decide between applications based on the merits of the projects and available resources.

Guild Alpha is no FOSS project, so we can not apply to most of the grant programs directly.

It might be that we could arrange a special agreement with some foundations or grant programs, but this is at present unlikely. I could only imagine this possible, when Guild Alpha has a proven track record of successes.

Charges

A third option for gaining income would be to charge the projects we work on. Mastodon, for example, allows any contributor to submit expenses to their OpenCollective. The fact that Mastodon is able to offer this to it’s contributors is great and probably a side effect of the enormous popularity that the project has been enjoying since 2022.

But many other projects, including those in the Fediverse, are not able to provide this to it’s contributors and those that are or will be, are probably so far developed, that they’ll not need the help of Guild Alpha to make substantial changes to the project.

In conclusion on this chapter:

• The Guild needs to be able to compensate members for expenses and time, to allow more members from different backgrounds to join.
• The Guild needs a permanent representative to be able to receive any income. To appoint said representative, the active members need to be clearly defined.
• The Guild has to successfully conclude more sprints, to grow it’s profile and presence, which may enable us to raise money through donations or negotiate with grant programs better.

Mental Health

The first sprint of Guild Alpha was a difficult project for me as an editor. We exceeded our own deadline by a month, many weekly reports were delayed and there were weeks where little moved or where it felt like I had to move the entire sprint along alone.

The last was a side-effect of the small size of the Guild at the time. I’m extremely grateful to @dannymate for stepping up in those moments and supporting me. Without his help in compiling the weekly report, the sprint would probably have failed.

But I hope that the first sprint was the most difficult sprint in this regard. Now we have three editors for the second sprint, with @dannymate joining @Tomat0 and me. This should alleviate a lot of the pressure that otherwise occurs as we can make majority decisions without waiting on every editor to sign off and on the flip side, all editors know that they can lean back sometimes and take care of themselves without halting the entire sprint.

It is nonetheless true that the sprints rely on an active and dedicated membership, that feels comfortable in it’s work and is not exhausted or burned out by the work.

In our current sprint we thus put a lot of focus on checking up on members and offering as many opportunities to ask for help. We should leverage our strength in numbers to support each other by making it clear that everyone can take a break from the sprint if they want to and that the sprint will be able to continue without them. This includes the editors, of course.

It also requires us to draw up some boundaries. The first of these is our new hard deadline. Regardless of the progress of our work, the second sprint will end at the latest 10 weeks after the kick off, i.e. 2023-11-29.

We will not use pressure to finish before this deadline and wind down work already two weeks before this date to protect our members. They are more important than the success of the individual sprint.

And if the goal we set for the sprint has not been achieved by the hard end of the sprint, that is ok. In the second sprint, we decided to focus on existing projects, so that we can always end a sprint by creating a WIP PR to the project and leaving it at that.

Democracy

Ties

The second sprint started with a little bit of difficulty. In our first ballot, we tried using the Condorcet method to select our project. Condorcet is a method of ranked-choice voting and means second and third choices are considered.

But because of that, this method is able to produce a tie, even when there is an uneven number of votes between three options. And that is exactly what happened.

This time, we decided to resolve the tie by holding another vote and selecting the project that most members vote for (FPTP).

For our next sprint, we want to have a predefined method for resolving ties. We will continue to use ranked-choice methods, though not necessarily the Condorcet method, but every ranked-choice method has the possibility of a tie.

The options we are currently considering to resolve them are:

1. Using plurality voting (again) as a tie breaker
2. Assigning an external tie breaker beforehand.
3. Holding a simultaneous poll on the Fediverse and using the result as a potential tie breaker.
4. Repeating the same vote again until no tie occurs.

Holding a vote to break another vote’s tie also has the risk of resulting in a tie, so the first and third option would also require a policy for dealing with a tie.

The third option has the added advantage of increasing the profile of the new sprint, which could be beneficial in recruiting new members throughout the sprint. I’m thus currently in favor of a policy where:

1. A ranked-choice vote among members is held.
2. If this ties, a poll on the Fediverse is held to break the tie.
3. If this ties, a plurality vote is repeated until a project receives a plurality of votes.
4. If two plurality votes fail, the sprint is disbanded.

The Fediverse poll could also be held along side the ranked-choice vote, thus removing most of the delay introduced by this system.

But the decision on which of these options should be chosen, will be left to the end of the sprint to be decided by the active members then.

Elected Editors

In the chapter on Financing the Guild, I mentioned that the Guild would need to hold elections for some sort of permanent representative to receive income and compensate members.

I don’t just think that we need to have elections for positions in the Guild for this reason, though. While the Guild should be as anarchic as possible, in my opinion, and maximize the freedom of individual members, there are still some positions needed to organize the Guild.

All of these positions are currently united under the title “editor”. A team that makes decisions by majority and should be of uneven number.

For the first and second sprint, the editors were @Tomat0, myself and @dannymate and we were also the initiators of the sprints.

We were not elected as this would have been impractical while we are still experimenting with the very format of the sprint. But we plan on introducing elections of the editors in future sprints.

I don’t want to be an editor in every sprint of the Guild and I also want to spread the knowledge of how to organize a sprint & start a Guild as wide as possible. This will make the concept of a Guild far more resilient than it ever could be, even if the three of us organized a hundred sprints.

I thus propose that in the next sprint, we have elections for the editors together with the vote on proposals.

This would divide the current role of the editors into two:

• Initiators, those who start a sprint, call for members and hold the proposal vote.
• Editors, those who organize the actual sprint and write weekly reports.

The initiators may not be elected (unless they are the editors elected in the previous sprint), but the editors would be.

This raises some questions, that need to be answered:

• How should editors be elected?
• How many editors should be elected? It should be in some proportion to the number of members, but at least three and an uneven number.

Holding online votes

Up until now, we have been using Cryptpad Forms for elections.
While Cryptpad is a great FOSS project and we were considering some of their issues as potential projects for the current sprint, their forms lack some features I’d like for our votes:

1. Voters can submit multiple votes. There are no “one time” links in cryptpad forms, which might mean that a voter submits two votes, whether intentionally or in error, by opening the form in different browsers, devices or privates windows. If links could only be used once, this risk would be removed.
2. Cryptpad only natively supports the Condorcet method when using ranked-choice votes. You can export votes into a spreadsheet and write your own ranked choice algorithm, but this is not ideal. I’d especially like to be able to use the IRV or Alternavite Vote method.

Are there any other FOSS platforms, we should consider for holding our votes?

Institutionalization

The final chapter to discuss here is institutionalization.
This is somewhat a culmination of all the topics of this thread. More permanent democratic institutions help us raise money, compensate members, support our mental health and make our democracy stronger.

Besides editors, elected on a per-sprint basis, I believe we need a sort of permanent representation for the Guild, even in between sprints. Some institution that can negotiate on member’s behalf, is elected by them and accountable to them.

This could be a council, elected by all active members in a year and for a one year term, for example. They’d operate similar to the editors, releasing regular reports (though on a different cycle than the weekly reports) and make majority decisions on important Guild questions, such as:

• How to change the format of sprints
• How to raise money
• How to compensate members
• How to cooperate with other projects, foundations and grant programs.

But any institution beyond the individual sprints needs to be highly accountable to the “active members” (a term requiring more rigorous definition) and to them alone. In the current setup, there is no risk of bribery or corruption in Guild Alpha, because any such violation of the trust of the members would immediately kill the entire effort. A more institutionalized Guild would not be so vulnerable.

[aschrijver]

A very thorough write up, @CSDUMMI, and I really like the considerate way that y’all are elaborating the Guild Alpha concept. There’s a lot of feedback I could give to the above, but I’ll (try to) keep this short.

On sustainability I’d like to advise: Consider all its aspects. You don’t need to delve as broad and wide as I like to consider it, but just for any moving part that you add to your organization structure ponder “Why would people be actively involved with this?” and then provide as many incentives as possible to motivate to participate in that area.

@CSDUMMI

At present, all members are volunteers and receive no compensation, either for their time or for the expenses they incur during their work (e.g. server costs).

@Tomat0 and I initiated the Guild with 0 starting capital, making it possible to experiment with the format freely and granting us the liberty to fail.

But this also puts a burden on members and restricts the potential pool of members considerably. A sprint can consume quite significant amounts of time that members could spend earning a living. The ability not to do so is a luxury and we must never forget that!

There’s a point here, and also in the Mental Health section that indicates a weakness and pitfall that should be covered sooner rather than later in the theme of holistic sustainability. I might summarize the theme of Guild Alpha to be something like “Collectively experience the Joy of Coding and contribute to FOSS”. Practical, pragmatic and hands-on. Great!

But all the process and organization structure incur an overhead to that, which entails an entirely different line of work. Different motives to be active. What inevitably will happen if not taken into account, is that this shifts workload to the people willing to do the ‘chores’. That may be no problem when people say “I gladly do that”, but then it becomes engrained and others take that for granted. When maintenance workload keeps growing, this can become a real issue though.

I think the focus is good and the democratic governance structure can mitigate the risks. But this structure itself adds maintenance and bureaucracy. Plus (this is an interesting thing, I haven’t explored much yet) the mere introduction of governance, while it can regulate power dynamics, at the same time introduces more power dynamics.

In this light wrt funding it may be prudent to first cover funding of the chores, rather than the code contributions in your sprints. Remember that “Joy of Coding” is an imortant motivator here. It is the quality of Guild Alpha that make it ‘fun’ to be part of it, and it should be made intrinsic to the culture.

See also:

• FOSS Dynamics: From "Joy of Coding" to Duty and Burdens
• (More background: CUPID, Social coding and Joyful Creation)

[Tomat0]

The vision of CSDUMMI has put forward in this post is essentially constitutes institutionalization of Guild Alpha, structuring it similarly to an NGO. What he has proposed, I strongly disagree with, and that is why I am laying out this response.

A First Statement of Principles

When I gave my talk to LibrePlanet for the need of new forms of organization within the free-software movement, one of the key points I wanted to drive home was the idea that “the foundations you start with end up defining the future you create”. How an organization structures itself, sustains itself, makes its decisions, and encourages its members to relate it all end up playing into a feedback loop.

Sometimes taking the easy route to these logistical questions (how do we incentivize participation, how do we make decisions, etc) early on can end up having long-term consequences that one may be unprepared for if they’re too focused on the short-term. It’s for this reason I do believe this debate is important to have, and why I will continue to strongly caution against imitating what works in the industry. Because what’s best for companies and NGOs (which often survive off of corporate backing) may not be what’s best for us.

Institutionalization is not costless: mechanisms of oversight, legal entities, fundraising, recurring costs, etc, all come with their own liabilities and dependencies (which I’ll get into later). Companies are able to mesh with this approach very well because they have a steady stream of capital to fund these operations, and as a profit-driven entity they are willing to prioritize the continuation of the institution.

This is why I have always held as a principle the idea that it is better to minimize costs than maximize income. Necessity breeds innovation, and in my view, it’s this “having to take the hard way” which has helped shape the Fediverse to what it is today.

For example, what separates PeerTube from YouTube is how each project responds to problems. Video hosting is obscenely expensive:

• YouTube chooses to approach this issue by maximizing revenue. Create an ad program to fund it, now you’re dependent on ad revenue. In order to keep the ad revenue above costs, all content has to be advertiser-friendly and only things which generate the most profit will be promoted. The institution’s survival becomes a capitalist question, as money capital was the lifeblood which YouTube was designed to run on.
• PeerTube on the other hand, had to start from the point of not having that capital at hand to centrally host everything. Instead, they needed to minimize costs, by distributing both the traffic load (via WebTorrent) and the storage capacity (via federation). This has created a design that is resillient to the sort of temptations and user-hostility present within YouTube? Why? Because the PeerTube as a network is not sustained by money but the efforts of the various people around the world hosting instances.

The crypto-bros make the exact same mistake: they create all these alternative platforms but fail to take seriously how their financing model creates perverse incentives. These platforms (as with the crypto-space as a whole) are built on a financial model of speculation/valuation, so is it any surprise that the platforms built on them show up as Ponzi schemes or hype-trains? The foundations once again influenced the future they ended up with.

What separates web0 from web3 is that web0 finds its foundations in simplicity, transparency, and freedom. Those principles, the same ones behind the Fediverse and it’s decentralization of hosting – the ones which stand so starkly in contrast to the models of Silicon Valley – are what I want to now bring over to the realm of FOSS development. And in my view, Guilds hold the seed for this – “federated” software development not beholden to capital or its interests.

Guilds as Guerilla Software Development

A brief bit of history, this concept of “federated” development was something I was working towards on an independent venture, until in discussions with Social Coding I came to realize CSDUMMI was also building up in parallel. Combining our efforts would be more fruitful, so I joined to launch the Guilds initiative, which was named such before I was involved.

I bring this up because I’ve generally seen this best, not as a “guild” or “union” of developers (which are terms which usually imply a formalized bureaucracy or mediator usually in collaboration with capital), but moreso as a form of “guerilla software development”.

Ideally what I would like to see out of Guild Alpha in the long-term is that with the lessons and recognition gained from our efforts, we’re able to publish a sort of handbook of sorts which provides a foundational structure to anyone out there who has the motivation to start their own guild.

This is how guerilla units have functioned in the past: rather than meeting their infinitely more equipped enemy with the same tactics, they use their mobility and smallness to their advantage. They didn’t need complex bureaucracies to get off the ground, often times motivation, mobilization, tactical creativity/adaptability, and a handbook proved sufficient. The ease of starting meant that they were capable of spontaneously and organically popping up everywhere without needing to get formal approval or centralize.

Capitalism is inherently totalizing, it seeks to turn all social relations into commodified relations. FOSS and it’s relationship to Silicon Valley is no different: Microsoft, Oracle, and other big players used every trick in the book to destroy open standards, open projects, and an open web. Only when “free software” turned into “open-source” and the majority FOSS development became about “brewing free beer for corporations”, did we see them soften their stance. Because at that point, the sphere had been sufficiently subsumed.

We now have development propped up by various grants (often by corporations or other non-profits sponsored by corporations), development propped up by donations (which often have significantly less spending room), and development directly done by corporate contributors.

In each of these cases, the success of the given initiative is tied directly to the survival of the administrative bureaucracy and the central organization performing the development. The future of a project such as Ubuntu is directly tied to the success of Canonical as an organization and their willingness to keep our best interests in mind.

The Hidden Costs of Institutionalization

My issue with the framing of “guilds” as a union is that it implies a permanent structure, one which merely represents the workers rather than being an instrument of the workers’ direct activity. The former fosters a sense of passivity, the latter fosters a sense of agency. As discussed at the formation, Guild Alpha is simply a prototype, it’s not meant to be the only guild or the ”primary" one. Its existence is transitory, its structure is suited to the small-scale, the goal of the initiative is redundancy: countless independent associations making decisions for themselves but united in a common goal/dialogue rather than a united organization.

And to finally bring this into practical terms, I think it’s this perspective of the “guild-union” which underlies a lot of CSDUMMI’s proposals here. Breaking it down, the main concrete suggestions/proposals by CSDUMMI are:

• The financial compensation of members
• The establishment of a fundraising structure
• The formation of a legal entity (such as an LLC) to manage the finances
• Establishing democratic mechanisms for selecting leadership

Each of these points tie into each other, as to financially compensate members you need fundraising and if you’re handling money you need an LLC, etc. I made the comparison to NGOs earlier because this approach to the tackling development is very similar.

Whereas an NGO’s development goal may be building up infrastructure in a third-world country, our goal is to build up infrastructure within a digital space. The NGO – as opposed to the traditional social movement – does this by raising funds, funneling those funds through an administrative apparatus, and then using money as the primary vehicle to drive development. NGOs have become commonplace under neoliberal capitalism, precisely because they operate within the same language. Governments and companies see them as an “efficient” means to clean up their messes in a fashion which is easily quantifiable and controllable.

The issue with NGOs (which I won’t get into too much detail here, but if you want more information, here’s a good essay) is that these often end up displacing organic social movements by members of the community, replacing them with a more top-down, less efficient form of mobilizing. The cycle of raising and directing funds requires a continuous stream of revenue (similar to how a business operates), which in turn means that overhead takes precedence.

It’s around this point CSDUMMI brings up an open question mark regarding accountability which is worth discussing:

But any institution beyond the individual sprints needs to be highly accountable to the “active members” (a term requiring more rigorous definition) and to them alone. In the current setup, there is no risk of bribery or corruption in Guild Alpha, because any such violation of the trust of the members would immediately kill the entire effort. A more institutionalized Guild would not be so vulnerable.

The accountability CSDUMMI here describes is a form of personal accountability, which works within the context of one guild. But long-term, we wouldn’t be the only guild.

A scenario which warrants concern, is one where someone chooses to set up a guild and mishandles finances. In such a scenario, it will not just be that the individual guild is met with distrust, but the concept of guilds as a whole. This suddenly becomes a matter of organizational responsibility.

IMO, organizational accountability can occur in two forms. The approach traditional organizations typically take is oversight. Set up an HR office, independent audits, external council, etc. The issue here is that this often comes with a trade-off between overhead and effectiveness. Lean too far one side and the mechanisms of oversight need oversight themselves, lean too far another and it becomes outright cumbersome.

In this scenario, a traditional organization may attempt to force every Guild to accept certain criteria, have certain standards of monitoring and accountability, etc to be part of the “official association of Guilds". But if we were to do this, we would lose sight of the original concept and make Guild formation a genuinely cumbersome process. Even just the requirement of forming an LLC (which in addition to being legal compliance, is a form of accountability) would already be a hurdle which’d render this inaccessible to many.

The other approach, which I would see as much more in line with the decentralized structure, is to focus on minimizing liabilities and dependencies. Right away, the most obvious one is funding. Introducing money into the equation instantly raises multiple layers of questions:

• How do you ensure nobody misuses the money?
• How are pay rates decided? The Guild, having a limited budget, has a structural incentive to pay contributors less, while the contributors have a financial interest to be paid more.
  • If there’s conflict over payment, how do we make sure the issue doesn’t blow up?
  • If the Guild is short on funds, are we going to see paycuts or layoffs?
• What happens if we aren’t able to consistently raise funds? Do we just shut down?
• Will pay create undue pressure or expectations on members?
  • Are guilds going to monitor people’s hours? Are they going to judge the quantity of their work to ensure they’re getting their value’s worth?
• If one Guild can afford to pay more than other Guilds, will that create a situation in which only the most well-funded Guilds are able to survive in the market?
• Is it reasonable to expect not just we, as Guild Alpha, deal with any of the above questions in a fashion that reflects well on the guild concept, but everyone who runs a guild?

So, before we take upon this liability (and by extension the dependencies we may have to donors/grant-bestowers/etc), we should first ask ourselves if we really need this. Remember, the foundations you start with end up defining the future you create.

Paying developers may open our pool of talent in the short term, but in doing so, we’d be creating a future in which FOSS development is relegated to the status of “second job”. We wouldn’t need to introspect and find intrinsic motivation for doing the things we do.

Relying on grant money may give us more flexibility in the short term, but in doing so, we’d be implicitly making a statement that FOSS development can only be sustained with grant money.

Motivation and Sustainability

In these discussions, a lot of emphasis has been placed on the word “sustainability”, but I really do want to ask sustainability towards what end? One of the questions raised by @dannymate was the following:

And lastly is your vision sustainable? We live in a capitalist society. The whole point of it is to grind down workers so they don’t have the energy to anything else. If we can’t offer an alternative to wage slavery then are we really helping people or are we just using people to push our cause. Is addressing that even a goal of a Guild?

Creating an alternative to capitalist wage-slavery cannot involve simply repeating the methods of capitalist wage-slavery. If I’m being grinded down 10 hours a day for a wage, but am told that I can put in 2 more hours a day for a wage, is this really addressing the issue at hand?

We have to return to the intrinsic motivations which power our work. We have to, as @aschrijver says, discover the Joy of Coding. The hell of capitalism is that it takes the creative, fun, activity of people and makes it alienating by tying it to a wage. If intrinsic motivations for working on software are not enough, then we are not challenging said capitalist society. Rather instead, we’d be admitting its inevitability, by mimicking its patterns.

I don’t see “our cause” as simply making better Fediverse projects. I see it as freeing the process of development itself, not just in terms of what we can get done but also in terms of having more freedom in what we do. The following are all very valid intrinsic motivations:

1. Tinkering with, learning about, and writing software can all be fun. People complete puzzles for fun, people problem-solve in video games for fun, people read for fun, people tear apart computers for fun. People contribute to free-software for fun too.
2. Wanting to see a feature, wanting to steer the course of development, or wanting to see the space grow. All the same reasons why you see people volunteer elsewhere, whether it be charities or political organizations.
3. Collaborating with other people can be a great way to meet people with common interests and socialize.

This is all in line with the theory of human motivation by Alfred Adler, one of the most influential figures in human psychology. Adler noted that human beings were intrinsically motivated by two things:

1. A sense of accomplishment or goal-directedness. Seeing the product of your labor or fruit of your efforts can in and of itself feel rewarding. It doesn’t feel rewarding under capitalism because you don’t have that creative agency over what you produce and on what terms, you’re always doing it for someone else.
2. A sense of social belonging or community. People are social creatures, and they bond not just over shared interests, but shared experiences and shared efforts. Collaborating with others allows you to meet new friends and socialize in a creative fashion.

It’s the same reason you see people participate in Godot Game Jams, or those Animation collabs without pay. Things only become boring, become a burden when you’re doing it out of an external obligation. By creating a structure which draws out the intrinsic motivation, that is how we truly create an alternative to capitalist drudgery.

And this is another point where I disagree with CSDUMMI:

On the other hand, compensating a member’s time should be a goal of Guild Alpha. Developing free software is a highly skilled profession and should be compensated as such. While this is at the moment unattainable, I believe we should aim to allow members to be compensated for their time fully in the future and never argue that the Guild is an endeavor that people should simply be happy to work on during their free time. Doing so would mean the Guild had failed in it’s purpose - to make free software development sustainable. Currently we can only make it more sustainable by providing support in a team, learning from each other and organizing. But we should also aim to make it sustainable financially for members to participate.

The purpose of the guild IMO is not just to make development “sustainable". It is to create a model of development that returns the sense of agency and fun to the process of development. What makes free software special isn’t just in the product or the benefits for the consumer, it’s in how it blurs the line between the roles of producer and consumer.

Development no longer has to mean begrudgingly doing the thing you do because it keeps the lights on. Recreation or “fun” no longer has to be passively consuming stuff other people made. Capitalism insists upon this strict division of relegating every form of activity to “work” and restricting “play” to only be passively consuming things. Because by doing this, all social relations simply become a matter of passing around money.

The goal of the guild should be to insist upon this subversive character of free software again, not just in product but in production. We’re not here to use people because the primary goal isn’t to meet deadlines: the primary goal is to do stuff, and have fun doing stuff.

This approach puts the hardest questions towards us up-front, such as how we can channel that intrinsic motivation within the context of a capitalist society, or how we get around certain hurdles which are traditionally solved with money. But in my view, it’s better to handle those questions up front, when we are afforded the benefit of trial and error, rather than to perch ourselves on top of short-term success and find ourselves having to deal with questions later down the road.

But this also puts a burden on members and restricts the potential pool of members considerably. A sprint can consume quite significant amounts of time that members could spend earning a living. The ability not to do so is a luxury and we must never forget that!

By expecting members to have this luxury, we are excluding large demographics unintentionally from participating in a sprint, foremost including the poor, national and global.

Computing and programming is an activity that has been turned into a place dominated by certain demographics: white, western, male and we are no exception to that.

To counteract this does not just require a declaration of “openness”, as as @Tomat0 and I have made in the first and now in the second sprint. It requires providing members without the luxury of time the ability to participate in exchange for compensation.

But as for the question of inclusivity, yes, functional time constraints are a genuine barrier to entry for these endeavors. However, I do think CSDUMMI is overrating the impact this would have, especially when we do not have market-level revenue incoming by which we can ensure market rates. In addition, a lot of people just do not have time, period.

As for the question of diversity and demographics, this isn’t just a matter of compensation. As you pointed out, industry-wide there’s an over-representation of white men (within the context of the West), however, this is despite the industry paying well relative to other professions. The lack of women, the lack of certain minorities has to do with cultural issues that are better addressed by existing organizations such as Outreachy. The best thing we can do in my view is treat these people with respect when they join.

We won’t be able to remove the hesitations/blockers of everyone, so the question becomes what steps can we take to increase accessibility without adding overhead which ends up affecting the whole guild. And remember, we aren’t the only Guild. Every layer added here adds another barrier to which starting a Guild becomes increasingly more and more inaccessible. Handling money, transmitting money, setting up institutions to comply with finance laws, matching the pay rates of other guilds, all of these are serious burdens which (in my view) constitute much larger burdens to accessibility (and long-term sustainability of the initiative as a whole, not just Guild Alpha) than the scenarios you laid out.

True sustainability will come from replicability and redundancy. A scenario in which Guild Alpha gains a sort of “institutional legitimacy” which puts it above other efforts is not sustainable. If something happens to Social Coding, if the team makes poor decisions, etc, that takes everything down with it. Power is going to come in numbers: as CSDUMMI said, starting this we had the liberty to fail and make mistakes. Why? Because we had 0 investment. Other groups should be able to quickly wind up, wind down, freely associate and dissociate as they see fit. Organizations rise and fall, techniques on the other hand, stay with us. They can be freely used, revised, and improved irrespective of what happens to their originators.

Keep it Simple

First of all, I think, we should be able to provide certain infrastructure to members, e.g. a server for testing purposes. It should be possible to compensate members for such expenses, which they have to incur to effectively work on a sprint. Whether this includes only those costs that were exclusively incurred for the sprint (e.g. registering a domain) or also more general purpose expenses that made participation possible (e.g. a computer) is debatable and I’d only compensate those more general expenses in special circumstances.

We’ve run into situations like this before, where a VPS was needed, where a domain was needed. Members took to self-funding these, and determined how to handle the expenses among themselves. Even in a scenario where a guild has nobody capable of bearing these costs, they’re still capable of making the determination among themselves about the best way to get the money (or whether they can circumvent the costs). I do not need to see why this matter needs to be outlined as a matter of standard policy. If the guild can avoid fundraising without putting undue financial burden on its members, then they have every reason to avoid.

And IMO this reflects a larger message which I think is important: keep things simple. Just as how many in the free-software space rightfully criticize the normalization of proprietary bloat, we shouldn’t automatically assume that every problem needs a complex solution or policy to address it.

In that earlier case about how do we ensure people don’t burn out, whether it be from the sprint development itself or the administrative tasks? We do it the way we did it during our first sprint. We keep a pulse on how members are doing, and adjust accordingly to what best fits the team and moment. We lessened expectations and emphasized structure. We came up with a schedule that didn’t pressure people to finish work, but rather instead do what they could within a boxed window. We had discussions about what kind of culture we wanted to foster and we began moving in that direction.

There is no one-size-fits-all answer or compensation package that’ll address the problem. Rather instead, we shouldn’t underestimate the power of just talking things out and adjusting the goals/workload to fit the team and what they want. This is not a job, there is no set of expectations here, if people don’t want to do the work then the Guild was a non-starter to begin with. Guild Alpha won’t always have the same amount of administrative work as in these first months, and most guilds may not even set up the same administrative things as us.

As a general principle, our decisionmaking processes should prioritize in-the-moment decisionmaking and do-ocracy, as those best give flexibility to teams, foster a culture of agency, and circumvent bureaucratic overhead. Guilds should be small enough that people are capable of working interpersonally. Members shouldn’t feel like voters, but actors.

On this note, that’s also why I caution against treating democracy as a generic principle: democracy can be great, there’s great applications, like how we set up proposal voting. But at the same time, it has to be remembered that democracy is a deliberative process: it’s defined by its functions of voting, campaigning, and proposing. Something can be put to a vote and not be a good fit, all depends on how it’s executed.

As for an election system for editors as CSDUMMI has proposed, I do agree with CSDUMMI in that it is important to not just have a fixed group of Editors, but ensure the knowledge is spread around:

I don’t want to be an editor in every sprint of the Guild and I also want to spread the knowledge of how to organize a sprint & start a Guild as wide as possible. This will make the concept of a Guild far more resilient than it ever could be, even if the three of us organized a hundred sprints.

I have a couple of hesitations about having this be done as an election, however. I’d rather not create a situation in which members are regularly pitted against each other (and if it goes too far, having to campaign). I’d rather see this executed as a queued volunteer system, where people apply, and if there’s too many, we do something like first-come-first-serve or a coin toss. Anyone who doesn’t get in on that Sprint could be put into the front of line for next Sprint. This’ll run less risk of creating ill-will, while also distributing the load.

Also worth noting, the lines between administrator and Editor are still not clearly demarcated enough for me to say for sure what it’d entail. Will the Editors take over Intersprint periods, would they handle the fundraising, would they administer the site and servers? I’d rather keep the administrator roles fixed to whoever founded the Guild and their discretion, as that constancy will run less risk and generally keep smoother operation. To encourage Administrators to maintain the culture of cooperation, maybe having a Code of Conduct for Administrators on what their place is in the larger system and how they should interact with other members.

Conclusion

This is somewhat a culmination of all the topics of this thread. More permanent democratic institutions help us raise money, compensate members, support our mental health and make our democracy stronger.

In conclusion, I believe institutionalization is very risky long-term and will undermine the strengths that set our community apart from the countless other organizations in existence.

Raising money has the capacity to turn guilds into a racket and foster perverse incentives. The accompanying oversight only make guilds more top-heavy.

We cannot assume adding more institutional layers will ease our burdens. More overhead means more work, and new stresses (especially with money involved). The most reliable way to support our mental health is to decide for ourselves, in the moment, what we as a group are comfortable committing to. Plenty of institutions, from NGOs to corporations end up undermining the wellbeing of members, as they become increasingly impersonal.

And finally, what does it mean to make democracy stronger? Is democracy in and of itself the virtue, or is democracy simply one means by which we can occasionally get other things (agreeable decisions, cooperation, etc)?

By embracing our strengths (mobility, personal connection, fun) as a non-institution, rather than being ashamed of them, I believe we’re able to offer something new to developers sick of the usual grind of their jobs and the free-software advocates who feel as if their only future is one subordinate to the market.

Extra Notes

• I agree with CSDUMMI in that CryptPad forms aren’t going to cut it long-term. When we get around to getting a VPS, we should have a discussion on what polling service to add onto there.
• As for tiebreaking, I would like to get to the point where we can do public polls to tiebreak, but until then, I’m fine assigning an external tiebreaker as the fallback.

[dannymate]

This is just me thinking out loud for the most part. It’s not going to be well thought out like the other ones. I posted this in Matrix chat in response to tomat0 but I thought I’d post it here.

I like web0 looks cool. Looks fun. I like decentralisation as a topic. I also like direct democracy. I also like you bring up mobility. Mobility is the most important part as far as I’m concerned. I’ve been thinking of a few things about the start of this sprint. And to be honest it does just feel like project devs would love to have a little pop up team they can use to get more stuff done. And I think that’s fun for a lot of people too.

Also alternatives to spending money I agree. We should actually mandate that nobody is allowed to spend money on things explicitly for guild work. Using stuff they already pay for sure. Alternatives will be found whether that means we partner with like minded groups or otherwise. I find restrictions are a good source of innovation.

I also agree that other guilds may not set up like how we have. Maybe they shouldn’t even. Though at the moment I see no issues right now with what we’ve done in terms of static sites.

I’m sad that the chore side of things didn’t get brought up though. I enjoy exploring the guild concept not writing Codes of Conduct or whatever. I wonder if the word Guild is giving us a subconcious biased view of the structure. I wonder if there’s a structure we can make where there’s no need for editors. Other Guilds hopefully will exist at some point. But I wonder if we can perform multiple sprints under one Guild because I think that would be cool. If that’s the case then I wonder what that says about the structure of a Guild.

Maybe a Guild can be a bit of software. A quest board that people post proposals and members vote on whether those proposals get added to the board. Members create little groups and take on the proposals. As a game developer I think this could be the most fun option. We can gamify it and make it all fun for everyone. Have silly little rewards like trophies and stuff. Like some kind of federated programming MMO (obviously not like WoW or anything) type thing.

I quite like my idea of Guild as Software (I suppose I would). It’s an idea I’d forgotten about before. The software, whatever the end product would be, would be part of the fediverse. Forges like Forgejo and Gitlab are all trying to implement ActivityPub. Whatever else a Guild could need can be hooked up using ActivityPub. Maybe a Guild should focus on socialising coding? You can see in MMOs people join guilds and socialise within. They compete and work with other guilds. I have a feeling there’s some interesting new ways of coding in this idea somewhere.

In terms of admin there’d only be the same amount as other social platforms really. Which maybe is a lot but at least it’s the same problems as the rest of the fedi community and we can thow our lot in with them.

Edit: I imagine this as a social media for developers. Like other social media we can have large general instances that do various things. This would be good for fledgling projects to go ask for help. Then we can have specialised instances like one for Mastodon where members of that community can better organise and take on tasks.

Of course you’d be able to be part.interact with multiple Guilds much like you can other fediverse stuff. I can imagine a Guild for accessibility or specific types of accessibility where they target implementing accessiblity into projects.

Maybe one day whole guilds can manage projects in a decentralised fashion using this software. Everybody in the Guild would have ownership of such a project. Would be interesting. Maybe we could be the first with this.

[aschrijver]

@dannymate

I quite like my idea of Guild as Software (I suppose I would).

The way I view Guilds has multiple perspectives. First of all it is an abstract concept, namely a form of organization aimed at doing stuff collaboratively. Secondly given the elaboration of that concept you can add technology (socio-technical) support. That should be aimed at minimising the chores, maximising the fun.

Do something manual the first time? → Hmm, maybe we can automate parts of that for next time.

Adopt a mindset of Kaizen, continual improvement, where even the smallest improvment counts, and they are made ‘just-in-time’ so as to keep things lightweight and not incurring too much overhead (chores).

[dannymate]

I think you’re missing the point. I’m not stating we should automate chores at all. I thought maybe we shouldn’t have any editors and therefore in that world chores can’t exist. If we’re already shooting to be different like tomat0 said then why are we holding to these ideas in the first place?

These are thoughts and thought experiments. These are based on my experiences with chores and on the sprint work. It’s also based on the fact that currently the best form of organisation devs currently have is to host discuss apparently.

My solution to this thought experiment on a world without chores was software. A social media for developers. A place where organisation can organically take place around an instance defined topic. There’s problems with the idea sure but it wasn’t really the point to be perfect.

We also need to decide if our end goal is something like guild as software otherwise known as Project Guildilocks. If it is then we can further define it and orient our ship towards that destination. Even if we don’t go down the software route, thinking about it can unlock some other idea we can use.

If not what are the alternatives? Automating chores is still a chore. Maintaining that automation is not fun. Developing software is fun. Software != Automation. If we can do Project Guildilocks entirely manually then I’m not sure there’s a point in developing it anyway.

I also believe we’re not the smartest people in the world. If it was able to be done manually then others would have done it centuries ago. And looking at the history of what a Guild is then I imagine they couldn’t under their systems. Software can do magical things.

I read the posts about trying to have fun with this whole thing and I took that to heart. I’m not having fun with Guilds right now. I will admit it was never actually my intention to take part but the idea speaks to me. I believe we can help organise the FOSS community. And this is a concrete idea based on platitudes and ideals.

Edit: Guilds should be all fun all the time. And if we’re not shooting for that then I don’t care for the concept.

[aschrijver]

The chores is the 2nd part in my post. It starts with some idea/concept → socio-technical support. Social coding movement itself started from this line of thought. So I’m fully with ya on the ideas. Chores, however, are inevitable imho. They always creep in. But if you are lucky you can find people that see fun in doing them, and you can specifcally look for them.

[dannymate]

Socio-technical: " Therefore, sociotechnical theory is about joint optimization,[5] that is, designing the social system and technical system in tandem so that they work smoothly together. Sociotechnical theory, as distinct from sociotechnical systems, proposes a number of different ways of achieving joint optimization. They are usually based on designing different kinds of organization, ones in which the relationships between socio and technical elements lead to the emergence of productivity and wellbeing, rather than the all too often case of new technology failing to meet the expectations of designers and users alike."
I think that’s right but I can’t instinctively understand right now so I’m going to just end up being more verbose and saying the same thing at the moment. I’ll try and learn more about it.

I don’t necessarily disagree with chores creep in but instead of thinking about it by ourselves we should lump ourselves in with the rest of the fediverse with this problem. It’s at least a known one.

Hosting a server and moderating it.

I also don’t believe that we should go into a topic thinking something is inevitable though. I like to think in the extremes and I will push the systems until the theory works.

I also try to think of chores as a resource and moving a chore to a computer still makes it a chore. Why can’t the computers have fun? Only when you turn chores into fun stuff is the chore gone. So I wouldn’t want to find the right person to find the chore fun but to make the chore as fun as possible in its own right. Then those people who already find it fun can have even more fun. That’s my indie dev instincts.

At the very least spread it among so many people that people just do it instinctively. Like voting. But you can totally make voting fun.

Edit: Actually one recent example of spreading a chore among multiple people is the Pine64 blog. The writer couldn’t continue with the blog posts anymore so they are now written collboratively by the community.

[Tomat0]

I’ll keep this short since I had my dump in the first post, already went into some of this in the Matrix:

1. I think the bulk of the administrative tasks can be eliminated in the future/for other Guilds if we take care to develop templates and standard procedures. Have a sample Code of Conduct, sample tech stack (maybe a script to get it running on a VPS), sample documents, etc. These are the first months of the first guild so we’re going to have more work than usual.
2. As for the software idea, I’m rather skeptical. I think it’s going to come with a lot of liabilities/questions (how do we keep the network active, how do we design all these tools in a way everyone will like, what happens if we stop maintaining the software, etc). I’m tempted to say Keep It Simple again. Keeping it as a handbook with instructions/model for organization will not only give devs the flexibility to adapt their stack to their needs but also means that the survival of the initiative isn’t inherently dependent on our capacity to maintain. As long as someone has that handbook, they can modify it, spread it, etc.

@dannymate has vaguely attested to ideas of gamifying chores/finding ways to spread them around, that personally sounds like a lot more promising of an angle to pursue to me, IMO.