NB: Over two years ago, I affirmed that I wanted to write and share more personal thoughts on my blog. Not only the professional and fully-polished things. Looking back, I haven’t really done that. Being a part-time perfectionist, I get stuck on the production value of the things I make. I feel like I have to get it just right before publishing. I have several unpublished stubs started on my blog (19 as of publishing time, to be precise). However, I have not yet overcome the hesitation of being content with a stub post just being a stub post. After all, if Wikipedia can do it, why can’t I? Furthermore, I can also write for the purpose of my own satisfaction and not the satisfaction of others.

So, here goes.

Me? Not represented? 🔗

After the Inclusion & Diversity summit ended and I returned to my hotel, I entered a thought loop. There was this uncomfortable idea stuck in my head that as a white American male, I didn’t feel represented there. Which depending on your view, either sounds very ironic or it might seem obvious (duh!). However, I did not want to suppress this uncomfortable feeling. I wanted to interrogate it, understand where it came from, and identify why I felt this way.

First, I came to see my feeling of under-representation was not (only) as a white American male—but instead as a privileged ally. Many speakers during the day called out issues in our industry, shared their work as advocates and champions in working to address these issues, or did both. But in our divided and divisive world of the 2020s, a feeling of frustration slowly overcomes me. Never all at once, but more often like the tides of the ocean—slowly rising, rising, until everything is underwater. What are my role and purpose? I care about DEI issues and I have made an effort to do what I can in the last eight years to make Open Source more diverse, more inclusive, and more equitable. I attempt to spend my privilege on others who don’t have the privilege and power that I was assigned at birth.

Noticing the white narrative. 🔗

However, at the same time, I can’t help but feel there is a narrative about people who look like me and come from where I come from. That narrative is white supremacy. The white supremacy narrative can be an integral part of identity to people who also look like me and come from places like I do. The narrative often comes from a place of anger. The narrative is often hateful. That context is understandable because the white supremacist narrative is always harmful to people who do not look like me and come from different places than I do. My daily life is least impacted by the white supremacy narrative.

However, I am not saying that white supremacy is unreal. On the contrary, Western media, news, and opinion articles quickly provide several easy affirmations that a white supremacy narrative holds real weight.

The paradox of the white narrative 🔗

Yet, I feel the narrative is also the exact problem. Does a white supremacy narrative override other narratives that a white person could relate with? I remembered a time when I took a History of Women in Science & Engineering course during my undergrad studies. While discovering hidden stories in history of accomplishments, struggles, and successes of women in STEM over hundreds of years, I was also intrigued to read about the allies who helped them. The allies I read about were white men who spent their privilege as sponsors to many of these early women innovators. They shared their own resources and enthusiasm as an act of asserting both the value of the women they supported and the work they did.

It was doubly sad to me that history relegated several of these stories to the sidelines, both the stories of these women innovators and the stories of their allies. These stories of early allies are under-represented because most often, they are simply not told.

No savior complexes. 🔗

At the same time, an alternate narrative to white supremacy must also not be a savior complex or white savior-ism narrative. True allyship does not look like a savior complex. The historical view could easily jump toward a conclusion with a savior complex narrative. There are no saviors; the only one we can truly save is ourselves. We can support, mentor, and sponsor, but there is no magic, quick solution that makes everything better.

In today’s world, I feel that healthier narratives are also not well-represented. I strongly believe in words that I attribute to Dr. Martin Luther King Jr.:

Darkness cannot drive out darkness; only light can do that. Hate cannot drive out hate; only love can do that.

Dr. Martin Luther King Jr.

Today in the United States, white supremacy is going more mainstream (again). It is also one of the most visible narratives of White identity. This begs a question of how do we influence the narrative and also inspire what a better, healthier “whiteness” can mean? How do we promote stories of transformative love, incredible allyship, and true compassion? There are many stories in history if you look closely. But often they are relegated to the periphery and cast aside, alongside the experiences of other white people who fit outside the societal power structure of White society. We need these stories told too, should we create a more equitable society that allows everyone to realize their innermost human potential.

Where do we go from here? 🔗

I write this without full answers. My motive to write is because this thought comes up from time to time for me. Sometimes I just long for better role models. I want a society where more white people lend their support and power for dismantling hate and destruction. I want more white people who use their privilege and power as superpowers for love and justice. A future default narrative for whiteness should not feature pain and center hate. This is in spite of what is an undeniable part of the legacy and history. Yet that is the heart of it. I want the mainstream narrative to change. I want us to take real steps toward reparation to atone for that legacy and history.

But it is like they say, “it is hard to be what you can’t see.” Sometimes I feel exasperated by the narrative staring back at me and my ancestry. My identity as a white American man is bound by nature of my birth. But perhaps instead of waiting for the right story to be written, perhaps this is my own action item. I should be better at writing my own story. The only person I have to do it for is myself.

Photo by Rishabh Dharmani 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.

I am opposed to the impact of Export Administration Regulations by the United States as it pertains to free and open source software. I am a strong believer that the impact of these regulations are most harmful to all free & open source software communities at an individual, human level. When I saw this discussion at the Fedora Council level, it offered me an opportunity to reflect on my own feelings about these regulations, and also to share an opinion on how I believe Fedora Linux could truly live up to its certification as a Digital Public Good to ensure a more equitable world.

Here is what I wrote to the Fedora Council, and perhaps also to anyone reading from Red Hat’s legal team:

Hi, I would like to add a counter-opinion, of course one that holds no weight as an official vote.

As Fedora Linux is forced to this decision by its relationship to its legal sponsor, Red Hat, I therefore believe it is also the responsibility of Red Hat to seek a solution that does not deny an individual their right to realize the Four Freedoms of Free Software on the basis of geography or citizenship.

I recognize no policy is being changed here. It is a deliberate clarification of rules that were always in effect. Yet this ticket opens the context behind the policy for greater scrutiny, and I posit the context is harmful both to the Fedora Project and to Red Hat.

This policy is harmful for diversity and inclusion, and compromises Fedora’s position to be an innovative platform built by a global community. The U.S. laws and regulations driving this decision exist within a specific context, but that context is grossly incompatible with the dynamics of inclusive Free & Open Source communities. In practice, these laws and regulations deny individuals (really, other human beings) of their ability to be a beneficiary of the open licenses we employ for creating our work, collaborating on it together, and sharing it with others.

I see two outcomes of accepting this as an unchangeable norm.

Firstly, it creates confusion, doubt, and feelings of ill intent. These laws and regulations are meant to impact governments and nation-states. In a Free & Open Source community such as ours, these regulations impact individual people. Not governments or nation-states. As an example, a Fedora community member, Ahmad Haghighi, was recently permanently removed from the Fedora Community. In a few quick clicks, Ahmad’s legacy in the project was erased. As a precedent, even if someone’s contributions were not “supposed” to be accepted in the first place, it does not sit well with me that any one person’s legacy of contributions can so easily be removed from project records.

Secondly, it challenges the vision and foundations of the Fedora Project. Particularly our vision statement and the Friends Foundation. When I contribute to the Fedora Project, I do not see people as a citizen of this-country or that-country. I see them as my peers and fellow Fedorans, helping meet that shared vision of creating “a world where everyone benefits from free and open source software built by inclusive, welcoming, and open-minded communities.” As an American citizen, I know my country makes such discriminations about large groups of people based only on their nationality, but as a contributor to Free & Open Source communities, I see people by their individual character and intention to be a part of our shared vision. But how can we truly aspire to this vision if we are consciously making deliberate exclusions, even if they make little to no sense in our own context? This geographic restriction policy sits in contrast to the vision and purpose we spell out “on paper”.

I understand why Fedora leadership is taking this action due to Fedora’s legal and sociopolitical relationship to Red Hat, an American incorporation subject to American laws and regulations. To an extent, the hand of Fedora is forced.

But I believe this is a great opportunity for Red Hat to be an enabler of Fedora’s First Foundation. Previously, Microsoft stood up for Iranian developers and successfully set a precedent about how the United States Office of Foreign Assets Control (OFAC) treats such cases. I found this excerpt from Nat Friedman’s announcement to resonate:

Over the course of two years, we were able to demonstrate how developer use of GitHub advances human progress, international communication, and the enduring US foreign policy of promoting free speech and the free flow of information. We are grateful to OFAC for the engagement which has led to this great result for developers.

Advancing developer freedom: GitHub is fully available in Iran - github.blog

I believe Red Hat’s legal team should take a stand for individuals in embargoed countries to remain a beneficiary of the free and open source licenses that enable a community Linux distribution like Fedora to exist in the first place.

After all, in Fedora, we are well-known for being first in the Open Source space for innovative new ideas and approaches. We know Fedora Linux is a digital public good that should be accessible to all and everyone. But to make this a reality, the Fedora Project cannot be first here on its own. We need our friendly primary sponsor, Red Hat, to help us clear this burden, which is brought on by our connection to Red Hat in the first place.

I’ll close this counter-opinion with an excerpt from our First Foundation:

“However, the Fedora Project’s goal of advancing free software dictates that the Fedora Project itself pursue a strategy that preserves the forward momentum of our technical, collateral, and community-building progress. Fedora always aims to provide the future, first.”

From What is Fedora all about?

Here is a chance to be clear on the future we want to provide and for whom.

Background photo by Omid Armin on Unsplash.

Many have started on this same path before. Several communities form a committee as a governance model for important decision-making. Usually committee membership is chosen through an election process. Paid employees, or sometimes, members of the community comprise the elected committee membership. This meritocratic approach is believed to bring in diverse representation and participation of highly-engaged people. After all, who better to represent contributors of a project than a committee of folks elected by their own peers?

Sometimes, committees do accomplish this lofty goal. My argument is that sometimes they don’t – especially if your committees are designed in a way to disable participation.

Context brief: what is a committee? 🔗

Frequently in this post, I refer to committees. But what are committees? I see a committee as a I see a committee as holding the following characteristics:

• Fixed group of individuals charged with important decision-making privileges
• Appointed or elected members with fixed term periods (i.e. an end date)
• May perform their work in a public and transparent way

Challenges of a committee 🔗

If designing a community for participation and engagement, a committee can do the opposite by pushing people away. It can be difficult for non-members to participate in important decisions. When building the foundation of a community on volunteerism, expecting others to give time in huge quantities is a false expectation. An active, long-term commitment as a committee member may be a big ask. Yet even if an individual wants to contribute, their company may not support such policy. So, this person is unable to contribute fully in the committee. Therefore, the opportunity is lost to include their voice as a representative of a larger community.

Furthermore, a committee depends on the engagement of its members to be effective. Committees are limited by the amount of time individual members actively contribute. Committees lose their effectiveness when:

1. Individual committee members practice poor time management, or are simply overloaded with too many responsibilities
2. Inclusion of others with valuable perspectives have no pathway to being heard or represented, unless they are on the committee

Committee members participate for a fixed amount of time as regular participants. This can be good for a healthy turnover rate, but it becomes bad when the same people are running over and over again. Often described as burnout!

What is a better design for community engagement? 🔗

A fatal flaw in community management is being too hands-off or too hands-on from a corporate context. I look back at 2018 in the difference of roles in Fedora Mindshare vs. Fedora CommOps. Red Hat strives for participation beyond paid Red Hat employees, yet the volunteer-driven community struggles at times for participation of any Red Hat employee.

The Mindshare Committee is the community body that leverages power in the community. These are tasks that could have been designed by CommOps too. I think the format and spirit of CommOps encourages collaboration and invitation to contribute. On the other hand, if you are not an elected or appointed member of the Mindshare Committee, there is not much in the ways of contributing. Even if that is more a belief than a fixed rule.

Accommodations move us closer to equality but not equity. The presence of accommodations implies a belief in an “us” and a “them”. One group benefits from default inclusion, while another group either raises a collective voice, or is de-facto excluded. Instead of designing our world for others different than ourselves, we must design our world together. It is a quicker way to achieve a more just world.

The “abled” community needs to challenge our perspectives and do our share of the learning required to see things from another perspective.

An example I saw from Twitter that made an impression on me was how someone explained the idea of combinations and permutations of the five human senses: sight, hearing, smell, taste, and touch. The commonly-held belief is that lacking one (or more) of these senses leaves you deprived. Without one of these senses, your potential is limited and you deserve to be pitied.

Multi-sensing > accommodations 🔗

So, what does it mean to be multi-sensing? Most of us see our five senses (sight, hearing, smell, taste, touch) as a fixed state of sensory stability. These senses and basic mental stability are socially-assumed as always present. They define how we individually experience life.

Often those lacking one or more of these senses are seen as deprived. They are perceived as missing something or to have lost something they can never fully regain. The absence of a human sense comes with the added psychological burden of living in a world where you are often the afterthought, the “new use case”, the countless trials of countless beta versions of any kind of software that might help overcome the disadvantage of “missing” a sense or mental disability.

I suggest an alternative way to design for accessibility and inclusivity. A personal deviation is not written off as “missing” something, but instead as a new combination of senses gained. Designers should assume an expected and guaranteed variable of this new combination. Accessible design must be a first-class citizen in early project management planning.

To put it another way, observe the presence and lack of senses among us as a matrix of combinations, instead of large swathes of characteristics assumed to always be present. We unlock the best of our design knowledge to think in the pursuit of access to the greatest many instead of “what ticks off the box”.

Before, we saw an accommodation as when a specific feature is added to software for someone lacking one or many senses. But we must shift from accommodations to full inclusion. Accommodations are acknowledgements of disability. It assumes a fixed state where a set of critical features to guarantee usability will always lag behind for a subset of people. True equality is seeing access for those with disabilities as equal to the design of features for those with five active senses.

Featured image photo by Matthew T Rader on Unsplash.
Modified by Justin Wheeler.

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.

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!

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!

I never intend to adjust myself to injustice.

“I’m proud to be maladjusted.” https://t.co/TFBiWBy6Xc

— Be A King (@BerniceKing) December 12, 2019

Where Byfield was accurate 🔗

While I don’t agree with all of Byfield’s sentiments, he identified some key challenges that still hold truth today: a predisposition to focus on differences and not similarities, an outreach approach centered on ethics and not software, and the importance of opportunities for intersectional interaction.

Predisposition towards difference 🔗

First, Byfield notes the differing age groups of the activist communities and the tendency for viewing others by their differences first, not their similarities. He seems to attribute the tendency to view others by differences first as a characteristic of older generations; however, this is not necessarily the full truth.

As a member of the young activist community, this explanation is too simplistic of the underlying cause. There is also a political motivation by established power to sow division among the population of a nation-state. It makes community organizing more difficult and presents diversity as an issue to “solve” instead of a source of greater unity and common strength.

This is exemplified by the social media algorithms of today that reward sensational content (judged on likes, views, clicks, or other user feedback) and share it widely across a huge platform. In 2006, it was difficult to imagine the relationship social media would have in the lives of an everyday person; today, a great deal of social power is granted to those who understand how to leverage social media, either for good (e.g. social activism) or harm (e.g. deceptively persuading large parts of a nation-state’s population leading up to a national election).

The politics of division are within the fabric of our political systems; this is a challenge for modern-day activism and community organizing to overcome. In identifying this as a challenge, Byfield is correct that a differences-first approach makes it harder to share and spread the importance of FOSS in other activism circles, especially as technology becomes an increasingly relevant way of how we experience our lives and how our systems of law and justice are enforced.

Outreach on ethics, not software 🔗

Second, Byfield suggests an ethics-based approach to outreach is more effective than a software-based approach. This is also correctly noted, even if perhaps overemphasized. The jargon and language of the technology world is not accessible to the large majority of the global population. While some degree of technology literacy might be expected in some populations, much of the existing FOSS community is deeply rooted in technology. Sometimes this limited perspective is counterproductive.

This revisits the rebranding of “Free Software” as “open source” in 1997. For many subsets of the wider open source community in 2019, the default approach to open source software is merely a secondary thought for how to collaboratively work on technology. This is part of the outcome of the Open Source Initiative’s gamble in 1997 by beginning to emphasize the business sensibility and practicality of open source, and de-emphasize the social roots of Free Software (or rather, try and position itself as some sort of translator between these two “worlds”, as if they cannot be spoken of together in the same room).

As such, those who work on open source software projects are not necessarily predisposed to assume the role of an activist. Truly if Free Software is to take root outside of technology, then those who see the ethical values of Free Software need to better organize and promote the values of FOSS externally. This will contribute to the diversity of Free Software activism by helping non-technology activists add FOSS as a tool to their existing work.

Intersectional movement building is the future 🔗

Thirdly and finally, and perhaps most importantly, Byfield suggests the importance of intersectional interactions between Free Software communities and other activist communities. This is a fundamental requirement for the growth of Free Software as a social movement. Those of us in Free Software see the world around us informed by a background informed by technology; this background is emphasized in a world that is generating new, advanced technology at an unprecedented rate. However, while software and technology are important parts of the world around us, they are not the world around us. They are one part of a greater picture of fighting for a common good and welfare for all people. There are others in similar niches who have a deep understanding of their problem space and how they want to approach a challenge.

“One group may be working against child poverty, another for recycling, but the people in these organizations can almost be transferred from one to the next.”

Peter T. Brown, Free Software Foundation Executive Director (2006)

Just like a healthy garden, cross-pollination of these niches is vital to help others understand how we can help each other in accomplishing our mutual goals (this also feeds into why the politics of division explained above is so pervasive and difficult). Bringing Free Software technologists to activist communities where there is not an overwhelming Free Software background (and vice versa) is vital to building an intersectional social movement that strengthens the social impact of Free Software, not just open source.

Where Byfield didn’t go far enough 🔗

Byfield made one assumption on how activists have “their own share of insularity” and that the presence of connections between two movements does not mean they could immediately connect their existing beliefs with new ones. Fioretti’s challenge was in others understanding why they should listen to him; there was a lack of foundational knowledge of open source and technology that is normally assumed of someone who works as a software engineer.

Indeed, attention is a currency in the world of an activist. It is not enough for a FOSS advocate to expect others to listen to you on an appeal of technology. Part of the work in sharing is understanding who you are sharing with; if FOSS wants to take deeper roots in the activist community, it needs to understand the backgrounds of activist communities and be creative in how to appeal the mission of FOSS to the mission of their work. Where you can build in-roads together with others through common initiatives is the beginning of grassroots community organizing. So, while Byfield is right that there is an almost competitive nature of ideas in activism, it is not enough to write insularity off as a fixed aspect of nature. To not acknowledge this is to deny the influence of capitalist power structures in the humanitarian sector as they pertain to sustainable funding.

What are today’s challenges? 🔗

Some of today’s challenges are about inclusion and power.

Inclusion builds power 🔗

Diversity and inclusion (D&I) are important but poorly understood; not only are D&I about including people of different identities in technology, but also people with backgrounds outside of technology. FOSS stands to benefit by including more people who do not necessarily have a strong technology or engineering background. The goal is to inspire different perspectives to contribute in meaningful ways to build sustainable technology.

Instead of seeing diversity and inclusion initiatives as problematic or unneeded, D&I groups in FOSS communities stand to be the most effective people at building community and influence.

Power and governance 🔗

In the activist / humanitarian / non-profit world, there is a power struggle for sustainability as it pertains to funding. Funding models in non-profit work (usually sustained by grants, sponsors, and donors) encourage solutions that get funded, not necessarily solve problems the most effective way. Many organizations struggle with how to achieve sustainable funding without being so dependent on the expiration date of a grant’s funding.

We need more representative governance models in open source communities that reflect the interests of the communities around them, not necessarily an individual, a company, or group of companies. Building governance models that empower people within a community to make decisions and reduce the corrosive influence of money from humanitarian work.

Where do we go from here? 🔗

This blog post is an active reflection of my own thoughts and perspectives of Free Software, activism, and humanitarian work. If you are interested in pushing this conversation further, find me in Brussels, Belgium for any of the following three conferences and let’s chat further:

• 30 January 2020: Sustain Summit
• 31 January 2020: CHAOSScon
• 1-2 February 2020: FOSDEM

If you want to discuss this further, you can also drop a line in our online discussion community, fossrit.community.

Photo by Walid Berrazeg on Unsplash

Use alt tags for Markdown images 🔗

Often an embedded picture in Markdown looks something like this:

![Screenshot_2019-06-14.jpg](https://example.com/Screenshot_2019-06-14.jpg)

When you render the Markdown, you see your picture. However, you don’t see the Screenshot_2019-06-14.jpg string. You might wonder what its purpose is or why bother changing it at all. But imagine for a moment if instead of seeing your picture when you rendered your Markdown, you only saw Screenshot_2019-06-14.jpg where your picture should be. Screen reader users often encounter this problem.

So instead, describe your Markdown image so a person that uses a screen reader can also follow the conversation:

![A flowchart describing how user data flows from a publisher, to a proxy, and to a group of subscribers](https://example.com/Screenshot_2019-06-14.jpg "A flowchart describing how user data flows from a publisher, to a proxy, and to a group of subscribers")

It takes an extra few seconds of your time, but it is one small way you can help make a better Internet for everyone.

P.S. – The text wrapped in quotation marks between the parentheses adds the title HTML attribute to your image, so the text appears as a tooltip when you mouse over the image. The more you know!

Photo by Roman Kraft on Unsplash

Growing up with easy access to the Internet grants the privilege of experiencing effortless knowledge and high availability of information. Wikipedia is an example of 21st century cooperation and collaboration. For many, it represents a beacon of free information and self-education. Some might credit it for charting wider participation in the movement towards free content and open resources.

Yet Wikipedia remains a tool of power and privilege, absent for many as societal myths perpetuate in the lives of children. As children are exposed to the Internet at earlier ages, their comprehension and correlation to the real world is in the context of living in a digitized society. In simpler words, everything they ever know always has technology, tablets, smart-phones, and smart devices present. There is no split experience of going from have-nots to haves.

For me, the split experience was my experience. As I became older, information became within click’s reach and a moment of patience. In prior generations, factual information existed in factual places, such as a library or a home study (for those privileged to own encyclopedias in their homes as children). Caught without any reference to support or dissent against a societal myth, the truth remained far enough out of reach for only the most motivated (and privileged) to continue searching for truth.

Today, this process takes seconds. From devices in pockets to sitting at desks. Desks now conveniently feature a computer workstation over “old school” writing utensils, books, and paper. Externally-verified information is available for those who seek truth or supporting evidence to define their own understanding of truth (additionally, misinformation is equally spreadable depending on prior motivations, but will not be covered in this short opinion).

If the answers are so near and available, it enables increased self-awareness among youth. The Internet’s ludicrous goals of a more interconnected species came not boldly, but subtly. It crept into our culture and perception of the world. As more gratis and factual information (academic work, scientific research, investigative reporting, and others, often under free licenses) creeps into the search-able Internet, answers remain convenient with a few taps on an LCD screen. Perhaps today’s youth, privileged to early Internet exposure, have subconsciously understood their perception of information as naturally free and available (with different understandings of what is true or false). For those searching for secularism, the true science remains easy to find and discover.

And thus, the root of the issue. What is the role of privilege? What early childhood development possibilities are created within information-rich societies? Are children better able to cast away their own doubts and suspicions? Do they avoid buying into a system designed to feed from them?

But what of the contrary? What is the experience to go without this privilege? It can be lack of access to information. The perception of information is opposite of naturally free and available, but costly and hidden. The odds are stacked higher against you because of poor accessibility to tools and resources.

But is access to free knowledge like Wikipedia truly inaccessible for even the most impoverished? Since even some of the poorest countries have better access to smart-phones than piped water, exposure to the wider Internet (including Wikipedia) is inevitable. But the timing is late. The critical period of early childhood development is missed. Early childhood development has three phases: conception, the first 1000 days (birth to three years old), and pre-school / pre-primary years. The brain of a child is most sensitive, almost like a sponge, in those first 1000 days. Researchers defend this period’s impact on child-society and community cohesion as critical, even influencing the neurobiology of peace.¹ So then what of those who have the privilege of exposure to technology in those first 1000 days? What of the billions, nearly trillion, dollars of advertising that slip through the cracks of what these children are exposed to? Are we subtly being written before language is even learned?

In this way, the open and closed systems compete in the Internet state. There are positive and negative qualities from both free information and black-box systems in information-rich societies. Wikipedia is a privilege, but it is only one small part of something bigger. A privilege of truth. A privilege of access. A privilege of self-liberation.

¹ Britto, Pia. “Building Brains, Building Futures.” Online webinar, UNICEF, 24 January 2018. Keynote address.

Photo by Clem Onojeghuo on Unsplash.

Across this spectrum of bold headlines and addicting scrolling, I began to wonder about identity. What determines how we choose to identify where we originate from? What makes us decide to disassociate from our birthplace? What parts of our culture make us proud and content and what parts are like fresh wounds withheld from time and space needed to heal? I started to wonder about my own identity and what it means to me to be defined as an American.

I fight a growing sense of dissatisfaction and disbelief of what I read happening each day. As I read about the United States and how its citizens are represented on a global stage, a feeling of repulsion sinks into my stomach. Society greatly shaped my perspective of what it meant to be an American as I grew up. What is around me now is contradicting: the qualities of inclusiveness and diversity espoused to the identity of being an American are the same qualities I feel are under attack.

One afternoon as I walked back to my Chicago apartment, I passed a Mexican restaurant. As I walked by, I searched for a menu to measure how authentic it would be compared to offerings in Atlanta (I’ve notoriously had a difficult time finding authentic Mexican food north of Virginia). However, I was disappointed, as the choices fell into the category of American-Mexican food and not the authentic dishes I craved.

But even though I continued on and left the food behind me, the restaurant didn’t leave my mind. As I continued to ponder on what it means to be American, I couldn’t get this restaurant, and countless others like it, out of my mind. One of the most unique observations of my travels is how culturally homogeneous so many countries are. From my experience living in Europe and visiting India, the difference of cultural diversity from my American experience was impossible to miss. Each country was mostly shaped by its dominant ethnic group. To see a Nicaraguan in Croatia or a Swede in India would be a memorable encounter because it was outside of preconceived expectations. But in America, I board a New York City, Chicago, or Washington DC subway, and I always remain pleasantly surprised at how unique and different all the passengers are.

But what of the Mexican restaurant? If my train rides reflect this unique cultural identity, what is the significance of the Mexican restaurant and why can’t I forget it?

Suddenly, I realize perhaps American culture is several shards of all other cultures that assimilate here. Instead of the restaurant being an imitation of the real thing, what if it is as real and independent of an experience as the original? Instead of being a clone or a derivative, what if they are their own original craft and subculture? In a way, they are mostly unique – many of the fusions of culture, from food to celebrations, and architecture to film are only found in this sort of combination here.

These pieces of foreign culture are transplanted seeds, taken from their native soil and planted into a new environment. It requires adaption and perhaps creativity too. But these pieces of culture, whether they are motivated to be imitations or not, are created from a place of love and genuine human connection. They stem from a desire to celebrate who we are and where we come from. Furthermore, they offer an opportunity to share these things with others and to pass along the memories and experiences to others in the hopes that they too will see the world from a different perspective, if only for a passing moment.

As I continue to read past another day of headlines, I feel hopeful knowing this spirit of America, although challenged today, remains and exists. In a city like Chicago, it would almost be impossible to miss this range of diversity. While some choose to wrap words of hate and fear around the red, white, and blue stripes of the American flag, I try to remain mindful to keep this flag closer to me too, and wrap it around my values of love and compassion for others, and what it means to me to be an American in this political era.

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

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

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

Demographic survey / marketing campaign 🔗

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

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

Building the questions 🔗

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

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

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

Noting the working process 🔗

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

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

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

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

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

Code of conduct 🔗

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

Background 🔗

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

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

Seeking positive engagement 🔗

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

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

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

Fedora Appreciation Week 🔗

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

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

Long-term 🔗

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

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

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

Short-term 🔗

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

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

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

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

Tying it together 🔗

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

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

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

Come say hello! 🔗

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

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

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

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

Heterogeneous group icon by Magicon from the Noun Project

So why am I writing about WiCHacks? I signed up as a volunteer for the event this year. I would help with the setup, running the event, and packing it up. During my experience as a volunteer, I met some other awesome people, saw some really cool projects, and discovered an inviting and inclusive community on campus.

Opening the doors for WiCHacks 🔗

I was scheduled for the Saturday morning shift (8:00am - 1:30pm) and the Sunday morning shift (11:00am - 5:00pm). When I arrived on Saturday morning, the prep work was just beginning. The WiC team had breakfast pizza for all the volunteers, which was surprisingly delicious!

After grabbing a quick bite to eat, I began helping with setting up sponsor tables, moving equipment and tables around, and other miscellaneous tasks to prepare for the first influx of people, scheduled to arrive around 10:00am. After two hours of setting up, the hackers began streaming into the Golisano building and filling the atrium. As more and more people began to roll in, it was awesome to see how diverse and culturally unique the room was. There were people of all races, from all over the country and even the world, that had come here to join other women hackers in a weekend of creativity and fun. With such a wide palette of culture and ideas, I was anticipating to see some awesome creations in my time volunteering.

WiCHacks begins 🔗

After an opening keynote by the WiCHacks committee leader Susan Heilman kicking off the hackathon, the hackers were served a quick lunch before jumping into brainstorming and programming.

For those who had never programmed before, there was a special Newbie Track that aimed to help teach some of the basics. It helped give girls who didn’t know anything about programming a booster to also create something during the weekend.

GO HACKERS GO! There are 117 people listed as apart of teams already make sure you register your team #wichacks #soundoff

— WiCHacks @ RIT (@wichacks) February 27, 2016

After lunch, the hacking began! Teams could go into a room and have access to whiteboards, plenty of chairs, and outlets to charge devices. If needed, Major League Hacking also had a hardware lab where people could rent out laptops and other accessories during WiCHacks.

Accidentally discovering something awesome 🔗

After my volunteering shift ended, I had a homework assignment for one of my classes due at midnight. I had made plans many months ago after 7:00pm that night, so I had to work on the assignment that day to submit in time. I went up to an empty IST department lab, fired up my laptop, and began working. Suddenly, a team of five girls walked into the lab and began setting up close to the whiteboard near me.

I was curious after a while to hear what they were working on. I kept hearing the words “open source” and “FOSS” dropping, and it pulled my attention in. I learned that their idea was to make a social platform to help make it easier for girls to get involved with open source software. The plan was to collect an inventory of open source projects that need help and connect interested girls with project mentors to guide them in contributing.

There was overlap with some ideas I’ve had while working with the Fedora CommOps team towards boosting #WomenInComputing in Fedora’s community. I was anticipating hearing out their idea and seeing what they would come up with!

Their project would be known as OpenCircle. After 6:45pm rolled around, I started packing up my gear to head out for the evening. The OpenCircle team was busy hacking away on laptops or making slight alterations to the whiteboard mock designs they had drawn. It was clear that the creativity and motivation were running high when I left.

I was envious that I wasn’t there for the rest of the evening. Later on that night, Insomnia Cookies delivered to the hackathon. There was also a spontaneous dance party in the atrium of Golisano. Next year, I’ll have to make sure I’m able to stay for the entire night!

What's better than an impromptu dance party at @wichacks? @RITWIC #wichacks16 pic.twitter.com/NvvTZC4scO

— Major League Hacking (MLH) (@MLHacks) February 28, 2016

Closing out WiCHacks 2016

After a final push by hackers throughout the night, hacking ended at 12:00pm the next day. After a lunch break, the hackers returned to the auditorium in time  to present their projects. Before the deadline, all the teams added their projects to the WiCHacks DevPost. You can also find the list of projects submitted over the weekend there.

After helping with some other closing work, I wanted to listen to some of the presentations given by the teams. Some people designed some really cool apps, like Pink Planet, Resumatch (a play on Tinder but with resumes), and the ever creative Loocator.

However, the OpenCircle team was the presentation I was looking forward to the most. While they noted that they hadn’t had the time to demo it as completely as they wanted, the idea behind their product was there and it was pretty solid as a prototype.

After the weekend was over, I submitted a simple pull request and filed two issues against the project. I’m anticipating any future development the OpenCircle team collaborates on and seeing where their idea goes!

WiCHacks 2016: In retrospect 🔗

I was slightly nervous when registering as a WiCHacks volunteer as I had no idea what to expect or the type of community that it would attract. However, after spending time with the volunteers, hackers, organizers, and mentors, it was clear that the environment was inclusive, welcoming, and receptive to all people.

WiCHacks is a well-organized, powerfully motivating event and something more and more people should look into checking out on the RIT campus each year. WiCHacks empowers women interested in computer science to do something awesome in the presence of people who want to see you succeed. The mentorship and leadership at WiCHacks definitely supports this.

Great job to the WiC team for organizing this, and I look forward to participating as a volunteer again next year!