This post is also an experiment in using AI generated summaries to provide useful, at-a-glance summaries of key Fedora topics. Parts of this content may display inaccurate info, including about people, so double-check with the source material.

Source material: discussion.fedoraproject.org/t/report-from-infra-and-releng-hackfest-at-flock2024/128743

Key Topics 🔗

• Standards for OpenShift app deployments: There’s a need for consistency in deploying applications to OpenShift. The group discussed creating best practices documentation and addressing deployment methods across various applications.

• Infra SIG packages: The workshop reviewed the “infra-sig” package group and identified a need to:

  • Find owners for orphaned packages.

  • Onboard new maintainers using Packit.

  • Remove inactive members from the group.

• Release engineering packages: The group agreed to add a list of release engineering packages to the infra-sig for better management.

• Proxy network: Discussion about potentially migrating the proxy network from httpd to nginx or gunicorn remained inconclusive. Further discussion is needed.

• AWS management with Ansible: The feasibility of managing AWS infrastructure with Ansible is uncertain due to limitations with the main Amazon account.

• Onboarding improvements: The group discussed ways to improve the onboarding process for new contributors, including documentation updates, marketing efforts, and “Hello” days after each release.

• OpenShift apps deployment info: A tutorial on deploying applications to OpenShift was presented and will be incorporated into the documentation.

• Future considerations: The group discussed upcoming challenges like GitLab Forge migration, Bugzilla migration, and a new Matrix server.

• Retiring wiki pages: The group needs to decide where to migrate user-facing documentation from the wiki. Additionally, someone needs to review and archive/migrate/delete existing wiki pages in the “Category:Infrastructure” section.

• Datagrepper access for CommOps: A solution was proposed to provide CommOps with access to community metrics data by setting up a separate database in AWS RDS and populating it with recent Datagrepper dumps.

• ARA in infrastructure: While AWX deployment offers similar reporting features, setting up ARA remains an option if someone has the time and interest.

• AWX deployment: Roadblocks related to the public/private Ansible repository structure were identified. A proof of concept using AWX will be pursued to determine if repository restructuring is necessary.

• Zabbix integration: The group discussed moving forward with Zabbix to replace Nagios. Action items include setting up a bot channel for alerts, adjusting alerts based on comparison with Nagios, and considering an upgrade to the next LTS version.

Action Items 🔗

• Create comments in each application playbook explaining its deployment method.

• Move all apps using deploymentconfig to deployment with OpenShift 4.16.

• Look into deploying Advanced Cluster Security (ACS) for improved visibility into container images.

• Create a “best practices” guide for deploying applications in OpenShift clusters.

• Find individuals interested in helping with orphaned packages and onboarding new maintainers for the infra-sig package group.

• Create a list of release engineering packages for inclusion in the infra-sig.

• Continue discussions on migrating the proxy network and managing AWS infrastructure with Ansible.

• Update onboarding documentation, implement marketing strategies for attracting contributors, and organize “Hello” days for new members.

• Archive/migrate/delete wiki pages in the “Category:Infrastructure” section.

• Work on tickets to set up a separate database for CommOps Datagrepper access.

• Investigate the feasibility of setting up ARA in infrastructure.

• Stand up a proof of concept for AWX deployment and discuss potential repository restructuring.

• Set up a Zabbix bot channel for alerts, adjust alerts based on comparisons with Nagios, and consider upgrading to the next LTS version.

Overall, the workshop was a success, with productive discussions and a clear list of action items to move forward.

Note: The workshop lacked remote participation due to network limitations. The source material encourages readers to express interest in helping with the action items.

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!

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!

The shared context is the most valuable piece of the conference. As a first-time attendee, I was blown away by the depth and range of topics covered by attendees. This blog post covers a narrow perspective of Sustain OSS through the sessions I participated and co-facilitated in.

Speed breakout groups 🔗

The morning started with speed breakout groups of between six to twelve people. Several attendees acted as facilitators for discussion on special topics. Every attendee could about half of all groups. I took extensive notes in the following groups:

• Charitable participation in open source
• Diversity and inclusion
• Turning open source projects into sustainable projects / companies
• Design in open source
• Open source financial sustainability models

Sustain OSS: High-level takeaways 🔗

To save you time, these are my high-level takeaways across all breakout groups I participated in:

• Open source isn’t something just done in people’s free time

• Complex systems can enable systemic bias in terms of what “open source” means

• Sustainability as topic of first priority / consideration, not an afterthought

• There is no “silver bullet” solution to any of these challenges; they all require adaption to work across communities, projects, and organizations

Charitable participation in open source 🔗

This breakout group focused on the connection between charitable organizations and free software projects. It was facilitated by the esteemed Karen Sandler of the Software Freedom Conservancy.

Overall, the conversation was split among creating ethical software, finding sustainable funding models, and balancing how much control to relinquish as a managing organization of an open source project. Some felt pride and ideology were strong drivers for contributors to ideological projects (which also mirrors my experience at UNICEF). These could be key motivations to understand for contributors. Additionally, the challenge around sustainable funding models was common across charitable foundations focused on free software. Grant funding is a common strategy employed by charitable organizations, but the short-term nature of grants puts additional strain on resources to continue searching for new funding. Lastly, for charitable organizations overseeing or supporting free software projects, there was uncertainty over how much control should be left to projects. Attendees generally expressed a desire to let projects do what they want, but it sometimes came at the risk of additional overhead for the organization when everyone does something of everything. The concern over toxic communities came up, and how some issues remain buried until farther along in a relationship with a project. One successful solution employed was to hold monthly meetings among all member projects of an organization to address difficulties.

One interesting detail that captured my attention: one attendee noted how extensive effort into fundraising campaigns targeted to members of a foundation actually increased member engagement with the foundation.

Diversity and inclusion 🔗

My biggest takeaway from this session was the danger in thinking of open source as something we do in our free time. This can be exclusive to different genders, races, and socioeconomic statuses. Some “free time” is more equal than others. The actionable piece for me is to be more conscious in building and growing communities to support different levels of contribution in a community.

The question I wanted to explore after reflecting is to ask of those who feel disadvantaged:

• What factors makes a project more or less inviting for you?
• What can we do better when designing for participation in our communities?

Turning open source projects into sustainable ones 🔗

My notes weren’t thorough on this session, but there was an interesting point on trademark that came up during discussion of the Commons Clause. One participant was pursuing trademark law to enforce commercial protections and sustainability. They gave an example of a large corporation advertising support with a major open source project (e.g. a major software/hardware vendor supporting a specific NodeJS version). They wanted to use this as a way to create a more financially sustainable model for some projects.

Design in open source 🔗

This breakout group focused on sustainable design and design practices in open source communities. The role of designers in technical projects was also discussed and how we can build technical communities to be more inclusive for designers. It was facilitated by Elio Qoshi.

My takeaways from this breakout were that established ways of working can be unfriendly to designers and there is a need to emphasize diversity across different roles in a project or organization. Certain tools, platforms, or other mechanisms for contributing have poor user interfaces. They can push people away because of barriers to contributing with a frustrating user experience. Next, the need for diversity in roles was noted, with an example of engineers leading project management. Sometimes bias or oversights afforded as an engineer accidentally excludes others like designers or writers from contributing to our project. We should endeavor for people to spend more time on their preferred and most effective methods of contribution.

Financial sustainability models 🔗

This breakout session focused on the traditional sense of sustainability: in finances and resources. Attendees discussed different models used to fund open source projects and foundations. The session was facilitated by the founder of the MusicBrainz project, Robert Kaye.

The model used by MetaBrainz essentially as a data broker was interesting and unique. MetaBrainz offers commercial data usage at a cost, and companies using their data have a strong need for the data and see value in it. Through other parts of their model since changing three years ago, they had significant gains in their revenue and were able to increase paid staff working on the projects.

The Amazon invoice cake is also an amusing story, but you should ask Robert directly about it.

Hour breakout sessions 🔗

After lunch, attendees participated in two hour-long breakout sessions to explore specific topics in greater detail.

Human aspect of governance 🔗

Longer form notes are available below. I won’t go into detail since it has its own document with notes and highlights.

Human aspects of open source governance - Sustain OSS London 2018Download

University engagement 🔗

Together with Josh Greenberg of the Alfred P. Sloan Foundation, we co-facilitated a spontaneous session on how universities can engage with open source communities and vice versa.

In our session, two major topics were discussed:

• Education (e.g. curriculum, institutions, programs, etc.)

• Research

We asked all participants why they decided to participate and what questions they had, even though we weren’t able to answer all of them:

1. How do we get the word out?
2. What research is most valuable for open source?
3. How to long-term sustain projects?
4. How to actually do and support research?
5. How to engage both students and faculty?
6. How to harness / enable institutions to make positive contributions to ecosystem?

For education, we agreed that introducing and teaching open source in curriculum better serves students and the institution (both financially and in career satisfaction). Many technology companies today are participating in open source and it is an important skill to have for students entering the workforce. For research, students are already doing research and proposing topics, so better student engagement in open source is better for research.

Our takeaways were to better engage with existing organizations working on these problems for years already (e.g. POSSE), shifting the perspective of universities to be stewards of FOSS, and using collegiate hackathons as a way to better engage with undergraduate students.

One additional point that stood out to me was the emphasis across all breakout participants for a need of good communication skills to be successful. In many cases, the companies hiring top tech talent (from our breakout attendees) listed this as most desirable skill. Technology and new skills can be learned, but teaching good communication skills and how to work collaboratively are not easily learned.

Other takeaways 🔗

One takeaway I couldn’t fit elsewhere was my changed perspective on “technical” vs. “non-technical” work. The phrase “non-technical work” implies an “other space where development does not occur”. Does the phrase place unequal priority on technical work? One action item is to avoid using “non-technical work” as an umbrella term, and instead call these areas by what they are: design, documentation, writing, marketing, community building, etc.

For me, I still want an umbrella term for these things, but I’m open-minded for better alternatives to non-technical.

Skill share: conflict resolution 🔗

The last event of Sustain OSS was a 1x1 skill share. Roughly half of the attendees identified a “skill” they could teach someone else in the room. The other half of attendees paired with someone teaching a skill they wanted to learn more about. I paired with Jono Bacon on a short breakout on conflict resolution.

Jono detailed steps of working through and resolving conflict, including how to identify root problems, how to make steps to resolve them, and some personal philosophy of how we build and maintain relationships with others.

An important first step is to identify the critical point: this could be an ongoing crisis, dealing with interpersonal conflict, or dealing with burnout. When someone is explaining a problem, listen fully to them and understand what they are saying. Let them get it off their chest. Is there something else causing this behavior? Tap into the cloud of ranting and determine what the root cause is.

Once common ground is established, make a plan to resolve it. Jono’s advice was to create written next steps and be explicit about expectations. This way, everyone is on the same page of what the next steps are and everyone involved has signed off on these next steps (this creates a sense of commitment and the next steps become written as “law”). Encourage others to restate the goals of conflict resolution in their own words. Once you have written goals and expectations, the crucial next step is follow-up. Check in on a regular basis with the person or people involved. Try to be neutral and unbiased when listening to others in these conversations. Go in with an open mind.

Lastly, we contextualized conflict resolution in personal philosophy of how we build and maintain relationships with others – both in and out of our open source projects. Sometimes the best way to address difficult interpersonal problems is to stop avoiding them and simply address them. Much easier said than done, but otherwise there is no escaping the perpetuated cycle of conflict if someone doesn’t make a first step.

It’s not just about code.

Thank you 🔗

To wrap up this Sustain OSS report, a few obligatory thank-yous are needed:

• Sloan Foundation / Ford Foundation: For the financial support I needed to attend and participate in the event – this is never something I take for granted and I am happy to have received a scholarship to attend and participate

• Josh Greenberg @ Sloan Foundation: For helping me get over some imposter syndrome and co-facilitate the university engagement breakout session with me – thanks for the gentle push

• Robert Kaye @ MetaBrainz: For being generally awesome and finally giving me someone to nerd out about all these crazy ideas of how free culture and music can actually be related!

• Stephen Jacobs: For always being supportive for yet another trip abroad and helping me map a strategy to get the most out of Sustain OSS

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

If you’re outside of the Mediterranean region, the Open Labs Hackerspace might be one of the hidden secrets of the region that you never knew existed. Free software and open principles build the community’s foundation. In their hackerspace, they support various open source projects with time, energy, and activism. Members work on various open source projects, ranging from Fedora, Mozilla, Nextcloud, Wikipedia, OpenStreetMap, and more. But the open source way goes beyond the software. The hierarchy of this Albanian non-profit organization is flat and open too. The hackerspace places a strong emphasis on empowering others to have a voice and to take part in the governance. No question is ever dumb, and anyone who wants to learn is able to find someone who will help guide them in the right direction. The combined effect of open software and open culture has helped Open Labs grow over the past five years.

Why Open Labs? 🔗

There are many hackerspaces in the world, but why does Open Labs mean so much to me? They love free and open source software and believe in the open source way… sure. That’s definitely part of it. But beyond the mission, beyond the activities, Open Labs fosters an inclusive and empowering culture. This culture has the effective of motivating others to understand that their voice matters and that they can have an impact on something far bigger than themselves. The hackerspace helps give young people in Tirana a platform to stand up and share their ideas. But beyond that, it provides them with the resources and community to help turn the ideas into reality.

So, what is the secret? Simply… the people.

Everything that the community here does, they take their unique passion and energy into those tasks. They invest their own personal resources into building solutions to answer complicated problems, inside and outside of Albania. Some of their work is best demonstrated in events that happened earlier this year. In March, Open Labs helped coordinate the first-ever 48 hour hackathon for United Nations Sustainable Development Goals. Later in March, they organized Linux Weekend, an introductory event to help introduce Linux to students. This was done by demonstrating what can be done with Linux and open source and then connecting students to professionals from Tirana and abroad. The organic energy that came from these events is almost immeasurable. Even an event report is hard to convey how inspiring that energy was.

This past weekend, from May 13-14, 2017, the community organized the fourth edition of the annual Open Source Conference Albania (OSCAL) in Tirana. This is the largest open source event in Albania and one of the most notable in southeast Europe. No event report for this yet, but you can expect one soon.

Why part of my heart is at Open Labs 🔗

Whenever I visit Albania and visit Open Labs, I learn something new. There’s many different types of things I learn. Sometimes it’s something about an open source project or community. Other times, I learn about events and opportunities happening in the local Tirana area for open source. And then other times, I gain unique insight towards some of the unique challenges and problems that citizens face here. Every time I visit, my perspective is always broadened in a way that I wouldn’t be able to normally find. It’s exhilarating.

I am privileged and honored to be an official member of this community. However, I am mostly an observer in my role. The passion and interest are at the heart of the hackerspace. The members from Tirana have invested so much of themselves into this community, its mission, and its values. From reading, visiting, and talking with the people involved with Open Labs, you see many of their hearts dedicated to what they’re doing. And when you see someone else who invests their heart into something, it’s challenging to not lend some of your own too.

And in today’s world, where the hearts of many people close with borders and the world shifts towards coldness, the warmth that radiates from Open Labs is refreshing, inspiring, and powerful.

Discover Open Labs 🔗

You can learn more about the Open Labs Hackerspace on their website. Additionally, you can also follow them along on Facebook and Twitter to see what they’re up to. You can also see their Discourse forums to say hello and take part in any discussion too.

The Fedora Diversity FAD (a.k.a. Fedora Activity Day, or a sprint) took place during the weekend of DevConf, 27-29 January. The original planning for this FAD started in August 2016, after the Flock 2016 conference. At Flock, the Diversity Team held a panel with open discussion about diversity and inclusion efforts in Fedora. Based on the feedback received during and after the panel, it was a priority for us to continue working on the objectives we had established before Flock. For the FAD, a majority of the Fedora Diversity Team was present along with a few others.

• Amita Sharma (amsharma)
• Bhagyashree “Bee” Padalkar (bee2502)
• Brian Exelbierd (bex)
• Jona Azizaj (jonatoni)
• Justin Wheeler (jflory7)
• Maria “tatica” Leandro (tatica)
• Marina Zhurakhinskaya (marinaz)
• Radka Janek (rhea)

We made significant progress in accomplishing our larger objectives and to contribute to the Fedora Project mission and goals. The primary objectives we established for our FAD were completing plans for the demographic survey, building a campaign based on those results, and analyzing our Code of Conduct to find ways to better impact the community. This report covers each of these objectives, what we accomplished, and what we plan to do next.

Demographic survey / marketing campaign 🔗

The majority of our discussions and planning on Friday and Saturday were focused on establishing strategic goals for the demographic survey and crafting the questions. The wish for having a survey like this predates the Diversity Team back to some of the earliest tickets in the Fedora Council ticket tracker (see #1 and #16). The need for a demographic survey was established by the Diversity Team as well shortly after Flock. At Flock, there was expressed concern about little understanding for the diversity of our community. Fedora is a global community spanning all four corners of the world. It’s hard to understand the unique needs and wishes of our community if we don’t know they are there or what they think we could do better. The survey is the means to this end and how we best understand how our community is composed to make Fedora a more welcoming and inviting place for our global community of contributors.

The FAD enabled us to make significant progress on establishing the groundwork for the survey and move towards deploying a live version of the survey. One of the early outcomes of our discussion was postponing ideas about a marketing campaign until we had actual data and results to work with. This would make sure our efforts and focus on that would not be wasted. While the marketing campaign is a primary goal for our team, we decided it was best to double our efforts on the survey. As it turned out, this was a good decision with the amount of time we had, as the survey discussion and planning took the longest part of our time together.

Building the questions 🔗

Before the FAD, Maria, Bee, and Marina had compiled a list of questions starting in a mailing list thread. Many of the questions at the beginning were based on survey questions used in the FLOSS 2013 and Apache Software Foundation Committer Diversity surveys. We started our discussion about the objectives and problems we wanted to solve with this survey. We established these two points as our primary goals.

1. Gather baseline demographics about the contributor community
2. Determine contributor knowledge about project components that ease contribution

With these points in mind, we revisited the draft of questions prepared by Marina. We took an initial pass discussing the questions and weighing if this was something we needed to know and whether we saw a use for the answers based on our goals. The first pass took the longest amount of time, but it narrowed the questions significantly. After getting to a smaller number of questions with varied opinions, the questions were organized them into a spreadsheet where we weighted them by point values and narrowed it down to our final set. Our final draft of questions can be found in the Pagure ticket tracking this task. We are awaiting feedback from Fedora Legal before moving forward. Once we receive additional feedback, we plan to revisit the implementation questions about how and where to deploy the survey.

Noting the working process 🔗

One thing worth mentioning and explaining is how we narrowed the questions. We originally had a wide set of questions and were struggling with how to narrow them down. The methods we ended up using, suggested by Brian, were successful in us focusing on the purpose and goals we originally identified. The concern was on survey engagement and trying to guarantee survey completion. Too many questions or making it too long could result in people not finishing the survey. It is more valuable for us to have the most important data (even if it’s less) rather than have more questions but fewer responses.

In the beginning, we started with the set of questions curated by Maria, Bee, and Marina. It was over 50 questions with different motivations or objectives. Our first approach was going from top to bottom of all the questions. We discussed each one and tried to justify if it was worthwhile to include. Some questions were easy to remove, but others were more challenging. All of this initial discussion gave background to the questions in the later steps. This took up a significant amount of time and was possibly one of the more difficult parts of this process.

After the initial pass, Brian organized all of the questions into a spreadsheet and established a scale from 1 to 7. Of the remaining questions, we ranked them in this order:

• Category 1: Five questions
• Category 2: Five questions
• Category 3: Five questions
• Category 4: Five questions
• Category 5: Five questions
• Category 6: Five questions
• Category 7: Four questions

After all of the team members ranked the questions by order of preference, we tallied up the points for all of the questions. We ended up taking the top twenty-two questions, which can currently be found in the ticket. This method of going through the options we had forced us into making tough calls and choices on the things we felt were most important. It was powerfully effective for us to go through our options in this way, and it’s a method that could definitely be recycled for other purposes or even by other teams in Fedora.

Code of conduct 🔗

A code of conduct is a valuable part of an open source community. Its purpose is to set clear expectations about how the community interacts and behaves with each other. An effective code of conduct empowers contributors to be excellent to each other. This creates a welcoming and inclusive space.

Background 🔗

Before we all gathered in Brno, we planned to analyze the Fedora code of conduct to understand its strengths and weaknesses. We also wanted to focus on its visibility and ensure that it is well-communicated. This includes new contributors when they first join the community and also current contributors. We published a post about the Fedora Code of Conduct to help raise awareness, but planned to cover this more during our FAD.

A comprehensive code of conduct is important to set the tone for interactions among contributors. This helps promote a global perspective and create a welcoming community. The code of conduct drives the belief that contributors should always be excellent to each other. This builds the community as a united, global team. It was valuable for us to deliver on our proposed impact for the Fedora community through our discussions and planning.

Seeking positive engagement 🔗

After we arrived in Brno, we started to have discussions about this and what some our actions would be. The tone of our conversation switched from looking at it from a disciplinary point of view to an enabling point of view. A code of conduct isn’t the only part of how to empower contributors to be excellent. To this end, we asked ourselves these questions.

1. What kind of behaviors does the Fedora code of conduct encourage?
2. How are we able to reward positive interactions that show this behavior?

While we spent time looking at the code of conduct, the main focus was how to promote the behavior the code of conduct encourages. The biggest idea that came from this discussion was Fedora Appreciation Week. It is a subtle yet positive way for people to be excellent to each other by saying “thanks!” and raising awareness for the work that people put into Fedora.

Fedora Appreciation Week 🔗

This discussion mostly occurred on parts of Saturday and the Sunday of DevConf. This idea was originally suggested on the CommOps Pagure. It was not an original part of our pre-planning, but it became a pivotal point in the context of how to encourage the positive behavior the code of conduct suggests. One of the first changes to the original suggestion was making it into an entire week instead of a day, so we have the most flexibility for planning the event and giving ample time for contributors to participate.

Afterwards, we started to look at systems used in other places to use as case studies. We examined the Red Hat appreciation system and the Happiness Packets project. These examples helped to understand the benefit of co-workers or other community members encouraging each other. The Happiness Packets website puts it simply: “The feeling that you made a difference, that your work matters and has value, and that the people you work with are happy to work with you, is an awesome feeling.” Taking the time to understand the background and motivations behind these systems helped us determine the background and motivations for Fedora Appreciation Week. We divided our plans into short-term and long-term criteria.

Long-term 🔗

The long-term discussion mostly focused on how we could make it easier for people to thank each other with Fedora web services. We started our focus with the existing platform of Fedora Badges. One idea was giving all Fedora contributors the ability to award a special type of badge to other contributors a fixed number of times in a release cycle. Each special badge would fit into one of the Four Foundations of Fedora (Freedom, Friends, Features, First). Each one would have guided criteria to consider when awarding the badge to someone else. The effect of doing is to strengthen our commitment to our Four Foundations and to thank contributors who are committed to any of the four areas.

As one example, imagine someone working on a new feature or exciting change for an upcoming Fedora release. They have invested a lot of time and energy into developing this change. Another contributor who noticed this could give them a “Features” badge to thank them for their commitment to driving Fedora forward. Another example might be when one contributor sends thoughtful words to another, thanking them for their time or for everything they do. That person might give the first person a “Friends” badge for being kind and considerate to them.

We also discussed the idea of tying the accumulation of these badges into a physical reward, such as a special t-shirt or sticker sent via the mail. We ran out of time to discuss this idea further.

Short-term 🔗

We started by trying to establish the general timeline for planning Fedora Appreciation Week. Initially, we want start defining guidelines and creating promotional materials to use and spread leading up to the week. This would include things like giving examples of the different ways contributors can give thanks and also to work on articles or posts.

The month before the appreciation week would focus on general awareness. This would include a Community Blog article and a post to the Fedora announce list. The week before the first day would include a Fedora Magazine article explaining what’s happening and also to provide a way for users or people outside of the contributor community to participate.

Methods to give thanks included thanking in IRC (either thoughtful messages or with karma cookies), writing messages on a public wall or forum, and sending personal notes to individual contributors. Methods we could use to measure this impact included but was not limited to were karma cookies, mailing list traffic, or wiki page edits.

For the short-term focus, more discussion is needed to develop the ideas for running Fedora Appreciation Week in 2017.

Tying it together 🔗

The first-ever Diversity FAD was a great opportunity to spend significant amounts of time looking at how we can build more inclusive environments for Fedora contributors and how to tackle other issues like understanding who makes up the Fedora community. Our team was able to use this valuable time to work on these issues more personally and intently than IRC or mailing lists can provide.

Special thanks and our gratitude go to the Fedora Council for supporting our work with the Fedora Project budget and enabling us to be gather and work on these tasks. To all of us, this also showed that Fedora leadership is committed to supporting these initiatives and helping make diversity and inclusion an important part of the Fedora community. Additionally, we’d also like to thank Brian Exelbierd for participating in the FAD even though his attendance wasn’t originally planned—we were lucky to have him with us and to steal his time from other DevConf activities happening during the weekend!

We’re looking forward to next plan talks and/or workshops at Flock 2017 this year.

Come say hello! 🔗

The Fedora Diversity Team mostly consists of a few active, core members. But we are always looking for more people to get involved and participate! Every contribution is significant and it helps to have numerous people from different backgrounds following along with our discussions, so they can speak up and add their voice when they feel it’s important.

There are multiple ways you can get in touch with the Diversity Team. We have a mailing list you can subscribe to and you can follow our discussions. We have an IRC channel on freenode (#fedora-diversity). You . We meet once every other week on Wednesdays at 12:00 UTC in #fedora-meeting on free

• Mailing list: Subscribe to follow our discussions
• IRC channel: Say hello in #fedora-diversity on freenode (you can join with a web client if you don’t have an IRC client)
• Weekly meeting: Meet every other week on Wednesdays (12:00 UTC) in #fedora-meeting on freenode
• Pagure tickets: See some of the current tasks we’re working on and what needs doing

Come say hello and introduce yourself—we’d love to hear what you have to say!

Heterogeneous group icon by Magicon from the Noun Project

Open source projects are built online and a lot of their community members are placed all over the world. Even though projects have people from around the world, this doesn’t stop ambitious community members to organize open source conferences or events in their own cities. Whether they’re focused generally to open source or for a specific project, you can find a variety of conferences, hackathons, workshops, or meet-ups all over the world. Fedora benefits from having Ambassadors to attend these events to introduce Fedora and spread the word about the community. It’s not uncommon to see Fedora participating in these events, and Linux Weekend 2017 in Tirana, Albania was not an exception.

From March 25-26, 2017 in Tirana, Albania, nearly 130 people attended the first-ever Linux Weekend 2017. Linux Weekend was organized by Open Labs Hackerspace at the Universiteti Politeknik i Tiranës as an introduction to Linux for beginners. Throughout Tirana, universities have a strong focus on Windows or macOS operating systems and little focus is given to Linux. Open Labs community members wanted to organize an event that would promote Linux as an open source alternative and demonstrate some of its benefits over proprietary environments. The event collected representatives from various communities, including Fedora, Ubuntu, OpenSUSE, NextCloud, MusicBrainz, and more.

Organizing Linux Weekend 🔗

The Open Labs community is not unfamiliar to organizing open source events in Tirana. Their portfolio includes Fedora release parties, OpenStreetMap map-a-thons, Wikipedia edit-a-thons, and Fedora community meet-ups. However, these events have been targeted towards people who already had prior interest or knowledge about open source communities. The organization and planning for Linux Weekend began in the middle of January as an idea to introduce Linux to complete beginners.

Planning and organizing Linux Weekend was a community effort. Jona Azizaj is a board member of Open Labs and a Fedora contributor, and was involved as an organizer for the event. “This was the first edition of Linux Weekend, so the main focus is to raise awareness about Linux and open source. We wanted to educate beginners and spread the word about the choices that are available,” Azizaj explained. The two tracks for the event were full of talks and workshops to introduce attendees not only to Linux, but also various software and applications of what someone can do with Linux.

Many of the attendees were students who had either heard of Linux in their classes or from their peers. Other attendees included industry professionals or other open source community members. Several representatives of Fedora from different parts of the community were in attendance as well. Ambassadors, designers, and translators were available to answer questions and teach newcomers about Fedora.

Albanian students learn Linux 🔗

Since the focus of the event was to teach newcomers about Linux and how it can be used, Linux Weekend was organized to be an introduction to various parts of the Linux ecosystem. Representatives from Fedora, Ubuntu, Arch Linux, OpenSUSE, Linux Mint, and elementaryOS gave introductions to the operating systems and their communities. In addition to distributions, there were also sessions on open source licenses, NextCloud, text editors, MusicBrainz, and more. The benefit of these sessions were demonstrating the different ways Linux can be used to accomplish various tasks.

In addition to the various sessions during the weekend, there were three community booths for Fedora, OpenSUSE, and Mozilla. Attendees had a chance to get swag from each project and also talk with representatives about their own experiences or how to get started using their project.

Sidorela Uku was both an attendee and a speaker at Linux Weekend. Her talk, “Programming in Linux, editors, and tools”, introduced various text editors and other tools to help customize any Linux distribution to someone’s needs or personal preferences. In addition to sharing her own knowledge, she was also excited to discover new things. “I wanted to attend the talks and workshops to learn as much as possible. I also wanted to figure out the next steps to find a project and get involved as a contributor,” Uku explained. “I also wanted to share the things I know with others to help them get started with Linux.” This was Uku’s first time speaking at an event and she looks forward to more open source events in Tirana in the future.

Fedora contributors introduce community 🔗

Various members of the Fedora community were also in attendance. Some of the Fedora presentations over the weekend introduced the project to newcomers, detailed the translation efforts to bring Fedora to Albanian, and also guided attendees on how to make their first steps as contributors. The Fedora presence aimed to help give newcomers a taste of the operating system but also to show the impact someone can have if they decide to contribute.

Mariana Balla was one of the first speakers on Saturday morning with her talk titled, “Introduction to Fedora Project and how to be a part of the community”. She started with localizing Fedora into Albanian in early 2016 and more recently started to become an advocate as well. “Fedora is one of the most used distributions, and it was great to have Fedora here to spread the word and show what our community is all about,” Balla said. “One thing I hoped to show in my talk was that technical skills aren’t required to contribute to Fedora. There’s so many things that aren’t code that people can help with!” One of the highlights of Balla’s presentation was breaking down the different sub-projects in the community and how they contribute to making Fedora what it is. One site that was mentioned was whatcanidoforfedora.org, a site anyone can click their way through to find an area that interests them.

One key contribution area that was important for the local community was localization. Many attendees and speakers alike thought it was important to have software translated into their native language. Anxhela Hyseni is a Fedora Ambassador and led the workshop on “Translation of Fedora”. “It’s important for Albanians to have software in Albanian because we are Albanians!” Hyseni laughs. “People are better able to understand Fedora and it makes it more accessible for us to have it in our local language.” She hopes that attendees left Linux Weekend with plenty of new contacts in the open source community and a better idea of what Linux is all about. She and others also helped Linux newcomers install Fedora 25 as a dual-boot or for virtual machines in the installfest on Saturday morning.

Wrapping up 🔗

After two days of talks, workshops, and hallway discussions, the final talk finished around 4:00pm on Sunday. Azizaj closed out with some final words of encouragement and thanks for attendee participation.

The presence of Fedora, open source software, and its philosophy was present during the entire weekend. Between stickers, install media, and brochures from community tables and the various presentations during the weekend, participants and organizers felt the event was worthwhile. “We had limited time to plan, but it was important to bring Linux to people to introduce the philosophy, show them how to use it, and also how they can give back,” Anxhelo Lushka, an event organizer and Fedora contributor, explained. “We hope attendees had new experiences and learned something new and useful for the real world, for jobs or studying. We also hope we convinced them to contribute and give back, even if in a small way.”

Now that Linux Weekend 2017 is finished, the organizing team is switching their focus to Open Source Conference Albania (OSCAL), the largest open source conference in the region.

Find Fedora near you 🔗

Open source events are happening all around the world, and Fedora might be closer to you than you think! Check for local user or meet-up groups near you to get involved in some of these events. Meetup.com is a great way to find local events happening in your community. You can also keep an eye on what Fedora is up to by following us on Facebook, Twitter, Google+, or Instagram.

We hope to see you at an event in the coming future!