A lot of non-coding work is done by people who would rather just be coding.
As previously noted, the typical path into FOSS infrastructure projects is by contributing code. However, a lot of work is done that is not directly connected to coding: project management, financial administration, design, community management, event organization, communication and coordination with other projects and companies, representation at events and public speaking. This other work is seen variously as a burden, an annoyance, an unwelcome surprise, and a side hobby.
- These non-coding tasks are taken on by developers involved in the project. They recognize they are neither qualified for this work, nor are they especially interested in doing it. Despite being a source of frustration that keeps them from doing what they enjoy, they do not easily delegate this work to others – one reason being that there are few people inside the community with the necessary skills.
- In spite of frequent complaints about this work, where dedicated roles exist, they are not much valued.
- Developers undertaking non-developer work can favour technical fixes to non-technical problems. One example is the “social fork” where a lack of community and care work within a project leads to massive social friction. Instead of solving the problems on a social level, parts of the community fork the code and establish a new technical project, partly to circumvent social tensions or abusive behavior. Matthew Garrett’s work on the Linux Kernel is a well-publicized example of a developer avoiding “the behavior of various high-profile people within the kernel community,” in this case the Linux Kernel Mailing List.
“We are not very good at marketing; we are problem solvers.”
“I would prefer to be just an engineer. In practice I am a community manager.”
“We are developers. We also do community and outreach, but that is learning by doing.”
Related RecommendationsAll Recommendations arrow_forward
The provision of free-to-access resources and examples of good practice about onboarding could help those who are willing to change the process, but do not know where or how to start.
Explicitly funding non-technical positions within tech projects can enhance their standing in the eyes of the FOSS community.
Bringing professional moderators to community events can help foster more constructive dialogue.
By choosing what kinds of work to support, funders send a message about what kinds of work are valuable. When working with projects in which essential management roles already exist, support them to the same degree as the developer positions. Refrain from focusing solely on developer positions. At the same time, avoid filling non-coding positions with people from underrepresented groups; this can reinforce the idea that coding is performed by higher-status people
Opening channels of communication and knowledge exchange with existing groups of experts who work on non-coding tasks can make it easier for FOSS infrastructure projects to reach out to them. This can help foster respect for the people and the work, and lead to greater appreciation for these positions within the community.
Fiscal sponsors can be put in charge of financial administration; incorporate this into project overheads. Fiscal sponsors are mostly a North American phenomenon, uncommon in other parts of the world. Organizations on their way to becoming fiscal sponsors in their respective legal and tax system should be supported so as to make it easier for FOSS infrastructure projects outside the USA to comply with funders’ requirements.