Fortunately, I was able to meet my one key requirement. The migration was a complete one-to-one pairing from WordPress to Hugo. Every post I wrote between 2015 and 2024 made the jump intact. Even the images and URL schema! You can go back, browse the archives, and read a decade’s worth of my written word in my new site. Best of all, every old URL for my WordPress blog will seamlessly redirect to the new home here.

But I didn’t just move the content; I also built a custom Hugo theme from the ground up. (Because of course I did.) I began working on the theme over a year ago for my own site (this very one!). Originally I developed the code inside my own website, but eventually, I moved the theme code into its own repository in June 2025. However, I spent a lot of time in March working on my theme, giving it a solid structure for blogging, and turning it into something highly functional. I confess that AI was significantly used in improving my Hugo theme. It was my first time ever using an AI agent to do something outside of a browser. For various reasons, I chose to work with Claude AI for this project, and it helped me accomplish clearly-defined milestones in my mind since a long time. I wanted to create a theme that was still useful for me, but had the broad appeals of any basic blogging tool or engine out there today. And I believe I achieved that together with AI assistance, my pedantic review patterns, and OCD-like obsession for my design vision. My hope is that eventually, more people than just me could benefit from it.

Of course, a beautifully optimized, custom-themed blog is still just an empty vessel if you don’t write. And to say a lot has happened in my life since 2024 would be an understatement. The last twenty-three months had much to teach me in holding profound grief and incredible joy at the same time.

The Hardest Goodbyes 🔗

The heaviest reality of this past year was a prolonged season of caregiving that culminated in back-to-back losses. Right before Christmas in December 2023, my mother was diagnosed with cholangiocarcinoma, better known as bile duct cancer. Throughout 2024, my sister and I walked alongside her through her cancer journey, doing everything we could to support her. Alongside this, my maternal grandmother’s health was steadily declining due to the onset of dementia.

The emotional and physical toll of managing both of their needs is why I spent so much time away from work throughout 2025, and why my availability became so unpredictable. Ultimately, we faced an unimaginable timeline: my mother passed away in September 2025, and then one month later, in October 2025, my grandmother also passed.

Toward the end of 2025, after they were both gone, I slowly but steadily began the process of climbing out and getting caught up on everything. Throughout all of this, my sister was my absolute rock. Even now, my sister and I are still dealing with the long-term ripple effects and the heavy administrative burden of navigating probate court and managing an estate. Walking through this long, heavy aftermath as partners with my sister means everything to me. I could not navigate this season of life without her.

Finding “Home” Across an Ocean 🔗

On the opposite end of the emotional spectrum, my life expanded in the best way possible: I married the love of my life and muse of my soul. In November 2025, my wife and I began the next chapter of life together. She is currently living and working in Germany. Most of the time since then is spent navigating the unique complexities of our union This includes what is usually a simple question for most married couples: where to live.

Because international immigration is a notoriously slow and complex machine, our life is currently a transatlantic hybrid. Right now, while I permanently reside in Georgia, USA, my time is shuffled between the USA, being with my wife in Germany, and traveling for work.

While we are managing the distance for now, our biggest ongoing project is my official relocation to Germany. The exact timeline is fluid, but our hope & prayer is to celebrate the winter holidays in Germany together this year as residents. I look forward to sharing more about this process as it unfolds. (Including any potential trauma of migrating from temperate, warm Georgia to somewhere much colder most of the year.)

The Weight of Context Switching 🔗

Between the flights, the time zones, and my day job at Red Hat supporting Fedora, my brain is regularly forced into a relentless state of context switching.

The “Execution Mode” I use to navigate probate court, resolving medical bills, and executing an estate actually uses the exact same back-office muscles I use to manage budgets and plan events for Fedora. The hardest part lately was not lack of passion, but the sheer volume of threads I am holding. I am constantly shifting gears between my work at Red Hat and Fedora, then to coordinating international immigration, and dealing with the immediate reality of life—like trying to figure out when a technician can fix the broken outdoor air-conditioning unit at my house in the middle of a workday.

If you have noticed me working odd, irregular, or even borderline unhealthy hours lately, that is why. Work is not necessarily an escape from the grief; it is one engine that keeps me moving. So, that is a part of my coping mechanism. But feeling spread this thin has also been a wake-up call that I need to delegate more, reduce the number of hats I am wearing, and focus on delivering deeper, higher-quality work on fewer things.

The Anchor and The Code 🔗

When I am dropping plates and feeling completely drained, someone might wonder why I keep showing up to work. For me, it was always about Fedora. I do not mean this as a humble brag, because I understand it is not this way for everyone. But for me, Fedora was always more than a paycheck; Fedora is the people and community bonds. Getting to build a free and Open Source operating system that aligns with my values, alongside a community I genuinely love, is what anchors me here.

That same drive to build and organize is the same reason why I took on this massive blog migration. Occasionally, I have some deep-seated OCD-like tendencies. Creating structure is another way how I cope with a world that often feels entirely out of my control. During my mother’s and grandmother’s health declines, the volume of incoming paperwork was overwhelming. It was an endless stream of letters, bills, hospital discharge packets, and insurance statements.

To manage it, I accidentally built a massive, semantic digital library. I ended up purchasing one of the best Linux-compatible HP digital scanners on the market to handle the influx of paper. I became incredibly efficient at scanning stacks of paper, writing rules to sort and filter emails, sorting and categorizing PDFs, and developing strict file-naming patterns so everything was easily searchable. It sounds novel, but keeping the physical paper stacks from taking over my own space gave me a tangible sense of peace. So, organizing the things I can control gives me the confidence to leap in and handle the chaotic, uncontrollable moments when they arrive.

Plus, if I am being completely honest, I am exhausted from the WordPress ecosystem altogether. I held significant anticipation for canceling my expensive WordPress hosting service and various other subscriptions and fees tied to running WordPress. However, what I did not expect to find while working on this project was a spark of joy for creation that I did not feel in a long time. My childhood and adolescence were filled with a curious desire to make things that were helpful and useful. This is perhaps what nudged me in the direction of computer science and information technology, because these were domains I could understand. I confess feeling mixed emotions that this rediscovery of joy for creation was mixed with AI assistance. Yet at the same time, this is a project that was on my list since several years, and “pays off” a lot of technical debt. I look forward to maintaining and hosting my website here, and rediscovering my writing voice. (And I can use Vim to write blog posts now too, hooray!)

My creative engineering spark is still very much alive.

Taking it One Day at a Time 🔗

It has been twenty-three months of extreme migrations—digital, geographical, and emotional. The dust is not all settled yet, and I am still finding my steady footing. But now that my new blog engine is finally running, I am excited to share more of the journey, the code, and whatever else comes next.

(One more yak shaved.)

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.

Today is May 2nd, 2024. The Outreachy May 2024 round results will be published in a few short hours. This year, the participation in Fedora for Outreachy May 2024 was record-breaking. Fedora will fund three internships this year. During the application and contribution phase, over 150 new contributors appeared in our Mentored Project contribution channels. For the project I am mentoring specifically, 38 applicants recorded contributions and 33 applicants submitted final applications. This is my third time mentoring, but this Outreachy May 2024 round has been a record-breaker for all the projects I have mentored until now.

But breaking records is not what this letter is about.

This day can be either enormously exciting and enormously disappointing. It is a tough day for me. There are so many Outreachy applicants who are continuing to contribute after the final applications were due. I see several applicants from my project who are contributing across the Fedora community, and actually leveling up to even bigger contributions than the application period. It is exciting to see people grow in their confidence and capabilities in an Open Source community like Fedora. Mentoring is a rewarding task for me, and I feel immensely proud of the applicants we have had in the Fedora community this round.

But the truth is difficult. Fedora has funding for three interns, hard and simple. Hard decisions have to be made. If I had unlimited funding, I would have hired so many of our applicants. But funding is not unlimited. Three people will receive great news today, and most people will receive sad news. Throughout this entire experience in the application phase, I wanted to design me and Joseph Gayoso’s project so that even folks who were not selected would have an enriching experience. We wanted to put something real in the hands of our applicants at the end. We also wanted to boost their confidence in showing up in a community and guide them on how to roll up your sleeves and get started. Looking at the portfolios that applicants to our project submitted, I admire how far our applicants came since the day that projects were announced. Most applicants never participated in an open source community before. And for some, you would never have known that either!

So, if you receive the disappointing news today, remember that it does not reflect badly on you. The Outreachy May 2024 round was incredibly competitive. Literally, record-breaking. We have to say no to many people who have proved that they have what it takes to be a capable Fedora Outreachy intern. I hope you can look at all the things you learned and built over these past few months, and use this as a step-up to the next opportunity awaiting you. Maybe it is an Outreachy internship in a future round, or maybe it is something else. If there is anything I have learned, it is that life takes us on the most unexpected journeys sometimes. And whatever is meant to happen, will happen. I believe that there is a reason for everything, but we may not realize what that reason is until much later in the future.

Thank you to all of the Fedora applicants who put in immense effort over the last several months. I understand if you choose to stop contributing to Fedora. I hope that you will not be discouraged from open source generally though, and that you will keep trying. If you do choose to continue contributing to Fedora, I promise we will find a place for you to continue on. Regardless of your choice in contributing, keep shining and be persistent. Don’t give up easily, and remember that what you learned in these past few months can give a leading edge on that next opportunity waiting around the corner for you.

Freedom, Friends, Features, First!

— Justin

The air carries a breeze,
In from the eastward-facing window.
The breeze carries whispers and secrets of the night,
Into the ear, mind, & soul.

A stolen moment is clearly crystallized,
In the cavity of consciousness.
The stolen moment seeps to the soul,
Filling it with wonder & dreams.

The breeze gently carries your essence,
And the stolen moment,
Promises eventually for eternity.

Photo by Ryan Hutton on Unsplash. Modified by Justin Wheeler, CC BY-SA 4.0.

about adopting a theme 🔗

Recently, Joseph Gayoso from the Fedora Marketing Team proposed the idea of the Fedora Marketing Team adopting a theme for 2024. Together with the below video explainer, I felt his explanation was also convincing for the Team.

YouTube: Your Theme. CGP Grey. Premiered 26 January 2020.

But it was not only good advice for the team. I tend to avoid resolutions for as a new year tradition. But I recognize change as something that can happen independent from January 1st. That is where the role of an annual theme comes into focus. It offers a flexible framework with wide guideposts. I can choose how to measure my success. Working from a theme provides me a clear way to measure incremental progress while also enabling me to feel tangible accomplishments along the journey.

So, if I could commit to one theme, what would it would be? It would have to be something that I believe in.

storytelling is my theme 🔗

I admire storytelling since a long time. I admire its flexibility to be simple yet powerful. It is flexible because there are multiple forms of storytelling. Storytelling can be defined in a literal sense and a metaphorical sense.

In a literal sense, storytelling is the telling of stories. Telling could mean written, spoken, or shown. Stories could mean almost any expression of human experience that fits into a timeline with a plot. Therefore, storytelling is creatively sharing a human experience with others.

In the metaphorical sense, storytelling connects communities. Stories represent several aspects of life that happen around humans. The most powerful stories compel hearts and minds to change. Someone who tells stories that change the hearts and minds of others is an influential person. In this metaphorical sense, storytelling becomes a skill that is honed and practiced.

building my storytelling habit back 🔗

What does this have to do with my theme? I am adopting storytelling as my theme because I admire the habits of good storytellers. I want to hone my own ability for both personal and professional contexts. My ability is weakened from lack of practice; it is like a muscle that is sore from not being used in a while. By adopting storytelling as my 2024 theme, it empowers me to write more often in my authentic voice. Lately, recent posts on my blog undergo a rigorous self-editing before I publish them. But in adapting with a theme of storytelling, I commit to being fine with not maintaining maximum production-value on everything I publish. I commit to being authentic over rigorous; honest yet open. I commit to the pursuit of documenting my own human history, or “the world as I see it.”

So, 2023 was a year of big changes for me personally and professionally. I have plenty of things to start writing about. To improve, I need to publish more and be ready to make some mistakes. That’s how I learn, after all.

So with that all in mind, more blog posts seems like a good starting point. To make this plan actionable, it needs more specific steps. My goal for right now is to make the commitment within myself, and follow it up with action in 2024.

Happy New Year, reader.

Original photo by S O C I A L . C U T on Unsplash. Modified by Justin Wheeler. CC BY-SA 4.0.

If you are missing the memories, you can still find a good part of the forums archived via the Internet Archive’s Wayback Machine. Click here to navigate to the last snapshot of the official forums. You can also find downloads of the survival and creative Minecraft worlds below:

• Creative world: 2015 Nov. 2 backup (~29MB)

• Survival world: 2018 Sept. 22 backup (~43.6GB)

• Survival world: 2018 Dec. 3 backup (~44.1GB)

History of the CrystalCraftMC forums 🔗

Since December 2013, I maintained the CrystalCraftMC forums on my own infrastructure and dime. Even after I passed the torch in April 2018, I continued to maintain and manage the forums. When the game server finally closed in December 2018, I continued to keep the forums alive as a novelty for past players. For me, whenever I felt nostalgic, the forums always gave me a place to remember good friends and memories from that era of my life.

If you are one of the few original folks who kept up with CrystalCraftMC in its lifetime, you may remember we used a different forum at one point, hosted by Enjin. Those forums are (miraculously) still alive, and you can still find them! Visit old.crystalcraftmc.com to get a nostalgia trip on the oldest memories of our Minecraft community.

Why the forums closed 🔗

The forum software behind crystalcraftmc.com was called XenForo. We used the 1.x versions of XenForo. XenForo was a great fit for us when CrystalCraftMC was in full swing, but the forums fell behind on updates. The forums eventually stopped receiving maintenance and security updates for XenForo 1.x when XenForo 2.0.0 was released. Since I never renewed our license and didn’t have time to complete the complicated upgrade, the CrystalCraftMC forums remained on XenForo 1.x.

This month, I took on a project to reduce the costs of my personal infrastructure. The total cost to run the CrystalCraftMC forums was >$200 USD every month. I hoped to reduce the cost to less than $50 USD every month. My goal was to migrate the database for the forums to a competitive and more affordable hosting service. However, during the migration, I discovered that XenForo 1.x did not support newer versions of the MySQL database software. I would need to continue paying my bill for a hosting service that supported the legacy version of the database used by the CrystalCraftMC forums.

After careful consideration, I decided ten years was a good run and it was time to finally close things down. It was not the outcome I wanted, but it was what had to be done. Nevertheless, I took a final “snapshot” of the forums and database. I retained a final copy, and perhaps one day in the future, I may choose to put a read-only copy online again. But for now, the forums will remain offline until further notice.

(This also doesn’t even note the hundreds of spam, scam, and porn emails I received every day because of the contact form on the website not having a captcha form to stop spambots!)

What now for CrystalCraftMC? 🔗

I will continue to pay for the domain names of crystalcraftmc.com and ccmc.pw. Both domains will now redirect to this blog post, which might be how you ended up here. But otherwise, there are no more public archives of CrystalCraftMC other than our memories, YouTube “Let’s Plays” and Echophox video series, and the super-old forums. This is the end of the road for CrystalCraftMC.

To all the players and the CrystalCraftMC community, you will always have a special place in my heart. CrystalCraftMC was one of these incredible things that happened to me in my life, especially when so many things in my life were honestly upside-down. I wish you all the best and hope you all also have fond memories of building spawn points, running drop parties, building amazing forts and bases (while hoping they don’t get raided), and hanging out with other folks who ended up becoming close friends.

Long live CrystalCraftMC.

Photo by Johannes Plenio on Unsplash. Modified by Justin Wheeler.

This post is a reflection on the past year in my work with the UNICEF Venture Fund. We integrated new open source tools to capture metrics and data about open source repositories connected to UNICEF portfolio companies and created a shortlist of key metrics that map to business sustainability metrics. Now, we are better positioned to look back on past, current, and upcoming portfolio companies and mentor support programs.

As we move into 2022, this post covers my current thinking on these points:

1. Defining investments.
2. How do these investments impact sustainability?
3. CHAOSS metrics as an open source tool for an investment lens on sustainability.
4. What next?

Defining investments. 🔗

When we talk about investing in open source, what do we mean? What are the known inputs? What are the expected outputs? “Investments” and “investing” are broad terms. Investments typically mean sizeable financial injections of support and growth, but can also include non-financial investments too. Investments can also take the form of both time and energy (i.e. electricity and digital infrastructure).

The UNICEF Venture Fund provides equity-free funding for start-up companies building open source solutions of interest to UNICEF. All the start-up companies are registered companies in UNICEF program countries. As part of the Venture Fund’s location in the Office of Innovation, it is also a vehicle for UNICEF to explore frontier technology areas through the investments. When a start-up company is receiving investment from UNICEF, the company receives both funding and tailored mentorship about business and open technology.

A question I want to know is, what is the impact of the received funding plus guided mentorship? How does this approach enable the companies to be successful after graduating? What discoveries or knowledge could be shared with others to assist the development of their own open programs?

To summarize, an investment can be financial or non-financial. Financial investments include direct funding, grants, venture capital, fellowships, or any other exchange of capital. Non-financial investments include time spent in coaching sessions, personalized content for companies, and shared digital infrastructure. Neither list is exhaustive.

How do these investments impact sustainability? 🔗

Data makes introspection easier. Bitergia’s Cauldron.io was a champion tool for kickstarting an open source metrics strategy for the UNICEF Venture Fund. Its introduction as a tool opened up a wider span of data to look at. There are new opportunities to ask questions and explore growth, scale, and sustainability.

In order to come to a conclusion on sustainability impact, we need streamlined data to test a thesis. The Venture Fund team improved internal processes to how metrics are collected from portfolio companies. The team is unifying behind fewer tools and methods to ensure we see the same data and have the same view of the data points we measure. This also provides a fresh opportunity to review how we measure open source impact across portfolio companies. Many have dashboards on Cauldron.io, but data needs a storyteller for it to make meaning. So, the next step is to ask questions with this new data and frame a thesis to measure and test the sustainability of Venture Fund investments into open source.

Many have traveled before me on the same trail of thought. I started first with the Community Health Analytics Open Source Software (CHAOSS) project and its metrics releases. This served as the initial point of brainstorming to frame questions and different scenarios of risk, evolution, DEI, and value.

CHAOSS metrics as an open source tool for an investment lens on sustainability. 🔗

I reviewed the latest release of CHAOSS metrics and narrowed down four metrics I want to measure in the next year. I also shared thoughts on why collect this data and how to do it. This blog post is no more than me wondering out loud, to help me frame an analytical approach for this metrics strategy.

The four metrics are detailed below:

1. Contribution Attribution
2. Contributors
3. Collaboration Platform Activity
4. Labor Investment

Contribution Attribution 🔗

Question: Who has contributed to an open source project and what attribution information about people and organizations is assigned for contributions?

chaoss.community/metric-contribution-attribution/

This metric is insightful because it is targeted deeply into team and project culture. This metric is a good representation of how much the project leans into an open source model of building their project. This work ethos and intention to forge on an open source path is difficult to understand at times. If a team takes care to attribute their software dependencies and other contributors to their code (if any), this is a good sign that the team accepts collaboration as a value and encourages working with others.

I would measure this across two types of contributions: attributions for software dependencies including those with permissive licenses, and for any other direct contributors to the code and how they are recognized for their participation. This could be filtered in a red-yellow-green light approach:

1. Red: No attributions are made, or all attributions are inadequate.
2. Yellow: One of two attributions are made, or one attribution type is inadequately attributed.
3. Green: All dependencies and used works are correctly attributed.

Contributors 🔗

Question: Who are the contributors to a project?

chaoss.community/metric-contributors/

This metric explores a more human dimension of the people and participants to an open source project. The metric defines contributors and contributions broadly, as “anyone who contributes to the project in any way.” Understanding the people participating in a community, their motivations, goals, and why they choose to be in that community is important to understand sustainability. Otherwise, you may lose out on good opportunities to attract contributions from people who are already engaged, and new engagements may be difficult because of a mismatch of expectations.

This metric is more a means than it is an end; that is, it provides opportunities to ask more questions than provide detailed answers. Nevertheless, it does provide some guidance towards understanding contributors in a project, and it can lead to some concrete actions based on gathered insights. For example, this metric will enable deeper looks in areas of diversity, equity, and inclusion.

Since I work with start-up companies with small, lean development teams, I look to understand the motivations of the developers working on their projects and where the motivations may align with another open source solution. This enables the two communities to leverage their combined brainstorming for meeting complimentary goals around development and innovation.

To collect this data, I would have the team define what areas of contribution they seek for their open source solutions and then map those desired contributions to a specific project area or different team members. This enables a form of consistent accountability for checking expectations with reality and understanding team capacity. Each area could be a key-value pair, where the value is the project area, team lead, or delegated team member for the type of contribution solicited.

Collaboration Platform Activity 🔗

Question: What is the count of activities across digital collaboration platforms (e.g., GitHub, GitLab, Slack, email) used by a project?

chaoss.community/metric-collaboration-platform-activity/

Collaboration platform activity is one effective proxy metric for community engagement if measured accurately. The metric does not define collaboration as much as it provides a data structure to measure it. It abstracts collaboration into key data points like timestamp, sender, whether the platform has threaded or non-threaded discussions, data collection date, and platform message identifier. To a degree, collaboration can be abstracted out in this way: a person takes any given action at a given time in a given way, and this action is measured as project-related activity on the collaboration platform.

There are a few possible approaches to collecting this data from UNICEF Venture Fund companies. Each approach does not cancel out another, but each approach could be combined with the others:

1. Measure common git activity like commits, issues, pull/merge requests. We already measure this data, but use it only in connection to validating Venture Fund workplans for each team with UNICEF portfolio manager(s).
2. Count communications like comments, reviews, public messages, and other outreach. Communications strategies and tools are typically inferred from common git activity. Measuring for engagement and stratifying those metrics into a smaller group could allow for deeper insights to the evolution of early-stage open source communities.
3. Make community hubs first-class citizens in the data curation process to infer about informal engagement. Both open source projects and UNICEF Venture Fund portfolio companies use a variety of tools to communicate, especially in view of COVID-19 and its seismic impact on how we work. Platforms like Discord, Telegram, Mattermost, Slack, Rocket.chat, Matrix, and others are focal points where projects collaborate, ask questions, and support others. Bringing this data stream into the mix offers deeper insights into how teams engage and build community around their work, and also guidance on when to push for contribution opportunities at the right time.

The satisfaction of these three options in their totality is not enough. To leverage the fullest impact, these metrics must tie into each other, and need to be connected back to a narrative. Why is this data being collected and what actions are influenced by the knowledge of this data? The data collection enables the evaluation of sustainability and understanding the birth, growth, and evolution of an open source technology product. Influenced actions can include moving more human resources (i.e. contractors or staff) to support a project, adopting a new open source best practice, and/or engaging new customers, talent, or other leads based on participation in the community.

Measuring collaboration platform activity is not black and white. Many new questions would likely come forward as part of measuring this activity. Yet this is the point—it lays the foundation for the next layer to the data collection, analysis, and reporting process around sustainability.

Labor Investment 🔗

Question: What was the cost of an organization for its employees to create the counted contributions (e.g., commits, issues, and pull requests)?

chaoss.community/metric-labor-investment/

This metric is perhaps the most ambitious of the group. How do you measure labor investment into an open source project? Or literally, the number of person-hours that go into software design, development, co-creation, and community management? It feels like a gargantuan effort, but there may be better ways to measure this in connection to other data the UNICEF Venture Fund is already connected about the businesses.

Measuring labor investment impacts two narratives: the rate of development on the open source work, and the impact of UNICEF investment into a company backing an open source work.

Firstly, understanding the rate of development on an open source work is easier to infer by understanding who is allocated on a project and how much of their time they dedicate to it. If a team of three contributors spares a few hours a week, it will mean something different compared to a team of five engineers spread across different disciplines working full-time. Mapping the labor investment for open source projects supported by UNICEF would enable better planning by understanding the typical labor investment in open source workplan tasks as piloted by other Venture Fund portfolio companies.

Secondly, this gives us a new way of talking about the impact of UNICEF Venture Fund investments as an investment not only in software products but also in labor. It gives us insight into the investment of labor in software engineering talent among portfolio companies. How does this measurement change over time of the investment? Do projects receive more or less investment of labor during the 12 month period we work with them? This could also be used as a proxy metric for the impact of our unique mentorship and coaching opportunities.

What next? 🔗

Knowing is half the journey. Even if the knowledge is not yet firmly rooted. The analysis and introspection are from me as an individual working among the UNICEF Venture Fund and do not represent the views and beliefs of UNICEF or the UN in any capacity. My intent is that by sharing this analysis in the open, it allows for a space where conversation can spark where it could not before. It also invites others to share ideas, feedback, and constructive criticism of an emerging metrics strategy for investments made into the open source ecosystem.

Next, more layers can be added and internal and external validation can help to keep this moving forward. An implementation plan would be the next step to follow this post. The implementation plan considers the process of how start-up companies move through the Venture Fund from start to finish. Who interacts with the companies and when? At what point is a company ready to begin building in a new metric or count in their monthly metrics? Do they understand the implications and assessments of these metrics? At what points in the process is data already being collected? Could these new data requests be added to existing requests? And so on.

I hope to formalize some of this new reporting and metrics strategy in upcoming cohorts in 2022, as part of a renewed effort into communicating how our open source investments tie into sustainable impact towards the U.N. Sustainable Development Goals.

This post will serve as a milestone marker on the metrics strategy discussion in the coming one to two months. See you in 2022.

Featured photo by Edward Howell on Unsplash. Modified by Justin Wheeler. CC BY-SA 4.0.

While I was saying “yes”, I was afforded opportunities that I had known only as unaffordable. I had a chance to live out and explore my heart, and the unusual circumstances that make up my life. For the time I said “yes”, I am grateful for the people and things that subtly shaped my subconscious mind and what I learned about myself in the process of learning about others.

But I was not the first one to say “no”. I found both the closure I needed after a frustrating final year, and the luck to find a better way to live according to my values through my work.

So it was surprising when the conversation restarted after so long. It caught me off-guard for a number of reasons. Of most interest to me, I had never valued my community management work in an annual salary range like that. This experience put the value of my work into perspective; the context of the “who” is also significant in this way. Not only did it change my perspective on the value of this work, but it made me aware to what the upper bounds of salary ranges may look like for those privileged few organizations with huge talent development budgets and incentive programs.

Why? 🔗

But this stroke of fate also made me question my “why”. Why do I do what I do? For what or for whom do I do it for? These are deep questions that I have a privilege of asking myself. When I looked inward and sought to understand my feelings, I knew that I measure employment offers in my ability to live with an abundant heart. The salary range is secondary.

Every day, I wake up and get to ask how my daily work and practice impacts the lives of children. While there is more complexity and metrics in play, the ultimate purpose of what I do is centered first on real human impact, not stock prices and operational profit. There is no salary in any dollar range that I would trade for what I have.

So this time, it was my turn to say no. Not out of spite, nor out of anger. But the seasons I have changed, and so have I. My old leaves have fallen and new ones are in their place. I am grateful for the mentorship and guidance I received for those years I said “yes”. As alluring as it is may be to imagine a 250% pay increase…

I’m happy to continue making good from where I am with the things I already have.

The most common reaction I received from friends and family in the United States is surprise and curiosity. Admittedly Tiranë is not a typical place for an American to end up. But I am no stranger to this city. I have a long history in Tiranë. I fell in love with the culture and the people, and made good friends that are still in my life today. Some even helped me relocate. (Thank you!) So while it may be unusual for an American to end up in Albania, it is not unusual for me to end up here.

But how did I make the jump? Or why leave the United States, especially while the world holds its collective breath amid a global pandemic? It was not an easy decision, so it will not have an easy explanation.

A visit to Tiranë in June. 🔗

In June 2021, I visited Tiranë with friends who had never visited Albania before. In the course of that trip, I did not realize I was being pulled back into a culture, city, and country that has stuck with me for many years. But I was.

Fate took my hand, and after a year of cloudy uncertainty, I knew a new part of my destiny. On a fateful flight flying westbound, my heart was resolved to return eastbound. And how hard must I bite my tongue to acknowledge this privilege bestowed unto me by my American passport? To leave the story unfinished was only a matter of resolve, thus I knew I must pursue the next chapter.

Fast forward… and I am here in Tiranë. I made my arrival quietly to give me time to settle. (Literally.) I only had a bed, fridge, microwave, and a sofa. Now it is feeling more like my home. I am eager to make rounds to my favorite places and saying përshëndetje to old friends again soon.

Is the future in Stockholm? 🇸🇪 🔗

Part of my move is also motivated by my work team’s upcoming relocation. My team will relocate to Stockholm, Sweden over the next year. I am not sure where my fate will leave me. I love what I do and I feel privileged to be paid for it. So if I will continue forward on this same path, then I know I will go.

Yet I prefer to know by experience than to guess by speculation. So if I will go with my team, I would like to experience first-hand what would be my new home. Another fact is that plane tickets to Europe are cheaper from Europe. Cheaper than from the United States, even though Tiranë is a “premium” destination by European standards.

Eventually I hope to visit my new office and see it for myself. Again wondering how hard to bite my tongue if I acknowledge the unique privilege I have to casually shift my life in such a seismic way.

Here, for now. 🔗

If you are a friend and happen to be in Tiranë, drop me a note!

No culture can live if it attempts to be exclusive.

Mahatma Gandhi

I believe in the value of upholding the Open Source Definition as a mature and dependable legal framework while recognizing the OSI needs to work better with works that are not Open Source. My ambition as a candidate is to support existing work to enable a more responsive, more agile Open Source Initiative.

Twitter: @jwf_foss

Why should you vote for me? 🔗

I bring a public sector perspective to a conversation where it seems missing, despite the dependent relationship of the public sector to Free and Open Source works. In my work, I provide Open Source mentorship and coaching to humanitarian-driven start-ups hailing from 57 countries. I am an excellent communicator, I understand a subset of challenges faced by Open Source communities, and I have a collaborative nature.

I am also a millennial. The GPL was first drafted before I was born. My lived experience with Free Software and Open Source gives me a vantage point not well-represented in Open Source legal and policy work. My personal experience with Free and Open Source software is impacted by years of untangling my own digital life from technology decisions made for me, not by me. With that in mind, I realize not everyone can afford to be a Free Software purist, but we can still uphold the values of Open Source even if we do not use it exclusively.

Who am I? 🔗

I work as an Open Source Technical Advisor at UNICEF in the Office of Innovation. I manage and support an Open Source Mentorship programme for start-up investments and teams building Open Source products and communities from more than 57 countries. I also provide Open Source support to other UNICEF colleagues and recently coordinated UNICEF Innovation’s participation in the [on-going, at publication time] Outreachy round.

Outside of work, I have contributed to the Fedora Project for almost six years. I am soon ending a year-long term as the Diversity & Inclusion Advisor to the Fedora Council. I am a founding member of the Fedora Community Operations and Diversity & Inclusion teams. 

What are my qualifications? 🔗

I first contributed to Open Source as a teenager. I was a community moderator and staff member of the open source SpigotMC project. There, I handled user reports for a community forum with over 400,000 registered members. This is one of the most unique communities I have worked in, as the Spigot Community is a population of hundreds of thousands with an age demographic concentrated between ages 13-25.

Additionally, I am on the advisory board of Open @ RIT, the Open Source Programs Office for the Rochester Institute of Technology in Rochester, New York. This enables me to work more closely with academia, which has a growing interest in the growing ecosystem of academic Open Source Program Offices.

Finally, I regularly work with teams building Open Source solutions in support of children and UNICEF’s core work. I have lived experience of coaching teams on Open Source best practices across six continents. I have seen where Open Source worked well and where it didn’t. I bring this background and perspective into the work I would do as a member and representative elected by the Open Source Initiative constituency.

In summary, my lived experiences in Open Source, my connection to academic Open Source, and the humanitarian focus of my work make me a uniquely-qualified candidate for the OSI Board.

Interview responses 🔗

Luis Villa published four interview questions for OSI Board candidates on Opensource.com. I originally tweeted my response, but I copied it here for wider visibility too.

Q1: What should OSI do… 🔗

“…about the tens of millions of people who regularly collaborate to build software online (often calling that activity, colloquially, open source) but have literally no idea what OSI is or what it does?”

I am excited at the opportunity to contribute here. The UNICEF Office of Innovation (and my own Open Source Mentorship programme) rely on the Open Source Definition to guide our international Open Source work, even if we are still learning how to do it best. But without the OSD as a guiding light, our work is much harder. My team is well-positioned to be an advocate and voice of support for the Open Source Definition in policy environments where Open Source is not. This relates to on-going Giga connectivity work to connect schools worldwide to the Internet for equitable education opportunities for children.

So to directly answer the question, we have a conversation. Avoid anger when others choose software that is not Open Source. Avoid exasperated frustration when people pick licenses that are not Open Source. But the first step is always to teach & educate on the stories, values and history of the Free/Open Source community.

Q2: If an Ethical Software Initiative sprung up tomorrow, what should OSI’s relationship to it be? 🔗

The good folks behind the Ethical Source movement have done so. The OSI needs to be open to collaborate and engage with other orgs who steward legal works that do not adhere to the OSD.

I want to invite the Ethical Source folks into the conversation. How can we better partner together? If elected, I would commit myself to organizing a public town hall or community discussion with the Ethical Source folks. Coraline Ada Ehmke, Tobie Langel, and many other folks are doing great work in this space. So, let’s collaborate and work together.

Q3: When a license decision involves a topic… 🔗

“…on which the Open Source Definition is vague or otherwise unhelpful, what should the board do?”

The OSI needs to improve at saying what it is not. We are more clear on what the OSD is than we were even last year. As a candidate, I don’t have crazy ideas for the Definition. But there are things that are not Open Source. The world is changing.

We need to adapt. We must be nimble in changing with the world, or the values and motives of the original Free/Open Source movement are at risk of volatility. As a candidate, if presented with an unclear situation, I would take one of two options:

1. If the proposed work stands against a principle of the OSD, it should not be approved as such, or the OSD becomes meaningless; OR
2. Take an interpretive, “living document” view of the OSD for new copyleft innovations where the OSD is not clear or ambiguous.

For context, I am a copyleft believer. Promoting and advocating for the stability and integrity of Open Source licenses is a fundamental part of my interest as a candidate for the Board.

Q4: What role should the new staff play in license evaluation (or the OSD more generally)? 🔗

I don’t have an answer to this one. Foundations are mostly new to me. I would defer to expertise and listen to what others with more years have to say. I want to better understand the capacity and ambition of the OSI to take on new work with a steady staff.

I am a collaborator by nature and a team player. So, I want to enable the work for the OSI to be more agile and responsive in what I see as core, critical work.

That’s it. If you have specific questions, you are welcome to get in touch with me on Twitter or add a comment below.

I don’t say that casually either. I have involuntarily found Open Source as my calling. Or my people. I contribute to Open Source because I love to collaborate and work together with other people. This challenges me. It humbles me in a way that I know I can always learn something new from someone else. For this, Open Source and Free Software have enriched my life. They have also given me, again involuntarily, an odd but productive way of coping with my own mental health issues, anxiety, and depression.

So how do I make sense of the emotions and feelings I have now? How do I untangle this complicated web of events and reactions by other people? To ignore it doesn’t seem possible. If I remove emotion, I am left with a purely rational motive to involve myself in this contemporary issue. My work, profession, and career goals are directly affected by however this discussion goes. There is no way out for me. It’s my job, so I have to care. But if you add emotions back in, to stand still and remain idle is heartbreaking. To do nothing is to commit to defeat. Resignation. The darkness.

Yet what is there to do? The only thing Stallman ever directly gave to me in life was an email explaining elegantly how there was nothing he could do for the Minecraft GPL community fiasco. At a time when I was so personally lost as I saw a community I love tear itself apart, he stood by idly as the so-called steward of these licenses that I was just too naïve to believe in. That experience to me now is amplified in the light of the much more egregious things he is accused of.

So, the Free Software Foundation welcomes Richard Matthew Stallman back to its board. Wonderful. Congratulations Mr. Stallman. I am going to pause for a moment of sadness and hurt as I contemplate the impact of this moment on our fragile movement, which has much bigger enemies today than it has in its 40 year legacy. But then…

I will move on. Because we have to. The only way is forward.

I put on our playlist,
Pure poetry to untrained ears.

My heart taken by the hand,
But led back to the Atlantic blue,
Wondering if I am singing your tune?

Will I continue to wait here,
Under the early April showers?

Am I ready to let someone new in?

Balkans and Bosnia. 🔗

My time abroad was counted in months, not years. Yet those five months in the Balkans gave me more opportunity to grow and discover myself than I could have anticipated. Living away from home is one step forward. But living away from your own country? Let alone somewhere you speak the foreign language? It is another three or five steps. I didn’t see it this way at the time, but my semester abroad broadened my passport and mind with each new stamp. Croatia first, then the Czech Republic and Belgium shortly after. Onwards then I went to Sarajevo, and then finally by bus to the company of great friends in Tirana, Albania. The end of my experience abroad would open an opportunity to travel and stay a short time in India, before returning once more to Albania and then finally back to the United States.

I remember my last-minute decision to travel over my spring break instead of studying in my apartment. The bus ride to Sarajevo was unforgettable. I was overcome by the thrill of learning something new and experiencing a city I had only read about. It was unexpected and wonderful all at once.

Patterns. 🔗

What strikes me now is the monotonous pattern of daily life. The opportunities for these learning experiences are fewer. On one hand, it was inevitable in some part due to a global pandemic. On the other hand, I have also been working on psychological well-being this year. Shockingly, it takes more energy and spoons than I originally anticipated (even with the great benefits and insights enabled by this work). The days when I counted the airports and train stations I passed through in a year is paused… but it is also difficult to imagine these places running at full capacity again.

My challenge in a virtual-first world is discovering new ways to restore and replenish the soul without being able to easily travel and connect with others face-to-face.

But over time, I blurred the lines between personal and professional communication. The emotional words in my vocabulary were gradually phased out through my formal education. There were many influences on the sculpting of my voice. High school teachers critiqued writing styles for A.P. exams. Communication professors clearly outlined how to write business emails in a level of detail I didn’t know was possible. These experiences showed me one way communication could be more direct and effective.

But I believe I may have mistaken professional communication as the only kind of communication. My education prepared me to understand scientific research studies and how a compiler works, but didn’t teach me how to listen to my heart and put words to the emotions I was feeling.

So, now looking back at my blog history, it feels like reading a news site instead of these personal slices into my thinking and what is going on for me at any given point of time. I retained some of it in the beginning, like with my annual Year in Review posts that last published in 2017. But now, there is little here that I think gives meaningful insight to who I am outside of the context of technology or open source.

Indeed, despite being the sole author, publisher, and editor of my own blog, there still seems like a great deal is left unsaid. I cannot speak words where there was already silence, but I can choose to break the silence. So, here is to breaking silences and finding your voice.

That semester, I traveled to different international FOSS conferences (before COVID-19), analyzed contemporary changes and trends in Free Software, and reflected on where I think we are going. I am sharing an edited version of my final report here, as a look into my “crystal ball” for what is coming to Free Software in the 2020s.

Preface 🔗

There are emerging challenges and changes to the Free Software status quo. Three pieces of context about me will help to understand my perspective.

First, I am a young adult who has contributed to Free Software for a third of my life. At fourteen, I landed my first Open Source contributions. In high school, I participated in Open Source communities with 100,000+ adolescents, teenagers, and young adults. Later, I led community-driven initiatives in Open Source projects older than me. Thus, these experiences are a significant part of my experience coming into the Free Software movement.

Second, I follow conversations about Open Source sustainability. I regularly collaborate with others who also care about Open Source sustainability. I participate in communities where Open Source sustainability is the key issue to address, like Sustain OSS and the CHAOSS Project.

Third, I am a white American male in my early 20s, which yields me certain privileges. I actively work to understand how my privilege constructs my worldview and experiences. I also acknowledge my freedom to participate in the global Free Software community is afforded to me in part by who I am. So, I acknowledge these biases in order to frame my perspective.

So, I propose three emerging trends in Free Software across the 2020s:

1. Sustainability of Free Software is here to stay.
2. Free Software will have its ethics interrogated.
3. More young people will stay, or leave.

Free Software sustainability is here to stay. 🔗

Sustainability has subliminal buzzword status today, yet it will not fade from our vocabulary soon. Unlike other tech buzzwords from the last decade, I suspect sustainability is here to stay.

Sustainability is broad though. This analysis begins broadly and then narrows down the definition. To start, here is the Oxford Dictionary definition of sustainability:

sus·tain·a·bil·i·ty

The ability to be maintained at a certain rate or level.

Oxford U.S. dictionary

From this definition, I look at two sub-types of sustainability: software sustainability and Free Software sustainability. While they do overlap, software sustainability is what we build: the technology we make and its ability to last into the future. Free Software sustainability is who and how we build: the people who comprise the Free Software movement and how they work together and collaborate.

Now, sustainability is less overlooked than five or ten years ago. However, we still have competing definitions for what sustainability means. The dictionary defines sustainability as “the ability to maintain” but there are different ways sustainability is interpreted.

The maintainer and the corporation 🔗

For example, to an Open Source software maintainer, the “ability to maintain” might mean their ability to pay for their bills, live securely and safely in their day-to-day lives, or supporting a family. On the other hand, to a corporation that depends on Open Source software for their business, the “ability to maintain” might mean the ability to make new software releases at a specific cadence. It could be lines of code added and removed, or the number of commits made. Both perspectives are valid, but they imply different expectations of what maintenance requires.

On first consideration, these competing definitions make the landscape confusing. But surprisingly, this varied interpretation does not weaken sustainability; it strengthens it. It creates more opportunities to collaborate and work together in solving common problems in new, intersectional ways. Instead of focusing on common differences, it encourages seeing common problems first. While the definitions of sustainability might be different between an independent tech freelancer and an engineering manager in a Silicon Valley tech corp, both of these people could still work together on something that benefits both of them.

While I cannot predict what sustainability will mean to us in 2030, I am confident it will not mean the same as it is today. So, I am interested to both observe and participate in the shaping of the sustainability conversation in software and Free Software communities over the next decade.

Free Software will have its ethics interrogated. 🔗

Free Software emerged in the 1970s as a social movement in an act of defiance to a global market change, when software became a commodity. Activists stood together and asserted what they believed to be essential freedoms of all computer users. So, Software Freedom as a concept was born through the GNU Project in 1983.

Today, a similar storm is on our horizon. The world is shifting again. It is not just software that is a commodity. It is data and human futures. Free Software was a bold assertion of essential freedoms about software. But those in the 1980s did not know how the world would change nearly forty years later. Today, the plot has thickened. The world is more complex. Technology impacts our lives in ways we never imagined in 1983. Software Freedom may protect us in one aspect of our digital lives, but it fails us in other ways.

Ethical Source? 🔗

Perhaps this is best understood by looking at the attitude towards the Ethical Source movement by those in the Free Software world. There are a wide range of views and opinions. It is difficult to build common consensus and understanding across these groups. Yet, somehow, we cannot move past this conversation. It persists.

One famous example is the Java programming language license that forbid its use in nuclear submarines. For this reason, Free Software activists did not consider Java as Open Source until Sun Microsystems and subsequently Oracle were challenged. To some, freedom meant the ability to do anything—with no limitations—to the original work. For others still, freedom means the freedom of all people. The “freedom to use” is a controversial freedom in respect to certain ways we use software.

“Join, or Die.” 🔗

Is there a consensus today in the Free Software or Ethical Source worlds about how we address the ethical issues of our field? No. There is not. Inside each movement, there are disagreements and differences on what is the most effective way to accomplish collective goals of building a more fair and just world. Depending on our unique perspectives and backgrounds, we have different views on the methods and means of how we address issues of ethical and unethical uses of software. I am doubtful there is a common definition of what ethical and unethical means in the narrow context of software. We have not yet clearly agreed on those definitions in global and transnational legal and judiciary systems.

It is not clear to me which way the winds will blow in the 2020s. But what is clear is that the storm is coming. Either the Free Software movement will fragment on different definitions of Freedom, or it will collectively converge around a new set of values updated to the ways the world changed so far in the 21st century (or even just 2020 alone).

One path weakens us all, amid global political shifts reminiscent of 20th century nationalist politics. The other path unifies us and builds common power together for the things we can change. I just hope the Free Software movement chooses right.

Free Software will see more young people stay, or leave. 🔗

Free Software will either be more inclusive of young people and new ideas, or it will see these young people move on to something else and fragment the movement.

In my own life, there were decisions and opportunities to influence the building of my digital life. But it was a paradox of choice, whether I wanted this digital life or not. It was simply the reality of the world I grew up in.

I am a millennial. The world changed around me as a child, as I grew into this new hyper-connected digital era. I owned my first computer at four years old. My home had a (dial-up) Internet connection when I was six. In grade school, I built a community site and online forum for my class. In high school, I participated in and moderated international online communities. These experiences collectively informed my worldview as someone who grew up on the budding World Wide Web.

“The world the children made.” 🔗

Millennials were the first generation to inherit the new always-online world built by the generation before. This is true for many others my age or younger who are transitioning into global citizens. This is no small part enabled by the constant-connectivity of the Internet mixed with different social and environmental circumstances we are born into. Young people are coming, and it is an open question whether Free Software will include them. Or if it will only include a select few who subscribe to the same pre-existing value system.

It is difficult to articulate this well, but I think Free Software will face a challenge of inclusivity for my generation. Either it will encourage and foster the next generation of Free Software activists to assert and protect our basic freedoms of computers, or it will isolate and push those people away from being a part of this movement.

Will others my age, or younger, emerge as leaders in their own right in the Free Software movement? Or will young people start something new that is more welcoming and empowering to them as individuals?

What now? 🔗

Just like the Free Software activists of the 1980s and 1990s, I cannot predict precisely how the world will change. But I think it is valuable to step back from the hustle and bustle of daily life to think constructively about where we are going. We can fall into a routine of living our life comfortably because it is easy, but our comforts can cover our consciousness unless we evaluate our own views and biases for what they are.

I cannot know for sure where we are going, but I am committed to the belief that there are essential freedoms that we, as human beings, have in the context of the systems and digital worlds we create together. It is to this core belief that I bind myself, and I am excited as much as I am nervous for what changes are to come in this next decade of Free Software.

This blog post was originally written for an independent study at the Rochester Institute of Technology as a supplement for IGME-583 Legal and Business Aspect of FOSS. Special thanks goes to my faculty advisor, D. Joe, for supervising this independent study and being a sounding box for ideas, perspectives, and thoughts.

Original photo by AbsolutVision on Unsplash. Modified by Justin Wheeler for this blog post. Special thanks to Wilfried Hounyo, Mike Nolan, and Olivia Gallucci for reviewing.

This blog post was first written on August 28th, 2020.

Today is a sad day. Chadwick Boseman is dead. At 43 years old, he lost a terminal battle with stage IV colon cancer. As his great light dims, I am left to wonder what loss will happen next in 2020.

But like the ashes of a phoenix, we will rise. His death reminds me of the fierce urgency of now, as said by Dr. Martin Luther King Jr. That in the moment of darkness that follows death, a new bright light will emerge. It is just so human for us to cling to the embers of hope, in the fear that we will one day be delivered from suffering.

Boseman was a social leader and source of inspiration for many. His life and many roles championed racial equity on the Hollywood screens. Boseman was passionate about what he did. He led a committed life.

Boseman’s death caused me to reflect on the definition of Freedom in the movement I am embedded within: the Free Software movement. Yet in this community I value, there are seeds of discontent. The fierce urgency of now has revealed that systemic social injustices continue to exist in our society, as they have for centuries. The generational question we must answer as witnesses to this moment is: will we continue to tolerate the systemic faults within our society? Or must we imagine a more fair society? A more just society? I know we can because we have to.

On the origins of Software Freedom 🔗

A background on the Software Freedom movement is helpful to understand this discourse on freedom.

Free Software is a social movement born in the 1980s in North America. In the beginning, it was mostly a set of ideals and values set forth by MIT computer scientist Richard Stallman. Stallman witnessed a dramatic shift in how the free market distributed software in the 1980s. Previously to then, software was usually trivial; an afterthought. Software was freely shared between companies, universities, and individuals. Part of this is to blame on the industry’s intent focus on hardware during the Cold War. At the time, there was no standardization to hardware development, so software source would have to be rewritten to compile on different hardware architectures from competing vendors. However, this mindset eroded in the 1980s. There were a few lead architectures at the time, mostly championed by Intel. Software had to be compiled less often. Now, this freely shared source code could be repurposed much more easily.

At this point, the software industry went mainstream. Software began to receive acute focus by companies with computer science talent. Talent needs moved beyond hardware. Stallman saw all this, and believed the shift was at a great loss to the personal freedoms of the individual. So he coined “Software Freedom”, and a movement formalized.

With that background, the word “Freedom” has a specific, coded meaning to people who believe in the principles of Software Freedom. Software Freedom protects a set of digital rights that the movement leaders first advocated for in the 1980s and 1990s. The Four Freedoms (to use, to study, to share, to improve) are entrusted to the individual user of a computer system.

Freedom in 2020 🔗

However, it is 2020. Not 1985. Not 1991. 2020.

Questions about what Freedom means could never be more removed from the context of right now. Software Freedom asserts rights fully-realized by participants in the new digital society. Yet billions of people on Earth remain unconnected to the Internet. How can you realize rights that were never accessible to begin with?

Even if you are participating in digital society, freedom to read source code and make changes to it are just one of many different examples of freedom. But what other definitions exist?

The freedom to be safe asleep in your home without being gunned down by those entrusted to protect you.

The freedom that your children may live in a world where they may realize their fullest potential.

The freedom to life, liberty, and the pursuit of happiness.

In comparison, the freedom to read the source code of the web browser that keeps crashing on an unsupported device does not practical value to people who have different questions in the pursuit of freedom.

Reconciliation and intersections 🔗

But surely there is somewhere we can reconcile these different definitions of freedom. They may conflict at times but they are not in opposition to each other. There must be a way to realize both the freedoms of the individual to live a better life, and the freedoms of witting or unwitting participants in a digital world governed by increasingly invisible hands.

The intersection is surprising. Before identifying it, it is important to understand its purpose. The purpose of the intersection of these two definitions of freedom is to unify and empower people to be in control of their own destinies. Our destinies and futures are influenced but not entirely controlled by our environments. Both types of freedom believe in the right of the individual to understand the ways a system works, in order to understand how the system impacts them.

Said simply, the purpose is inclusion. The purpose is to bring together. The purpose is to empower. The purpose is give individuals the tools to shape their own destinies.

The name of this intersection is digital intersectionality.

Digital intersectionality makes inclusion a first-class citizen. It must take an intersectional approach from the outset if it is to accommodate the hyper-globalized world we live in. Albert Einstein once reflected in a letter to schoolchildren in Japan about his great delight in being able to communicate across such distances—something that was unheard of at the time. It is a cute memory, but also emphasizes the ways the world has changed since the most widely-known events of human genocide. Digital intersectionality has no borders. Its borders are decentralized; its borders may or may not have nationality. Copper wire, fiber lines, satellite receivers; these are the conduits that digital intersectionality resides in.

Digital intersectionality must be about inclusion. Digital intersectionality by definition must always be intersectional. Digital intersectionality must always consider the role of the individual in contributing to healthy, collective society. Digital intersectionality must embrace love.

What now? 🔗

Chadwick Boseman is gone. But we are not.

We are in the same world. Breathing the same air. Living under the same sun, and the same stars. As I see the void and grief left behind in his wake, as I look around me in a global pandemic that places the heaviest burdens on those with the most to bear, as I continue to see the effects of unjust systems perpetuate, I am thinking more about my own role in shaping the world we must create.

So I will continue to advocate and celebrate both freedoms, software freedom and inner freedom, under the mutual banner of digital intersectionality.

Special thanks to my early editors!

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.

There are several new and noteworthy changes in TeleIRC v2.0.0. This post walks you through the major changes and differences for TeleIRC v2.0.0. Read on for the highlight reel of this release.

Full rewrite to Go 🔗

TeleIRC v2.0.0 is a complete and total rewrite. With the lessons learned and best practices of the NodeJS v1.x.x releases under our belt, the team set out in September 2019 to rewrite TeleIRC in Go. The rewrite was motivated by fun and personal interest, but it was also intended to make the future of TeleIRC more sustainable.

The rewrite makes TeleIRC simple, fast, and lightweight. TeleIRC is unique from other chat bridge software, which usually focus on extensive configuration and supporting many chat platforms.

Additionally, the success criteria in order to release was feature parity with v1.x.x releases. The team accomplished this almost completely, with one exception. TeleIRC v2.0.0 does not include Imgur image upload for IRC; however, a v2.1.0 feature release will include Imgur support.

To summarize, TeleIRC v2.0.0 is written to be a simple and excellent Telegram <=> IRC bridge. No more, no less.

Run TeleIRC v2.0.0 as a compiled binary 🔗

The new release is available as a standalone 8 MB binary. The only deployment assets needed are the binary and a config file. Other pathways, including build from source and Ansible Roles, are also available.

This is a departure from TeleIRC v1.x.x releases, which required a NodeJS run-time and installing project dependencies. TeleIRC v2.0.0 does not require a Go run-time on the host.

Improved TeleIRC v2.0.0 documentation 🔗

End user feedback shaped and improved documentation during development.

Thanks to feedback collected during the pre-release process, the documentation is simplified and written to be easy to understand. We hope you find the TeleIRC Quick Start page a helpful introduction to getting TeleIRC running in little time.

Future roadmap for containers 🔗

Because of v2.0.0 design decisions, there is a planned future for container and container orchestration use cases. At release time, a Dockerfile is available, but it is not yet tested or documented.

In future releases, the TeleIRC Team will continue to test the container image and iron out bugs. Future deployment assets and documentation will offer pathways to run TeleIRC in Kubernetes or OpenShift v4.x.x.

Article format inspired by Ryan Lerch’s format for “What’s new in Fedora Workstation”.

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!

Grief is a strange emotion. One text message read early in the morning can send your day into a long walk down the beach of your own memories. Memories flood back, making us conscious that these lost moments of time were never really lost to us, but locked under deep layers of interlocking memories and contexts that only had to be connected back together, like a broken circuit. Today, my memories and heart are on my former summer camp roommate and friend Hannah/Honor Loeb. (I knew her as Hannah in her life, but at time of death, she identified as Honor, so that is the name I will use for this post.)

When I think of you, Honor, a mixed spectrum of emotions comes over me.

First, I feel selfish for making a post that is probably as much for me as it is for you. A great irony in death are the many interpretations of an explanation it brings. It is impossible to know exactly how the deceased would wish for their death to be remembered, because they are not present. Yet those who were connected to the deceased also experience their own spectrum of emotions. Perhaps it is human for us to make the death of someone else about ourselves, where we become included in the attention that death brings. But perhaps it is also the natural experience of how we process grief and trauma, in that making someone else’s death about us, it affords us the privilege and opportunity to reflect on the meaning of their life, and how we will continue to live our life in light of their absence.

Second, I feel happiness and joy. I remember my first experience living together with you as roommates at the Duke University Talent Identification Program at the University of Georgia. I remember the trips from Georgia to Alabama to visit and stay with your family. I remember the time you showed me Battlestar Galactica for the first time, and staying up with me to watch episode after episode. Even though you had probably seen these episodes countless times before. I remember the warm sunny mornings in Montgomery when we would go out for breakfast and we would talk about life. I remember when at the end of every meal out, I never had a choice of whether I would pay for myself or not.

Third, I feel guilt and shame. I remember being afraid to invite you to my home in Georgia, because my home was not a safe place then. I remember when you drove from Ithaca to visit me in Rochester, and you let me interview you as a member of the trans community for a class assignment. Then, months later, I remember not replying to your texts, missing your calls, and always putting off invitations to meet. I remember seeing our lives slowly drift apart, and how I felt powerless to do anything about it. Even if the powerlessness was imagined. I remember not knowing how to help you with your emotional burdens when I was still figuring out how to carry my own experiences and traumas. I remember the random times in my life where you did come across my mind, unprompted. In those moments, I thought of all I learned from you and how you lived in life. In those moments, I remember hoping you were well, but I also remember my fear and hesitation about reaching out to you after so long. I remember consciously deciding not to try the phone number or the email I had saved for you from 2013. Maybe your contact info changed eventually. But maybe it didn’t. I’ll never know.

Today, I learned that you passed away. You are dead. I will never get to see your smile, I will never get to hear your voice, and I will never get to have a warm hug with you again. These are all hard truths that I must acknowledge. Like I said, grief is a strange emotion. We all handle and process grief in unique, personalized ways that reflect our life experiences. For me, I have to define and understand the losses of this experience in order to practice gratitude and appreciation for the positive moments and experiences we shared.

The end of a life is never black-and-white. As you always exemplified in being a powerful trans voice from the socially-conservative state of Alabama, a binary understanding of complex social issues is rarely sufficient. Experiencing my grief from the end of your life is a wide spectrum of emotions because your life spanned several different emotions. Instead of categorizing my different emotions into their categorical boxes, I am allowing them to all wash over me. The happiness, the joy, the sadness, the anger, the selfishness, the guilt, and the shame. I know I cannot deny any of these emotions because they are all a part of you.

I have to accept these emotions as feedback to what your life means to me in this moment. I appreciate the great ways you expanded my mind and taught me to see the world differently. I lament the ways I let our connection fade and sputter, and that the last significant moment I have to connect with you is in your death. From what you taught me as a teenager, I began to see beyond the binary belief instilled in me from my youth. From what you taught me as a young adult, I know that how we carry our relationships, friendships, and love throughout life is always in some part our own responsibility.

When reading the news of your death, I have to be honest with myself. A part of me was not surprised or entirely shocked by this news. In a world where queer and trans folk are often treated as second-class humans, the pandemic of mental illness and suicide are undeniable in LGBTQ+ communities. I don’t understand how I feel even now to learn that your death was from a “non-COVID infection”. You fell sick. To what degree this infection inflicted pain upon you, I don’t know. All I know is, the path in life I followed brings me to this point where the first thing I hear about you in a number of years is your death.

Part of me knows I cannot assign myself blame for these circumstances. I know I alone cannot wear all blame because we live in an interdependent world, where every effect and outcome is linked by several smaller causes. But if only for myself, I have to acknowledge what my role is in your life and how I will choose to continue my life in the knowledge that yours ended too soon. I acknowledge that I probably played differing roles in your life, sometimes a loving friend, and sometimes an apathetic jerk. But again, life is often not so binary, not in life nor in death. I only hope that if you had the opportunity to read this, you would be able to forgive me for the ways I wronged you in your living life, and for you to know how much I really did love you.

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.

What’s coming in TeleIRC v2.0.0? 🔗

TeleIRC v2.0.0 is a complete rewrite of TeleIRC. The team is migrating the code base from NodeJS to Go. In September 2019, the team began scoping the requirements and how to approach this large task. TeleIRC v2.0.0 does not add new features, but aims to have feature parity with the v1.x.x version of TeleIRC.

You might be asking, why bother with a total rewrite? What does this actually accomplish for the project? To answer this question, some historical context is needed!

TeleIRC v1.0.0 was an experiment. 🔗

TeleIRC v1.0.0 was originally created and released in September 2016 by RIT alum Mark Repka. Mark created TeleIRC as a cool project for the RIT Linux Users Group (RITlug) when he was a student and vice president of RITlug. The project was written in hackathon spirit: to prove that something that was not yet common wasn’t that hard to do.

Fast forward to today: TeleIRC ends up being pretty popular! As do chat bridges (Matterbridge, Matrix/Riot, etc.) as a whole. The Fedora Project is one of our largest users, with a dedicated Special Interest Group to manage the bots. The LibreOffice community is another one of our biggest users. Several international communities also adopted TeleIRC to make their chat rooms more accessible to a new generation of open source fans. Some example users are Linux and BSD user groups and hackerspaces in Argentina, Albania, and across Asia. You can see the full list of TeleIRC users for yourself.

TeleIRC has grown in a way we never thought it would. Which is awesome! But the project was not originally designed to grow or scale the way it has. Additionally, by being at a university, contributors come and go as students graduate and move on to industry. We also have to think about how to maintain TeleIRC beyond the typical student life-cycle common in the academic world.

Let’s approach TeleIRC v2.0.0 as engineers. 🔗

A full rewrite allows us to fully leverage our knowledge as software engineers. In 2020, we know TeleIRC has a large user community and is an important part of how many open source communities communicate. We also know that breaking code into smaller, more modular pieces makes it easier to maintain and bring in new contributors. A full rewrite allows us to apply the lessons the team has learned over the years, in a way that incremental feature releases does not allow.

A few areas are in clear focus for the TeleIRC v2.0.0 rewrite:

1. Write clean, simple code that is easy to understand
2. Test the code so it is easy to tell when things are working and when they aren’t
3. Think about how to bring in new contributors to continue the project in the future

But maybe you are also asking, why the jump to Go?

A Go rewrite distinguishes our project. 🔗

When Mark and I launched the project in 2016, we didn’t look around to see if anything else like RITlug’s TeleIRC already existed. Turns out, there was another NodeJS project with the same name. Skip forward a few years, and there are also projects like Matterbridge, pytgbridge, and other implementations. So, with all this commotion out there these days, why bother with our version of yet another chat bridge?

First, there is one design principle guiding our project from others like us: to do one thing and to do it well. Matterbridge is an excellent tool, and we even use it in conjunction with TeleIRC at our university. However, it is a complex tool with many features and options. For some people, this is a non-issue. But the TeleIRC team likes to think there is beauty in simplicity. Instead of offering a tool with the most features and configuration options, we aspire to do a single thing and to do it really well: connect Telegram groups and IRC channels together.

Second, although the FruitieX/teleirc project is archived today, it was once the biggest alternative to our project, also written in NodeJS. When we decided to launch TeleIRC v2.0.0 development, it had a larger community and user base then ours. So instead of offering a “similar but different” NodeJS project, we would be the first Telegram-IRC bridge written in Go. (Yes, Matterbridge is also written in Go, but see the above paragraph.)

Third… many of the existing maintainers of TeleIRC simply wanted an excuse to learn Go. It is an opportunity to expand our knowledge, experience, and skills, especially since we are students preparing to enter the industry.

Go has a better story for Kubernetes / OpenShift. 🔗

Finally, we are carefully considering the needs of one of our biggest downstream users: the Fedora Project. Several TeleIRC developers also support Fedora’s TeleIRC SIG. Recently, the Fedora Infrastructure team launched an OpenShift instance for the Fedora community, called Communishift. All existing infrastructure in Fedora is gradually moving from virtual machines or OpenStack to OpenShift. To support this migration, we want to make a Go-based TeleIRC as easy to deploy in OpenShift as possible.

And fortunately, Go has a great story in the container orchestration world. Kubernetes and OpenShift are also Go-based projects. Go is the dominant language of this ecosystem. Its excellent performance in the niche of networking makes it a great choice for what TeleIRC does.

Now that you know more about the “why is this happening,” let’s talk on where things are and what you can expect!

TeleIRC v2.0.0: Progress so far 🔗

TeleIRC v2.0.0 is approximately 76% complete. All progress is tracked in the v2.0.0 milestone on GitHub. 46 issues and pull requests were closed since we began in September 2019. At publishing time, about 16 more issues and pull requests are left before we cut the v2.0.0 release.

Earlier in 2019, the maintainer team consisted of Justin Wheeler, Tim Zabel, Seth Hendrick, Nate Levesque, Nic Hartley, and Robby O’Connor. Now joining the committer group, we are happy to welcome Nicholas Jones, Kevin Assogba, and Kennedy Kong to the team. The current core group of maintainers for v2.0.0 are Justin, Tim, Nicholas, Kevin, and Kennedy.

When to expect TeleIRC v2.0.0 🔗

TeleIRC v2.0.0 is targeted for a release date of Friday, May 15th, 2020. At this point, we expect to have full feature parity with the v1.x.x version. We will recommend all existing users to upgrade to the latest release then.

In the meanwhile, the team is getting ready to cut a v2.0.0-pre1 release, our first “pre-release” of the Go port. We expect this release to be available on our Releases by Saturday, March 28th. Along with the v2.0.0-pre1 release, there are a few other details to note:

1. TeleIRC v1.5.0, the final version of the NodeJS version, will be released.
2. No future contributions will be accepted to the NodeJS version.
3. master branch in git will reflect the latest Go version of TeleIRC.

Once the v2.0.0-pre1 release is available, we want help to take it for a test drive! If TeleIRC is critical for you, we do not recommend using it yet, as it does not have full feature parity yet. But your early feedback can help improve the future of the next release while we are in active development.

Get involved with TeleIRC! 🔗

You can be a part of the upcoming TeleIRC v2.0.0 release. We’d love your help! There is no formal commitment to contributing, although we ask for participation through a single sprint cycle.

Read our Contributing guidelines on how to get started with TeleIRC. Virtual developer meetings take place every Saturday at 15:00 US EDT, so anyone can join and participate.

Come say hello in our developer chat rooms, either on IRC or in Telegram!

Background photo by Daria Nepriakhina on Unsplash.

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!