Community Manager Gathering 2019

Community managers are accustomed to meet before OSCON. This year, Community Manager Gathering served this need.

The morning was planned with talks. We had very interesting talks that sparked a lot of conversation, pushing back subsequent talks. We applied the flexibility required of managing communities to our gathering and made the best of our engagement.

The afternoon was planned for unconference sessions. I personally love the unconference format, because it sparks real conversations that are unplanned and very natural.

Talk: Growing a community through diversity and inclusion metrics

Nicole Huesman and I presented a talk on “Growing a community through diversity and inclusion metrics”. We based the talk on our experience working with diversity and inclusion efforts. For me, this was mostly the work in the CHAOSS D&I Working Group and my dissertation work. The slides are available online.

Unconference session: Community Metrics (CHAOSS)

My favorite unconference session was about measuring community health. I facilitated the session and brought in experience from the CHAOSS project.

We discussed the process of defining metrics in the CHAOSS project, specifically the history and how we work in working groups.

We talked about metrics that are used by different participants, specifically sharing the experience that metrics are a tool to telling stories and themselves are meaningless.

The danger we all acknowledge is that metrics can be misused by people who don’t understand a community. A problem with metrics released by CHAOSS may be that these metrics seem endorsed by CHAOSS and people reflect less on whether and in what situations a metric should be used.

Next year

Next year, the Community Leadership Summit may return to OSCON. Or, we may have a second version of the Community Manager Gathering. If anyone is interested in helping with next year’s meeting, please speak out.

Contributing to practice and research – experience with the engaged scholarship research method

With Sarah Conway from the Linux Foundation, I published a contributed blog post in The New Stack. We wrote about the CHAOSS D&I Working Group’s history, present, and future.

What is the relevance of this blog post? Obviously, writing about the CHAOSS D&I Working Group is publicity for the work we do. Obviously, writing about how the working group operates and what goals it has makes it easier to onboard people. Obviously, getting a blog post accepted makes me happy. However, the relevance of this blog post goes beyond what is obvious.

Not so obvious is why I initially wrote the blog post. I wrote the text as a section for my dissertation. The CHAOSS D&I Working Group has been my field site for studying how metrics for open source project health are created. I needed to describe the work of the CHAOSS D&I Working Group for the dissertation to tell the full story. Once I had a draft of the story, I found the text to be a nice summary and thought it was worth sharing with the CHAOSS D&I Working Group. Another reason for me to share the text was to make sure I did not forget or misrepresent anything – this is called member checking and increases the validity of my research.

After sharing the text with the CHAOSS D&I Working Group, the text in the dissertation and the text that is now the blog post evolved differently. Sarah extended and revised the blog post to make it more attractive to the audience of The New Stack. Meanwhile, I merged the text in my dissertation with findings from interviews to tell a more focused story for my theoretical discussion. Core elements in both versions still exist, the screenshots that show the CHAOSS D&I Working Group work, for example, but they have different foci and purposes within the blog post and dissertation.

To me, the background behind of the blog post demonstrates the double benefit that researchers provide when they engage with professionals on the subject that they study. I find it very rewarding to be providing value to a community of practice while doing research. I am very glad that I learned how to do engaged scholarship research during my Ph.D.

Seeking my Next Adventure

UPDATE: I joined Bitergia as Director of Sales.

My time as a PhD student is coming to an end and I’m ready to move into a full-time role at a company around August. TL;DR is included with more details below.

TL;DR:

What I’m looking for in my next adventure:

  • Open source focus
  • Building communities
  • Remote work + travel

What I’ve been doing (resume):

  • Engaging and empowering contributors
  • Optimizing communities & contributions (CHAOSS)
  • Public Speaking and open source evangelism (Talks)
  • Instructing and training

You can contact me at linkgeorg@gmail.com


Now for the longer version and more details what I am searching for in my next adventure …

I am finishing my Ph.D. from the University of Nebraska at Omaha. I enjoyed my time in academia and especially when paired with industry experience. I am now seeking a new adventure in industry and would like to start around August.

I am looking for a remote position to work from Omaha, Nebraska. I founded a family there and want to nurture our roots as a legal permanent resident. I have a dedicated home office and live 20 minutes from an airport with excellent connections to anywhere in the world.

My primary job criteria is that I continue to work in open source. I have ten years experience in open source and focused my 4-year Ph.D. program on how organizations engage with open source projects. I co-founded the Linux Foundation CHAOSS Project to foster industry collaboration for better understanding open source project health. I strategically steered the project as a Governing Board member, tactically fostered a community as a maintainer, and operationally created content as a contributor. I made many friends across organizations and projects and want to continue working with these amazing people.

As part of my employment, I would like to continue giving talks at conferences and connecting with people face to face. Conferences I like to travel to and present at include Linux Foundation events, CHAOSScon, FOSDEM, and SustainOSS.

You can contact me at linkgeorg@gmail.com


Here are a few links with examples of my work and more details about my past experience:

Idea: Sustainable Best Practices Badge 🥇

TL;DR The idea is to establish a checklist of best practices for sustainable open source communities. We could follow the same model that the CII Best Practices Badge has for security best practices. Communities voluntarily sign up to achieve a badge and provide public evidence for following sustainable best practices. The Sustainable Best Practices Badge application tracks this information, serves as a place for checking the status of a community’s badge, and provides badges that communities can display on their repositories, websites, blogs, newsletters, and marketing material. With wide adoption, this badge becomes a quality signal for open source communities. Foremost, the badge serves as a checklist for communities to review their practices and improve where necessary.

Problem

Open source communities have no uniform way to signal that they are sustainable. An observer has many different signals to look for, for example: What is the bus factor? How is the community financed? How diverse are the contributors? Are there security policies? Is there a code of conduct?

Communities want to signal that they are sustainable because it attracts users, developers, designers, translators, advertisers, and in short new contributors. Users need to know they can count on the community to support an open source software long term. Especially, corporate users face risks when an open source software to go unmaintained after it was integrated in their innovation stream, product development, and service offering. Contributors want to contribute to a community that is welcoming, values their contributions, and serve as a credential on their open source resume. In short, all stakeholder incentives align to benefit from signals about the sustainability of open source communities.

We, as the open source ecosystem are lacking a reliable way to signal the sustainability of an open source community. We may look at the size of a community, what companies are backing it, whether it has a code of conduct, how active the members are, when the last release was, or whether it gets positive press coverage. Sustainability is a many-sided problem and to date, only one-sided solutions exist.

Existing Work

We have a Sustainer Manifesto with principles that sustainers believe in (Adam Jacob’s established similar principles). However, these principles need to be translated into specific actions and best practices.

Academic research has not identified what best practices make an open source community sustainable. Researchers report that communities have a variety of different governance models and establish their own practices. Tracking various metrics to predict whether a project will be sustainable and continues to be active in the future yielded inconclusive findings. Many of these studies were conducted with Sourceforge.net but GitHub is now the norm. These older studies are also unable to speak to the new reality considering the recent influx of corporate community members. In short, research does not have an answer but rather poses many unanswered questions.

Several resources exist for open source communities to learn about sustainability issues and how to address them. These are based on anecdotal evidence.

Incomplete list in alphabetical order by author first name:

The problem with these resources is that they are input for communities but do not translate into signals for observers to know whether a community is sustainable.

The CHAOSS project collects different metrics for assessing open source communities. The problem is that as an observer, who is not part of a community, data for metrics can be difficult to collect. CHAOSS is useful for communities to figure out how to measure themselves and prepare metrics as signals for outsiders. CHAOSS is addressing the problem that communities signal in inconsistent ways and thus observers have no baseline for comparison.

The CII Best Practices Badge advanced security practices in open source. Communities can self-certify to follow security best practices from a checklist and have to provide public evidence. Many communities report having changed their practices in an attempt to earn the badge. As a reward, communities can display the badge to signal that they follow security best practices.

Sustainable Best Practices Badge

The idea is to combine the above existing work. We borrow the idea from the CII Best Practices Badge and create a checklist of sustainable best practices. We may even fork the web app that CII developed. We derive best practices from the resources available today and common sense. We vet the list of best practices through a community review process with long-standing members of the open source ecosystem. We use CHAOSS metrics to measure outcomes from appropriate best practices and provide evidence. We follow a scientific approach to track which best practices are more indicative of sustainable communities.

Each Sustainable Best Practice has to be actionable for communities to implement them. The checklist serves as a tracker of how many best practices a community is already following. A sustainable community may have little to change to check all best practices and earn a badge.

Communities can use the Sustainable Best Practice Badge to signal that they are following these best practices. This is not a guarantee that a community is indeed sustainable. A checklist cannot eliminate all risks and danger. However, airplane safety has improved thanks to checklists pilots go through before every flight. Similarly, communities can be more sustainable if regularly checking that they are following known sustainable best practices.

Communities have an incentive to earn a Sustainable Best Practices Badge because of the signal it provides and because it helps them establish proven practices.

I am putting this idea forward for discussion and would love to hear feedback, criticism, support, and suggestions on the SustainOSS forum.

Disclaimer

While the idea for a Sustainable Best Practices is mine, it is shaped by conversations at the Sustain Summit, metrics work in the CHAOSS project, co-authoring the Sustainer Manifesto with Justin Dofman, and a Twitter thread with Adam Jacobs. This proposal is based on my own experience. In the spirit of transparency, I will declare my involvement. I co-authored the paper on why we need more research into open source. I co-founded the CHAOSS project and am a member of its Governing Board. I translated the CII Best Practices Badge to German and participated in the discussion for adding silver and gold badges. I know there is more work out there and I look forward to the conversation this blog post hopes to start.

An Open Source Toolchain for Recording Interviews

TL;DR: When recording through conferencing system is unavailable, I use three open source tools to record interviews: OBS Studio, Blender, and Audacity.

As a qualitative researcher, I enjoy engaging with people directly and occasionally I want to record an interview. I conducted XL (roman numeral) interviews as part of my PhD and I figured out how to capture the audio and transcribe it. A primary concern is the quality of a recording. Because I am undoubtedly not alone, I describe here lessons learned and my open source tool chain.

My first attempt at recording an interview involved an old-school telephone on speakerphone and my smartphone with an audio recording app. The audio quality was abysmal. My voice was clear, but my informant’s voice was distorted through the analog transformation between phone speaker and smartphone microphone. I never tried this again.

The best solution is using the conferencing system that my university provides. The system allows my informants to connect via app, browser, or phone. In my experience, about 90% of informants join via app and activate their camera, which makes for a great conversation. The recording quality is only dependent on the microphones quality. Sometimes, I ask informants if they have an alternative they switch between a headphone to a built-in microphone.

This optimal solution is not always practical and some informants prefer to use alternative ways to connect, such as Skype, Jitsi, Meet.me, GoToMeeting, or a conferencing system they control. When I need to make a phone call, I use Google voice from my laptop. I developed a toolchain of open source software that allows me to record an interview in such settings. I use three tools: OBS Studio, Blender, and Audacity.

OBS Studio (Open Broadcaster Software Studio) allows to capture anything on my screen and record in-going and out-going audio. I simply record the audio output from my computer and my microphone input during an interview. The quality is the same as directly recording it through a conferencing solution. The downside is that OBS requires computing resources and at times bogs down my laptop. I end up with a *.flv video file that contains the desired audio.

Blender is a 3D modeling software but has powerful video editing capabilities. I recommend Mikeycal Meyers’ tutorial on how to get setup. Blender is overkill for extracting audio, but it is a tool I know. Once the *.flv file is loaded into Blender, I export the audio, without doing any editing. I end up with a *.flac audio file.

Finally, I use Audacity to cut the audio and tweak it. I edit any audio, whether recorded by OBS or a conferencing system, with three goals in mind. First, I cut the beginning and end because small talk is not important to my analysis. Second, I check to make sure my informant is audible. When the audio is too quiet, I boost it using Effect –> Compressor… for the whole audio or Effect –> Amplify… for small sections. Third, I shorten pauses using Effect –> Truncate Silence… which saves fees on transcription services. I export the final audio as an *.mp3 audio file.

After generating a good quality audio file, I need to transcribe the interview. I transcribed one interview myself using OTranscribe and it took me six hours for a one hour interview because I worked to get every word and half sentence and expression right. I quickly learned that this level of detail is hindering me and a more streamlined transcript is easier to analyze. After making this experience, I value having a research grant that pays for a transcription service and I am a returning customer of rev.com.