This post does not describe what the Principles are (click that link to learn more about them). This post describes the story behind the Principles, and how our Sustain Working Group worked together over three months of virtual facilitation during the COVID–19 crisis to build these Principles.

Overview 🔗

This blog post is a story, or perhaps open source lore. So, here is the abridged summary:

1. The Sticky Idea: How did a discussion topic at a one-day open source sustainability conference evolve into a three-month extended collaboration?
2. Facilitation, Roosevelt-style: The people are here. How do you facilitate a conversation with no scope and few bounds?
3. Is there a next chapter to this story?: The Working Group is winding down. What happens to the Principles next?

If you are hooked, read on.

The Sticky Idea 🔗

How does a discussion topic at a one-day conference evolve into an inter-organizational, international collaboration that spans three months?

When the accountability and transparency discussion groups formed at Sustain Summit 2020, none of us knew what would come after the event. Not to mention, there were several different sustainability topics explored at the Summit.

So, the conversation about corporate accountability was about the same as every other conversation during that morning: someone was motivated enough to step up and say, “I’ll do it – I’ll facilitate this conversation!”

Open Source Accountability Goals 🔗

Duane O’Brien volunteered to lead facilitation on defining goals for open source accountability. Duane proposed four goals to iterate on in the Summit break-out groups:

1. Set and publish a goal for open source contribution relative to value capture
2. Adhere to principles of authentic participation
3. Publish documentation of open source policies, processes, and project governance
4. Well defined reporting process that is publicly available

The morning discussions broadly focused on these goals. After the ice was broken and conversation was flowing, themes and patterns emerged in the stories we shared with each other. Later that day, Allen Gunn asked me if I would lead an afternoon discussion session. The second goal, these principles of authentic participation, were personally interesting to me, and the morning group was engaged too. So I said, “Yes, I’ll do it!” Even though I did not really have any idea what I was going to do yet.

Facilitation of Authentic Participation discussion 🔗

After lunch, I gathered folks for the discussion group to discuss what authentic participation means. If we could propose a basic set of principles that we agree on, could this be a useful tool for the pain points of stories shared in the morning session?

The afternoon discussion was insightful, but lacked firm conclusions. We had great ideas and lots of stories, but nothing to tie them together. I collected email addresses of folks who wanted to continue engaging on the Principles of Authentic Participation. However, I wasn’t sure what the next step would be at the time.

At the Summit, I committed to facilitation of a public Discourse forum discussion, but some attendees voiced that Discourse was not accessible for them. To compromise without exhausting myself across too many platforms, I promised to host a few online discussions for folks to gather and talk about these things again later.

The embers were hot on this discussion at the Sustain Summit. But it was still just embers. How do we get these embers to “spark” into something bigger? Enter the Fireside Chats.

Facilitation, Roosevelt-style 🔗

So, skip ahead a couple weeks. I was ready to push the conversation forward. The time was right for the first follow-up email to the discussion group participants. As promised, I opened a Discourse discussion that summarized our notes from the conference and asked open-ended questions. Later on, I announced the first of four Fireside Chats. The Fireside Chats became the primary vehicle of collaboration for the working group.

Text-based communications are my preference. But video?? I would have to swallow my introverted shyness if I was going to lead this. I never facilitated an online discussion group before. There were also not many public examples to learn from either. The style I took to the Fireside Chats was mostly my own. I relied on my past experience of facilitating open source project meetings and development to drive these Fireside Chats. And I borrowed a little inspiration from former American president Franklin D. Roosevelt’s fireside chats during the 1930s/1940s.

For the first Fireside Chat on 2020 February 28th, I had no idea what I was doing. I prepared a loose agenda, but I left it broad so people could bring their own interests and passions into the conversation. I figured doing this would allow people to bring their own needs, desires, and wants to the conversation. It was unrealistic to expect a collaboration driven by my own motivations.

A successful collaboration requires all participants to have an opportunity to satisfy their own personal motivations for showing up in the first place. So, my approach centered our collaborative work on the group and not just myself, to avoid a high initial interest that dwindles down over time.

How did facilitation start? 🔗

The first Fireside Chat was exploratory. It was our first time talking about the Principles since the Sustain Summit. We caught back up on where we left off, detailed what we wanted to get out of this collaboration, and began scoping out what we thought we could accomplish together.

Although the first chat was mostly unstructured, it was essential to to identify themes and ideas that led to more focused, structured discussions for the next three Fireside Chats. The Discourse thread was also useful as an accessory for the Fireside Chats. I published notes from each Fireside Chat on the Discourse thread, and there was some asynchronous discussion between Fireside Chats.

Beyond the first Fireside Chat, the agendas became easier for me to write and the feedback became more focused. Fortunately, most of this work happened in public on the Discourse thread. So, if you are curious for more details on how the final three Fireside Chats went, take a look at the discussion thread.

Is there a next chapter to this story? 🔗

For now, the Principles of Authentic Participation Working Group is going dormant. We met our original goal of drafting some basic principles.

So, now what happens? So, let’s try to predict the future! (That can’t be that hard, right?)

My hope is that the Principles of Authentic Participation leads to more story-telling about what it means to authentically contribute to open source, whether you are an individual or an organization. To help curate the stories, I created a template to encourage folks to share them with us. The template provides question that makes it easy for a maintainer to copy and paste the story into our published Principles of Authentic Participation website.

Whether this hope comes true or not, we will see. But the Principles have a life of their own now. It doesn’t mean the Working Group will never meet again, or that we won’t revisit these ideas over time. But these Principles are now the “property” of the community to continue building. I will continue to participate where I can to curate stories about the Principles.

Closing thoughts 🔗

My hope in sharing this story is to help other facilitators and activists in the open source world approach digital-only organizing. Digital facilitation and organization is a skill we are all learning, for better or worse, in a COVID-19 world. But it isn’t a new skill. Lots of folks have been doing this for a long time, especially in the digital-first world of open source.

So, I hope this paints a picture of how we pulled off the Principles of Authentic Participation and how others can take what we did and improve on our processes.

It is possible to work collaboratively with new people on digital initiatives across different backgrounds and sectors. Remote facilitation is someone being brave enough to step up and lead, even if they have no idea what they are doing. After all… isn’t that what many other white American men like me do anyways? So can you.

FOSDEM 2020 took place from Saturday, 1 February, 2020 to Sunday, 2 February, 2020 in Brussels, Belgium (shortly after Sustain OSS 2020 and CHAOSScon EU 2020). On Saturday, together with my colleague and friend Mike Nolan, we presented on a topic he and I have co-conspired on for the last six months. What are the intersections of Free Software and artificial intelligence (AI)?

What is a rights-based approach for designing minimally safe and transparent guidelines for AI systems? In this talk, we explore what a Free AI system might look like. Then, taking research and guidelines from organizations such as Google and the UN Office for the Coordination of Humanitarian Affairs, we propose practical policies and tools to ensure those building an AI system respect user freedom. Lastly, we propose the outlines of a new kind of framework where all derivative works also respect those freedoms.

Freedom and AI: Can Free Software include ethical AI systems? Exploring the intersection of Free software and AI

Video recording from FOSDEM 2020

This post is an abridged summary of the key ideas and thoughts Mike and I presented at our FOSDEM 2020 session.

Let’s frame this first. 🔗

The idea behind this talk was a seed planted at MozFest 2018. I remember sitting with Mike in a hotel lobby while he was clocking some remote hours for work. We had some honest conversation about the experiences we’ve had across the public, private, and humanitarian aid sectors. At the time, Mike worked at the International Rescue Committee, and I had just finished a six-month internship with the UNICEF Office of Innovation working on open source community management.

The best way I can think of to describe humanitarian work is that it comes with the highest of highs and lowest of lows. Finding success usually means either a direct or indirect impact on some of the most vulnerable populations on our planet. Making mistakes or seeing planned efforts spin out in the wrong direction mean the resources your organization do not have the full impact they could, or sometimes worse, they fix one problem and create another.

At MozFest 2018, the seeds of thought for the intersections of Free Software as it relates to humanitarian aid and artificial intelligence were planted. Fast-forward a year to October 2019. Mike and I caught up after a while and after we had both had new experiences out in the industry. We began tending to the seed planted the year before. Our venting sessions and simultaneous cheers turned from our video chats back to the wider Free Software ecosystem.

The FOSDEM 2020 call for papers would open in a few more weeks from when we first began talking about these ideas in 2019. FOSDEM 2020 is a great collection of many different minds and people in the Free Software world, so it felt like the perfect audience for us to deliver our thoughts to an audience for the first time.

We applied, and later found out our application to the main track was accepted, landing us in the Community and Ethics track on Saturday.

This blog post is a partial recap of what we covered in that FOSDEM 2020 session linked above. The FOSDEM 2020 talk covered three main ideas. This blog post summarizes only the definitions of our AI Freedoms.

Looking to yesterday for today 🔗

Before we define AI freedoms, we need to define the origin of Free Software. While the precise origin is debatable, Mike and I posit that the Free Software movement began with a definition of rights. These freedoms were first established by the GNU Project on 27 Sept. 1983.

So, in the spirit of the movement that precedes us today, Mike and I started asking questions. As we go into a new decade, what would Freedoms of AI look like? We know we aren’t presenting The Truth or The Answer. But we are presenting our experiences and reflections.

What freedoms do we want to protect? 🔗

So, Free Software has the Four Freedoms. Combining our shared history in the Free Software movement with our personal experiences working in both commercial and humanitarian contexts, this is our vision of Three possible Freedoms of AI:

1. Audit automated decision-making systems 🔗

We are entitled to know and understand how decisions that affect us are made. So, you should have to freedom to audit, or understand, how those automated decisions are made.

For a moment, picture yourself in a classroom. Your teacher gives you a bad grade on an essay. You are probably curious to know why you received the grade that you did, especially if it was something important to you. You would likely go to the teacher and ask for help understanding why you received the grade you did, if there were no comments or notes.

So, why wouldn’t you want to understand how a decision is made that affects you?

This does tie closely to one of the Four Freedoms of Software: the freedom to “study the source”. This AI freedom restates that Software freedom as, “the freedom to understand how a system that is impacting you works”. But this does go beyond the Software freedom to study the source because it is more than just source code.

2. Deliver accountability and responsibility 🔗

We already know AI systems are capable of harm. We deserve the guarantee of liability when these systems do create harm. Not if, when. So, you should also have the freedom to deliver and expect accountability and responsibility from the designers of automated decision-making systems that impact you.

Think about it for a minute. When machines make decisions for us, who is accountable for those decisions? Is it the machines? Is it the creators who programmed them? Or is it the end-user?

It should be the creators and organizations that create these systems, as they directly profit from their output. Those who create these systems typically do so to profit themselves.

But we as those affected deserve to be put over their profit.

Myanmar and Facebook 🔗

What would a real world example of this look like? Have you ever thought about how social media could be connected to genocidal campaigns? This is what the United Nations is asking of Facebook in the role of the news feed in inciting genocide. But why would the U.N. ask these questions of Facebook?

The problem identified with Facebook is the news feed. The news feed optimizes for “engaging content”. To understand this, we have to define what “engaging content” means. Studies have shown that optimizing for “engagement” increases recommendations for extremist and alarmist content. Researchers knew the potential of “engaging content” to be misused, years before the Rohingya genocide began in Myanmar.

Then, the warnings in research became real. Religious and military leaders created “fake news” to divide the citizens of Myanmar. This “fake news” campaign is suspected to be a major contributing factor of the ethnic cleaning of the Rohingya people in Myanmar.

Obviously Facebook didn’t take genocide into account in their feature planning when building the news feed. Yet it was still a contributing factor. And because of the research and warnings delivered to Facebook before the genocide, they did know about the potential for misuse.

So, who is responsible? Facebook? Myanmar religious and military leaders? Nobody? Even today, nobody will take responsibility. But what we do know is that profit was placed over people.

Thus, we must demand for a freedom that delivers accountability and responsibility in a world increasingly defined and shaped by automated decision-making. We are already in a “catch-up” mode to the changing world in this regard.

3. Appeal a decision 🔗

No decision-making system is ever perfect. We are always missing some data. So, lastly, you should also have the freedom to appeal a decision that impacts you.

In your life, have you ever told a story to help someone empathize with your situation? Have you ever had to explain a misconstrued fact about your background or history? You are probably familiar with the phrase, “walk in someone else’s shoes”. Our ability to empathize and understand is what connects us as humans. It helps avert disaster more often than you think.

There are always hidden stories not captured by a set of data points. Thus, we should also have the opportunity to break through automated systems that influence an organization. We deserve the opportunity to appeal to the people behind the systems in order to use our humanity.

Resume/CV filtering 🔗

If you have ever applied for a job, you might be familiar with the importance of keywords and certain requirements on your resume or C.V. Automated tools already exist to review these documents and filter out candidates.

But what is the point of interviews? Where you talk with a real person? Interviews are a chance to tell our own hidden stories and explain the gap between what is on our CV and what is not. It gives us a chance to build empathy between us and who we want to be our employer.

Practical examples 🔗

It is not hard to look for examples of appealing systems in our society. Two examples are appellate courts and credit denials in the U.S.

Appellate courts are legal systems where we appeal decisions we think were unfair or incorrect. Sometimes this is because of an unfair trial. It could also be because of a biased judge. Either way, a system is in place to appeal a legal decision.

A similar system exists in the U.S. if you are denied a credit offer or loan. You can appeal to an impartial third-party if you believe a credit offer or loan was denied to you on unfair criteria. again, there is a system in place to appeal a decision that could have significant personal impact to you.

How else could we describe the freedom to appeal? We must not erase the opportunity for human connection and empathy when these decisions are made. Even by automated systems. To do so is to deny our humanity.

Where do we go from here? 🔗

The stakes have never been higher. These systems are being built not next year, not next month, not tomorrow, but now. These problems are not going to go away. They are only going to continue and grow. But we know we can imagine and have a better world, because we have to. The alternative is simply unacceptable.

The history of the Free Software movement left us clues about how to build a social movement to address problematic patterns in our digital society. So, let’s take the cues and demand for our Freedoms to be respected, just like those who came before us nearly 40 years ago.

If there is anything to take away from this post, or the original talk, it is this: me, you, and everyone has some power to make change. So, let’s build a future that we own, together, for everyone.

For more details and ideas on how we as individuals can protect these Freedoms and how to get others to respect these Freedoms, watch the full talk!

Why does this matter? 🔗

This exploration and thought experiment is important to understand when revisiting social movements in technology in the current day. In the FOSDEM 2020 talk Mike and I gave, we presented three possible digital “freedoms” for artificial intelligence. The rights-based approach we presented at FOSDEM 2020 was inspired by the origin of the Free Software movement.

But to understand how we got to today with thousands of contributors to the Linux project, billions of dollars in open source company buyouts, and the words “open source” used on mainstream cable news channels, we have to start from the beginning, in 1983.

27 Sept. 1983: GNU Project announced 🔗

On 27 September 1983, the GNU Project was announced by Richard Stallman. The GNU Project was a collection of Free Software tools for building a free operating system. But it was also more than that. The GNU Project came with a vision to give computer users freedom and control of their use of computers. To do this, the GNU Project advocated for four fundamental freedoms:

• Run software in any way desired
• Copy and distribute the software
• Study it (i.e. reading the source code)
• Modify it and make changes

Today, we call these the Four Freedoms.

So, the GNU Project was founded with these fundamental freedoms as the motivation for why they did what they did. It was more than shipping code for code’s sake, but to lead by example in how software could be developed without sacrificing the rights of users.

4 Oct. 1985: Free Software Foundation founded 🔗

Next, skip ahead to 4 October 1985. Two years after the launch of GNU, the Free Software Foundation (F.S.F.) is founded to support and sustain GNU and the Free Software movement. The values of the GNU Project were important and valuable, but it wasn’t enough to leave them out in the world on their own.

At first, the F.S.F. focused on employing software developers to work on Free Software and the GNU Project. Later, the F.S.F. transitioned to legal and structural issues to support the Free Software community.

So, it is one thing to have your values and ethics out there, but they need to be protected and respected by the rest of the world too. The F.S.F. represented the sustainability of protecting these rights and beliefs, originally put forth by GNU.

While the F.S.F. does help sustain those rights, how does a nonprofit foundation actually enforce these rights in practice?

25 Feb. 1989: GNU General Public License created 🔗

Finally, we skip ahead four more years to 25 February 1989: the first version of the GNU Public License (G.P.L.) is created. This is the license that gave “copyleft” a name. It was written and released for the GNU Project, but the license itself was stewarded by the F.S.F.

The G.P.L. put power in the hands of individual people and activists to shape how others used their software. Thus, copyleft is put into a practical legal policy. In a sense, the G.P.L. allowed software developers to place the Four Freedoms at the core of their code.

Although enforcement of copyleft licenses has a blemished history, it was still the “teeth” in translating these values and values to the rest of the world. It took inspiration from how copyright was not something often considered when distributing software until the early 1980s.

And thus, copyleft becomes a radical invention in software with the proliferation of the G.P.L., especially in its adoption in prominent projects like the Linux kernel.

Is the past relevant to social movements today? 🔗

So this was a lot of history. Is the past relevant to where we are today? First, consider how the early Free Software movement responded to these emerging societal issues in the 1980s.

Free Software was a response to the changing ecosystem of software distribution. Software became more valued because of a standardization on hardware that didn’t exist previously. There were simply fewer architectures to compile for!

Suddenly, the value of software increased. It became a commodity.

Before this commodification of software, the Four Freedoms were, in a sense, the default way of distributing and sharing software. After commodification, this was no longer true. The Four Freedoms were rooted in a belief that there are essential rights that belong to all users of computers and computer systems. Stallman observed this change directly at the MIT Media Lab in the 1970s and early 1980s. This motivated him and many others to stand up for Software Freedom by asserting these freedoms.

To respond to commodification of software, Free Software took a freedom-based approach to established their values, as the Four Freedoms. So, looking back 40 years ago, is it possible to extend and make the past relevant again in today’s changing world?

Before we can answer that, we have to first ask. How has the world changed?

Your future is the new commodity. 🔗

The history of Free Software overlaps with what is happening now.

Today the world is about predictions: predictions about human futures. This is accomplished by the combination of software and data. Human futures are a simple formula: Data + Software. Or, artificial intelligence and machine learning.

But how are human futures becoming a commodity? In the 1980s, software became the thing we “sold”. It had inherent value. Today, the ability to predict what you are doing to do next is valuable. This makes both your and my future the new commodity. Where will we go next? What will we buy next? Who have we contacted recently?

But data is only one piece of this big puzzle. It is the enabling force for determining our futures. Third-party organizations collect the world’s data on a massive, centralized scale. Your data is what allows companies to sell your future.

To add a metaphor, data is like oil, not gold. You consume the input (data) to sell the output (human futures).

Where are we today? 🔗

So, how have we responded to our changing world?

There have been some successful resistance to the new value of user data and human futures. The privacy movement and legislation like G.D.P.R. are representative of this.

However, data privacy is only one part of the big picture. Focusing on individual empowerment does not protect us from societal effects. Consider predictive policing and court rulings as two examples.

Ultimately, the data privacy movement has been a key factor in combating the effects of surveillance capitalism, but there are still gaps. Mike and I noticed we need to approach topics like artificial intelligence not in pieces, but as a whole.

And some organizations have recognized this challenge and are working to address it. “Working groups” and reports with non-mandatory recommendations are on the rise. However, these groups are not effective on moving forward ways of ensuring people are effectively protected from the unforeseen harms of AI systems. “Light self-regulation” works on an opt-in model, and it is against the interest of some actors to opt in.

So, if we are in the middle of this societal shift from software as a commodity to human futures as a commodity, where do we go from here? Do we choose chaos or community?

At time of publication, I am still wrestling with these questions. As are a lot of people! To get a wider picture of what is on my mind in 2020, read my event reports from my pre-coronavirus 2020 travels.

Photo by Shane Rounce on Unsplash.

This will be the second annual International Copyleft Conference. Participants from throughout the copyleft world — developers, strategists, enforcement organizations, scholars and critics — will be welcomed for an in-depth, high bandwidth, and expert-level discussion about the day-to-day details of using copyleft licensing, obstacles facing copyleft and the future of copyleft as a strategy to advance and defend software freedom for users and developers around the world.

This event will provide a friendly and safe place for discussion of all aspects of copyleft, including as a key strategy for defending software freedom!

Official conference website

This was my first time attending CopyleftConf. I attended on behalf of RIT LibreCorps to represent the sustainability efforts at the RIT FOSS@MAGIC initiative. However, I also represented myself as an individual in the Free Software movement. For CopyleftConf 2020, I arrived hoping to learn more about where we, as the Free Software community, are going. I also hoped to gain a deeper ethical perspective about our digital society.

Event reports take many forms. Since CopyleftConf 2020 is structured in a unique format, my event report is structured as follows:

• At a glance: structure and key takeaways: High-level overview of what CopyleftConf 2020 was like. What the biggest ideas on my mind were at the end of the day.
• Copyleft adopt curves: what drove copyright adoption then (or now?): Musings on the history of copyleft and movement building.
• Free Software, but for kids: Children and teenagers are already building open source communities. How do we include the next generation?
• Where are we going?: Software ethics and copyleft licensing.

At a glance: structure and key takeaways 🔗

If you’re here for the quick overview, this is it.

CopyleftConf 2020 is one of the best conferences I have attended. I bought my ticket the morning of the conference. Karen Sandler and Bradley Kuhn fired me up the day before in their FOSDEM 2020 talk. My initial reluctance to go was because I assumed it was a conference for FOSS lawyers. While it definitely includes that group, it isn’t exclusive to that group. CopyleftConf 2020 collected people from a diverse range of experiences and backgrounds in the open source world.

However, I also realized the “movers and shakers” in the Free Software world have been around a while. Many people there are embedded in this ecosystem for the last 10, 20, or even 30 years. I think I was the youngest person there. I realized Free Software has not done an excellent job of including my generation. This left me with interesting reflections on the future of copyleft and its ability to transfer lessons and values on to the next generation.

Structure: Dialogue and discussion 🔗

The best way to describe the format of CopyleftConf 2020 is “dialogue and discussion”. The first half of the conference started with traditional sessions, with speakers and slide decks. The end of the conference moved towards open panels with stronger audience participation. Most panels centered around topics or ideas addressed in the morning sessions.

I attended these sessions:

• Keynote (Tony Sebro)
• Copyleft adoption curves: what drove adoption then (or now?) (Luis Villa)
• Copyleft Expansion: What should – and shouldn’t – be on the table? (Deb Nicholson, Bradley M. Kuhn, Allison Randal, Heather J. Meeker, John Sullivan)
• The Rising Ethical Storm in Open Source (Coraline Ada Ehmke)
• Software Ethics and Copyleft Licensing (Karen Sandler)

I came up with three key takeaways from CopyleftConf 2020 as a whole (not including the detailed sections further below):

1. Open source is in an identity crisis. 🔗

Many people are confused. The confusion is simultaneously indecisive and divisive. I believe the identity crisis stems from that early decision in 1997 about what we call this particularly different way of developing and collaborating on software and technology. Free Software or open source? One is politically charged and historically exclusive, while the other is more neutral and business-friendly, and more inclusive to people who believe in compromise. Today, we are seeing a similar divide emerge between Free/Open Source and Ethical Source.

There are several emotions. It is deeply personal. For some, the promises of free/open source failed our collective humanity. For others, open source is a vastly successful turn of events to make the closed world more open. Yet for others still, it is both. CopyleftConf 2020 took a highlighter to this tension between what we consider right and wrong. It also questioned what the role of Free Software is in all of this.

I don’t think anyone has the answer yet. Surely some people left CopyleftConf 2020 with a more clear view if they think licensing is a viable approach or not. But CopyleftConf 2020 did not have this answer. It just made it clear that most of us are still wrestling with this.

2. Millennials are underrepresented. 🔗

Most of the time I was at CopyleftConf 2020, I had massive imposter syndrome. This is no fault of the conference or the great steps the organizers took to make it inclusive, but wow. There were so many people there who I have seen all across Twitter. People who are moving and shaking in different realms of the open source world.

Yet as I looked around the room, I started to wonder what the average age demographic of the room was. Being in my early 20s, I felt like I was in a room of Free Software giants. Many people there have been pushing the conversation forward and definitively fighting for Software Freedom for a decade or more.

And then there was me. I don’t know what my role or higher calling is yet in this great big movement we call Free Software. While I was glad to be in the room, I felt sorely underrepresented in age.

Born digital 🔗

I couldn’t help but find it unusual though. My generation and those after me are the first generations who were born into the digital society, built by those who came before us. When I was four years old, I was privileged to have my own computer. By six, I was connected to the Internet (even if it was dial-up). By fourteen, I was in a Linux command line running my own Minecraft server with thousands of players.

While my perspective is rooted in some privilege, there is something interesting in my experience. I was born into a world where I didn’t make the choices of what hardware or software I used. In the beginning, everything was handed to me or provided for me.

For kids and teenagers today, this couldn’t be more of a reality. Before COVID-19, when you went out to a restaurant or public place, how often would you see a small kid clutching a tablet, provided by an exhausted parent? Adolescents today grew up in the always-online worlds of Google and Snapchat.

Today’s teenagers and young adults I know are often keenly aware that they are the prey in a complex digital world they are already so deeply embedded in. So, why resist at all? To them, there is little point in resisting because all the technology decisions made for them early in life locked them deeper into this “predator-prey” ecosystem.

Is Free Software ready for the millennials? 🔗

So, I felt like an imposter at this conference of people who are wise to the role of Software Freedom in our new digital society, but never grew up in the kind of world I did. A lot of the people in the room at CopyleftConf 2020 developed their worldview, ethical perspectives, and software preferences as the world changed around them. Me and other people of my generation were born into this world.

It makes the conversation around Software Freedom very different, and also challenging, because the next ten and twenty years of Software Freedom will have to include today’s youth to be truly sustainable.

3. The world is changing. Will Free Software? 🔗

Related to the identity crisis and under-representation of youth, the theme of change begins to emerge. Stallman and other Free Software leaders in the 1980s and 1990s were ahead of their time to realize the importance of Software Freedom in respecting and protecting user freedom. Some of those same people were also in the room at CopyleftConf 2020.

But today’s world is changing. Software became the commodity in the 1970s and 1980s. Free Software was the resistance. Today, data is the new digital commodity. Software is just one piece of a bigger puzzle. Software Freedom may protect one aspect of our digital lives, but it would be nonsensical to assume the digital world would stay the same. Why should Free Software?

The 2020s will be definitive 🔗

So, CopyleftConf 2020 made me realize that the next ten years will be definitive. The 2020s will determine whether open source becomes yet another cog in strengthening our capitalist society and enthroning corporations as a great benefactor to technology, or if Software Freedom undergoes some sort of transformation to meet the new demands of freedom in our digital world.

No matter your political leanings, read any news site that isn’t a tech journal and tell me honestly that there are not some scary trends in our technology world. COVID-19 is just the latest example, with our data privacy and digital rights being on the sacrificial alter for our “safety” and “protection”. This line is all too common. I have heard it as a justification of many things across my life since September 2001.

So, what will Free Software do?

Copyleft adoption curves: what drove copyright adoption then (or now?) 🔗

Copyleft adoption has changed significantly over time, for better and for worse. This talk will survey the many factors that drive adoption, with particular focus on GPL v2 and Affero GPL v3. While some factors are obvious and reasonably well-understood (particularly the shift towards SaaS economics) many other nuanced factors play in as well.

Luis Villa

What I highlighted in my notes from Luis’s talk was his history lesson on adoption. While the history of Free Software wasn’t new to me, nor most people in the room, Luis took it in a different way. His history lesson was a reflection on “why?” and not just “what?”

Whether you think Free Software “won” or not, open source is here to stay. So, how did we get to where we are today? How did a famous software company go from calling open source an “intellectual property cancer” in 2001 to investing billions of dollars into open source and open source companies by 2020?

Add more chairs to the table 🔗

I loved this quote that Luis dropped: “Movement building is the only way to influence political change.” Luis gave examples from the 1990s of how evangelism and education were part of the building blocks of open source. There were “leading apps” that brought new people to the Free Software (or open source) table. Mozilla was the first browser that brought common lawyers in. A focus on education for lawyers, such as the F.S.F.’s 22,000 word F.A.Q., converted a motivation to learn into practical knowledge used for compliance work.

However, I think Luis’s goal was to define, not to prescribe. He implied that building a movement doesn’t start with writing a license, based on his personal experiences (he did lead drafting of the Mozilla Public License). My takeaway from Luis is that we need to think about how we build a movement that includes people who aren’t at the table today to build a strong foundation for what comes next.

Free Software, but for kids 🔗

There was a panel on copyleft expansion and what should and shouldn’t be at the table. At some point, the role of “the next generation” came up in heralding the values of copyleft licensing forward in light of the popularity of permissive licenses.

This was personal. My first experience in the open source world was as a community member and later a volunteer staff member of the largest open source Minecraft server software project. In my time in that community, I learned a lot. I saw a major breakdown of the GPL for a community of hundreds of thousands of young adults, teenagers, and children. So, indeed, how is “the next generation” going to herald these values of copyleft licensing?

Talk with us, not at us 🔗

It is interesting to be present in these conversations about “the next generation” because it usually feels like people are talking at me instead of with me. It took some reflection time to realize this after CopyleftConf 2020, but I feel like some older folks like to imagine that younger folks will come on board and just start steering the ship in the same course it has always traveled. Some younger folks may be fine with that.

But I also think a lot of younger people will ask more of Free Software because of our collective experiences with Free Software licenses. From my hey-days in the Minecraft community, there is bad blood towards the GPL and copyleft licensing because of the scars it left on the community, even if it was really because the GPL should never have been used in that context.

But the demands for more also stem from the collective treatment by those senior to us in traditional “FOSS circles.” Even at my university, I also see how students become bitter and frustrated in instances where senior faculty and older community members insist on a Free Software-first, no-compromises approach. As if it were so simple for my generation.

I already explained the perspective of younger folks earlier in this blog post. But the way some senior folks treat us in the proper Free Software world is sometimes exclusionary and off-putting, even if that isn’t the intention. It discards great opportunity for guidance and mentorship. There is an innumerable amount of times an older person completely dismissed my decision to use a proprietary or mixed-source platform for a community, yet they lament about not having the patience to troubleshoot the Free Software tools they rely on when they fail (mailing lists and email spam filters, I’m looking at you).

Teach early and teach often 🔗

But that point aside, let’s bring it back to the panel. I think it was Allison Randall and John Sullivan who emphasized the importance of early education around the concepts of Software Freedom. The average middle school student interested in STEM will not comprehend the GPL. However, the Four Freedoms (by design) are easy to comprehend. The freedoms to Read, Run, Remix, and Redistribute are not that difficult to understand. Perhaps part of the answer lies in how we think about messaging to younger folks and keeping foundational concepts like the Four Freedoms at the forefront.

I still lament over the way that Free Software built itself in a technology-centered way instead of a people-centered way, but I digress.

Where are we going? 🔗

The hottest discussions I participated in were from The Rising Ethical Storm in Open Source (Coraline Ada Ehmke) and Software Ethics and Copyleft Licensing, emceed by Karen Sandler. Coraline dropped absolute fire in her talk, even knowing that the essence of her talk would alienate some people. But it was a call-out to us folks in tech who consciously or unconsciously live these values that our Free Software movement is built upon: the freedoms of personal liberty, as it lends itself both for justice and harm.

I won’t spend a lot of time summarizing these talks and sessions, but one interesting thing to look up that Coraline mentioned was the Parable of the Locksmith.

During Karen’s session, I penned what ended up being a short speech in my notebook. When I was eventually passed the mic, I tried to fit too much into too little time, and I was not fully respectful of other folks who also had something to contribute to the discussion. So, instead, I will recap the full essence of what I wanted to say in my blog post.

Our software freedoms are not enough 🔗

The Four Freedoms, the foundation of all copyleft licenses, is not enough.

On the Saturday before CopyleftConf 2020, I presented at FOSDEM 2020 with my colleague and dear friend Mike Nolan on three new freedoms for AI that go beyond software. In our talk, we analyzed the history of how Free Software began as a social movement. It roughly flowed as follows:

1. GNU Project, 1983: Establishment of values
2. Free Software Foundation, 1985: Establishment of organization to champion the values
3. GNU Public License, 1989: Establishment of license to enforce and protect the values

In today’s complex and changing world, we need more than Free Software’s Four Freedoms. This libertarian base was susceptible to the co-opting of its values as “open source.” It was always inevitable, because Free Software was built from the strengths and biases of those who founded the movement (i.e. Richard Stallman).

Free Software was designed with technology at its center, not people. This is to say, it was poorly designed.

Now, we have an ethical dilemma that was always possible because Freedom means freedom to do as you wish, not the freedom of all people.

Some context for discussing legal issues is key, but we need to push the conversation forward beyond semantics. We need to identify whether unethical uses of our software is something we will tolerate. We can’t continue to ignore or delegate social responsibilities for what we do.

So, now what? 🔗

On one hand, we need to be ready to have these conversations about real effects and the impact of what we do on people. Look at the Facebook news feed and the Myanmar genocide. Legal semantics is where we are stuck since we defined the Four Freedoms. But these freedoms are no longer enough.

There is not one answer of where we are going. There are only multilateral answers. We have to be intersectional and inclusive for where we go from here. Free Software needs to turn to its allies not only in law and licenses, but also in labor organizing and regulation authorities.

One direction on my mind is continuing to support D&I initiatives like Outreachy. Outreachy interns do awesome things during their internships, and many continue to do awesome things even when their internships end. Bringing more diverse perspectives to the table, especially from underprivileged groups, is key to giving those perspectives equitable power and influence.

We do have the power. 🔗

But everyone in that room at CopyleftConf 2020, and you, the reader, have some power. We all have some room to influence change for good. But we cannot avoid the discomfort. We can not keep turning away our eyes.

So, what will you do?

For me, I am wrestling with that question actively as I continue to make my way out into the world.

Thanks folx! 🔗

To wrap up this CopyleftConf 2020 report, a few thank-yous are in order:

• Stephen Jacobs: For always being supportive for yet another trip abroad and helping me push my career forward in a number of ways (and footing the bill!)
• Mike Nolan: My co-conspirator, partner in FOSS, and comrade in arms
• Software Freedom Conservancy: For creating and holding this important space.

CopyleftConf 2020 continues to give me a lot to think about and consider. I’m fortunate to have attended. I hope this event report gives additional visibility to some of the conversations held in Brussels this year.

FOSDEM is a free and non-commercial event organized by the community for the community. The goal is to provide free and open source software developers and communities a place to meet to:

- Get in touch with other developers and projects;

- Be informed about the latest developments in the free software world;

- Be informed about the latest developments in the open source world;

- Attend interesting talks and presentations on various topics by project leaders and committers;

- To promote the development and benefits of free software and open source solutions.

fosdem.org/2020/about/

This is my third time attending FOSDEM. I attended on behalf of RIT LibreCorps to represent our engagement with the UNICEF Office of Innovation and the Innovation Fund. For FOSDEM 2020, I arrived ready to give my talk (coming in pt. 2) and honestly to see where the weekend took me.

Planning out FOSDEM is hard. So, my strategy is to figure it out as I go, since most of what I get out of FOSDEM comes from casual conversations and “hallway track.”

Sessions: Play-by-play 🔗

Event reports take many forms. My form is an expanded version of my session notes along with key takeaways. Said another way, my event report is biased towards what is interesting to me. You can also skim the headings to find what interests you.

Also, I live-tweeted several sessions of FOSDEM 2020, so some sections include tweet excerpts with pictures.

Building ethical software under capitalism 🔗

The software that is the easiest to build – the software that is the easiest to fund the development of – tends to serve those who are already extremely well-served. So, how do we bridge the gap between what society needs and what many people with money want to fund? Free and open source software platforms can get us part of the way there, but without some big changes, it won’t be enough. Let’s talk structure!

Deb Nicholson

Deb is making a regular appearance on my blog.

A foundational piece of Deb’s FOSDEM 2020 talk is something I started calling the “buck factor.” In 20 minutes, she gave context for the challenges of fundraising and achieving financial sustainability for open source projects with ethical missions. She also commented on the divides between “community” and “enterprise,” and how they are frequently on opposing ends of a spectrum.

Deb offered suggestions on how the Free Software movement can stand up and protect our shared values. Some are practical and others are aspirational, but I believe Deb aimed to get the audience thinking in different angles on this challenge:

• Encourage self-reporting within organizations
  • Build an ethical strategy inside an organization
• Labor organizing
• Build alternatives:
  • Community-driven non-profits
  • Worker-controlled options (e.g. worker co-ops)
• Advocate for policy changes (e.g. public utilities)

I also learned new vocabulary from Deb: rainbow/pink capitalism.

Growing sustainable contributions through ambassador programs 🔗

Open Source Program Offices are utilizing ambassador programs more and more. We’ll talk about why we decided to implement ambassador programs, how we implemented them, got buy-in (from a time and budget standpoint), and more.

Additionally, we’ll both talk about how we use this program to scale and reach thousands of developers internally. Also, we’ll throw in a few case studies and lessons learned throughout our (ongoing) journeys.

During this talk we’ll go over what an ambassador program is, how we decided to use them in our organizations, the path to buy-in and budget approval, how they were implemented, results we saw, and lessons learned. We’ll present specific case studies of how our Ambassador Programs helped with specific campaigns and how that fosters open source sustainability.

Shilla Saebi & Alison Yu

Shilla and Alison shared their experiences and advice in building open source ambassador programs at the Indeed and Comcast open source program offices (OSPOs). In the Community devroom at FOSDEM 2020, they introduced their ambassador programs, what goals and responsibilities of ambassadors were, and lessons learned from building their ambassador programs.

What is an ambassador program? 🔗

Ambassador programs were created in response to a growing need for decentralization in the OSPO. An OSPO team is a finite group of people with finite resources and time. To be successful in internally promoting open source, an ambassador program empowers others and builds open source allies across an organization. Similar to how technology must scale in order to grow, consider the “people” factor as something that must scale in order to grow.

When launching ambassador programs, both Indeed and Comcast planned multiple phases. In the beginning, it started with an exploratory pilot program phase. The OSPOs identified success metrics and transparently set a date to reevaluate program efforts. A small number of open source leaders inside each organization were invited to participate.

Then, over time, early success led to a gradual expansion phase. More people were recruited with an internal kick-off and training week. Each quarter, ambassadors received an events stipend to represent projects and the organization at local conferences and community events.

Who and what are ambassadors? 🔗

Ambassadors are like a “working group” of volunteers. They are champions and advocates of open source inside an organization or community. Ambassadors can be both internal and external: internal to a company or organization, but also external members of a community outside of a single organization.

But what kind of person makes a good fit for an ambassador role? There is no one-size-fits-all approach. However, Indeed and Comcast shared strategies they used to identify strong candidates for their ambassador programs:

• Prior experience contributing to an upstream project
• Already an advocate for open source (internally or externally)
• Willingness of managers to support participation
• Ability to pass an online learning assignment on open source

What do ambassadors do? 🔗

Responsibilities are different at different organization. Ambassador programs at Indeed and Comcast share three common ways to participate:

• Evangelize open source
• Participate in internal policy review
• Advise in license reviews

Additionally, a culture goal was to shift the perspective of open source away from “one and done.” Or rather, the OSPOs aspired to promote long-term contributions and partnerships with open source projects and their communities.

How to incentivize ambassadors? 🔗

Some people may fulfill ambassador responsibilities as part of their paid work. However, most people adopt a volunteer ethos. Ambassadors are not just colleagues representing open source inside an organization. They are also people with their own aspirations and goals too.

Personal development opportunities are effective incentives for participating. For example, an in-person training week teaches new skills to ambassadors based on areas of identified growth. Getting mentorship is also key to enable participation. Mentorship opportunities lower the “bus factor” of an OSPO. It also recruits ambassadors to identify colleagues doing unrecognized open source work. Instead of leaving them out on the fringe, bring them in as co-conspirators!

Additionally, organization-supported travel is one way to validate an ambassador’s time and effort. This furthers an ambassador’s careers by connecting them to more opportunities in the industry. They get the chance to build their network across other organizations, projects, and communities to facilitate inter-organizational collaboration.

Finally, ambassadors were incentivized through their ability to influence program direction. Ambassadors are empowered by contributing to the direction and strategy of the ambassador program itself. Inclusion is key, so ideas, suggestions, and criticisms from ambassadors are actually reflected in program policy. After all, they are the ones who are directly impacted by future program policy. As key stakeholders in the program, their voices are important to include.

Lessons learned 🔗

Shilla and Alison listed off some “lessons learned” and ideas on where to take their ambassador programs next:

• Ambassadors appreciated structure and knowing transparently how they are measured
• Needed more support from OSPO than originally expected
• More opportunities for feedback
  • Specifically, more 1x1 conversations
• Check for manager support at the beginning
  • Example: Employee gets manager approval to spend 10% of their paid time as an ambassador
• Schedule more ambassador community calls for access to OSPO and mentors
• Share more swag with ambassadors!
• Set clear expectations (or as clear as possible) in advance
• Provide more training opportunities for ambassadors
  • Open source is broad; many people have experience in some areas but could use mentorship/guidance in other areas
• Create stretch goals for ambitious folks to reach for

Future goals 🔗

• Provide internal resources to build allies in organization
• Create digital badges to identify organization/project ambassadors across the web and also internally
• Highlight/recognize ambassadors in visible ways
• Schedule mandatory 1x1 check-ins between ambassadors and OSPO mentors

Open source won, but Software Freedom hasn’t yet 🔗

Karen and Bradley, building on the substantial feedback from last year’s keynote, follow up their 2019 FOSDEM keynote with real-world suggestions, ideas, and discussion about how we, as software freedom activists, can live in a world with so much proprietary software. Software freedom is hard to find, but we can find it together, and we can support each other when we must face the proprietary software world and make hard decisions. Let’s figure it out together and support each other!

Bradley M. Kuhn & Karen Sandler

This was the most powerful talk I attended at FOSDEM 2020.

Kuhn and Sandler asked how we decide what is right for Software Freedom and how to increase the impact of our advocacy. Being a Free Software “purist” is increasingly difficult in our world. The Free Software movement must recognize the privilege of access. If the most underprivileged people are not included in our movement, we collectively lose the metaphorical “battle” of Free vs. Proprietary.

Resisting in 2020 is not the same as in 2000 🔗

Kuhn and Sandler state in no uncertain terms that resisting proprietary software is increasingly difficult. Sandler’s pacemaker is one of the most compelling examples. But from another perspective, the advent of “digital-only deals” is also common. Digital deals for a smartphone may not be essential, but what about grocery coupons on food? It is easy to avoid these deals if you’re well off. But it is less of an option if you live paycheck to paycheck. The savings have a bigger impact relative to you. Choosing data privacy means choosing a financial disadvantage. Choosing data privacy means losing out on saving money on essential goods. To protect personal privacy means to lose access to savings not available on any platform except proprietary software.

A follow-up question might ask why we cave to proprietary software where we do have some power as consumers. But not having access is embarrassing. There is social pressure designed into parts of our society that makes saying “no thank you” difficult. Sandler gave an example of Disney’s theme parks, where “Fast Pass” access is made available as a proprietary phone app that requires access to personal data in order to work. “Fast Pass” allows you to skip lines for rides and attractions. Explaining the principles of Software Freedom to children while waiting in longer queues is not a powerful appeal. While the Disney example is from a place of higher privilege, it is one perspective of many that shows power of social pressures that stigmatize choices that better protect us an individuals and consumers.

Stop shaming 🔗

Kuhn and Sandler made a powerful appeal. Stop shaming for using proprietary software. Start educating respectfully about software ethics. Free Software conferences sometimes trend towards being a proprietary dumping ground. However the Free Software community sometimes exists in a small bubble. In broader, societal terms, we are losing the freedom to choose Free Software. We need to put pressure on our companies and organizations to create the right kind of Free Software; that is, sustainable software that respects our freedoms by design. Our software is not sustainable unless it respects our Freedoms.

Design contributions to OSS: Learnings from the Open Design project at Ushahidi 🔗

Ushahidi builds OSS humanitarian tools, remotely for some of the most marginalized people across the globe. To tackle these systemic problems with how to ‘open source’ a design effort and bring the community along with the ‘on-staff’ Ushahidi designers, we’ve been piloting a series of design events on our OSS crisis communication tool TenFour with our partners Designit and Adobe. Together, we’re looking to solve the problems with how open source design can work by engaging through meaningful technology that makes a difference in the world.

In this session, we’ll briefly cover the history of the project and the main problems we attempted to solve and we’ll present the learning and adaptions to our workshop framework and methodology that aims to engage design teams and individuals that are not yet ‘on-board’ with OSS as an ethos or movement.

Eriol Fox

I had two useful takeaways from Eriol’s FOSDEM 2020 talk in the Design devroom:

1. Perception of “open source” in design world is largely undefined and unknown (because of systemic challenges)
2. Open source folks can learn more about what design work looks like when encouraging designers to participate

Open source perception 🔗

Eriol noted that most designers are in the dark about what open source is or what it can be. Open source is not included in design education. Also it is not incentivized in hiring for designers. If open source is poorly understood as a strength in the design community, how can designers use open source to build their CVs/resumes?

While they noted the root cause of this perception is systemic and difficult to change, it is helpful to weigh this perspective as an open source contributor. Developers and community managers should consider the systemic challenges when encouraging design contributions to an open source project.

For developers, open source is going mainstream. Without being prompted, you might be asked about open source in an engineering job interview. But it is different for designers. So you might have to “design” a different approach to effectively engage designers in our communities. (pardon the pun)

Learn what design work looks like 🔗

Open source developers, program managers, and community managers may have an uninformed view of what design work is. Eriol’s work in the Open Design project at Ushahidi included workshops with topics about how to construct tasks for designers and developers together.

Listening to their talk, I became conscious of my poor understanding of design work. I realize I have some areas to grow and improve my understanding of open design. Eriol gave some specific examples of design work I want to explore further:

• Empathy mapping
• Defining problems
• Ideation
• Storyboarding
• Sketching and prototyping

Also they gave a humanitarian-centered example of inviting a “witness” into the software design process. Or in other words, inviting someone part of the group that primarily “needs” the software. In the developer world, we are familiar with user testing or conducting focus groups and interviews. But those steps typically come after we have a product or design to get feedback on. Inviting a witness happens early, before much or any code is written. They bring a unique perspective of someone impacted by a particular problem or issue that the software will address.

I want to explore this one deeper. It takes more effort to practice active inclusion for someone who is a non-engineer to feel their opinions and perspective are useful and important in a room of engineers and product managers.

Twitter thread! 🔗

Did I live-tweet this one? You bet.

What makes people come and what makes them stay 🔗

Over the years the tech industry has been trying to change its diversity and inclusion statistics but that seems to have been a hard nut to crack. This is a talk about what makes people come, but then also what makes people stay. Because diversity is inviting people to the dance, but inclusion is enabling them to join it. Let’s figure out how you can make people come and want to stay in your organizations, and teams, and let’s see one use-case where Mozilla did the same.

Gloria Dwomoh

I meticulously live-tweeted this one. Check out the tweet thread below! There are lots of pictures too.

Beyond FOSDEM 2020 🔗

Of course, there is much more to FOSDEM than just a conference. Some highlights outside of the conference were my daily reflective breakfasts with Mike, a ramen lunch with him and Gloria Dwomoh, and evening dinners with Remy DeCausemaker, Georg Link, and Justin Dorfman.

Also, originally I intended to give myself the Monday after FOSDEM off to recover and work from home. However, I heard about this other little conference called Copyleft Conf happening the next day. So, I ended up buying a last-minute ticket for this one too! Read the details in my full event report!

Thanks folx! 🔗

To wrap up this FOSDEM 2020 report, a few thank-yous are in order:

• Stephen Jacobs: For always being supportive for yet another trip abroad and helping me push my career forward in a number of ways (and footing the bill!)
• Mike Nolan: My co-conspirator, partner in FOSS, and comrade in arms (HELL NO, MANIAC!)

I saw many familiar faces and also met many people I previously only knew from Twitter. FOSDEM 2020 takes a lot out of me, but it is always fulfilling to get a healthy dose of the Software Freedom perspective to fill me up on why I do what I do.

Until next time!

Learn about open source project health metrics and tools used by open source projects, communities, and engineering teams to track and analyze their community work. This conference will provide a venue for discussing open source project health, CHAOSS updates, use cases, and hands-on workshops for developers, community managers, project managers, and anyone interested in measuring open source project health. We will also share insights from the CHAOSS working groups on Diversity and Inclusion, Evolution, Risk, Value, and Common Metrics.

chaoss.community/chaosscon-2020-eu/

This is my second time attending CHAOSScon. I attended on behalf of RIT LibreCorps to represent our engagement with the UNICEF Office of Innovation and the Innovation Fund. For CHAOSScon EU 2020, I arrived hoping to learn more about effective metric collection strategies for open source communities and also get a deeper understanding of the technology behind GrimoireLab.

Sessions: Play-by-play 🔗

Event reports take many forms. My form is an expanded version of my session notes along with key takeaways. Said another way, my event report is biased towards what is interesting to me. You can also skim the headings to find what interests you.

Also, I live-tweeted several sessions of CHAOSScon EU 2020, so some sections include tweet excerpts with pictures.

Ethics: What You Know & What You Don’t Know 🔗

Metrics give us a lot of insight into what’s going on with our projects – but only if we have enough context. The catch is that personal biases and pre-conceptions are extremely hard to filter for so no one person can see everything. Those gaps means that even the most well-meaning of us could end up doing more harm than good. In this talk, I’ll share a few examples of the ways human brains make assumptions, some of our typical blind spots and how incomplete data can cause harm when deployed without any checks. For folks who collect, analyze and ultimately make mission critical decisions with metrics, the challenge is to constantly maintain a bit of healthy skepticism of what the numbers seem to be telling us.

Deb Nicholson

Deb’s session was a great opener to a day focused on metrics and automated reporting. Her talk underscored unconscious bias and the ways poorly-designed metrics fail us. We should take an active approach to questioning our perspectives and take suggestions with grace.

During Q&A, my colleague Mike asked for advice on pushing back on management when they ask for bad metrics. Deb suggested a clever strategy to respond in these situations:

1. Provide the metric asked for
2. Provide a metric that contradicts what was asked for
3. Provide the metric they should have asked for

Heat, Light, and Love: Telling Twitter’s Open Source Program Office’s Story 🔗

Making it simple to trust, ship, and grow open source at Twitter demanded visibility into contribution trends that were not readily available. Twitter’s open source program office and the Augur project collaborated with CHAOSS using student interns from Google’s Summer of Code, Twitter’s intern program and the University of Missouri. First, this talk describes Twitter’s engaging interface design and its fit to the needs of Open Source stakeholders within Twitter, but also outside the open source program office. Second, we describe how an open API and data collection tool, Augur, evolved in close collaboration with Twitter.

Sean Goggins & Remy DeCausemaker

This one inspired me. It represented a dream of mine for many open source communities. Sean and Remy presented on three years of building an automated metrics visualization site with GrimoireLab and Augur. The visualization was powerful to communicate the value of open source engagement, participation, and investment to internal and external stakeholders.

The work was based on a philosophy familiar to me from working with Remy years ago in the Fedora Project community:

If we are speaking in metaphors, one way to extend Remy’s “light” metaphor is tying in a theatrical concept: stage lights and backstage lights.

Stage lights are the metrics and insights to present out to the world. They are front and center! These insights validate your mission to an external audience.

Backstage lights are for an internal audience. These metrics and insights illuminate the inside of an organization and build understanding of who and what is there. These are useful to validate work and efforts to funders, or perhaps your CFO.

This talk served as inspiration for something I hope to explore later in 2020.

Measuring Culture 🔗

They say you can’t be certain of anything unless it can be measured – so what about culture? We know it exists and can be passed on to others, so there must be a way to measure it. Using Apache Kibble we attempt to look for cultural indicators at the Apache Software Foundation, set a cultural benchmark then match real Apache projects against it. In theory we would expect a perfect match but as the results show, culture isn’t that simple.

Sharan Foga

Sharan introduced five factors to measure culture: bus factor, contributor experience, contributor retention, sentiment analysis, and key phrase extraction.

Sharan defined culture as what we believe and what we do. So, she introduced five indicators for open source communities to measure culture. These came from learnings at the Apache Software Foundation’s Kibble project:

• Pony (“bus”) factor:
  • “Committership”
  • Authorship
  • Meta factor (# of organizations involved)
• Contributor experience / contributor retention:
  • People who (re)joined
  • People who quit (why?)
  • People retained
  • Active contributors
  • Cross the above over time (e.g. # of months/years involved)
• Mood, or sentiment analysis: Look for these moods…
  • Trust
  • Surprise
  • Neutrality
  • Sadness
  • Positivity
  • Anger
  • Negativity
  • Joy
  • Anticipation
  • Disgust
  • Fear
• Key phrase analysis: Understand community jargon (e.g. if “+1” is used to indicate agreement)

I had two key takeaways. First, nothing matches completely, so don’t over-rely on one factor or metric. Second, identify your baseline indicators and iterate on those. For the above indicators, maybe these are specific to Apache projects. Maybe they apply to your projects too… or maybe they don’t!

Meet Cauldron! Your SaaS Software Development Analytics solution 🔗

Cauldron is a brand-new free open source SaaS able to analyze software development community and processes. It relies on CHAOSS GrimoireLab to collect and process data from different tools used in software development such as git, GitLab, GitHub and/or social platforms like Meetup, and Open Distro for ElasticSearch to store and to display the project data. The talk shows how Cauldron can be easily put into action to analyze the software projects that matter to the attendees, and to get some CHAOSS metrics about them.

Jose Manrique Lopez de la Fuente

I had no written notes other than “wow!”

Finally, Bitergia built a hosted GrimoireLab service, called Cauldron. Cauldron takes the pain out of hosting your own GrimoireLab infrastructure. It is in early alpha and does not support all the data sources available in GrimoireLab yet, but it is promising.

In the FOSS@MAGIC community, we want GrimoireLab to understand our open source community at the Rochester Institute of Technology, home of the first academic minor in free/open source. But as I go deeper, I realize GrimoireLab is very complex. Since my contract with RIT ends in a month, I want to leave something sustainable for my successors. Cauldron seems like a valid option.

I have some homework to do!

Language barriers for open source contributors 🔗

While open source development is common across the world, projects from countries outside North America and Europe, such as China, have difficulties attracting international contributors. One major reason for this is language differences. The presentation provides an overview of the diversity of non-native English speakers in different open source ecosystems. Furthermore, we will provide results about whether or not those contributors face a language barrier when contributing to open source projects. The presentation concludes with a discussion on how we can create metrics to assess the spoken language diversity in open source communities and how to include those people in the community more easily.

Isabella Vieira Ferreira

Fascinating work from @isaferreira_57 on language barrier in #opensource. #choasscon

Contributing + participating in a project operating in a language (technical too!) that's not one's first always require more effort– a useful reminder to be kind and empathetic 💖💖 https://t.co/3cJ6qWWSsH

— Emmy Tsang (@emmy_ft) January 31, 2020

Isabella’s talk was insightful and challenged my unconscious bias. An interesting insight from two case studies was translators did not transition over time to software development contributions.

I believe a bias exists in open source projects with active localization communities. I have seen project leaders invest in localization efforts as one way to bring new people into a community. While it does bring new people in, there is a subtle implication that “bringing new people in” means bringing software contributions. That’s not always the case. Instead, the value of translation work needs to be quantified beyond just software contributions.

This is especially true for supporting grassroots advocacy communities. Localization may not build your developer community, but it can support stronger local communities in regions where English is not the first language.

Metrics are more than the sum of their parts 🔗

We are in a state of Community building that maps success to metrics like lines of code and GitHub stars. I would like us to explore where these metrics fall short on capturing the most significant value of a community, and how we can use other metrics to show the much larger impact Community organizations like Developer Relations (DevRel) can have on a business. This improved process begins with mapping value to business need, pairing it with a community need, and back to the business opportunities. There will be practical advice on how to pitch and position Community, whether you’re a Community Manager, Developer Advocate, or other Developer Relations professional.

Matt Broberg

Matt’s CHAOSScon EU 2020 session pitched strategy on communicating the value of developer relations to our organizations. He covered a lot of material and left me many thoughts to reflect on. I look forward to seeing the video recording of this talk to reflect further on integrating his ideas into my day-to-day. The themes of Matt’s talk struck a chord with me for challenging advocacy work ahead for me in 2020.

Emerging Tech Open-Source Scoring System (ETOSS) 🔗

This is a framework used by the UNICEF Innovation Fund, to evaluate and track the strategic position and growth potential of the early stage startups in its portfolio. The focus is on startups building open source frontier tech: Blockchain, Data Science, Artificial Intelligence and Extended Reality. It classifies the startups into four quadrants, based on two dimensions: the software developed (technology), and the financial sustainability of the project (business sustainability).

Cecilia Chapiro & Justin Wheeler

.@jflory7: The UNICEF tech KPIs are quite similar to @CHAOSSproj metrics - there are also business sustainability metric to measure, placing organisations / tech projects on a sustainable and tech scale... #CHAOSScon pic.twitter.com/e3M440FMS4

— yo yehudi stays away from humans! 🏳️‍🌈 (@yoyehudi) January 31, 2020

Interested in getting involved? Contact details for @jflory7 and @ceciliachapiro here! #CHAOSScon pic.twitter.com/jMsfiCK9Rg

— yo yehudi stays away from humans! 🏳️‍🌈 (@yoyehudi) January 31, 2020

@jflory7 thanks for the great talk, great to hear @UNICEFinnovate is actively funding OSS for the greater-good! #CHAOSScon pic.twitter.com/g81koSI4Ov

— Farbod Saraf (@farbodsaraf) January 31, 2020

#opensource rubric mentioned by @jflory7 at #CHAOSScon https://t.co/U2pIZsgrMz

It helped me evaluate the last proposal we received at @eLifeInnovation 🙌🙌

— Emmy Tsang (@emmy_ft) January 31, 2020

Hey, it’s me!

My colleague Cecilia Chapiro proposed a session for CHAOSScon EU 2020 on how the UNICEF Innovation Fund evaluates the health and success of funded open source projects. However, due to travel complications, she was unable to attend. I presented her slides and work on her behalf at CHAOSScon EU 2020.

Many people were excited, if not also surprised, to hear that UNICEF funds humanitarian open source. In Cecilia’s evaluation framework, there are two key areas: business sustainability indicators and technology indicators. There were good questions about how UNICEF measures on business sustainability. I hope to further explore GrimoireLab/Cauldron to better automate how we measure sustainability with industry-standard tools from the open source ecosystem.

I also gave a shout-out to RIT LibreCorps and the resources we maintain to help UNICEF and the Innovation Fund cohorts build and support sustainable open source projects.

Open and Reproducible Research with Community-driven Research Software Metrics 🔗

What do artificial neural networks, images of the black hole, and SETI@home all have in common? They all trace their roots to research software. In this session, we hope to explore metrics and best practices for evaluating open research software. Research software engineers are evaluated largely based on the numbers of publications and citations. However, metrics based on the number of publications encourage re-creating ‘new’ things or re-implementations instead of reuse, and there are huge variations in existing practices to cite software, meaning software isn’t always cited or citations aren’t always captured. Better metrics that reflect the health of research software is crucial to avoid gamification, incentivizing research software engineers to follow best software development practices by recognizing and rewarding their effort appropriately, and ultimately advancing open science and improving the reproducibility of research.

Yo Yehudi

Yo teamed up with Emmy Tsang and Mateusz Kuzak to deliver this session. I appreciated the audience participation in the second half, which was a creative idea for a session later in the day. It helped revive the conference energy!

Yo and the team captured excellent notes from their time across Brussels, so look there for a deeper dive if this is interesting to you.

Diversity & Inclusion Badging Program 🔗

Within IT, open source software exhibits some of the worst D&I. The open source survey run by GitHub states that only 3% of contributors to open source software are female (GitHub, 2017). While open source has made strides in some aspects of D&I, such as event inclusivity (Irwin, 2017) and community engagement to support organizational diversity (Alexander, 2019), work remains. The proposed is aimed at contributing to this positive growth through the development of a D&I badging system. In open source, badges are available for community leaders to publicly display, providing a way for projects to signal their attention to such things as community health and software security. We can draw from this badging work to improve D&I in open source. In this talk, I will discuss complexities associated with D&I metrics and propose a D&I badging system that provides open source communities the ability to make diversity and inclusion within open source projects more transparent.

Matt Germonprez

First, I must pay my full respect and gratitude to Matt for digging into this topic. It is hard. It is tricky. Nobody I know of is working on this. So, my feedback comes from a place of love because this is an important topic to me too, and I appreciate Matt’s work! Thank you Matt and the CHAOSS D&I Working Group.

Critique: Is a badging system how to do this? 🔗

Matt presented a strategy to incentivize organizations and projects to follow best practices for diversity and inclusion (D&I) through a badging system. Organizations embed a badge on their project website or README when following best practices. This provides an easy way for new contributors to understand if a project community is inclusive and values equality before contributing. Since best practices are defined not by a single organization, there is a way to measure if an organization is living up to their commitment to D&I.

However, a badging system seems like a difficult way to practically measure an organization’s commitment to D&I. There is a risk for manipulating trust of the system at the expense of open source novices. Novices have the least context and direct experience to see through an unauthentic commitment. Also, ongoing compliance seems difficult to enforce over time with a badging system. Maybe initially an organization or project is “checked off” for D&I best practices. But if project leadership or management changes, community culture can also shift. How do you account for change?

Instead of badges, perhaps a central, inter-organizational certification body makes more sense to achieve this goal. A certification body acts as a central authority for validating accountability. They also have an authority to assign (or revoke) public recognition of organizations and projects with authentic, ongoing commitments to diversity and inclusion.

There is potential here, but I don’t think gamifying D&I best practices with a badging system is the way. We need a long-term, human-centered process in evaluating D&I. We need to build in human-centered evaluation as a “feature” to truly hold projects accountable to their commitments.

Addendum: Events and inclusivity 🔗

There are a few things I’m genuinely proud to have contributed to open source. Most of them aren’t code. International candy swaps at conferences are one of those things.

Time for the international candy swap! There are so many things to love about #DevConf_CZ but the geographic diversity of attendees might be my favorite part. Thank you for organizing, @jonatoni & @jflory7! pic.twitter.com/rU1ETp5aTa

— Mary Thengvall (she/her); mary-grace.bsky.social (@mary_grace) January 25, 2020

DevConf CZ 2020 candy swap, mentioned in a previous blog post

Candy swaps are fun, informal events hosted during a conference. Attendees bring local candies, sweets, or snacks from their hometowns to the conference. For an hour or so, folks gather together to swap candies. Before sampling the sweets, everyone introduces themselves, where they are from, and anything special about what they brought with them. When everyone introduces themselves and their candies, the floor is open to sample from the collected assortment.

This is a fun and engaging way to get to know other attendees beyond the conference’s context. Conferences collect people around a specific context: be it technology, metrics, design, engineering, or something else. But beyond that specific context, we are also people! We have families, we have friends, and we eat food. We have things we miss about home when we travel hundreds or even thousands of miles from home. Events like candy swaps help us connect to other people not just as conference attendees, but as people. You learn something new about each other, and if you’re bold, you try something new too.

While it is not a metric in itself, it would be cool to see things like this included as practical examples of how to evaluate “family friendliness” or inclusivity at events.

True Confessions: The Seven Deadly Sins of Open Source Communities 🔗

This talk would take a humorous approach to explaining what really no one should do when managing and measuring open source community best practices, with the primary goal of instilling positive open source development practices to the audience. Such ““don’ts”” include not documenting anything, establishing no clear paths to success, and not bothering to communicate.

Brian Proffitt

Brian explained what to avoid in building healthy open source communities. While I was already familiar with most of them, the most interesting “sin” for me was the last one: “not seeing ourselves in others.”

Brian offered mitigation strategies and metrics for the first six sins, but he acknowledged “not seeing yourself in others” is hard to mitigate and measure. However, I think things like candy swaps (explained above) are one possible way to do this. They connect us to others in an authentically human way, beyond the specific context of a conference we traveled for.

This is more challenging when interaction is virtual. Virtual systems often take away communication cues that make us human! I’m still thinking on how to mitigate “not seeing ourselves in others” if interaction is mostly virtual. (For what it is worth, I don’t think running open source project meetings in V.R. is the answer either.)

Beyond CHAOSScon EU 2020 🔗

An event report wouldn’t be complete without mentioning the hallway track. It was great to see familiar faces and also meet new folks at CHAOSScon EU 2020.

I had a great lunch conversation with Erik Albers from Free Software Foundation Europe. It was cool to meet a facilitator of the Public Money? Public Code! campaign. Hopefully there are future opportunities to collaborate with RIT LibreCorps and AI freedoms.

As always, face time with Mike Nolan and an OG mentor of mine, Remy DeCausemaker, is appreciated and fulfilling. I wish I could get more of it around the year.

Thanks folx! 🔗

To wrap up this CHAOSScon EU 2020 report, a few thank-yous are in order:

• Cecilia Chapiro: Thanks for putting your work forward to the wider open source community!
• Stephen Jacobs: For always being supportive for yet another trip abroad and helping me push my career forward in a number of ways (and footing the bill!)
• Mike Nolan: My co-conspirator, partner in FOSS, and comrade in arms

I hope to continue conversations started here later into 2020 and keep talking with folks doing great things for the ecosystem. Until next time!

Sustain Summit events are led by a facilitator. There are no keynotes, talks, or sponsor demos. Your undivided attention is required. Phones and laptops should not be used throughout the day and you will be asked to put devices away if they are a distraction to you or anyone else.

When we talk about sustainability, we are talking both and equally about the sustainability of resources and the sustainability of its people. We hope you can join us for the conversation.

sustainoss.org/summit-2020/

This is my second time attending Sustain OSS (see my 2018 event report). I attended on behalf of RIT LibreCorps to represent the sustainability efforts at the RIT FOSS@MAGIC initiative, but also to represent myself as an individual and sustainer in the open source movement. For Sustain OSS 2020, I arrived hoping to learn more about community-first governance models. I left with a lot of notes and the first blueprints for Principles of Authentic Participation.

Event reports take many forms. Since Sustain is structured in a unique format, my event report is structured as follows:

• At a glance: structure and key takeaways: High-level overview of what the conference is like and the biggest ideas on my mind at the end of the day
• Community-first governance: I came ready to explore this idea, and had a unique conversation about citizen assemblies
• Principles of Authentic Participation: Impromptu session I facilitated, and thus spent most of my time focused on

At a glance: structure and key takeaways 🔗

If you’re here for the quick overview, this is it.

I loved Sustain OSS 2020 because it is a unique collection of people from various backgrounds in the Free/Open Source movement. Both old and new folks, software engineers and designers, open source program office folks and the FOSS lawyers, all together in one room. Perhaps the best part for me is leaving with a sense of empowerment and connection to a bigger movement of people.

Speed breakout sessions 🔗

The first half of Sustain 2020 started with speed breakout sessions led by many facilitators. There were around twelve small discussion groups focused on specific topics. You could spend 4-5 minutes at six topic groups. Choosing was hard! These speed sessions are primers on what to spend the second half of the day focused on, in a more detailed discussion.

I attended these sessions:

1. Diversity and inclusion
2. Open source movement in Africa
3. Minimum Viable Product: Good governance models
4. Documentation
5. 20 years of sustainability
6. Models for corporate accountability as open source community members / what does it mean to be a corporate member of open source communities?

Key takeaways 🔗

I came up with four key takeaways from Sustain OSS 2020 as a whole (not including the detailed sections further below):

Inclusion is local 🔗

When reaching out to new areas and demographics, include local community leaders. This is to say, if you are organizing communities in Asia or Africa, the success of your outreach campaign depends on your ability to enable and include existing community leaders in these regions. Local perspective is required for authentic grassroots success.

Rules for revising rules 🔗

When defining community governance or policy, expect change. So, include ways to change the rules later when the world changes around your governance or policy.

Generalists transition to specialists 🔗

In the early phases of an organization or project, community members are often generalists. Fewer people wear many “hats.” But context-switching has a cost. As the organization/project grows, defined roles become more important. Defined roles avoid everyone doing everything.

Designers focus first on design. Developers focus first on code. By specializing, you maximize the potentialities of what your team brings to the table.

We got the power 🔗

There was a breakout group about ethics in Free Software. Two emerging themes were creating ethics review boards at organizations and the power of labor organizing. Some suggested normalizing ethics training in employee on-boarding.

Most notably, there was a highlighted need for safer spaces for labor organizing discussions. Labor organizing comes at a high personal cost for many.

Community-first governance models 🔗

I came to Sustain OSS 2020 ready to explore community-first governance models. In December, I published a blog post on why Free Software is still not on activists’ agendas. Free Software outreach often emphasizes technology, not people or ethics. We focus on technology so much, we forget why this movement began in the first place. So, in a world where corporate interests in a project often conflict with interests of grassroots communities, I wanted to know what “community-first governance” really means.

For context, I consult with humanitarian organizations and non-profits that want to build community around their open source projects. But from personal experience, I realize community stakeholders need input to decision-making if the community is going to stick around.

Citizen assemblies in open source? 🔗

While I didn’t explore this in a session, I did have an interesting conversation with Xavier about citizen assemblies and how open source communities might be modeled after them. Xavier explained citizen assemblies to me as a form of hyper-local representation in policy-making in regional governments. For example, U.S. citizens are obligated to serve on jury duty, or a jury with your peers on a court hearing. Similarly for citizen assemblies, individuals are selected at random based on different demographic factors. Those selected serve a period of time on a local legislative body.

In open source projects divided across different contexts, think about the demographics represented in our communities. What might the demographic factors look like?

• In internationally-dispersed communities, it might be approximate region or nationality.
• In corporate-focused projects, it might be diversity of employers.

Citizen assemblies in open source could mean a group of contributors are selected at random to serve on the executive decision-making body of a community. The decision to serve is always optional. If a selected person declines, another person is selected.

I think this is a crafty way to address a cultural divide often present in Global South communities. Many contributors subconsciously look for an invitation to contribute. Being explicit by selecting an eligible, qualified candidate actively includes perspectives not commonly represented. It could also be a way to get around imposter syndrome and self-(non)selection in communities that use committee governance models.

I am still sitting with this idea. But I think Xavier’s idea of applying citizen assemblies to open source communities is valid. I’m interested in exploring what this model could look like in practice when the opportunity for experimentation presents itself.

Principles of Authentic Participation 🔗

I attended a session about corporate accountability in open source contributions. It evolved into a longer discussion about Principles of Authentic Participation. This week, I launched a wider discussion about this on the Sustain OSS Discourse forums, so instead of repeating myself in this post, read the Discourse thread and leave your thoughts there.

However, for the reader’s convenience, the six principles we drafted are below:

Authentic Participation Starts Early. 🔗

This came out of discussions about organizations showing up with mature, fully-baked contributions over which the community had no input.

Authentic Participation Puts The Community First. 🔗

This reflected the general consensus that when an organization and the community want different things, the community needs to come first.

Authentic Participation Starts With Listening. 🔗

This was Duane’s reflection of some comments about folks showing up to projects with no historical context and telling them everything they were doing wrong.

Authentic Participation Has Transparent Motivations. 🔗

Without a shared understanding of the motivations, it’s impossible to resolve differences of opinion effectively. No hidden motives.

Authentic Participation Enforces Respectful Behavior. 🔗

This is about organizations taking responsibility for the behavior of their representatives.

Authentic Participation Ends Gracefully. 🔗

No sudden withdrawal of resources without notification and an exit plan. Clear documentation that would allow the community to pick up projects when a company decides to withdraw support.

Thanks folx! 🔗

To wrap up this Sustain OSS report, a few thank-yous are in order:

• Stephen Jacobs: For always being supportive for yet another trip abroad and helping me push my career forward in a number of ways (and footing the bill!)
• Mike Nolan: My co-conspirator, partner in FOSS, and comrade in arms
• The Principles of Authentic Participation group: I didn’t plan to facilitate at Sustain and I was nervous about it, but you all were wonderful. We had a fruitful discussion and I’m looking forward to the follow-up.

Sustain OSS 2020 continues to give me a lot to think about and consider. I’m fortunate to have attended. I hope this event report gives additional visibility to some of the conversations held in Brussels this year.

DevConf.CZ 2020 is the 12th annual, free, Red Hat sponsored community conference for developers, admins, DevOps engineers, testers, documentation writers and other contributors to open source technologies. The conference includes topics on Linux, Middleware, Virtualization, Storage, Cloud and mobile. At DevConf.CZ, FLOSS communities sync, share, and hack on upstream projects together in the beautiful city of Brno, Czech Republic.

devconf.info/cz/

This is my third time attending DevConf CZ. I attended on behalf of RIT LibreCorps for professional development, before a week of work-related travel. DevConf CZ is also a great opportunity to meet friends and colleagues from across time zones. This year, I arrived hoping to better understand the future of Red Hat’s technology, see how others are approaching complex problems in emerging technology and open source, and of course, to have yummy candy.

Sessions: Play-by-play 🔗

Event reports take many forms. My form is an expanded version of my session notes along with key takeaways. Said another way, my event report is biased towards what is interesting to me. You can also skim the headings to find what interests you.

Diversity and inclusion meet-up 🔗

Would you like to meet other attendees who stand under the umbrella of “Diversity and Inclusion” or would you like a introduction into what Diversity and inclusion is and why it’s a good thing? this is the session for you! All are welcome!

Imo Flood-Murphy

This was a short, informal session ran by Imo to network and get a high-level introduction to diversity and inclusion in open source. Everyone in the room introduced themselves and gave a short explanation of who they were or what projects they represent. I appreciated the opportunity to meet others and better understand how Red Hat approaches diversity and inclusion.

A suggestion for next time is to allow more unstructured time for conversations. I think fun icebreakers get folks comfortable in a short amount of time to help make connections for the rest of the weekend.

Lessons learned from testing over 200,000 lines of Infrastructure Code 🔗

If we are talking that infrastructure is code, then we should reuse practices from development for infrastructure, i.e.

1. S.O.L.I.D. for Ansible.

2.Pair devops-ing as part of XP practices.

3. Infrastructure Testing Pyramid: static/unit/integration/e2e tests.

Lev Goncharov

Lev shared best practices on building sustainable, tested infrastructure. Infrastructure-as-Code (IaC) was important to how T-Systems scaled their infrastructure over time.

My key takeaways:

1. Smaller components:
   1. More sustainable
   2. Easier to maintain
   3. Easier to test
2. Ansible Roles encourage best use practices for Ansible
3. Spreading knowledge is essential (if nobody understands it, the code is broken)
4. Code review creates accountability
5. Use static analysis tools (Shellcheck, Pylint, Ansible Lint)
6. Write unit tests (shUnit2, Rspec, Pytest, Testinfra, Ansible Molecule)

Content as code, technical writers as developers 🔗

In the open-source project Kyma, documentation is an integral part of code delivery. We, the project’s Information Developers, believe that using the same tools and methodology as your good old code developers, we can create comprehensive and accurate documentation. During our talk, we’ll share the whys and hows of our approach, showing you that the “developer” in “Information Developer” isn’t there just because it sounds cool. We’ll prove that creating documentation goes beyond linguistic shenanigans and salvaging whatever information there is from a trainwreck that is the developer’s notes. Testing solutions, finding our way around Kubernetes, tweaking the website, engaging with the community are just a few examples of what keeps us busy every day.

Barbara Czyz, Tomasz Papiernik

“Information Developers” is a cool phrase I learned. Barbara and Tomasz explained the value of technical writing and asserted documentation should live close to project code.

My key takeaways:

1. Documenting processes like release notes enables others to join with less barriers
2. Docs-as-Code (DaC): Visibility of docs across development process is important
   1. Placing docs with code encourages feedback loops and avoids silos
3. Put links to docs in visible places (e.g. API messages, console messages)
4. Management aside: Emphasize/incentivize value of technical writing in your team
5. Remember bridges across skill areas is possible (technical writers can also be community-oriented people too)

Uncharted waters: Documenting emerging technology 🔗

We can’t help but feel the lure towards the hot new thing, especially when it comes to technology. Part of that lure is the breaking of ground, venturing into the unknown, and working on solutions to new problems. But a lot of the same things that make emerging technology fun and exciting to work on are exactly why it can be difficult to document. These challenges are quite different to those associated with mature products.

This talk is for anyone working on new products and emerging technology, or just interested in learning about fast-moving documentation. It is for the developer as much as it is for the writer, since it usually falls to them to write the early docs before a writer is added to the team.

Andrew Burden

This was the talk I didn’t know I needed to go to.

Lately I work with “emerging technology,” which means different things to different people. Regardless of what emerging tech means to you, Andrew focused on how to write documentation in a fast-paced environment with “pre-release” technology, where things change fast and suddenly. Normally this is an excuse to not write docs, but Andrew showed, yes! It is possible to write good docs, even when context changes fast and often.

Key considerations of fast-paced technical writers 🔗

An even balance of these considerations helps get into a user’s mindset:

1. Scope / scale of release
2. Release schedule
3. Developer meetings / face-time
4. Exposure with $TECHNOLOGY
5. Deployment experience with $TECHNOLOGY

Surviving the information wall 🔗

The “information wall” is the endless wall of information and things to know about a project. If information is endless, how do technical writers survive?

• Take notes: Be like a scientist
• Take notes about your notes
• Be organized with your notes

Obviously Andrew was getting at the value of note-taking. Practicing note-taking skills is critical to keep up with the pace of change.

“Multi-Version Syndrome” 🔗

Sometimes you are writing features for things that will not be released in the next release. There is a risk of losing information across multiple releases (e.g. publishing the wrong thing too soon, or the right thing too late). Clarify the release schedule as you go. A good safeguard against losing information is to rigorously understand release cycle cadence and priority.

If your product isn’t mature yet, anticipate change instead of avoiding it.

Access to technology is critical 🔗

Technical writers are often User 0. To understand the technology, you need access. There are interactive and non-interactive ways of getting access. Interactive ways are preferred because they are always reproducible.

• Interactive
  • Deploy your own
  • Get someone else to deploy it for you (but lose install context)
• Non-interactive
  • Live demos
  • Demo videos
  • Asciicinema (CLI-oriented)

Other takeaways 🔗

• Screenshots have high maintainability cost; avoid if possible
  • Sometimes good stop-gaps until something more maintainable
• Where to begin? Make a table-of-contents for the Minimum Viable Product
  • Never underestimate outlines (ahem, like how I wrote this blog post…)
• Avoid documentation scramble near release day:
  • Make lists / check-lists
  • Take more notes
  • Pre-release checklist
  • Think now, and for the future
• Audit your docs: On-boarding new people is a powerful opportunity to test out your docs

Thanks Andrew for a deep dive on this narrow but important topic.

Community management: not less than a curry 🔗

Every volunteer joins an Open Source community for a reason. The reasons could range from technical gains to finding his/her/their passion. This community of diverse volunteers require a leader who can not just mentor them with their interests but also a manager managing the community activities in terms of community engagement and planning. A community manager is not less than a candle of light and in this presentation, I would be highlighting my learnings and experiences about starting a community from scratch around a project and maintaining a healthy community management practices.

Prathamesh Chavan

Prathamesh designed an activity to help the audience understand community management. My key takeaway was community management is about connecting and understanding others as their authentic self.

In the activity, Prathamesh passed papers and pens to the audience. His session had three steps. Between each step, all attendees traded papers with another attendee:

1. Define a project idea (why, how, what)
2. Identify challenges to idea (i.e. questions)
3. Answer challenges

It reminded me of a similar workshop I attended before. This inspired me to work on my own workshop idea for a future conference.

Cognitive biases, blind spots, and inclusion 🔗

Open source thrives on diversity. The last couple of years has seen huge strides in that aspect with codes of conduct and initiatives like the Contributor Covenant. While these advancements are crucial, they are not enough. In order to truly be inclusive, it’s not enough for the community members to be welcoming and unbiased, the communities’ processes and procedures really support inclusiveness by not only making marginalized members welcome, but allowing them to fully participate.

Allon Mureinik

Allon recognizes the importance of diversity, but asking for improved diversity is one side of the coin. A friend recently shared a powerful quote with me: “If diversity is being invited to the party, inclusion is being invited to dance.” Allon’s message was to dig deeper on including marginalized people in our project communities.

He identified ways we accidentally make our communities less inclusive because of our cognitive/unconscious biases. Everyone has blind spots! Allon suggested ways to be more conscious about inclusion in open source:

• Knowledge barriers
  • Procedural knowledge, not just technical
    • How do you submit code? File a bug? Make meaningful contributions? These need to be documented
  • Documentation fosters inclusivity
• Language barriers
  • Working proficiency in English not universal
  • Conversations have extra barriers (e.g. communicating complex ideas, understanding advanced words)
• Time barriers
  • Work schedules no longer 9 to 5
  • Remember other folks in different time zones
  • On giving feedback: Fast is not a metric! Be smart
    • Merging PRs while others are away, or shortly after opening it
    • Allow time for input on non-trivial changes
• Transparency barriers
  • If not in the open, it didn’t open
  • Negative example: Contributor makes a PR, reviewer has face-to-face conversation with contributor, reviewer merges PR without public context
  • Default to open: in many ways
    • If you can’t be open, at least be transparent

Diversity in open source: show me the data! 🔗

How diverse is your work environment? Diverse communities are more effective, they allow us to share the strengths of the individuals who make up the community. Have you ever looked around and noticed that most of our Open Source communities are predominantly male? Why do you think that is? We’ll use gender diversity as a case study and share some intriguing data points. Let us convince you why it’s so important.

Regardless of your gender, we would love for you to join us! We will also give you some tips on how you can make a difference.

Serena Chechile Nichols, Denise Dumas

Serena and Denise divided the talk into two sections: metrics and action. The way they presented, they brought the audience on the same page by visiting a variety of metrics and then transitioned to an empowering discussion about changing trends we see.

Next time, I hope to see expanded messaging by defining diversity beyond only women. Diversity was frequently tied to gender participation metrics in open source. While women are underrepresented, there are additional aspects of identity that can compound discrimination. Race, socioeconomic status, nationality, sexual orientation, and more also play a part in understanding challenges collectively faced in inclusion work.

The data 🔗

• Gender differences by # of contributors:
  • GSoC 2018: 11.6% female-identifying contributors
  • OpenStack: 10.4% female-identifying contributors
  • Linux kernel: 9.9% female-identifying contributors
• U.S. Dept. of Labor: 22.2% of technical roles filled by women
  • 2014-2019: More women entering tech jobs at companies like Apple, Microsoft, Google, etc.
• Years of experience by gender (<9 years):
  • 66.2% female
  • 52.9% non-binary/queer
  • 50.1% male
• GitHub user and developer survey:
  • 95% male
  • 3% female
  • 1% non-binary

Let’s make things better 🔗

Serena and Denise asserted diversity creates change. All changes come with challenges. Diversity can increase the friction in the process, but that is okay. They emphasized the need for multiple perspectives see past our initial biases (conveniently covered by Allon in the previous talk).

This transitioned to questions, comments, and thoughts from the audience. One interesting point was using the phrase, “we don’t do that here” to create and set norms. I gave a suggestion to look at projects you already participate in and see if there is a diversity and inclusion effort there already. If there is, see if there are ways to help and get involved. If not, consider starting one (or network with the Open Source Diversity community).

To wrap up, one recurring theme of Serena and Denise’s talk is to make time to step back and evaluate the bigger picture. Questioning our biases is an important skill to practice. We need the space and time to recompute!

Candy Swap 🔗

Do you have a unique sweet dessert or candy from your country or hometown? Do you love to try new and exciting foods from around the world? Spend an hour with fellows as we share stories and candies from the world with each other. Participants are invited to bring a unique confectionary or candy from their country or city to share with multiple other people. Before going around to try yummy things, all participants explain what item they bring and any story about its origins or where it is normally used. After sharing, everyone who brought something rotates around to try candies brought by others. After all participants have had a chance to sample, the rest of the community is invited to come and try anything remaining.

Jona Azizaj, Justin Wheeler

I am biased when I say this is one of my favorite parts of conferences I go to. Jona originally proposed the candy swap for DevConf CZ. After unexpectedly adding DevConf CZ to my travel list for 2020, we teamed up to share the sweet tradition from Fedora Flock to DevConf CZ! This is one of my favorite conference traditions because I get to know other attendees in a context outside of technology. And food is always an easy way to win me over.

Instead of listening to me, see what other people have to say about it:

Time for the international candy swap! There are so many things to love about #DevConf_CZ but the geographic diversity of attendees might be my favorite part. Thank you for organizing, @jonatoni & @jflory7! pic.twitter.com/rU1ETp5aTa

— Mary Thengvall (she/her); mary-grace.bsky.social (@mary_grace) January 25, 2020

The "sweetest" activity of #devconf_cz: Today at 3 PM! 🍬🍫
Join Candy Swap, share candies, sweets and stories with others from around the world! https://t.co/OlfdmgGa3a pic.twitter.com/Jnlqi3lsaq

— DevConf.CZ (@devconf_cz) January 25, 2020

Candy Swap time at #DevConf_CZ 😍 pic.twitter.com/zFCNnXZoJf

— Jona Azizaj👩🏻‍💻 🥑 @jonatoni@mastodon.social (@jonatoni) January 25, 2020

Well I experienced this for the #Flock 2019. It's a great opportunity to know the tastebuds of diverse people and enjoy! :D

— Aal (Alisha)🌻 (@withloveaal) January 26, 2020

From Outreachy to cancer research 🔗

Outreachy program is helping women and other underrepresented people to make first steps in tech career. Picking a project, making first open source contributions, working on assigned project and learning from advanced people. But what happens when this three months are over? Can Outreachy be a lifechanging experience?

I will share my story of conversion from a chemist and full time parent into a Fedora Outreachy intern and how I found my place as a junior software developer in cancer genomics research at IRB Barcelona.

Lenka Segura

This was a favorite of the weekend. “Fedora Outreachy intern Lenka Segura on how Outreachy opened the door for her career to cancer research at IRB Barcelona!”

I put effort into live-tweeting a Twitter thread. Get the full scoop there!

Connect and grow your community through meetups 🔗

Open source communities collaborate in a multitude of ways - chatting on irc, submitting issues and contributing code on GitHub, discussing and sharing ideas on reddit and other social channels. Face to face gatherings add another dimension to that, where community members can learn and share their experiences. Local meetups provide a venue for people with similar interests to socialize and connect. However, organizing meetups is not trivial. How do we encourage and motivate the community to arrange meetups, and to keep the momentum? In my one year with the Ansible community, we have doubled the number of active meetups in Europe. These meetups are community driven, rather than Red Hat. Find out how we use metrics to analyze the situation and needs, and the steps we are taking to reach our goals of connecting with even more community members. Learn from our mistakes and challenges (100 RSVPs and only 20 turned up?), plus some tips to make your meetups more inclusive.

Carol Chen

Carol explained the role of local meet-ups around the world in building communities around software projects. She emphasized that single metrics are not always useful, so it is more helpful to evaluate on multiple areas. The most useful takeaway for me was the 5 W’s: why, who, what, when, where.

• Why? Common curiosity (noticing something new in your community)
• Who? Connections and networking
• What? Concise, compelling content
  • Consider venue travel (how to make it worth their while?)
  • Provide alternatives to git-based submissions
  • All talks don’t have to be technical! Diversify to appeal to wider audiences
    • Announcements for future events, work-life talks
    • We are more than just the technology we work with
• When? Consistency
  • Helps with venue scheduling
  • Helps retain attendee focus and build habits

Carol also gave suggestions for common points to think about for improved inclusion. All of these need active, not passive inclusion.

• Special needs / disabilities
• Food allergies
• Beverage preference (often alcohol/non-alcoholic)
• Language
• Traffic-light communication stickers
• Photography lanyards
• Gender pronouns

Beyond DevConf CZ 🔗

While the sessions are excellent and fulfilling (and sometimes frustrating when you miss a good talk with a full room), DevConf is also more than the sessions. It’s also the people and conversations that happen in the “hallway track.” It was nice to see many old friends and make new ones.

I spent a few extra days before and after DevConf CZ in Brno. In some of that time, my colleague Mike Nolan and I rehearsed in-person for our FOSDEM talk the following weekend (to come in a future blog post). I also enjoyed coffee and waffles with Marie, Sumantro, and Misc!

A few memories of a great week in Brno

Until next time! 🔗

I learn a lot and have a lot of fun at DevConf CZ. I’m happy to return for a third year. Hats-off to the organizers and volunteers who pulled it all off. Each year, DevConf gradually makes improvements. It’s nice to see inclusion prioritized across the board.

Thanks also goes out to RIT LibreCorps for sponsoring my trip. Extra thanks to Jona Azizaj!