Building Community
The free and open software community is the culmination of the free software movement, the open source movement and numerous other independent developers who support software freedom. The GNU and Linux projects are the most extensive examples of free and open-source collaboration.
 |
 |
Through the collaborative creation of open software modules that fulfill precisely defined roles and tasks, Linux can be pieced together in many ways. This creates an expansive ecosystem where you are free to use the software that you choose. These large-scale experiments were not only technical, but social: how do you revolutionize the communication systems that go into decentralizing development?
Eric S. Raymond – a founder of the open-source movement – attributes Linux's success not to any particular technical innovation, but it's cooperative social systems and distributed power structure. Linux wasn't painstakingly handcrafted by a small group of privileged developers like other operating systems of the early digital age.
Linux evolved in a completely different way. From nearly the beginning, it was rather casually hacked on by huge numbers of volunteers coordinating only through the Internet. Quality was maintained not by rigid standards or autocracy but by the naively simple strategy of releasing every week and getting feedback from hundreds of users within days, creating a sort of rapid Darwinian selection on the mutations introduced by developers.
Melvin Conway – an early computer scientist and hacker – expressed a formative principle that is still relevant today: the structure of software will mirror the structure of the collective that built it. By embracing a new development model that relied on volunteers from around the world, a radical new form of asynchronous communication was necessary.
Open Collaboration
The Internet's capacity to build digital connections between two computers – and the people who used them – fundamentally changed the ways we can collaborate as Humans. We now had the power to communicate with little delay across vast distances and decisions could be made in near real-time.
This enabled people to work together directly, forming communities around mutual interests and shared goals. For the mutual benefit of the digital commons, communities produced valuable shared resources through processes that weren't primarily focused on generating profit.
 |
Particularly notable examples include Wikipedia, open-source software and open hardware. These communities and the projects that coalesce from within them are not owned by any one party. Each project has its own philosophy about their approach to design and development.
The Cathedral and the Bazaar, a living document by Eric S. Raymond, details his observations from within the early teams creating the Linux ecosystem. He examines the tension between bottom-up and top-down approaches to design within software. He likens these styles to the ways that knowledge arises within a cathedral versus the bazaar.
Essay Excerpt
But I also believed there was a certain critical complexity above which a more centralized, a priori approach was required. I believed that the most important software (operating systems and really large tools like the Emacs programming editor) needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time.
Linus Torvalds’s style of development—release early and often, delegate everything you can, be open to the point of promiscuity—came as a surprise. No quiet, reverent cathedral-building here—rather, the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches ... out of which a coherent and stable system could seemingly emerge only by a succession of miracles.
– The Cathedral and The Bazaar
|
Church |
The Cathedral These open-source projects release their source code once it has been finalized, but it is not available to the general public while in active development. This restricts who has the privilege to make changes to the underlying source code to an exclusive group.
The GNU project often uses this philosophy.
|
| Storefront |
The Bazaar These open-source projects make their source code completely available on the Internet throughout the entire development process. Everyone has access to the source code, but making modifications to it requires oversight by the project.
The Linux kernel uses this philosophy. |
A Linux distribution is primarily powered by its community – which can take many different forms. Debian is a well-known example supported by the public on a volunteer basis by global developers. Some distributions like Fedora are community-maintained operating systems that were split off from corporate-focused Linux builds.
While Linux is generally free-of-charge, technology companies contribute to the continued development of the ecosystem. An estimated 85% of the modern Linux kernel was written by developers who were paid for their work.
There is an array of digital communities that support Linux users and developers, each with a specific purpose or mission. Linux Questions and Stack Exchange are online discussion forums that can provide general Linux support. Many open-source projects have their own forum as well as IRC chatrooms, mailing list and newsgroup.
Decentralized Community
Rather than concentrating power within a single location or team, decentralization distributes tasks and decision-making across multiple contributing members. This is a flexible and efficient option for collaborating, but requires constant communication and robust planning if it's going to succeed.
The concept of version control is heavily leveraged by open-source software projects. This has led to powerful tools that can keep track of changes in the source code made by hundreds of potential contributors. This creates a central repository for critical project files with strict processes in place for modifying them.
Git is a program originally created by Linus Torvalds in 2005 as version control for the Linux kernel. It is now the official standard over 90% of developers consider it to be their primary tool for the job. In essence, Git downloads an exact replica of the central repository to your computer.
With the source code on your hard drive, you can compile the program for yourself from scratch. As a developer, you can make alterations and upload them back to the central server. This helps ensure that a developer can work on one section of the program without getting in anyone else's way – while also leaving a trail of the changes.
 |
 |
While Git is primarily a command-line utility, there are many online repositories that work with Git – but the most popular is by far GitHub. Owned by Microsoft, it is the largest online repository of open source-code with millions of developers and projects. GitLab is an open-source and decentralized alternative that can be self-hosted.
In addition to acting as a shared Git repository, these platforms provide community development tools. This includes bug tracking, feature requests, task management, a forum and a wiki for documentation. Developers can configure "continuous integration and continuous delivery" where pre-programmed tests are performed on source code before it is automatically compiled.
When using a public software repository platform, there are roles that get fulfilled within each project. While there can only be one formal owner of the project, they are free to create granular permissions for who can edit what. Most projects hosted on a public source code repository maintain these general conventions when it comes to collaboration.
|
Domino_mask |
Anonymous Unless a software project has been intentionally marked as private, the source code is freely available for download by anyone who accesses the repository even if they haven't logged in. |
|
person |
User This is any person who has an account on the platform with a verified email. Each project can configure how unaffiliated users are allowed to interact with the source code. Open-source software debelopers often value diverse perspectives from every day users and explicitly request feedback. |
|
deployed_code_account |
Collaborator This is any person that a software project has explicitly chosen to give affiliation status. This can offer fine tuned control to specific developers and provide blanket access to all collaborators. In the case of a private project, this can be used to offer exclusive access to source code. |
| Person_edit |
Contributor Once a verified user has submitted a change and it's accepted, they are considered a contributor within that project. Before proposing changes, each user must follow the rules and integrate themselves into the community. These contributions are not limited to source code, but also include stewardship responsibilities – such as bug reports, feature requests and documentation writing. |
| how_to_reg |
Trusted Member This role can vary widely between projects and is often defined more by their responsibilities than their privileges. While an average contributor can suggest changes, these project members are often the ones in charge of actuating them. These tasks often have a greater degree of risk involved and require earning the respect of the community. |
| engineering |
Maintainer This entity has the significant responsibility of overseeing the project and it's community. While there can only be one primary maintainer, this can represent a collective or organization. They perform technical tasks as well as maintain the project's direction.
|
Project members work together to complete work within the main repository containing all the project's source files. This software development process is likened to a tree – with the collective source code called the main trunk.
As existing bugs or new features are explored, new branches in the tree can be split from the source code – essentially creating two isolated versions of the same software. This is often done when developing new versions of a program to make it easier to keep track of differences over time.
|
call_split |
This is an isolated copy of the source code that makes it easier for developers to collaborate on changes without risking damage to the trunk. These help to keep track of what was changed, by who, and for what reason. These exist within a project to facilitate collaboration and coordinate development.
|
| call_merge |
Once changes within a branch are finalized and tested to ensure stability, then can be merged back into the main trunk. This allows all software development loose ends to be addressed before creating a final release of the software trunk. |
| Flowchart |
This is a completely new repository – under new ownership – that is a complete replica of another existing repository. This can happen for a variety of reasons ranging from personal modifications to differing decisions among the development team. Repository forks allow anyone to modify software to their needs and propose changes back to a project they are not a developer on. |
Developers can commit changes to files within each branch to test put features and make sure everything works as expected. Large software projects – like an operating system – can go many branches deep to explore specific topics.
The community can discuss development at many granular levels. When changes are complete, these branches can be consolidated and merged back into the main trunk. This can include resolving any conflicting changes in the source code. When changes are finalized, the software can be released for general production usage.
|
Commit |
This is a formal change to source code files on your local repository that are given a unique identification number and maintain a narrative about the history. This builds a foundation of accountability by tracking who made what changes to files when. Traditionally, these contain a message from the developer about their changes and the reasoning behind it. |
| cloud_upload |
Once you have finalized your commit, the changes can be pushed upstream to the central repository so they can be accessed by everyone.
|
| Cloud_download |
When first acquiring the source files from a project's repository, Git on your computer will pull the code from the repository. This allows you to modify the files and compile the program yourself from scratch.
As a part of the project, you can often commit and push the files directly back to the repository. When you are not affiliated with the project, you can create your own fork and communicate with the parent project about your proposed changes. From there, they can perform a pull request to merge the new code created by your personal fork.
|
This enables every developer to quickly create their own environment to experiment with code, compile the program and test for any bugs. By providing redundant layers of communication, a diverse collective of developers can keep in communication about emerging changes to the software.
Documentation
Git is a fantastic tool for facilitating collaboration among a diverse development team on complex coding problems. However, it doesn't do much to help out someone looking to use the software for the first time – or a developer looking to get involved.
What we can independently learn about an open-source project greatly informs our ability to use it. In the long term, it affects our ability to become a part of the community surrounding it. While Git manages how the software is created, documentation ventures to cover just about everything else – like what it does, how it works and why you would use it.
Software documentation, as the name implies, relates specifically to software projects. These are foundational resources that enumerate, extrapolate, explain and educate about each part, procedure or platform that keep it functional – like it's assembly, installation, setup, use and maintenance. Since it's coverage is expansive, documentation is often split into self-contained – but intertwined – parts.
|
Support |
User Documentation While intended for a general audience, this resource can explore the software from multiple distinct perspectives – such as users, systems administrator and support staff.
This describes the features of a program and explores how users can fully leverage them. Consider it the contract detailing what the software does. Documentation can fulfill using guides, tutorials, troubleshooting and frequently asked questions.
While they are not inherently designed in a specific way, the overall goal to create a resource that is intuitive and accessible – clearing more confusion than it creates. Most incorporate an index for exploring defined concepts or sections. |
|
Engineering |
Technical Documentation Intended primarily for developers, this resource helps to grasp how the programs works internally. This covers the logic behind algorithms, explains how to leverage their API, and details emergent software systems that power the program. Technical documentation may be available on its own wiki or integrated directly into the source code.
|
| Volunteer_activism |
Contribution Guidelines Open-source software projects often come with information about how you can help contribute to the project. This generally explores the process and guidelines for becoming a contributor, such as how to submit bug reports and feature requests as well as rules and etiquette for communication.
|
Documentation is an essential resource for fully leveraging software. When well-executed, it lowers the barrier to entry and offers entrance into a more connected community. Comprehensive coverage can improve the overall experience with a safety net for troubleshooting problems and finding answers. When possible, it is details how we can give back to the free and open-source community.
IdentityCollectives and CommunityIdentity
The free and open-source movements are a massive experiment in decentralizing the creation of software among a diverse collective of unique perspectives. This offers a potential glimpse for communities to form radical new ideas that upend the status quo.
There is a conversation in the room that only this people at this moment can have. Find it.
On paper, this may appear as the utopian egalitarian ideal capable of giving both equal voice and access throughout the development process. We bring our entire selves to these creation-oriented ecosystems and that can bring as much synergy as friction.
Indeed, many people get involved with free and open-source software seeking to contribute back to the community. However, prejudice – already an existential problem within computing – have only further distilled within these communities.
We must work towards equitable and accessible systems that value our perspectives yet hold us accountable for biases. This may require radical new ideas and implementations, but we can still learn the value of our voice within the crowd.
Who Contributes?
The Debian Project has an influx of applicants wishing to become developers.[205] These applicants must undergo a vetting process which establishes their identity, motivation, understanding of the project's principles, and technical competence.[206] This process has become much harder throughout the years.[207]
Debian developers join the project for many reasons. Some that have been cited include:
- Debian is their main operating system and they want to promote Debian[208]
- To improve the support for their favorite technology[209]
- They are involved with a Debian derivative[210]
- A desire to contribute back to the free-software community[211]
- To make their Debian maintenance work easier[212]
Debian developers may resign their positions at any time or, when deemed necessary, they can be expelled.[29] Those who follow the retiring protocol are granted the "emeritus" status and they may regain their membership through a shortened new member process.[213]
Debian has made efforts to diversify and have members represented from the community. Debian Women in 2004 was established with the aim of having more women involved in development. Debian also partnered with Outreachy, which offers internships to individuals with underrepresented identities in technology.[214][215]
Here are the 10 most common that we’ve come across:
- Altruism (e.g. doing pro bono work to make the world a better place)
- Gaining skills/experience (e.g. developing competencies that will help their career)
- Giving back to the community (e.g. adding a feature or performing a code review because they use the software every day and want to help out)
- Paid work (e.g. they’re employed to design the UI for an Open Source project)
- Participating in competitions (e.g. Hack days)
- Political/social motivations (e.g. feeling empowered by moving forward a particular agenda)
- Reputation and recognition (e.g. building a rounded GitHub portfolio in preparation for applying for jobs)
- Scratching an itch (e.g. fixing a bug that’s been irritating them)
- Side projects (e.g. they have a boring day job and want to feel more fulfilled)
- Working with others (e.g. collaborating with people outside of their geographic area or sector)
Many of these are linked. For example, reputation and recognition goes together with side projects, as do working with others and giving back to the community. Open source contributors have overlapping motivations for their contributions, and these may change over time.
Diverse Perspectives
https://en.m.wikipedia.org/wiki/Diversity_in_open-source_software
The "very seductive" moral and ethical rhetoric of Richard Stallman and the Free Software Foundation fails (Raymond), he said, "not because his principles are wrong, but because that kind of language ... simply does not persuade anybody".[24]
Researchers and journalists have found a higher gender disparity and lower racial and ethnic diversity in the open-source-software movement than in the field of computing overall, though a higher proportion of sexual minorities and transgender people than in the general United States population. Despite growing an increasingly diverse user base since its emergence in the 1990s, the field of open-source software development has remained homogeneous, with young men constituting the vast majority of developers.
Since its inception in the 1990s, as open-source software has continued to grow and offer new solutions to everyday problems, an increasingly diverse user base began to emerge. In contrast, the community of developers has remained homogeneous, dominated by young men.[3]
In 2017, GitHub conducted a survey named the Open Source Survey, collecting responses from 5,500 GitHub users. Among the respondents, 18% personally experienced a negative interaction while working on open-source projects, but 50% of them have witnessed such interactions between other people. Dismissive responses, conflict, and unwelcoming language were respectively the third, fourth, and sixth most cited problems encountered in open-source.[4]
Another study from 2017 examined 3 million pull requests from 334,578 GitHub users, identifying 312,909 of them as men and 21,510 as women from the mandatory gender field in the public Google+ profiles tied to the same email addresses as these users were using on GitHub. The authors of the study found code written by women to be accepted more often (78.6%) than code written by men (74.6%). However, among developers who were not insiders of the project, women's code acceptance rates were found to drop by 12.0% if gender was immediately identifiable by GitHub username or profile picture, with only a smaller 3.8% drop observed for men under the same conditions. Comparing their results to a meta-analysis of employment sex discrimination conducted in 2000, the authors observed that they have uncovered only a quarter of the effect found in typical studies of gender bias. The study concludes that gender bias, survivorship and self-selection bias, and women being held to higher performance standards are among plausible explanations of the results.[5]
The gender ratio in open source is even greater than the field-wide gender disparity in computing. This was found by a number of surveys:
- A 2002 survey of 2,784 open-source-software developers found that 1.1% of them were women.[7]
- A 2013 survey of 2,183 open-source contributors found that 81.4% were men and 10.4% were women.[8] The survey included both software contributors and non-software contributors and found that women were much more likely to be non-software contributors.[9]
- In the GitHub's 2017 Open Source Survey 95% respondents identified as men and only 3% as women,[4] while in the same year about 22.6% of professional computer programmers in the United States were female according to the United States Bureau of Labor Statistics.[10][11]
In an 2013 article for the NPR, journalist Gene Demby considered Black people and Latinos to be underrepresented in the open source software development.[12]
- In the GitHub's 2017 Open Source Survey the representation of immigrants, from and to anywhere in the world, was 26%.[4]
- In the same survey, 16% of respondents identified as members of ethnic or national minorities in the country where they currently live,[4] while according to the United States Bureau of Labor Statistics, Black, Asian, and Latino people accounted for a total of about 34% of programmers in the United States in 2017.[10][11]
Among the respondents of GitHub's 2017 Open Source Survey 1% identified as transgender, 1% as non-binary, and 7% as lesbian, gay, bisexual, asexual, or another minority sexual orientation,[4] while according to a Gallup poll in conducted in the same year 4.1% of the United States population identify as LGBT.[13][11] A 2018 survey of software developers conducted by Stack Overflow found that out of their sample of 100,000, 6.7% in total identified as one of "Bisexual or Queer" (4.3%), "Gay or Lesbian" (2.4%), and "Asexual" (1.9%), while 0.9% identified as "non-binary, genderqueer, or gender non-conforming".[14]
Large personalities in open source and complicated views
Eric s Raymond
Linus torvalds
The "very seductive" moral and ethical rhetoric of Richard Stallman and the Free Software Foundation fails (Raymond), he said, "not because his principles are wrong, but because that kind of language ... simply does not persuade anybody".[24]
The Value of Your Perspective
Why are there fewer people represented who aren't white men
There are a few possibilities to consider when thinking about an answer to this question:
1. Maybe there isn’t a strong correlation between programming talent and GitHub activity.
Both agreed that while being active on GitHub is typically a good indicator of engineering expertise, the reverse isn’t true, mentioning that they know plenty of great engineers who aren’t involved in open source at all. The tech industry agrees too, with many companies assessing GitHub profiles during hiring processes (although this practice seems to be quite biased, which isn’t really a surprise given the results of my study).
Anna-Chiara commented that it takes a great deal of confidence to contribute to open source, something that she thought may be more difficult for female developers to overcome, given the tech industry’s poor history with welcoming women.
There are certainly several biases that could potentially be at play with this GitHub data (including the fact that almost 25% of the names couldn’t be classified as male/female with confidence).
3. Female programmers are leaving the tech industry.
If activity on GitHub correlates with seniority and expertise, then the extremely low number of active female contributors (low even compared to female contributors overall) could be explained by the alarmingly high departure rate of female engineers from the tech industry.
If the tech industry can’t retain as many women past their mid-career mark, then it’s likely that they won’t be contributing to many open source projects either.
https://www.toptal.com/open-source/is-open-source-open-to-women
https://biancatrink.github.io/files/papers/TOSEM2021.pdf
https://thenewstack.io/why-women-are-underrepresented-in-open-source/
The current inclusion of the historically disadvantaged might help wash some consciences without changing anything from the root. However, what is needed is a mental and structural paradigm shift. From there, it will be possible to build a more horizontal structure where decisions are made more inclusively and democratically.
https://www.computer.org/csdl/magazine/co/2022/12/09963732/1Iz0RZM9Wbm
Different aspects of diversity
Open source projects benefit from various types of diversity:
| Aspect | Description |
|---|---|
| Cultural | People from different backgrounds bring new ideas |
| Racial and ethnic | Helps make software that works for everyone |
| Gender | Mix of men and women improves understanding of user needs |
| Age | Different age groups add varied experience levels |
| Disability | Includes people with disabilities to make software accessible |
| Socioeconomic | Ensures software is useful for people from all backgrounds |
How Can I Contribute?
How to contribute to open source software projects
Financial Support
Donations
Sponsorship
Non profit funds
Open Collective is a crowdfunding platform focused on grassroots groups. It enables organizations, communities, and projects to get a legal status and raise funding through subscription or one time payment. It's particularly favoured by open source projects.[1] It currently hosts funding for thousands of open-source communities.[2]
https://www.spi-inc.org/donations/
https://en.m.wikipedia.org/wiki/Software_in_the_Public_Interest
Software in the Public Interest, Inc. (SPI) is a US 501(c)(3) non-profit organization domiciled in New York State formed to help other organizations create and distribute free open-source software and open-source hardware. Anyone is eligible to apply for membership, and contributing membership is available to those who participate in the free software community.
https://www.pledge.to/women-in-linux-4579
Community Support
Documentation
Feedback
Finding forums, chat apps, websites
Forums and mailing lists
Polls and feedback
Emergent strategy
Irc chatroom
I offer, from this defensive and sacred place, a protocol for those who are most comfortable approaching movements from a place of critique, AKA, haters.
1. Ask if this (movement, formation, message) is meant for you, if this serves you.
2. If yes, get involved! Get into an experiment or two, feel how messy it is to unlearn supremacy and repurpose your life for liberation. Critique as a participant who is shaping the work. Be willing to do whatever task is required of you, whatever you are capable of, feed people, spread the word, write pieces, make art, listen, take action, etc. Be able to say: ‘“T invest my energy in what I want to see grow. I belong to efforts I deeply believe in and help shape those.”
3. Ifno, divest your energy and attention. Pointing out the flaws of something still requires pointing at it, drawing attention to it, and ultimately growing it. Over the years I have found that when a group isn’t serving the people, it doesn’t actually last that long, and it rarely needs a big takedown—things just sunset, disappear, fade away, absorb into formations that are more effective. If it helps you feel better, look in the mirror and declare: “There are so many formations I am not a part of—my non-participation is all I need to say. When I do offer critique, itis froma space of relationship, partnership, and advancing a solution.”
4. And finally, 1f you don’t want to invest growth energy in anything, just be quiet. If you are not going to help birth or raise the child, then shhhhh. You aren’t required to have or even work towards the solution, but if you know a change is needed and your first instinct when you see people trying to figure out how to change and transform is to poop on them, perhaps it is time you just hush your mouth.
Development Support
Feature requests
Pull requests
Contributions