Tag Archives: Open Source

Detours on my Journey to Open Source

Posted on by

Last week, I reflected on my journey to open source. This week, I reflect on how that journey continued into my academic career. The focus of today’s story is on the detours I took that led me to where I needed to go.

By the end of my high school education, I had experience in open source, specifically the OpenOffice.org and Drupal communities. I was convinced that open source was a great licensing model and I valued the collaboration it enabled. I was building websites as a freelancer.

I had a noticeable passion for software development. Many years later, a high school friend told me how he found it hard finding time to meet with me because I often preferred getting into the flow of writing software.

In high school, everyone believed I would pursue a career in software and become the next Bill Gates, only with open source. This is not how it played out. I did end up in the open source software world, but I took several detours on the way.

Detour: B.A. in Business, Economics, and Banking

As I was considering career choices for after high school, I had all options open to me. I was very fortunate to pursue any like of work that interested me because I had supportive parents, the necessary mental capacity, education, as well as the social and economic status. I considered studying computer science and becoming better at what I had a passion for.

However, a piece of eye-opening advice I received pointed out that all software exists to solve a problem and if I wanted to create impactful software, I would need to understand the problem domain including the business and economics side of it.

For three years, I put writing software and participating in open source communities on the back burner as I followed the advice to build out my business and economics understanding. I joined a dual-studies program that had two components.

The first component was an apprenticeship at Bankhaus C. L. Seeliger, a local bank in Wolfenbüttel, Germany. The apprenticeship concluded with a certification by the Chamber of Commerce that would allow me to practice banking in Germany.

The second component was a 3-year bachelor program in business at the WelfenAkademie, a college in Braunschweig, Germany. The program concluded with a Bachelor of Arts degree in business with a concentration in banking.

The two components were well-coordinated and I took turns spending several weeks at the bank and attending classes.

During this time, I continued to read news about what was happening in the IT industry and I was especially interested in news about open source projects. I would also choose technology and software topics for my independent studies and research reports.

In the bank, I most enjoyed my time in the IT department. I enjoyed helping with PC issues. The only thing I enjoyed more was helping with the rollout of a new document management system.

In fact, I wrote my bachelor thesis on the subject of change management for the rollout of this system.

Detour: Overcoming a Career Blocker

Towards the end of the apprenticeship and bachelors, I was eager to back into IT. The bank did not have a job opening in the IT department and so I looked elsewhere.

Fun fact: Out of a love of traveling, I applied at Lufthansa as a flight attendant. Lufthansa rejected my application after the assessment center with kind words that I interpreted as: “Don’t waste your talents.” I redoubled my focus on a career in IT.

I approached the Technical University Braunschweig (TUBS) about joining their computer science master’s program.

I had falsely believed that the newly introduced bachelor’s and master’s programs allowed for movability between degrees. It turned out that I did not meet the enrollment criteria for computer science masters.

I was lucky to have talked with the program coordinator of the management information systems (MIS) degree. He showed me that I was only a few credit points shy of joining the MIS masters and suggested that I enroll as a bachelor student in the degree to earn the necessary credit points.

Within one semester, I enrolled in all foundational computer science and MIS classes. I felt like I just had to prove that I already had the skills necessary for pursuing the MIS masters and so I did.

Detour: Studying Abroad and Falling in Love

While enrolling in the MIS masters program, I found on the program website an unassuming link that promised information about an exchange program.

The PDF document I found there described a 1-year exchange program with the University of Nebraska at Omaha (UNO). I would transfer credit points between the TUBS and UNO, double-dipping on my course work. The promise was to earn the master’s in MIS from TUBS and an MBA from UNO without losing any time.

I was intrigued, asked how to enroll, and then learned that accepted students also received a scholarship to cover the expenses of the exchange program.

Long story short: I started the MBA program at UNO which set wheels of destiny into motion.

I fell in love and started considering living in the USA and Omaha, Nebraska specifically.

Looking at options to stay in Omaha, I explored the Ph.D. in IT program at UNO. I liked the makeup of the program. It was very interdisciplinary and open to me joining with a background in business and MIS. I felt that with the Ph.D. in IT would finally complete my move to a career in IT after my detour with a bachelor’s in business and banking.

To get into the Ph.D. program, I asked a professor if he would take me in as his Ph.D. student. I collaborated with him on my master’s thesis project and demonstrated my ability to engage in research. The research area we were working on was collaboration science. At the time, I was not even considering open source as a research option but in hindsight, it is stunning how closely related the topics are.

End of Detours: Coming to Research into Open Source

The professor I was planning to work with accepted a job at another university while I was still applying to join the Ph.D. program at UNO. He offered me to follow him there but I was set on living in Omaha, Nebraska, starting a family here, and getting married.

This left me without a mentor when I joined the Ph.D. program. I scheduled meetings with faculty who had interesting research topics.

When I met with Matt Germonprez, I learned that it was possible to do research into open source. I was immediately hooked.

My experience in the OpenOffice.org and Drupal community came back to me. I had never considered that open source could be a research option but now it was.

I was hesitant at first to work with Matt because he specializes in qualitative research. I was afraid that with English as a second language, I would not be equipped to do qualitative analysis where an in-depth understanding of language was necessary. Matt promised to train me, gave me the confidence that I could learn the skills, and so I gave it a chance.

The research approach I learned was built on engaged fieldwork. This means participating in open source projects, fully embedding myself in open source communities, and talking as much as possible to professionals in the space to learn their language and viewpoints.

Throughout the four years of my Ph.D., I got to know many people in the open source ecosystem and participate in different open source projects.

This is where my detours ended and I arrived in open source again. I had what was needed to dive in and become a contributing member of the open source ecosystem. There is plenty of fodder for more blog posts. I have already shared some of my stories and can recommend as further reading:

Today, my main focus in open source is on metrics, the Linux Foundation CHAOSS project that I cofounded, and Biteriga.

Let me close by saying this: It is my mission to help the open source ecosystem become more professional with how we use metrics. I do this through (1) my work in the CHAOSS project and (2) by helping organizations hire Bitergia to receive professional services for their metric needs.

My Journey to Open Source

Posted on by

I just realized that I have known about open source software for more than half of my life. Today, I look back to using open source software for 17 years and joining my first open source community 14 years ago. This blog post is about how I got started in open source and some early lessons learned.

Georg holding up the OpenOffice.org DVD case that he designed
One of my early open source contributions was designing this DVD for the OpenOffice.org Conference 2006 in Lyon, France. I couldn’t go and cherish this copy sent to me via mail.

I learned about open source software after I bought my first computer at the age of 13. I had made a deal with my parents that I would get money for a computer if I successfully spent one year in the USA. I went from not understanding English to having A’s and B’s in all subjects. Back in Germany, I found a computer I liked on eBay, bought a 19” CFT monitor, and Diablo II as my first video game. Oh, the memories.

Learning to develop software

At the time, I had a friend in school who was a few years ahead of me and already knew Delphi 6, a programming language taught in our school. I was amazed by the things he could make his computer do and my interest in software was born. I got a copy of the Delphi 6 and started combining recipes from an online cookbook to build software that was fun and entertaining. I still light up at the thought of an endless loop opening and closing the DVD drive — only today I don’t have a DVD drive anymore.

I found other friends who were interested in computers and software. One of them showed me web technologies and PHP specifically. On a youth group retreat, I devoured a PHP+MySQL book I had bought with my own money. I still remember creating one of my class project reports as a PHP application and having to explain XAMPP to my teacher. While learning more about PHP and web technologies, I was also learning about open source.

Joining my first open source community

I don’t recall reading The Cathedral and the Bazaar but I knew of the text and how it described the collaborative way that open source software was developed. As a high school student who was writing software for fun and sometimes to annoy my siblings, I was intrigued by the possibility to join a community that was developing software together.

I followed a recommendation to join an open source community of a software package that I was already using. This is how OpenOffice.org became my first open source community. I started by lurking on mailing lists. I learned that there were separate groups in the community. As a German boy, I decided to help with testing the German release of OpenOffice.org. I downloaded the release candidate, installed it, and reported issues when I found them.

Contributing non-code contributions

Testing a release candidate was my first contribution. The sense of being part of something bigger was exhilarating. I never contributed a single line of code to OpenOffice.org but found other ways that I could help. This first experience impressed on me the importance of having an open source community in which all types of contributions are welcomed and valued, not just code-contributions.

For example, I vividly remember rethinking mnemonics. What are mnemonics? They are the underlined letters in a menu that allow you to quickly select a menu entry by typing that letter on the keyboard. Over the years, menu entries had been added and in the German user interface, there was no apparent logic to the mnemonics. I volunteered to fix this situation. I printed all menus and while on vacation in Vermont, USA, I sat in the backyard and mulled over which letters would best be used for mnemonics. I was not the one implementing it but I provided a first draft that was accepted with few changes.

Learning from and experiencing an open source community

I’ll mention one last contribution to the OpenOffice.org community because I have a physical artifact and it taught me three important lessons. For the OpenOffice.org conference in Lyon in 2006, I designed the DVD label and cover.

The first lesson I learned from creating the DVD label and cover is the importance of attributing the work of others. I had taken a scalable vector graphic (SVG) image created by someone else and added specific information about the event. When I submitted my draft, I was called out for changing the “author” field in the SVG, because I had not created the original version but only modified it.

The second lesson I learned from creating the DVD label and cover is the value of iterating with the community. I went through several iterations of the design and always got good feedback from other community members. To be honest, I had never designed a DVD label and cover before and so I learned a lot in the process. To this day, I think of that same feedback when I am designing anything graphical.

The third lesson I learned from creating the DVD label is the power of thanking community members. I still know the name of the person who asked me for my address to send me a copy of the DVD and I still cherish this little trinket.

Moving on to other open source communities

A traumatic event occurred in the OpenOffice.org community when Oracle acquired Sun and with it the trademark and employed maintainers of the OpenOffice.org project. The fallout that followed and led to the founding of The Document Foundation and LibreOffice have impressed on me the power that a vibrant community has, even over a large corporation that basically “owned” an open source project. I first hand experienced and understood the implications of forking, a core feature resulting from the open source licensing model.

I will wrap up my journey into open source by highlighting other communities that I have been part of and what they have impressed on me.

I joined the Drupal community because I was developing web pages as a freelancer and I found Drupal to be a flexible platform that suited my needs. Drupal was the first open source project that I contributed code to and I was super excited to be involved in the development of Drupal 7.

Toolkit for YNAB is an unofficial browser plugin that adds features to the You Need A Budget (YNAB) web service. I had contacted the YNAB support about features I wanted and ways in which YNAB was not intuitive for me. The YNAB support kindly referred me to the open source community that was implementing those features in Toolkit for YNAB. The features are not part of the web service and break with new releases. I am amazed by the ingenuity of this project.

The Core Infrastructure Initiative (CII) Best Practices Badge Program is a self-certification that open source projects can obtain to signal that they have established best practices. I joined the conversation during the development of the Silver and Gold badges. Then, I started translating the CII Best Practices Badge web app to German. Funny story: When a friend of mine visited from Germany and asked for something to do, I recruited him to help with the translation. He ended up translating more than me. To this day, I maintain the translation and update it when the web app gets updated.

At the Open Source Summit North America 2017 in Los Angles, I spoke with Don Marti learned about Bugmark. I was intrigued by the idea to have a futures market for open source software issues as a way to provide sustainable funding to open source software contributors. I helped think through and shape the core elements of the futures marketplace. You can read more about it in the Journal of Cybersecurity and HMD Praxis der Wirtschaftsinformatik (German).

I joined the SustainOSS community after attending the summit in 2018 in London. This is not a typical open source community because it is not developing software but establishes a network of professionals around an important issue, the sustainability of open source communities. I volunteer to be a forum moderator.

Lastly, I am a co-founder and co-lead of the Linux Foundation CHAOSS project. This is a much larger story for a different blog post, one part already shared on The New Stack and mentioned here on my blog.

In closing, I am very fortunate to have learned early in my life important lessons about how open source software is developed and how open source communities work. Today, I am happy to have my professional home among the wonderful people who work in open source.

Community Manager Gathering 2019

Posted on by

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.

Update: Jono Bacon announced that CLS will return in 2020.

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