Seeking my Next Adventure

Posted on by

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 🥇

Posted on by

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

Posted on by

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.

My first German paper

Posted on by

I am super excited!

For four years, I publish academic papers. All in English. Today, I have my first paper in my native language, German.

A big thanks to UNO Criss Library for funding the Open Access fees! It is great to have the amazing support for a future of a more open science.

I am very happy to have an amazing author team of Malvika Rao, Don Marti, Andy Leak, and Rich Bodo. They developed the core of the idea before I joined them and created a welcoming environment for me to learn so much and expand my horizon. – THANK YOU!

A big thanks to all of my test readers who provided invaluable feedback and helped me fix mistakes. Admittedly, I German grammar rules are different from English.

Without further due, the title and abstract of the paper:

Marktplatz zur Koordinierung und Finanzierung von Open Source Software

Open Source ist ein zunehmend beliebter Kollaborationsmechanismus für die Entwicklung von Software, auch in Unternehmen. Unsere Arbeit schafft die fehlende Verbindung zwischen Open Source Projekten, Unternehmen und Märkten. Ohne diese Verbindung wurden Koordinations- und Finanzierungsprobleme sichtbar, die zu schwerwiegenden Sicherheitslücken führen. In diesem Paper entwickeln wir acht Design Features, die ein Marktplatz für Open Source haben sollte, um diese Probleme zu beseitigen. Wir begründen jedes Design Feature mit den bestehenden Praktiken von Open Source und stellen einen Prototypen vor. Abschließend diskutieren wir, welche Auswirkungen die Einführung eines solchen Marktplatzes haben könnte.

Weiterlesen…
Der Artikel ist open access und bei Springer verfügbar.

Marketplace to Coordinate and Finance Open Source Software

The popularity of open source as a collaboration mechanism for developing software is increasing. Organizations increase their engagement. In our work, we draw the missing connection between open source projects, organizations, and markets. Without this connection, we have seen severe software vulnerability result from coordination and financing breakdowns. In this paper, we develop eight design features that a market place for open source should have to address these breakdowns. We develop the design features based on literature about the practices of open source. We present a prototype and discuss what implications would result from implementing such a market place.

Read more… (in German) 
The paper is open access and available from Springer.

Full reference:

Link, G. J. P., Rao, M., Marti, D., Leak, A., & Bodo, R. (2018). Marktplatz zur Koordinierung und Finanzierung von Open Source Software. HMD Praxis der Wirtschaftsinformatik. https://doi.org/10.1365/s40702-018-00474-6

Is open source wealth distribution fair?

Posted on by

I published the following blog post originally on Opensource.com.

If wealth is the abundance of valuable possessions, open source has a wealth of software. While no one “owns” open source, some are better than others at converting this communal wealth to personal wealth.

Many open source project maintainers who produce free open source software do not have a model for deriving income from the assets they have created. However, companies that use open source software to enhance their products and services convert this valuable asset into income.

The open source ecosystem needs novel mechanisms to distribute privatized wealth back to maintainers if open source projects are to remain sustainable. In this post, I’ll discuss the challenges of distributing wealth more fairly, starting with three key observations:

  • We need to identify projects that are important and need funding.
  • We lack fair rules for distributing money among open source project contributors.
  • Transaction costs are too high in underbanked areas. Bugmark and ossgrants (both discussed below) are two project ideas for addressing this problem.

Wealth creation in open source

The wealth created by open source rests today on an imbalance between those who bear the costs and those who enjoy the income. Consider the following example:

An amateur developer creates an open source project as a side project or hobby and releases the software free of charge. The software increases communal wealth when users derive value from it. Companies in particular leverage the open source software in their innovation stream, building products and services with less investment and converting valuable open source software assets into income.

A growing user base brings more support inquiries, bug reports, and feature requests, which take more time and increase costs for the maintainer. A community of contributors might form and share the work of developing and maintaining the software. Sharing the cost of creating communal wealth by contributing, however, does not provide income for the maintainer, who cannot generate personal wealth without mechanisms that distribute income from other users.

It is important to recognize that maintainers need to make a living, and if they have no income from open source projects, they likely have another job—which reduces the time they can spend on maintaining open source software. A lack of funding for open source projects becomes problematic when the software is part of our modern infrastructure and requires long-term maintenance.

The relationship between those who create open software and those who generate income from this communal wealth.

The relationship between those who create open software and those who generate income from this communal wealth.

The question then becomes: How can the wealth created by use of open source software be distributed to support long-term maintenance by paying maintainers?

At MozFest 2018, 23 people gathered to discuss this question. In small groups, participants discussed problems of interest, chose one problem to work on, and later presented their solutions to the larger group. This post summarizes key takeaways from this presentation and draws on ideas discussed during Sustain Summit 2018.

Participants in MozFest 2018 met to discuss open source wealth distribution.

Participants in MozFest 2018 met to discuss open source wealth distribution.

 

Why and how to share wealth

A central question is this: Why would companies share the income they generate from using open source software?

For-profit companies are seen as profit maximizers, and sharing revenue with open source maintainers, who license their intellectual property for free, seems counterintuitive. One survey found that 50% of respondents believe that large tech companies gain more from using open source than they contribute, which demonstrates that companies generate means to give back by using open source. (Note that I am not referring to the many open source projects companies actively maintain, or those that a company started. The focus here is on volunteer-driven communities.)

Three concrete value propositions can convince a company to pay open source maintainers:

  • Donating to open source projects earns a good name within the open source ecosystem. Donating to a project or a maintainer—for example via Patreon, OpenCollective, or an open source foundation—funds development work without exerting influence.
  • Funding open source maintenance ensures that an open source project will be updated and vulnerabilities fixed, which is important for companies that rely on the software for their products, services, and infrastructure.
  • A company gains influence over the strategic direction of an open source project when a donation or membership fee is rewarded with access to core maintainers. Special access can require that maintainers sign non-disclosure agreements and help develop solutions for vulnerabilities that may not yet have been publicly disclosed.

An open source project can also start a company that provides hosting and support services, and collect funds by selling their services. This is the most formalized way of securing funds and provides a clear value proposition. The key point is that a maintainer must figure out how to participate in the economy around open source software.

Distributing wealth: 3 practical issues

The following issues arise when the donation model is used:

First, not every project benefits equally from funds. Do you rely on open source software that might become unsupported if you do not donate to the project? The goal of such an evaluation is to find weak spots in an open source supply chain that can be strengthened with the least amount of cost. Consider using metrics, like the ones created by the CHAOSS project, for determining the health of an open source project. How exactly to identify open source projects that need funding before they become unmaintained is an unsolved problem. The Core Infrastructure Initiative has developed the Census Project to work on a solution. TideLift takes an innovative approach, paying more than $1 million to open source project maintainers based on how much a project is used.

Second, how should funds be distributed among open source project members? Defining how donations will be used should be declared upfront to avoid conflict. One approach might be to recognize individual contributors based on their contributions. For example, you could distribute funds based on the number of issues closed, commits accepted, lines added, wiki pages edited, documentation pages revised, forum messages posted, blog posts published, or other quantifiable contributions. But not all contribution types to a project can be measured—for example, organizing meetings and presenting at conferences are valuable but time-intensive contributions that do not produce trace data in a collaboration software. Every project must set its own rules, but we can share stories and best practices. Open Collective brings this conversation to the public.

Third, transaction costs hinder fair distribution of the wealth created by open source. Specifically, many people in underbanked regions struggle with the logistics of receiving payments. When an open source team member must wait for hours to cash a check, the cost of the time might outweigh the amount they receive for their work. This very real problem may be beyond the scope of what open source projects can do (except perhaps initiatives for Web3), but it deserves attention. Ultimately, the solution is to bring banking to all people and improve the interoperability of banking systems around the world.

Facilitating and incentivizing wealth transfer

There are many initiatives to solve the sustainability problem in open source, but I’ll highlight two projects that I find intriguing.

Bugmark answers the question of who within an open source project should get paid, and how much, by creating a marketplace that introduces price signals to open source. The Bugmark exchange allows trading on the status of an issue—for example, issues listed by an open source project on their GitHub issue tracker. Unlike bug bounties, trading on the status of an issue is independent of doing work. By decoupling payment and work, Bugmark has the potential to fund open source work that is not reliant on fixing an issue. For example, a project member who does bug triaging, an honorable but tedious task, has in-depth knowledge of how a project is doing and what is being worked on. This person can use their insider knowledge to trade on Bugmark and earn money. For more details on how Bugmark works, I recommend this publication.

Funding Index is an early-stage idea that revolves around donations. Donations provide a project with money without restrictions. Donations benefit companies, but the publicity effect is short-lived. At SustainSummit, we developed an idea to capture donations more permanently and create a funding index. Donations would be logged and aggregated across companies and projects. Similar to consumer rating agencies that rate products and services, this index would rate companies by how much they donate to open source projects relative to how many employees they have. We could produce badges for “#1 donor to open source,” “#1 donor to infrastructure open source projects,” or “#1 mid-sized company donor to open source.” Such a badge would extend the publicity effect of donations and hopefully incentivize companies to donate more. Funding Index exists in a first prototype and welcomes discussions on the Discourse Forum.

Sustainability is more than funding

Funding helps to pay for living expenses, servers, stickers, and travel to conferences to enable face-to-face collaboration. Funding is a necessary component of a sustainable open source project, but it requires additional elements.

A sustainable open source project fosters a healthy community, which is welcoming, provides a productive work environment, supports its members, and is prepared to let members move on when their focus in life changes. These governance and community concerns build the foundation from which open source projects work, and once they are in place, funding can leverage the work and help project members excel.

A final thought: Companies that are willing to financially support open source projects need to see the business value. Currently, there is no single solution that fits all open source project contexts. Every open source project may need to experiment for themselves and find a way to secure funds. Umbraco, for example, built a sustainable business around its open source CMS system and has experimented with 11 different business models since its inception in 2004.

More conversations are needed, and experiences must be shared. SustainOSS.org brings sustainers together to have these conversations. In conclusion, fair distribution of the wealth created by open source can enhance what already works well in open source, but it will not replace traditional open source practices.

Post Scriptum

I acknowledge that companies and foundations also create open source projects. Sustainability issues exist nonetheless, and takeaways transfer.

Acknowledgments

I’d like to thank all MozFest 2018 session participants, especially the note-takers. I appreciate constructive feedback from Sean Goggins and Tobie Langel. I received a Linux Foundation Community Travel Fund to present at Open Source Summit Europe 2018 in Edinburgh, which allowed me to participate in the SustainSummit and MozFest in London later during the same week. This work is supported through the Alfred P. Sloan Foundation Digital Technology grant on Open Source Health and Sustainability, Num: 8434