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:
- Donations (OpenCollective, Patreon, etc.)
- Grants (NLnet, Prototypefund, etc.)
- 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:
- Using plurality voting (again) as a tie breaker
- Assigning an external tie breaker beforehand.
- Holding a simultaneous poll on the Fediverse and using the result as a potential tie breaker.
- 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:
- A ranked-choice vote among members is held.
- If this ties, a poll on the Fediverse is held to break the tie.
- If this ties, a plurality vote is repeated until a project receives a plurality of votes.
- 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:
- 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.
- 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.
See: socialcoding