Editing Community Organizing (section)

== Transitioning from Cathedral to Bazaar ==

The reader should be familiar with “The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary” by Eric S. Raymond.

The transition from a Cathedral to Bazaar is a critical milestone that can determine the long-term success and sustainability of open source projects. While projects can remain successful in the Cathedral phase with a small core team, transitioning to a Bazaar model with a larger community offers significant advantages - from incorporating diverse user feedback to ensuring project sustainability beyond reliance on individual contributors.

Successful open source projects typically start in a Cathedral phase with closed development by a small group, but must actively work to transition to a Bazaar phase to achieve broader adoption and community growth. This transition requires specific actions from core contributors and careful timing. The prototype needs to be functional enough to attract volunteers while still having clear opportunities for meaningful contributions.

Several critical factors enable a successful Cathedral-to-Bazaar transition:

* Core contributors must actively create new directions and modularize their projects that give new contributors clear avenues for participation. Studies show new contributors strongly prefer to work on adding new features and modules that are limited in scope (and therefore easy to understand and contribute to). Large projects are often inpenetrable and represent a barrier for Newcomers.
* The project must reach an appropriate maturity level - functional enough to be useful but with sufficient room for improvement. Projects that are too basic or too complete struggle to attract contributors.
* Core contributors need to implement proper onboarding processes and actively foster community participation through documentation, mentoring, and engagement.
* The project should maintain openness to external contributions while ensuring quality through proper review processes. Too much restriction can inhibit growth while too little can harm quality.
* Core contributors must be willing to transition from direct development to community management roles, focusing on reviewing contributions and guiding project direction.

Projects that fail to make this transition often remain limited in scope and face sustainability risks from relying on a small contributor base. In contrast, projects that successfully transition to a Bazaar phase show sustained growth in both contributor base and project scope over time. The empirical evidence demonstrates that actively pursuing and properly managing this transition is vital for projects aiming to build thriving, sustainable communities.

<span id="types-of-contributors"></span>
=== Types of Contributors ===

Participation in online communities tends to manifest as a long-tail distribution; a tiny, active minority produces most of the content while the majority of community members produces very little individually. For example, the most active 0.1% of contributors produce nearly half of Wikipedia’s value, and the English Wikipedia’s consumers outnumber producers by 10,000 to 1.

* '''Peripheral''' contributors, aka “lurkers” are often Users and predominantly consume the community projects, they may contribute only once or irregularly and have shorter-term involvement. While they make up the majority of contributors, they account for a smaller portion of total community activity.
* '''Newcomers''' are contributors who have recently joined the ecosystem and are still learning the community norms, practices and codebase. They often start with smaller contributions as they build up experience. Proper onboarding and mentoring of Newcomers is critical for ecosystem sustainability.
* '''Core contributors''' are those with substantial and long-term involvement in the ecosystem. They make frequent contributions, work across multiple projects, and are responsible for the majority of community effort. Core contributors typically have both high intensity (many commits to important projects) and spread (contributions across many projects).
* '''Mentors''' are experienced contributors (often core contributors) who help guide and support Newcomers. They play a vital role in knowledge transfer, maintaining community practices, and helping new developers become productive contributors. Good mentorship increases contributor retention and helps grow the community.

<span id="institutional-arrangement"></span>
=== Institutional Arrangement ===

There are seven key institutional arrangements that shape open source projects:

# Project governance and decision-making processes
# Community sponsorship and support structures
# License terms and restrictions
# Systems for recognizing and rewarding contributions
# Development infrastructure and tooling
# Technical architecture and codebase organization
# Social dynamics and technical practices specific to the community

It’s important to note that institutional priorities can sometimes work against the core values and motivations that drive individual contributors. This typically happens when institutions focus too narrowly on external metrics and rewards (like maximizing commercial gains) while neglecting the intrinsic motivations that sustain long-term participation (such as technical excellence, craftsmanship, and the joy of creating something valuable). When institutional goals and contributor motivations become misaligned in this way, it can lead to disengagement and demoralization within the community.

It is important for those in the management of the institution to be aware of this and maintain a healthy balance.

<span id="design-and-implement-community-engagement-and-onboarding-strategies"></span>
=== Design and Implement Community Engagement and Onboarding Strategies ===

Building bridges to other communities is essential for growing the project’s contributor base. While we may start with a small core group, sustainable growth requires actively reaching out to adjacent communities and creating clear pathways for new contributors to get involved.

First, identify communities that have natural overlaps with your project - these could be users of similar tools, developers working in related domains, or groups interested in the problems. Identify where these communities gather, whether that’s social platforms like Mastodon, X.com, Lemmy, Reddit, Farcaster &amp; Nostr. The goal is not to aggressively recruit, but rather to become a genuine participant in these spaces, sharing knowledge and building relationships.

Once you’ve established connections with other communities, create explicit onboarding paths tailored to different types of potential contributors. Document exactly how someone can go from being interested to making their first contribution, whether that’s fixing a bug, improving documentation, or helping with translations. Break down the process into clear, manageable steps - from setting up a development environment to submitting their first pull request. The more specific and welcoming these instructions are, the more likely newcomers are to successfully make the transition from observer to contributor.

Different communities have different norms and expectations. What works for attracting contributors from one community may not work for another. Be prepared to adapt your outreach and onboarding approaches based on the specific community you’re connecting with, while staying true to your project’s own values and standards. The goal is to create bridges that benefit both communities through meaningful collaboration.

Onboarding Strategies MUST have a clear purpose, be as frictionless as possible (see Barriers) and reduce the hacktivation energy and have a clear understanding of how it increases motivations to contribute.

<span id="understanding-motivations-for-contribution"></span>
=== Understanding Motivations for Contribution ===

Enjoyment-based intrinsic motivation, namely how creative a person feels when working on the project, is the strongest and most pervasive driver. The contributor need for intellectual stimulation derived from practicing their craft, and improving skills are top motivators for project participation.

* '''Altruism''' is an intrinsic motivation in which one seeks to increase the welfare of others. It is the personal disposition at the opposite pole from welfare of others. It is the personal disposition at the opposite pole from selfishness—doing.
* '''Community Identification''' is a variant of altruism corresponds to Maslow’s needs for belonging and love. A particpant may identify themselves as members of the community. If successful, this can establish obligation/community based intrinsic motivations.
* '''Future Rewards''' A participant may view participation as an investment from which they will obtain future returns.
* '''Self-Marketing''' Participants may regard working for the projects as an effective way to demonstrate their capabilities and skills. Their achievements in way to demonstrate their capabilities and skills. Their achievements in open-source projects can be used to reinforce their.
* '''Peer Recognition''' Peer recognition derives from the desire for fame and esteem, which is also associated with Future Rewards and Community Identification.
* '''Personal Needs''' As the history of open-source software shows, open-source projects are often initiated because a programmer has a personal need for a certain kind of initiated because a programmer has a personal need for a certain kind of software.
* '''Ideology, Morality &amp; Values''' Related to Community Identification. Ideology, Morality &amp; Values motivates people to act, social movements that confront the establishment of the software industry on ideological grounds. See Moody’s “Rebel Code” (2001). Virtues like honesty, truthfulness, trustworthiness, justice, courage, loyalty, benevolence, should be embedded &amp; exemplified. Self-identification with the ideology, morality &amp; values become the basis for establishing extended kinship ties - ultimately leading to community identification, which in turns acts as a driver to participate in community projects.

For example, the ideology of the free software movement continues to be one of the factors which mobilize people to contribute to free and open source software development.
Read “Character Strengths &amp; Virtue Ethics”

* '''Compensation''' A long-term contributor may receive compensation, this motives cover desires for social rewards such as money, power, authority, good reputation and job stability. A minority of contributors are paid to participate in F/OSS projects, according to “Why Hackers Do What They Do”, 87% of all respondents reported receiving no direct payments from the core foundation, if this is not the case, it represents a failure.

Individuals may join for a variety of reasons, and no one reason tends to dominate the community or cause people to make distinct choices in beliefs. These findings are consistent with collective action research, where group heterogeneity (in motivations) is considered an important trait of successful movements (Marwell and Oliver 1993).

The significant determinants of hours per week dedicated to projects were (in order of magnitude of impact): - enjoyment-related intrinsic motivations in the form of a sense of creativity. - extrinsic motivations in form of payment. - obligation/community-related intrinsic motivations.

The effort expended is substantial. As a performance indicator benchmark, individuals should on average contribute 14 hours per week.

All processes and strategies should clearly define how they contribute to (and increase) motivations.

<span id="build-reputation"></span>

=== Build Reputation ===

Reputation is a critical motivator and success factor in open source communities. Research shows that both social interactions and individual contributions are key determinants of a developer’s reputation.

The reputation system should balance both technical contributions and social interactions, as both are essential for community health. However, reputation disparity within project teams should be managed carefully, as large differences in reputation can potentially limit participation from newer members and negatively impact collaboration.

In F/OSS Communities, the key determinants for reputation are:

'''Coding Quality''' The quality of a developer’s contributions, measured through user ratings and project success, has a significant positive impact on reputation building. High-quality contributions that are well-received by the community help developers inherit positive recognition from their previous work.

'''Consistent Commitment''' Stability and reliability in contribution patterns positively affects reputation. High variability in monthly contributions can negatively impact reputation building. Contributors should aim for sustained, regular participation rather than sporadic bursts of activity.

'''Community Experience''' The length of time actively participating in the community correlates positively with reputation. More months of active contribution helps build stronger reputation scores.

'''Collaboration Experience''' Working with diverse peers across different projects helps build reputation. The number of different collaborators a developer works with has a positive impact on their standing in the community.

Enable recognition of reputation by:

'''Track Quality Metrics'''
* Monitor user ratings of contributions
* Measure project success metrics
* Track consistency of participation

'''Enable Peer Recognition'''
* Allow community members to acknowledge valuable contributions
* Implement visible reputation scores (i.e leaderboard, announcements, social media posts)
* Create mechanisms for peer evaluation

'''Foster Collaboration'''
* Encourage participation across multiple projects
* Create opportunities for peer interaction
* Support mentorship relationships

'''Maintain Transparency'''
* Make reputation metrics visible and understandable
* Provide clear paths for reputation building
* Document contribution impact

<span id="establish-a-gifting-economy"></span>

=== Establish a ‘Gifting’ Economy ===

Gift-giving serves as a fundamental organizing principle in F/OSS communities, creating and maintaining social relationships, power dynamics, and quality standards. Unlike traditional economic exchanges, F/OSS gift economies operate on reputation, recognition, and social status derived from contributions rather than monetary value.

The gift economy in F/OSS creates a self-reinforcing cycle where contribution leads to recognition, which motivates further contribution. This dynamic supports both individual growth and community sustainability while ensuring high-quality output through peer review and shared standards.

'''Why Gift-Giving Works in F/OSS'''

* '''Digital Non-Rivalry''' Code and knowledge can be infinitely shared without diminishing value, enabling a culture of abundance rather than scarcity
* '''Status Through Giving''' Social standing is determined by the value and quantity of contributions rather than accumulation
* '''Quality Assurance''' Peer review of contributions ensures high standards while validating and recognizing donors
* '''Community Building''' Gift-giving creates bonds of reciprocity and obligation that strengthen community ties
* '''Power Dynamics''' Core contributors and maintainers gain legitimate authority through consistent valuable contributions

A gifting economy can be implemented

'''Recognition Systems'''
* Implement visible contribution metrics and badges
* Maintain public acknowledgment of valuable contributions
* Create contributor spotlights and success stories
* Design reputation systems that reflect community values

'''Social Validation'''
* Foster constructive peer review processes
* Encourage mentorship as a form of gift-giving
* Celebrate knowledge sharing and documentation
* Create spaces for public recognition

'''Community Norms'''
* Establish clear contribution guidelines
* Model generous behavior from leadership
* Value both code and non-code contributions
* Promote teaching and learning as gifts

'''Power Distribution'''
* Create paths for contributors to gain authority
* Distribute decision-making rights based on contribution history
* Balance gatekeeping with openness
* Recognize diverse forms of contribution

<span id="barriers-that-reduce-hacktivation-energy"></span>