Unionize Free Software. Found Software Guilds

In the article “The changing economics of open source” Ken Mugrage present the Free Software Sustainability problem from the perspective of companies depending on free software developed by hobbyists.

The article defines three different types of free or open source software:

  1. Free Software developed by companies or individuals trying to make a living by this activity.
  2. Open Source projects used for publicity of Big Tech.
  3. Free Software developed by hobbyists as a recreational voluntary activity.

And provides examples for each of these types of projects, namely ElasticSearch, React and Log4j respectively.

It ends with a recommendation for companies to:

  1. Investigate what project’s they depend on
  2. Review how likely these projects are to change licensing.
  3. Investigate the possibility of maintaining a fork of a FOSS project if the project developers change licensing.

While these recommendations are rational from the perspective of a business depending on free software - which today is almost every business, even if they just use Wordpress for their website - I disagree with the underlying assumption that free software can be exploited for maximum gain and that companies should try to make themselves independent of a free software developer only to then continue to benefit from their work for as long as possible.

The example the article provides of ElasticSearch and AWS I find particularly disturbing:

For instance, ElasticSearch changed its licensing terms in 2021, to include requiring cloud service providers who profit off its work to pay it forward by releasing the code for any management tools they build. […] They prompted Amazon Web Services, which had been offering a managed service based on ElasticSearch until the change, to “fork” the codebase and create a new distribution for its OpenSearch product.

Here the enormous company AWS would not accept that ElasticSearch wanted them to afford the same courtesy they had provided AWS by releasing their source code to others.

This is exploitation by a big tech company of free software. And it cannot stand!

We shouldn’t advise companies to exploit free software as much as possible and to cancel that relationship as soon as it gets inconvenient.

If a company makes the majority of their profits from a service reliant on free software, they shouldn’t be able to dictate to the free software developers the terms of that relationship.

Unionize Free Software

Free Software Developers, regardless of whether they develop software for recreational and hobbyist purposes or to sustain their living should unite into a group.

In this group they should be united to:

  1. Share maintenance of projects by making it possible to quickly find temporary or permanent maintainers for projects in the group or even sharing the maintainer role between two developers permanently.
  2. Defend against exploitation by collective action. The licenses of the group would by synchronized and the group should be able to sue in case of violations to the license terms of any of the member’s projects. In a case like that of ElasticSearch and AWS, the entire group might change their licensing together, making it too expensive for AWS or another big tech company to fork each and every single project and maintain it in house. Thus forcing them to negotiate with the group as equals.
  3. Pool donations and funding. Instead of every developer raising the money to maintain their own development, the group collects donations and funding together and distributes them according to a democratic decision by all members.

Let’s for example ask, why I (@CSDUMMI) or @aschrijver would want to join such a group? @aschrijver is a maintainer of several projects, among them the coding.social website and I’m a developer of free software, such as the maintain-website-tool.

By joining such a group we would gain:

  1. Maintenance sharing and support. Maintenance sharing means developers in the group agree to be maintainers of each others projects, allowing them to take time off from development and having the other taking over either temporarily or permanently even. Support is both financial, social and collaboration.
  2. Defense against big tech by collective action. If my maintain-website-tool for example was integrated into a service by AWS or Google, the group would provide me with a stronger voice to challenge this if I wished, while I personally would think more than thrice about sending a complaint to the overflowing Irish or American mailboxes.
  3. To be allowed to sustain ourselves by our development and our development only. We don’t want to have to split our time between development and fund raising at all times.

Union of Free Software Developers

Free Software development is a peculiar and unique industry. It is the only industry where volunteers, paid employees of third companies and employees of the company developing a piece of software can work side-by-side - without discussing this difference in compensation or incentives.

Due to this situation a Union of Free Software Developers have to be open and accessible to all of these people.
It needs to be as global as free software, directly-democratic and yet be able to sue and represent their members in court.

Thus I propose an organization in two parts:

  1. The group itself, organized through online forums and the Fediverse, holding votes and debates, raising money. Accepting members and the like.
  2. A non-profit foundation cooperating with one or more of these groups that is financially supported by them. They should be able to sue and defend the terms of the licenses of the projects of the group members they cooperate with, hire lawyers and do lobbying work to give these groups a place at the table for negotiations in government. They need to. The exploiters certainly already have an ancestral seat at those tables.

Conclusion

Free Software Sustainability is the problem of free and open source software today. Providing solutions to this problem will not just determine how free software will be developed in the future but also what free software will be developed.

Because the way people are supported and motivated to develop software is an important determinant in what is being developed.

I believe in the force of internal motivation and despise any attempt to demand free software to commercialize or otherwise optimize towards some external quantitative goal - ratings, stars, users, downloads and other such statistics.

If free software development can only be sustained by all of it fulfilling some external standard, neither the freedom 1 nor the freedom 3 makes any sense anymore.

  • The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this. […]
  • The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
    The four freedoms

These freedoms are the basis of collaborative free software development. So, to limit or define what constitutes “proper”,“sustainable” or “reliable” free software is to limit these freedoms by limiting how they are exercised “properly”, “sustainably” or “reliably”. You can make arguments that software ought to be developed using some paradigm or using unit tests but don’t require free software to fulfill these criteria to be considered “proper”, “sustainable” or “reliable” free software. Otherwise you are limiting what free software itself means.

To return to the article I began this post with, Ken Mugrage does just that. The article defines what free software a company should work with, which they should undermine and which they should avoid - once again, this is legitimate from a company or even devops perspective. But the free software movement should not let itself by commercial company interests…

2 Likes

There has been some very active discussion about this post on the Fediverse in response to my toot requesting feedback.

I want to summarize the arguments that were raised in response to this post and respond to them.

Free Software shouldn’t be developed to be exploitable by the big tech capitalists.

@alcinnz@floss.social made this argument, that they advised against making free software that suits the big tech capitalists.

Examples for this kind of software might be:

  • Deep Learning Libraries, that can only be operated on super computers and cloud services - which profit big tech capitalists, who own these services.
  • JavaScript Frameworks. These most benefit the websites with the most complex and advanced browser logic. And these are mostly profiting the big tech capitalists. While most websites only need a CMS or static website generator with a little bit of styling.

While these discussions are legitimate and should be had, this is a discussion on creating sustainable free software. And we shouldn’t make make more assumptions about free software than are part of the definition of free software.

In my post I took the four freedoms of the GNU Project for this definition, but I’m not limiting this post to only the GNU Project Software or their licenses. Since they are not the only licenses that uphold all or some of these freedoms.

I believe these kinds of arguments should be had, but not to develop a system for sustaining free software - because that’d then only apply to parts of the free software movement.

Creating an organization for free software centralizes free software.

This was a concern raised by several people, @TMakarios@theres.life and @thatguyoverthere@charlestown.social among them.

The arguments against decentralization brought forward are:

  • Centralization is prone to corruption and overreach. The term corruption is not used, but the term used - mistake - is not very specific and most mistakes can be averted in a centralized organization.
  • Gate Keepers. What if the union creates a Gate Keeper for free software - excluding some and creating some hypothetical bureaucratic burden on others.

I find all of these arguments odd, mostly because I have not provided details on a structure. The only place that I could conceive of as a cause for such concerns are these two points:

But I actually wrote these two points because I don’t want to create a centralized, bureaucratic structure that limits who can and cannot develop free software.

So, let me provide some elaborations on these points.
Firstly, membership in a group should not be a prerequisite to contribute to free software. Membership should probably not even be public.

Secondly, the reason for this division into an incorporated organization (a non-profit foundation) and an unincorporated, global, online organized group is to isolate bureaucracy and centralization and put them on the fringes of these unions. Only when a Union has to take legal action in a jurisdiction, i.e. the EU or USA, do they rely on an incorporated entity. All other actions can be taken without bureaucracy and in a form determined by the group members themselves. I would advocate for an online forum where new members are accepted by a simple vote and all decisions can be made by a simple online referendum. In such a system appointed leaders, delegates and the like are to a large part unnecessary. Why should a parliament of delegates make a decision if all members of the group can make the decisions just a quickly and through the same process? And those appointees that are still necessary are more accountable because they can at any time be replaced by quick online referendum.
Digital civil organization is very much possible.

I understand and agree criticism that this could lead to a hierarchical or centralized authority, but I the remedy for centralized authority cannot be individualism - because individualism benefits the status quo, which is exploitation of the individual software developer, who cannot defend this because they alone stand against companies and governments that make profits each year that are enough to live hundreds of lives every minute and are located on the other side of the globe.

We need to organize at the risk of becoming more synchronized in order to gain equality, recognition and the support we need to sustain the current model of free software development. One that is open to all - even those who only have minor or even no technical knowledge - but one that anyone who wants can also make a living independently from the far more exclusive gate keepers of big technology capitalists.

Because the truth is, if you do not just want to contribute to free software but also want to sustain yourself from this or even get fair payment for your labor the gate keepers are far more restrictive than any such union would be. Currently the only ways to sustain yourself through free software development are:

  1. Being hired by a tech company that wants you to work on free software. Here the company and company priorities are gate keepers.
  2. Providing a software so useful that people will donate to you. The chance of this being enough to sustain yourself on are about equal to sustaining yourself as any kind public figure, because that is what you inevitably become. A person perpetually engaged in self-promotion in order to gain donations.
  3. Hiring a lawyer to investigate license violations and offer open core or dual licensing. You are essentially founding a business on free software - with all the gate keepers that that entails, including access to capital, to a stable government and bureaucracy and international labor markets - because you cannot do this on your own, unless you want to do significantly more than actually developing software, such as accounting and advertising.

None of these options are without gate keeps and all but the second one involve a centralized bureaucracy. So, trying to create an alternative that is accessible regardless of where you live and regardless of the wealth and social status you have, is a legitimate third way in my opinion.

As long as they don’t break with the license requirements they can do whatever they want

The above is a quote from @thatguyovertheer@charlestown.social and exemplifies what I think an old mindset that originates in the struggle for free software and open source software to be successful but that really does not apply today anymore.

Sure, the license does not preclude a company from doing whatever they want with the free software they are provided with, but don’t they have a moral obligation to the people who’s work they are using to great profit? Shouldn’t they at least talk to them and consider their needs instead of ignoring them and exploiting the existence of free software almost as an infinite resource. Assuming, falsely, that it’ll always exist and that any bugs and problems will be solved on their own. Is see a pronounced parallel here to the fossil fuel industry and their exploitation of the environment, just that the fossil fuel industry only indirectly exploits the lives and quality of life of people while Big Tech exploits human beings directly by using their software and seeing themselves under no obligation to return anything to these human beings.

Changing this attitude requires collective action - as has been proven by the long history of labor and union organizing around the world.

2 Likes

I want to follow up with some additional thoughts…

Be Unionizable

For Social Coding we are elaborating all the aspects from Inception to End-of-life of the Free Software Development Lifecycle (FSDL).

A healthy, sustainable FOSS project should have “being strong to withstand the forces that lead to exploitation” as a strategic objective, and follow Best-practices to make that so. While the unionization entails organizing as a collective each and every project can organize to:

  1. Taking care to be least attractive for exploitation.
  2. Preparing project organization to be easiest-to-unionize.

Being part of a union and benefit the most from that participation will impact project processes, and point 2) relates to those measures, even before a union is joined. It’ll help lower the barrier to join, and increase the effectiveness of the cooperation after joining.

In summary there is an indivual part to unionization, and that can be combined with the collaborative approach. And there is an equivalence in the business world. In some countries there’s by law the establishment of a Works Council (in Dutch: “Ondernemingsraad”). A union at company level, where a council of employees monitors the management decisions.

Translating to FOSS projects it would relate to people monitoring detrimental forces to the health and sustainability of the project.

“Let’s play and win our own game”

This was the title of an ActivityPub Conference 2020 talk by Darius Kazemi talking about strategies whereby the Fediverse would utilize their own strength. There’s some good advice in it. For instance around the 16 minute mark comparing what is “Easy to centralize” and what’s “Hard to centralize”:

It boils down to “Easy to centralize → Technical features, Hard to centralize → Social features”.

Decentralized unionization

In the discussion and feedback highlighted above there are concerns about the centralization, power and authority of the Union. This is a very sensitive and controversial subject on the Fediverse, and it always pops up in these kinds of discussions. A centralized non-profit would likely be rejected outright by a lot of FOSS projects, and many fedizens would communicate negatively on its existence.

But I believe this problem can be tackled, and that the unionization can be inherently decentralized while still be able to raise a collective fist. Going further on the “Be Unionizable” above, each project could be contributing to a larger organization structure, as decentralized ‘circles’.

I am thinking in particular of organizing along the lines of Sociocracy to make things governable but not centralized. We are holding meetings to define Sociocracy as building blocks on the Fediverse. I will add a reference to this topic as input for next meeting.

“Union” in the abstract

A union doesn’t have to be an organizational form that is similar to how we traditionally know them to be. The “Union” is more of an organizational pattern, and can be embedded / integrated into all different kinds of organization structures. It doesn’t have to be a non-profit / NGO called “FooBar FOSS Union” that is specialized on unionization tasks and to which FOSS projects apply for membership.

Another FSDL and Ecosystem Foundation pattern I recently created a placeholder topic for is the:

FSDL: Ecosystem Alliance

Summary: Strategic cooperation whereby different projects, groups or communities, while each operating independently, agree to collaborate and evolve an ecosystem collectively. They anticipate each other’s needs, align roadmaps, features, etc.

Well, an ecosystem alliance could just as well include a Union to defend it.

Proposal: Develop the Union as a pattern and building block that is part of the FSDL

Note that this would aligns very well with the principle that any FOSS project should be able to just pick & choose from the patterns and practices in the FSDL in the way that best fits their own preferences and needs. And this will provide them a range of options to implement unionization strategies. Here I will also cross-reference to FSDL: Open Strategy best-practice placeholder.

Incorporating the Union

In earlier discussion there’s mention about incorporation, e.g starting a non-profit. With my additional feedback of Decentralized Unions, Sociocracy, and Ecosystem Alliances it can be seen that there may be multiple different incorporations, either as non-profit or cooperatives, etc. Each with their own governance, but still part of a larger unionization force / movement.

Non-profit as interface to the biz world

I’d like to mention more on the notion that a non-profit is a centralized entity…

It doesn’t need to be that. The non-profit can be stripped of all tasks except for providing those services to allow it to interface to the traditional business world. So it can have a bank account to collect funds, so it can hire a lawyer to defend union interests, etc. It does the hiring and the funding, the bookkeeping, but the actual activities are not performed in the non-profit itself.

The non-profit may be part of a Non-Profit Venture, where the other part is a Cooperative with its members being FOSS projects and Communities. The Cooperative consumes the services that the Non-Profit buys / obtains.

Advice: Break down into FSDL Patterns

This is a large idea with many moving parts. I must urge anyone when elaborating on it to think about how it can be broken down into separate patterns of the FSDL and how they interact with other patterns already defined. (As a helper think of it like elaborating a software project into modular code).

Example: Licensing protection discussion

In Matrix chatroom this forum topic was discussed, and the interesting idea to use FOSS Licensing strategically to fend off exploitation. The Union here would be the guardian of licensing issues and act on a project’s behalf if some external party is in breach of the license clauses.

Licensing is a separate FSDL component. Licensing strategies are additional pick & choose patterns for a FOSS project to adopt. They encompass a world of expertise in itself.

So, I encourage anyone to think about the breakdown into constituent parts of the FSDL, and add a reply to this thread, but also a new topic when a different Best-practice pattern is discussed. And then create a cross-reference between those.

In this case one thing that was addressed is adoptiing non-free licenses that aren’t recognized by FSF and OSI as FOSS licenses. Still, there may be good reasons to adopt those. But this consideration comes with its own Pros and Cons. It is a pattern that must be separately documented.

I posted this thread on the Fediverse in relation to “Let’s play and win our own game” by Darius Kazemi, as mentioned above. Summarizing some interesting points from the discussion…

Community and Guilds

On fedi @garbados@herd.bovid.space pinged by Darius posted two of her blog posts…

Blog post: Community Takes Work (a letter to fedi)

Delves into how on Fediverse despite many “community-minded people with big ideas and compassionate ideals” the techno-anarchist approach and their fear for any concentration of power hamper the establishment of real meaningful community cuture. That their drive for decentralization hinders cohesive organizing. One astute observation:

“I find anarchists always on the front lines of mutual aid and direct action, but lacking institutions that can guard movements and their momentum from co-option. The material bonds that emerge tend to be ad-hoc rather than systemic, and are not always reliable. Affinity groups struggle to address their blindspots or falter at the first sign of internal conflict, while volunteers burn out and their efforts go underfunded.”

For a long time I’ve been advocating that on Fediverse we need better ways to express Community. That the abstraction of Community as supported at technology level should be a closer match to how we live in countless communities in daily life. And support how these are connected together by intricate social relationships. I call it “Community has no Boundary” as there should be more seamless crossing of IRL and online space, and also a ‘fabric’ of relationships that allow us to overcome the eternal fragmentation of efforts that makes us weak.

Aldo de Moor, a researcher of Community, put it to me ike this: “I am mainly interested in th ‘Space Between Communities’ right now”.

I will transfer and summarize my thoughts on Community wrt the Fediverse to this forum (from many dispersed places) in a separate topic, but the topic has relevance to any Union / Guild organization, and doing that with amindset and culture that fits our ecosystem.

Let’s summarize that I think a sociotechnical solution is needed: Some supportive tech, making Community a native concept of the Fediverse, to enable the rich social relationships that enable stronger forms of organization and social bonds.

Blog post: Structural Advantages for Software Developers to Leverage and Destroy

The article deals on how the improvements we managed to make by the Free and Open works we create, are still co-opted by hypercapitalist forces we are unable to avoid. That more is needed to withstand them. And here the concept of a Software Guild is introduced. Guilds existed since medieval times. Some survive until the present day, though harmed by the same detrimental forces.

The article speaks how the same advantages of FOSS lead to its weaknesses, that allow it to be exploited. Mentioned is the fragmentation whereby we are “plagued by reinvention [and] we struggle to distribute our knowledge”. Overcoming the weaknesses involves “Organizing the Craft in Software Guilds”:

“Today we approach our obligations to the craft in pieces, on occasion and in ad-hoc manners. […] Only by synthesizing these duties can we shoulder the whole of the burden. […] to manifest a higher standard for our works and our communities we must take on obligations bigger than ourselves.”

The article then lists a number of aspects to address. And these should relate to the best-practice of the Ecosystem Alliance, and I will summarize there and cross-reference.

A very interesting observation was made on Guilds and their growth:

" A guild scales by splintering. Maintain a tight scope and branch efforts as needed in order to maximize your bus factor. Together splinters become a federation, and with enough application arbitrary opinions become living standards. Remember that the craft is bigger than code: involve project managers, accountants, and even lawyers, and pay them as you are paid. As the IWW argues, it defeats us to factionalize workers. Rather, we must take collective responsibility for our works, even within the nuance of specialized scopes like ours. Together, we are strong!"

This comes really close to why we started the Social Coding Movement, and I feel this a very well-made and important point.

Unions versus Guilds

In response to another post by @garbados I mentioned that “Guilds” as terminology appeal to me more than “Unions”.

I feel that “Guild” is a better word. First of all because its less loaded than “Union” and doesn’t raise preconceived notions on what it is about. It is a concept that can be molded better to the principles we want to highlight.

It also sounds friendlier, which in itself better fits FOSS culture. It highlights the ‘craft and arts’.

Darius’ “Let’s play and win our own game!”. Guild fits better. Why position as underdog with Union? FOSS is our own. Independent!

If we’d use Guild for this concept it would still mean that “Unionize Free Software” be one of its major tasks and/or objectives. So “unionization” is still used in the language, just not as prominently to when having “Union” be the umbrella term for the organization structure.

Two more examples where the terminology of Guilds is used:

@CSDUMMI wonder about your feedback on the concept of ‘Guilds’ instead of ‘Unions’? Proposal to rename this topic to “Free Software Guilds: Unionize Free Software”…

This thread has become too large and detailed for anyone to act on it.

Social Coding’s aim is a sustainable, mutually beneficial community for and of software developers, practicioners and dependents.

To ensure this aim this forum is insufficient. It requires action and the structure to enable this action.

I propose that this structure should be the FOSS guilds. Guild’s should have a set list of members, though only for making voting practical.

The guild members’ democratic decisions must be the basis for all actions taken by and on behalf of the guild.

Guild’s allow for the organization of labour (developing standards, that are actually followed, teaching principles and technology to improve members), the organization against exploitation (oppossing the abuse of projects, ethically and legally, promoting free software to capital and enterprise, not just as a ressource but as a community and developing projects and invention beyond the limits and necessities of profit that too often limit the ideas implemented in software development.) and thez benefit society by providing an alternative entry and forum for software development to capital controlled Big Tech and capital coopted open source software.

1 Like

@CSDUMMI I love where you are taking this. Some very relevant discussion topics to hook into…

Maturing tools

This thread has become too large and detailed for anyone to act on it.

I get what you mean, yet you should see #ideation-hub:ideas topics in the proper light. These ideas are about:

  1. Brainstorming where anything goes, non-critical
  2. Collecting thoughts from multiple people over prolonged periods of time
  3. So that ideas can ripen and mature
  4. Until there are people who commit themselves and dedicate to creating a Project

Reminder of the video “Where good ideas come from” that mentions the “slow hunch” that lead to the best ideas.

We came up with the idea for IdeationHub seeing how with just Microblogging, Mastodon et al, ideas are continuously mentioned and then lost again in the timelinez. They pop up again and again with different people interested in them, and then you can’t find that previous thread and ping the people participating at the time.

To ensure this aim this forum is insufficient. It requires action and the structure to enable this action.

Yes and no. Until we have better tools we must make do with what we have. And make the best use of it. The Social Coding Movement itself must be subject to continual improvement to make us more sufficient over time.

In terms of tools we currently have to work with what we have, but must ensure things can mature. This goes in phases e.g. like:

  1. Just-a-forum: There’s a forum and anyone can post about anywhere, talk about anything. Nice, but very inefficient. Nowhere near objectives of our movement.
  2. Forum plus process: The forum has a well thought-out structure and procedures for how to post on it. We “bend” the tools to our needs, until we have better tools to replace them.
  3. Engaging community: A forum with just staff members dilligently facilitating is insufficient, and doomed to fail. It is too labour intensive, and makes other members passive participants. Community must be formed where tasks are delegated and shared among more people.
  4. Community and ecosystem: Social Coding Movement is an umbrella organization. We need projects and affiliated communities, with people dedicated and committed to them, who also feel they are part of that movement. Their work is adjacent to SC objectives and they’ll help provide better tools.

We are now in Step 2) where we have a forum that already has a structure and basic ideas for procedures to follow. But these aren’t well-known yet, and underdocumented.

Proposal

Hurray :tada: I embrace that proposal. Now I encourage to see it in the light of what I’ve just written above…

  • Are you committing to the proposal, willing to flesh it out, make it actionable? → 3) Engaging community

  • Then use our existing tools and process to elaborate the proposal. → 2) Forum and process

  • Refine tool use and procedures along the way. → Continual improvement

I am fully with you to help and think about how to best do these things.

“The Slow Hunch”

Now I want to come back to your first sentence:

This thread has become too large and detailed for anyone to act on it.

This forum topic was posted in April 2022. At the time the idea dealt with “Unions”. We have brainstormed, determined that “Guilds” are a very interesting improvement.

But in parallel elsewhere in our movement there have been other developments too. And now they can be combined. A “slow hunch” leads to the best ideas :smiley:

So - after side-stepping into organization topics, kinda OT to this topic - let’s continue our brainstorm… what are these other developments, I hear you ask?

  • Ecosystem alliances: A proposed #documentation:practices to organize around a common cause.

  • FSDL: The Free Software Development Lifecycle as the central theme, the backbone of the movement against which we can build it up. And Ecosystem Alliances are building blocks of the FSDL.

  • Co-shared community: An invitation for independent projects and communities to join the movement, come under Social Coding umbrella and benefit from shared services and synergy created.

  • LOCI: Organizing local chapters and bring citizens, local residents in contact with fedizens, organize all kinds of collective activities. It is ideal for combining with the notion of “Guilds”.

  • Forgers Ecosystem Alliance: Preparatory notes to establish a strategic alliance for the evolution of forge federation that takes the full FSDL into account. Multiple people and parties are interested.

  • “Forging software” branding & marketing: A new idea forming on how to position FSDL, Social Coding Movement and Forge Federation initiatives in a way that’ll be able to compete with Big Tech.

All these thoughts and ideas are highly related. They are “hunches” that can be forged (pun intended) together, welded into a Great Idea™ :stuck_out_tongue_winking_eye:

How?


:boom: The Forgers Guild :hammer_and_pick:


By combining them…

  • Guilds are (or can be) Ecosystem Alliances.
  • Guilds dedicate to forging Free Software.
  • Guilds bring craftsmanship and specialties.
  • Guilds can be generic or focus on particular areas of interest.
  • Guilds are at the ‘heart of town’, stand in the midst of society.
  • Guilds are open and accessible to anyone.
  • Guilds teach their craft, help people, and receive help in return.
  • Guilds cooperate with other guilds, be stronger together.
  • … (etcetera)

This thread and the slow hunch has inspired me to update the ideas for a forge federation alliance, and I will take that further and commit to spreading the idea, asking input and feedback as well as collaborators to make it real. In other words:

I will commit to advocacy for The Forgers Guild to be founded.

(Yes, that domain of forg.es isn’t yet available. But it is registered by @realaravinth with whom I wanna collab in setting up the alliance)

As for your proposal and the elaboration of it, that means there’ll a concrete case to work with. “The First Guild”, if you will (might be… just an idea). And other people likely interested to help with the elaboration.


"Building Construction" emoji from emojipedia.com

2 Likes

I’m quiet but supportive. Count me in !

2 Likes

I am committed to guilds.

I want to set up the first guild quickly. It only needs two steps:

  1. a member list
  2. a means to make democratic decisions

A first goal of the first guild should be the organization of labour by giving education, support and addressing the problems of the members.

I’d organize this first guild using a Codeberg Repo under the SocialCoding or Coders org. The repository contains these files:

  • Members
  • Decisions
  • Constitution

The members text file contains a list of all members.
Decisions is a folder of decisions as text files.
And constitution is a text file containing the fundamental rules of the guild.

Issues

Issues in this repo serve as the ground for discussions on the guild and guild activity.

Pull Requests

Pull Requests are proposed decisions, membership changes or vhanges to the constitution.

Pull request must be voted on prior to being accepted, if they affect decisions or the constitution. If a member is removed, this must also be voted on.

New members do not need to be voted in.

I’m unsure on how voting should take place. It could happen by way of reactions, comments or through a third-party app integrating into the Gitea API. The latter would be the long-term optimum and at first the use of reactions (thumps up, thumps down).

This structure is easy to understand and implement (especially for developers familiar with forges) and thus quite universal. Setting up another second guild is also made very easy with this model.

1 Like

A question for @aschrijver is the forg.es guild going to be that first guild?

Short answer: That is not up to me to decide. There’ll be kick-off event where we’ll gauge interest, scope and participants.

Forgers Guild has a big scope and vision, and longer trajectory to get it off the ground. Guilds do not necessarily encompass whole Ecosystem Alliances. They can also be any small group of people in any context. So, if you have plans to organize a particular Guild yourself, that may be the first one then :slight_smile:

I just created this repository to try it out:

1 Like

I added the first PR and structure laid out above. I hope this can both serve to create the first guild and be a pattern for future guilds to follow and adapt.