My brief readout is a guided reflection using questions shared by Matt Germonprez. This reflects my review of our work as a team to date and also shares some of my hopeful outlooks for what our amazing team can accomplish together. This readout will cover (1) our accomplishments as a team, (2) what was expected and surprising, and (3) what we could change in the next year.

CHAOSS accomplishments & learnings 🔗

Three achievements and aspirations stand out over the past year:

1. Established process management and a team workflow.
2. Created a small but active Community of Practice (CoP).
3. Sharing our results with CHAOSS and the Open ecosystem.

Processes & workflow 🔗

For direct participants of the team, the Ford Foundation funding did not come with strict requirements or success metrics. As we assembled our team, we were given the discretion of how to conduct a D.E.I. review for the project and determine the best course of doing that. This allowed for creative freedom to figure out what would work best for CHAOSS. Additionally, I could not identify a straightforward way to discover other Open communities and projects doing our kind of work. Since there were also not many other known successful models to follow, we combined our shared experiences across multiple Open communities to build our team, identify main areas of focus, and engage the community around our efforts.

This is an achievement because we collectively created an active group that makes incremental, positive changes to CHAOSS. This is a model we could share with other projects so that others can learn from our experiences.

Community of Practice 🔗

Our team is a small but engaged group of D.E.I. practitioners. We share a connection through our ongoing review of the CHAOSS Project, but we also give and take from our own personal experiences outside of CHAOSS. Our group regularly meets and discusses complex, difficult issues that are both (a) not easy to discuss openly and (b) applicable to many communities beyond only CHAOSS. Our team meetings are a safe space that promotes honest and constructive discussion centered on diversity, equity, and inclusion. In addition to our recommendations and direct efforts with CHAOSS, I often reflect on our conversations as a team when working with other Open communities. An example of this is how we built a list of questions to get a “pulse” from the community on their feelings about CHAOSS.

Sharing results with CHAOSS and beyond 🔗

This is aspirational and not yet fully realized. Our team has collected a solid portfolio of stories and experiences that other communities would stand to benefit learning from. I consider this a current achievement because while our work does specifically look at CHAOSS, we also often reflect from a general perspective and how a topic of interest might look in other communities. When the time comes to package our findings, I believe we are setting ourselves up for easier messaging and outreach opportunities in the future.

According to expectations 🔗

While I have worked in Open Source D.E.I. communities since 2015, I have never conducted an applied research review for community D.E.I. before. I did not come into this with strong immediate expectations because it would inevitably reflect the backgrounds and strengths of the team we would assemble. However, I did have specific hopes or things I hoped would be realized by this work.

As expected 🔗

• Data-driven approach: We began this work without a strong representation of the state of CHAOSS. What do contributors think about the project? While data is not a universal panacea, we gravitated to a community survey early on because we needed to understand the community experience better first before making serious suggestions.
• Time zones are hard: Our team was spread out across North America, Africa, LATAM, and Europe. Additionally, the work with CHAOSS was also a part-time venture for most of us, in addition to primary employment. Calendars and schedules are hard to get right. Since our team’s organization was ad-hoc, momentum would occasionally slow for some periods.
• We have an amazing team! I expected great things once we identified our roster. We have also had more amazing people join us over time and add new passion and insight to our focus as a group.

Surprises 🔗

• Documenting our impact is not always intuitive: While we have done internal storytelling work within the CHAOSS Project, we do not have a good record of our achievements to date. Our linear progression does not lend itself easily to self-reflection and recalibration. Although much of our focus is on the CHAOSS community survey and CHAOSS Africa, we also facilitated several other notable achievements in the project in the last year. See the following examples:
  • Supporting the establishment of a Code of Conduct Committee.
  • Community office hours for newcomers.
  • Improved, peer-to-peer onboarding experience in CHAOSS.
  • Increased efforts in CHAOSS mentored projects (e.g. Outreachy and GSoC).
  • Recommending changes to the project and community, like broader localization to Chinese & Spanish and establishing a D.E.I. council.
• Losing and regaining steam on the survey: Although the community pulse survey was one of the earliest tasks identified in our work, launching a first survey proved to take a lot of resources from the team. We briefly stalled out on the survey effort while focused on other areas (like listed above). While our team was able to achieve many smaller victories for CHAOSS with low-hanging fruits, it took a sustained focus and slowdown on new topics to achieve larger contributions like the community pulse survey.

Changes for the CHAOSS team next year 🔗

Looking ahead to 2023, I hope to strengthen our efforts as a team in these areas:

1. Packaging our work
2. Dissemination of our work

Packaging 🔗

Our work stream was linearly ordered and we took a forward-looking approach. Now is a good time to look back and reflect on our results to date. What are our key findings and observations? What suggestions will we make to CHAOSS? How could other communities learn from our experience running this review? One task for us as a team is to identify key messages and themes so that dissemination into broader domains is possible.

Dissemination 🔗

Once we package our work, notes, and reflections, we should take an active approach to disseminating and sharing our work. This includes both the CHAOSS Project and a more general audience. For the CHAOSS Project, this could be a written report, presentations to the CHAOSS board, speaking at CHAOSScon, and outreach to the multiple Working Groups. For a general audience, this could include speaking at industry conferences, sharing our work with other Communities of Practice, social media, or other ways of promoting our deliverables.

This year, the UNICEF Venture Fund celebrates five graduating companies from a recent investment round. For the first time, many of these companies are exiting from the Venture Fund having already earned recognition as Digital Public Goods (DPGs). With the support of a cross-sectional team of mentors, these graduating companies worked to achieve compliance with the DPG Standard.

The Digital Public Good Standard offers a nine-point baseline for evaluation and recognition of Open Source software, content, data, and standards that adhere to privacy and other applicable laws and best practices, do no harm by design, and help attain the Sustainable Development Goals (SDGs). Once a solution is recognised as a digital public good it is discoverable on the DPG Registry.

This recognition acknowledges their use of vetted Open Source licenses, useful documentation, and adherence to relevant best practices and local data protection laws. What makes this achievement a first for the Venture Fund is that these recognitions were achieved by the companies during the investment round. Typically, companies that go on from the Venture Fund achieve recognition after a year or more of graduation. This new shift is made possible by the growing investment in Technical Assistance at the Venture Fund and the leadership of a robust team of mentors.

This article introduces the Technical Assistance mentoring programmes offered by the UNICEF Venture Fund, the addition of new mentors in the last year, the shift of mentor focus around the DPG Standard, and the results achieved to date from the latest graduating Venture Fund cohort.

Origins of Technical Assistance at the Venture Fund 🔗

The Venture Fund offers different areas of Technical Assistance to start-up companies who apply and are selected to receive early-stage seed investment by UNICEF. Originally starting in 2018, the Technical Assistance programmes only included Business Development and Open Source. Over the years, we have piloted and pivoted mentorship models with input from our portfolio of startups. Today, the Technical Assistance programmes cover a range of topics across an experienced team of mentors, depending on the relevance to the start-up companies:

• Blockchain with Arun Maharajan and Alex Sherbuck (former)
• Business Development with Jamil Wyne and Philippa Martinelli (former)
• Evidence of Impact with Milena Bacalja Perianes and Jennifer Sawyer
• Data Privacy & Security with Lydia Kwong
• Data Science & A.I. with Daniel Alvarez
• Open Source with Justin Wheeler, Abigail Cabunoc Mayes (former), and Vipul Siddharth
• Software Development with Iván Perdomo

The mentors work closely with the experienced team of portfolio managers (Meghan Warner, Kennedy Kitheka, and Madison Marks) to guide and coach Venture Fund companies to achieve their targets and success indicators during the investment round.

Starting in 2021, the Venture Fund broadened the Technical Assistance programmes to include Software Development, Data Science & A.I., Data Privacy & Security, and Evidence of Impact. This was a marked change in growing the support and expertise made available to start-up companies during their investment round. However, as the team of mentors and Technical Assistance offerings expanded, there was a growing need to bring a common rallying point across all programmes. How could the mentors ensure their Technical Assistance programmes complemented one another without duplicating topics or repeating conversations?

Further complementing the core Technical Assistance programme, specialized workshops were held by like-minded institutions outside the Venture Fund’s core team of mentors , along with personalized mentorship sessions. The recent Blockchain Cohort, for example, benefitted from targeted mentorship from AW3L, a blockchain consulting firm that share many of UNICEF’s values around leveraging blockchain for social impact.

“Blockchain has immense potential, but it remains just a tool and its impact is dependent on what we do with it. That’s why it is crucial to have local entrepreneurs on the ground building use-cases that solve real problems unique to their geography. We are therefore extremely happy and proud to support UNICEF and its portfolio companies to tackle real-world problems in emerging markets by utilizing blockchain technology.”

Martijn van de Weerdt, Founder, AW3L

How the DPG Standard unified the mentoring streams 🔗

The DPG Standard became a common rallying point for the UNICEF Technical Assistance programmes. As our mentoring programmes increased and topic areas broadened, we needed coordination and a synchronized stream of Technical Assistance programmes. In the last year, the Venture Fund reviewed its workplan development and strategy to enable more solutions to achieve recognition as a digital public good at or near the graduation point for a Venture Fund portfolio. The most recent graduating cohort, the 2021 Blockchain cohort, represents this improved alignment, with 4 of 5 companies receiving recognition of their products as digital public goods by their graduation this year.

How does recognition of an open solution as a Digital Public Good help Venture Fund startups? It is an acknowledgment by the Digital Public Goods Alliance of a commitment and adherence to best practices and steps taken to protect data privacy and do no harm. Additionally, recognition as a DPG unlocks stronger potential for adoption and deployment of the solution by global stakeholders by providing greater visibility in a public roster of open solutions that adhere to best practices and standards. The recognition of 80% of an off-boarding Venture Fund portfolio speaks to both the intrinsic capabilities of the companies and the value of the Technical Assistance programmes and mentorship provided to them by the Venture Fund.

While past Venture Fund companies have received recognition as digital public goods before, this is the first time that a company achieved the recognition at the time of their graduation from the Venture Fund. Aligning the Technical Assistance programmes around the DPG Standard provided common frameworks and mental models for the diverse team of mentors to support the companies and help them achieve the Standard as an important part of their product development lifecycle.

“As an early-stage startup, we struggled with a clear business model. Especially in the last six months of the investment, support from the mentor network helped in building clear business growth and impact metric plans. Also a year ago, we were very heavy on the tech side but lacked considerable planning on network and visibility growth. We have developed a customer persona and a pricing model, and now have a clearer vision of our Total Available Market, Serviceable Available Market, and Serviceable Obtainable Market (TAM, SAM, and SOM) models.”

Rumee Singh, Co-Founder, Rumsan

Further, farther, together 🔗

What comes next? The Technical Assistance programmes at the UNICEF Venture Fund are gearing up for additional cohorts benefiting from our seed-stage investment: a Data Science & A.I. cohort and an upcoming Blockchain cohort. These early-stage companies undergo a technical assistance programme involving a technical and strategic workshop series and monthly mentorship meetings. Graduates of our seed-stage investment that  have received additional capital through our Growth Funding to take their solution to the next level of impact also benefit from customized mentorship to support their evolution from good prototype developments to solutions that can be implemented and scaled, with sustainable business models and proven pilots.

Additionally, mentors are developing digital toolkits to enable Venture Fund companies and anyone to read up and study best practices for building and sustaining digital public goods. Most of these toolkits will be released digitally online under Open Source licenses. You can find three of these toolkits below:

• Data Science & A.I.
• Drones
• Open Source

Since the first Technical Assistance programmes were launched in 2018, the Venture Fund has seen improved results that correlate with the Technical Assistance programmes. In the most recent Blockchain 2021 cohort, across 500+ hours of mentoring, the cohort collectively reached over 700,000 beneficiaries, raised $4M in follow-on funding, and 4 of 5 graduating companies were recognized as a digital public good before graduation. This also marked a new record of external contributors, with a total of 39 people who contributed to repositories across all portfolio companies. The expert guidance and coaching provided by the team of UNICEF mentors aids the start-ups in achieving new record heights.

“UNICEF’s support helped Xcapit build value, with a premium put on discovery, iteration, survey, and experimentation with the end user. The guidance at the right time is priceless. It prevented us from facing a major problem in the future when our blockchain UNICEF mentor guided us when we were deciding the technology to create our wallet. Changing our mindset to become a fully open source company was also challenging. We had the best guidance we could ask, and we successfully overcame the difficulties and doubts, understanding the benefits of open collaboration.”

Antonella Perrone, COO, Xcapit

Contribute to Technical Assistance knowledge and mentoring 🔗

The UNICEF mentor toolkits are open source and you can also participate. The toolkits are currently accepting contributions for UI/UX and front-end development, as well as content curation and authorship. Get involved with the toolkits by participating via GitHub:

• UNICEF Inventory theme (see “good first issues”)
• UNICEF Open Source Inventory
• UNICEF Data Science & A.I. toolkit

With the Digital Public Goods Alliance, we built upon our learnings and successes from portfolio companies and created the DPG Accelerator Guide as a collection of resources for accelerators to also support local ventures in developing digital public goods, setting them up for scale and impact.

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.

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

Preface 🔗

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

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

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

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

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

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

Free Software sustainability is here to stay. 🔗

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

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

sus·tain·a·bil·i·ty

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

Oxford U.S. dictionary

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

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

The maintainer and the corporation 🔗

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

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

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

Free Software will have its ethics interrogated. 🔗

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

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

Ethical Source? 🔗

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

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

“Join, or Die.” 🔗

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

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

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

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

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

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

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

“The world the children made.” 🔗

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

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

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

What now? 🔗

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

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

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

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

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

Overview 🔗

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

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

If you are hooked, read on.

The Sticky Idea 🔗

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

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

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

Open Source Accountability Goals 🔗

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

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

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

Facilitation of Authentic Participation discussion 🔗

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

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

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

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

Facilitation, Roosevelt-style 🔗

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

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

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

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

How did facilitation start? 🔗

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

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

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

Is there a next chapter to this story? 🔗

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

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

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

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

Closing thoughts 🔗

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

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

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