During this round, my co-mentor Joseph Gayoso and I experimented with new approaches at handling the tsunami wave. There are two competing forces at play. One, you need to provide engagement to top performers so they remain motivated to continue. Two, you need to provide new opportunities for emerging contributors to distinguish themselves. It is easier to do one of these but hard to do both simultaneously. However, Joseph and I agreed on something important. We agreed that all applicants should end the contribution phase with something practically useful. As mentors, we asked ourselves how to prepare applicants to be successful open source contributors beyond this one month.

In this article, you will get some practical takeaways for mentoring with Outreachy. First, I will share our practical approach for structuring and planning an open source project during the Outreachy contribution phase. Second, I will detail the guiding philosophy Joseph and I follow for how we planned the contribution phase.

About Outreachy 🔗

This article assumes you already know a thing or two about the Outreachy internship program. If not, Outreachy provides internships in open source and open science. Outreachy provides internships to people subject to systemic bias and impacted by underrepresentation in the technical industry where they live. You can read more on the Outreachy website.

What makes Outreachy unique is that the internships are remote and often open without geographic or nationality constraints. Applicants from nearly every continent of the world have participated in Outreachy. Also, Outreachy is distinguished by the contribution phase. For a one-month period, approved Outreachy applicants are encouraged to participate in the project community as a contributor. Applicants spend the month learning about the project, the community, the mentors, and the work involved for the internship. This provides applicants an opportunity to grow their open source identity. It also gives mentors an opportunity to assess applicants on their skills and communication abilities.

However, this contribution phase can be intimidating as a mentor, especially if you are new to mentoring with Outreachy. A wave of people eager to contribute could suddenly appear overnight at your project’s door steps. If you are not prepared, you will have to adapt quickly!

Pre-Requisite Tasks: Raising the Outreachy bar 🔗

My co-mentor and I knew that a wave of applicants was coming. However, we didn’t expect the wave to be as big as it was. After the first week of the contribution phase, we knew we needed a better way to scale ourselves. We were limited in our person-power. The approach we took to addressing the mental overload was defining pre-requisite tasks.

We defined pre-requisite tasks as tasks that any applicant MUST complete in order to be considered eligible for our internship. Without completing these tasks, we explained that final applications would not be accepted by mentors. The defining characteristics of these pre-requisite tasks were that they were personalized, repeatable, and measurable. We came up with five pre-requisite tasks that all applicants were required to complete beyond the initial qualification for Outreachy:

1. Set up your Fedora Account System (FAS) account

2. Set up a personal blog

3. Write a blog post that introduces the Fedora community to your audience

4. Promote your intro blog post on social media

5. Write an onboarding guide for Outreachy 2025 applicants

How were initial contributions personalized? 🔗

Each of these tasks were personalized to each applicant. They each have a unique account profile, with their pictures, time zones, and chat system usernames. The personal blog is a personal space on the Internet for each applicant to start writing new posts. The blog post prompts encouraged applicants to start filling up their blogs with Fedora content. The social media post helped applicants promote themselves as budding open source enthusiasts in their existing web spaces.

This approach had two benefits. First, it provided clear guidance to all newcomers and early-stage applicants on how to get started with contributing to Fedora for the Outreachy internship. This took a burden off of mentors answering the same questions about getting started. It also gave new applicants something to start on right away. Joseph and I were able to put more time into reviewing incoming contributions and brainstorming new tasks.

Portfolio-driven submissions for Outreachy 🔗

Toward the third week, many applicants had completed the pre-requisite tasks and were ready for more advanced tasks. Many had already taken on advanced projects already, beyond the pre-requisite tasks. Although the pre-requisite tasks did reduce the applicant pool, there were still between 20-30 people who completed them all. Again, the approach had to adapt as our ability to keep up with new contributions slowed down.

From here, we encouraged applicants to build personal portfolio pages that described their contributions with Fedora. This encouraged applicants to use the blog they built in the previous tasks, although they are not required to use their blog to host their portfolio. The only requirement we added was that it should be publicly visible on the Internet without a paywall. So, no Google Docs. Most applicants have ended up using their blog for this purpose though.

How did a portfolio help? 🔗

Building a portfolio solved multiple challenges for our Outreachy project at once. First, the portfolios will simplify how the project mentors review final applications after the deadline on April 2nd, 2024. It will be streamlined because we will have a single place we can refer to that describes the applicant’s achievements. It gives us a quick, easily shareable place to review and share with other stakeholders.

Second, it ends up being something useful to the applicant as well. The portfolio page captures a month’s worth of contributions to open source. For many applicants, this is their first time ever interacting with an open source community online. So, it is a big deal to block out a month of time to volunteer on a project in a competitive environment for a paid, remote internship opportunity. Writing a portfolio page gives applicants the confidence to represent their contributions to Fedora, regardless of whether they are selected for the Fedora internship. It becomes a milestone marker for themselves and for their professional careers.

Our philosophy: You win, we win. 🔗

This idea of applicants building something that is useful for themselves underpins the approach that Joseph and I took on structuring our non-engineering Outreachy internship. If I had to summarize the philosophy in one sentence, it might be like this:

Everyone who participants as an Outreachy applicant to Fedora should finish the contribution phase with more than they had at the start of the contribution phase.

myself

Our philosophy can be applied to engineering and non-engineering internships. However, applying the philosophy to our non-engineering project required improvisation as we went. There are examples of design-centered Outreachy internships, but I have not seen a marketing or community manager internship before. This was a challenge because there were not great models to follow. But it also left us room to innovate and try ideas that we have never tried before.

Adopting this philosophy served as helpful guidance on planning what we directed applicants to do during the contribution phase. It allowed us to think through ways that applicants could make real, recognizable contributions to Fedora. It also enables applicants to achieve a few important outcomes:

1. Get real experience in a real project.

2. Build their own brand as open source contributors.

3. Gain confidence at collaborating in a community.

The contribution phase is not yet over. So, we will continue to follow this philosophy and see where it guides us into the end of this phase!

Share your Outreachy mentoring experience! 🔗

Have you experienced or seen a marketing or community manager internship in Outreachy before? Know a project or a person who has done this? Or is this totally new to you? Drop a comment below with your thoughts. Don’t forget to share with someone else if you found this advice useful.

Product roadmaps are something many projects struggle with. It fits into the communications and outreach umbrella, which unfortunately is typically an underresourced part of many open source products. They are one small part of a larger strategy around openness and transparency. If customers and stakeholders know what to expect, they gain more confidence in the product and company mission. For instance, this is especially true when the company continuously delivers on its roadmaps and meets its ambitions. As a result, delivering on those ambitions leaves a strong impression.

Highlights from Proton product roadmaps 🔗

Of particular note, these product roadmaps do the following things well from a messaging point-of-view:

1. Builds context with previous work delivered in the last year for the product.

2. Several clearly-defined goals and ambitions for each product are defined and explained. The aspirations for the coming year are spelled out and users can begin to form realistic expectations about what new features to anticipate.

   • Some highly-motivated individuals may use this as an opportunity to make their first contribution to the product, whether in the form of feedback or code.

3. Strong call-to-action at the end of each article, where Proton defines how people can participate and engage with feedback about the products.

Check out each of the three product roadmaps below and let me know what you think about them in a comment on this post.

Proton Mail & Proton Calendar 🔗

[…] we want to provide an update on what’s coming next for Proton Mail and Proton Calendar. As 2022 wraps up and we look into the new year, we want to develop stronger protections against technologies that invade your privacy, improve your reading experience, and make your day more productive through deeper integrations between our products. 

proton.me/blog/proton-mail-calendar-roadmap

Proton VPN 🔗

In March, we shared our 2022 roadmap for Proton, including Proton VPN. Now that we’ve reached November, we feel it’s a good time to revisit our progress this year and explain what you can expect from Proton VPN in the near future.

protonvpn.com/blog/proton-vpn-roadmap-spring-2023/

Proton Drive 🔗

In September 2022, we were excited to launch Proton Drive and introduce the first standalone Proton Drive paid plans. As with all the services we’ve rolled out over the years, we know the launch is just the first step. The real work is in the continual improvements, advancements, and added features that follow. Building an encrypted file storage service is not easy, particularly one that uses end-to-end encryption on both your files and file metadata like Proton Drive.

Many of you have asked us what is next for Proton Drive, and today, we wanted to share with you a short-term roadmap of what you can expect in the coming quarters. Of course, we also have longer-term roadmaps. We look forward to sharing those and keeping you updated on the latest developments as Proton Drive progresses.

proton.me/blog/proton-drive-roadmap

Photo by Slidebean on Unsplash. Modified by Justin Wheeler.

May I continue to hone this practice into an art. 🙏🏻 This is my meditation for the day!

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.

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.

The UNICEF Innovation Fund invests exclusively in Open Source technology – with today’s rapidly evolving innovation landscape, Open Source software, hardware, data, and content not only create value and generate revenue, but also ensure greater collaboration and impact. This reflection is a look back at Open Source activity and participation stemming from the UNICEF Ventures Team from June 2020 to date (July 2021).

By the end of this article, you will have a better understanding of the evolving and forward-thinking approach to Open Source taken by the UNICEF Office of Innovation.

This article looks at a few aspects of Open Source engagement at the Innovation Fund:

1. Support models
   1. Legal & policy
   2. Building and leveraging from the community
2. Case study: Cloudline and upstream engagement

New to Open Source at UNICEF? 🔗

If you are hearing about the UNICEF Open Source Mentorship programme for the first time, check out this introduction post to get important context behind why UNICEF invests in Open Source mentorship and support for Innovation Fund portfolio teams:

/blog/2021/07/unicef-open-source-mentorship/

Innovation Fund support models 🔗

Start-ups receive both funding and customized mentorship during their 12-month investment period with the UNICEF Innovation Fund. Since the Innovation Fund launched in 2016, the Innovation Fund team noted the impact of hands-on guidance to help start-ups understand how to work open and lead open. Start-ups receiving Open Source support were better equipped to develop sustainable business models that made Open Source intellectual property work with them instead of against them.

By the end of the 12-month investment cycle, graduating companies achieve the following milestones in place with their projects:

• Solid understanding of Open Source licenses and different business models depending on a permissive or copyleft strategy.
• Laying foundations for growing or participating in friendly, inclusive communities.
• Documentation site to showcase their Open Source work, and how to get involved.
• Continuous Integration pipeline to test new changes in the code-base before they are added, and avoid common human errors.

Across these milestones, three themes of support have emerged as as most essential in the past year: legal & policy, building and leveraging from the community, and building in the open.

Legal & policy 🔗

The UNICEF Innovation Fund is unique in Venture Capital on its open-first investment strategy. Start-ups receiving UNICEF funding are obligated to either create their own Open Source works or contribute to existing Open Source works. This leads start-up teams to ask more questions: how does this work in a legal sense? How do you establish a sustainable business model with Open Source dependencies and the different types of license models that exist (e.g. permissive and copyleft)? These are the questions that start-ups receive tailored guidance on from the Open Source Mentorship programme.

How did the Open Source Mentorship programme support both start-ups and UNICEF Country Offices receiving funding from the UNICEF Innovation Fund? The programme improved business and legal resources and referrals for managing Open Source intellectual property. This was primarily done by creating a self-serve knowledgebase of legal, governance, and tech policy: the UNICEF Open Source Inventory. The Inventory was created in close consultation with start-ups receiving UNICEF funding, leading industry experts in areas such as Open Hardware and open design, and other existing Open Source communities of practice.

Building and leveraging from the community 🔗

Over the past year, we also saw more upstream collaboration. UNICEF Innovation Fund start-ups collaborated on existing projects like the PX4 Drone auto-pilot software instead of reinventing the wheel themselves. This enabled the work done with UNICEF funding to go further and impact the wider ecosystem, instead of an individual project with highly-specific use cases.

Furthermore, as the Innovation Fund portfolio continues to grow, new inductees in the Open Source Mentorship programme are able to build on top of work done by previous portfolio companies. This accelerates the rate of development for the new inductees and gives them a model of success to look towards during their engagement with UNICEF.

For example, two companies from the 2019 Drones cohort created documentation websites that were used as models for the 2020 Generation Unlimited cohort. qAIRa from Perú and Rentadrone from Chile created documentation websites using the popular toolchain Docusaurus, created by Facebook’s Open Source Program Office. The work of qAIRa and Rentadrone was leveraged as models by VRapeutic and I-STEM in the 2020 Generation Unlimited cohort. Using graduated companies as models accelerated both technical and content development for the new teams when they had relatable models to use in building their own Open Source documentation websites.

Innovation Fund case study: Cloudline and upstream engagement 🔗

Cloudline Africa (South Africa) operates small-scale autonomous airships that have longer endurance and range than current commercial drones; their solution will help deliver medical supplies to hard-to-reach communities and reduce operational costs in the last-mile.

Four highlights from Cloudline’s period with the Innovation Fund are below:

• The team launched the airship with a payload capacity of 10 kgs with a 50 km range.  
• Full endurance capability (40km/h) along with automated waypoint flying. 
• Contributed flight control software to the PX4 upstream community by introducing a new mode of aircraft to the community in the form of airships.  
• Cloudline received the Fast Company South Africa Most Innovative Company Award 

“Our greatest triumph of the year was the flight of our pre-production airship. Capable of a 10kg useful payload and a 50km range, this aircraft is ideally suited to medical logistics and other high-value scheduled deliveries.” — Spencer Horne, Co-Founder

Going upstream 🔗

Contributions made to another popular upstream community was another major highlight of the Open Source Mentorship programme. Furthermore, the contributions were not casual “drive-through” contributions; they were consistent and focused broadly around the ecosystem instead of a single repository of source code.

During the mentorship programme, Cloudline added 61 commits across four repositories. The summary of their contributions were adding a new vehicle type to the PX4 auto-pilot software: airships. The team first opened a discussion on the PX4 community forum. After getting feedback from a developer, they proceeded to add the Cloudline airship into the upstream software. This was followed by documentation additions with controller diagrams and simulation instructions. Through their contributions, a wider network of developers can simulate and interact with airships similar to the one created by Cloudline.

But the contributions did not stop at code. Cloudline developer Anton Erasmus delivered a deep dive presentation at the PX4 2020 virtual contributor summit. He explained to other developers about how to leverage the multicopter control system, as used in the Cloudline airships and other popular drone devices. This outreach step is important in growing awareness in the existing community for new introductions to the common software, and how both Cloudline and the PX4 community could help each other in achieving their similar yet different goals.

What is next for the Innovation Fund? 🔗

What does the next year ahead look like for UNICEF’s Open Source Mentorship programme? Stay tuned for the final post in this series, which will explore on-going work to standardize the mentorship curriculum, detail how Innovation Fund companies are being coached in becoming Digital Public Goods, and the research and development for an Open Source Program Office at the UNICEF Office of Innovation in 2022.

Special thanks for content and data collected in this post: Sanna Bedi, Zenani Orengo

However, this question only led to more questions. Much of the existing Open Source discourse on sustainability centers on defining, tracking, and understanding “dependencies.” Yet when we say dependencies, people typically mean source code, software packages, and license compatibility. So, how do we describe the value proposition of people and the impact of cross-pollinated communities?

So, what if Open Source dependencies weren’t just software? Furthermore, what if Open Source dependencies could mean people… or simply, human beings? In this blog post, we’ll walk through this thought experiment.

Open Source dependencies are people. 🔗

My purpose is to augment the idea of “dependencies” from exclusively source code to be more inclusive of its authors as well. We typically center software in our Open Source conversations, so I want to deliberately center people. There are many ways to cover this, but I will offer three ways we could think of Open Source dependencies as more than source code:

1. Community inheritance
2. Legacies
3. Love

Dependencies: Community inheritance 🔗

New, smaller projects sometimes form up underneath or within an existing larger project. Sometimes a new project is created to support the existing project. Sometimes it is a passion project led by a few that aligns with the motivations and values of a wider community. But these new projects begin with an added advantage of inheriting the collaborative ecosystem surrounding the existing project, instead of being tasked to create this from scratch themselves.

Why measure this? 🔗

Ask anyone responsible for building an Open Source community from scratch. The approach at this stage is experimental:

• Will using this feature encourage new contributors to participate?
• Does someone in a related field discover our project on a casual whim looking at GitHub?
• How do we make our project more accessible for contributors we do not yet have?

Many times, it is about forming a hypothesis and then testing it.

However…

If you exist within the dynamic of an existing community, you benefit from resources, people, and infrastructure that would be unavailable if you started independently. Finding communities with compatible values and motives exposes you to a wider network, and thus more visibility in a world where there is already too much information. Working within an existing community can cut light-years off of time-to-market or improving product sustainability and community resiliency (in the context of other variables).

Example of community inheritance 🔗

The Fedora Project produces Fedora Linux. Fedora Linux is a Free and Open Source operating system derived from the open source Linux kernel. The Fedora Project also creates other software in order to facilitate the production, creation, and updates of Fedora Linux. Examples of this are asynchronous meeting minute note managers, community calendars, gamified badges, software package distribution tools, and more.

While none of these smaller software projects are the ultimate purpose and goal of the Fedora Project, they are supplementary to the overall goal of producing Fedora Linux. The sustainability of these smaller parts ensure a healthier ecosystem around the larger project.

Another way to see this is as a planet with several orbiting moons, where the planet is an existing project and each moon represents another smaller project orbiting around the existing one. Each moon is different, yet each is still connected to the gravitational force and motions of the planet.

Dependencies: Legacies 🔗

Open Source projects are more than source code. Human beings are social creatures, and Open Source is a social activity. An individual or groups of individuals may influence the hearts and minds of others in the movement. To win hearts and minds is to merge the intentions of the individual with the intentions of the wider community. The power to change minds is the power to move mountains.

Why measure this? 🔗

Open Source is a social activity. It has both a written and oral story-telling tradition. There is a rich history from the movement that first took root in the 1980s. We use stories to expand our imagination, or to see a perspective in a way we might not have before. So, it is important to note the value these historical stories play in shaping our movement and creating leaders.

Legacies of kindness and love result in thriving communities where contributors look out for each other. People are not motivated by the will to survive; they are motivated by the will to thrive with a community. Legacies of discrimination and hate result in divided, splintered communities who are focused on counting their differences instead of seeing how alike we are.

Example of legacies 🔗

Seth Vidal wrote the Yellowdog Update Manager (Y.U.M.), and he contributed to Fedora. Matthew Williams helped others learn about Linux and Open Source, and he contributed to Fedora. Thomas Gilliaird helped me with using Fedora Linux in IRC as a teenager, and he contributed to Fedora. The ways we help other humans while on our own journey is how we create a legacy with wider wings. The impact of a few kind people is enough to inspire more to follow.

To ignore the impact of legacies in social activities surrounding Open Source is to deny the impact of charismatic leaders who lead in styles of either unity or division.

Dependencies: Love 🔗

Power at its best is love implementing the demands of justice. Justice at its best is love correcting everything that stands against love.

Dr. Martin Luther King, Jr.

The act of existence can be political. We cannot escape the sociopolitical environment of our world, no matter how much we wish to push it aside. If we choose to ignore it, there are others who choose to manipulate common ignorance, to the exploit of their own unbounded wealth. We must embrace and acknowledge the political atmosphere permeates our world; it does not disappear and hide away when it makes us uncomfortable.

Why measure this? 🔗

Open Source does not get a “get out of jail free” card.

Open Source is political. Its roots in the Free Software movement were firmly rooted in politics, even if they were narrowly confined to a few key issues. The real question is, how do we wield our own political agency and expediency? We should act from our hearts and move to inspired action to correct everything that stands against love.

Example of love 🔗

This blog post. These words are a radical act of love. Acknowledging it and choosing to embrace it is the first step in using our Open Source power responsibly.

Featured image arranged by Justin Wheeler. Original photograph by Ian Schneider on Unsplash.

2020 saw the launch of a formalized Open Source Mentorship programme for the UNICEF Innovation Fund, built up on two years of work from RIT LibreCorps expertise and consulting.

The Open Source Mentorship programme includes five modules about Open Source intellectual property and communities delivered across twelve months. UNICEF grantees are matched with an experienced Open Source Mentor to guide them through the modules. The mentorship takes an interactive, guided approach to understanding the unique context that each team and product exist within. The assigned Open Source Mentor provides specialized advice and training:

• Tailored feedback based on business models
• Existing local user communities
• Best practices for collaborating together with others on similar challenges.

The geographic diversity in the UNICEF Open Source Mentorship programme is unusual for technology incubators or accelerator programs. All funded projects come from UNICEF programme countries. The UNICEF Innovation Fund provides equity-free funding for Open Source solutions from local innovators and entrepreneurs solving local problems. To date, the Innovation Fund has invested in teams from over 57 countries. Argentina, India, Iran, Kenya, Mexico, Nepal, and Rwanda represent the most recent incoming cohort in July 2021.

But why does this kind of work matter to UNICEF or the United Nations?

UN Roadmap for Digital Cooperation 🔗

In June 2020, the United Nations Secretary-General released the UN Roadmap for Digital Cooperation, a call for action and a vision with several key considerations:

• An Inclusive Digital Economy and Society
• Human and Institutional Capacity
• Human Rights and Human Agency
• Trust, Security and Stability
• Global Digital Cooperation

The report explores the impact technology has in each key area:

“Digital technology does not exist in a vacuum – it has enormous potential for positive change, but can also reinforce and magnify existing fault lines and worsen economic and other inequalities. In 2019, close to 87 per cent of individuals in developed countries used the Internet, compared with only 19 per cent in the least developed countries.”

UN Roadmap for Digital Cooperation, June 2020

Open Source Mentorship enables digital cooperation. 🔗

Therefore, the conception and development of Open Source Mentorship is inspired by the Roadmap, in four key aspects:

1. Digital Public Goods: To encourage knowledge transfer and collaboration on practical, everyday advice on building technology projects in line with the Digital Public Good Standard.
2. Digital Capacity-Building: Empowering others with the skills and information they need to be bringers of Open Source change and innovation in a disruptive and competitive Venture Capital ecosystem.
3. Digital Trust and Security: Providing a holistic view of Open Source intellectual property that is influenced by, but not bound by, quarterly earnings reports and share prices. Understanding the commitments of Open Source licenses and technology, and how trust is earned and lost in Open Source products and communities.
4. Global Digital Cooperation: Designing and structuring communities to be healthy and collaborative in nature, united in resolving common challenges and problems.

No culture can live if it attempts to be exclusive.

Mahatma Gandhi

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

Twitter: @jwf_foss

Why should you vote for me? 🔗

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

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

Who am I? 🔗

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

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

What are my qualifications? 🔗

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

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

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

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

Interview responses 🔗

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

Q1: What should OSI do… 🔗

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

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

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

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

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

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

Q3: When a license decision involves a topic… 🔗

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

I joined the UNICEF Innovation team in June 2020, although this is not the first time I have worked with UNICEF Innovation. I have had some opportunity to write about Open Source, but my personal blog has been quiet! So, this felt like the right opportunity to talk about what I am up to these days.

The Open Source Archetypes report (below) provides nine archetypes common among Open Source projects and communities. These archetypes provide a common language and perspective to think about how to capture the most value of Open Source in various contexts.

Open Source Archetypes (May 2018)Download

This article covers the following topics:

1. How Open Source Archetypes align with my experience
2. How I use Open Source Archetypes at UNICEF
3. Unanswered questions

How Open Source Archetypes align with my experience 🔗

The Open Source Archetypes report is useful to me because it aligns with my own experiences and encounters with common Free and Open Source Software projects. An advantage of taking my alma mater’s Free and Open Source Software and Free Culture Minor is experiencing what real Open Source projects are like long before I entered the industry. The projects and organizations I contributed to and interacted with all ran their projects in one of the nine models identified in the report.

The Open Source Archetypes report speaks to my personal experience either using or contributing to projects like Fedora, Kubernetes, SpigotMC, MusicBrainz, and various independent projects. The value of Open Source for any project is in meeting the goals of the intended audience. By itself, “Open Source” is a broad term, even if it does have a legal definition. My experiences taught me the importance of how different Open Source projects meet the needs of different audiences, or even different combinations and balances of audiences. The Open Source Archetypes report creates language for something I previously only understood through direct experience.

When I first read the report earlier in 2020, I knew it was relevant to my work. But how could I begin to integrate it into the Open Source Mentorship programme I manage for the UNICEF Innovation Fund?

How I use Open Source Archetypes at UNICEF 🔗

The UNICEF Innovation Fund provides early stage funding and support to frontier technology solutions that benefit children and the world. Most teams in the Innovation Fund are from countries where UNICEF has an ongoing country programme.

A requirement for solutions we fund is that they must be Open Source. I have seen many different types of projects and business models since I started working as a part-time consultant for UNICEF in 2018. As exciting as this is, it was challenging to understand the best way of supporting each team and their Open Source projects. Each team and project had differences unrelated to their source code, but closely tied to their business models and impact they wanted to have through their work.

So, the Open Source Archetypes report have me language. It gave me examples and explanations of how Open Source can work to teams who had little to no prior experience of Working Open. I take the unique context and details I understand about each team I work with, and contextualize what they are doing compared to the different models in the report.

The feedback I received so far on the report with the 15+ teams I currently work with is mostly positive. Some teams exclaimed this report was what they wish could have read months before because it resolved many of their doubts. Others were more overwhelmed, and needed extra time to read and review.

For my role as a mentor, the Open Source Archetypes report gives me cues for how to best support and direct each team I work with. The task of building an Open Source community or participating in an existing one is not a small task. Whether it is documentation, project management, quality assurance and testing, or community engagement, I have yet to see any small team accomplish all of these things at once. So, identifying which archetype a team best identifies with gives me a cue to guide the teams on their path forward. It gives me context for how to make Open Source something that works for them instead of against them.

Unanswered questions 🔗

I have great appreciation and gratitude for the folks at Mozilla and Open Tech Strategies who compiled this report. But it was written over two years ago, and like all things in life, things can change. So, while I look comfortably from the position of hindsight, there are some critiques and missing components to the Open Source Archetypes reports.

My unanswered questions are below.

Does the Linux kernel (and subsequently, Linux distributions) represent another unwritten archetype? 🔗

The report explicitly avoided using the Linux kernel as the basis for any archetype:

In some ways the Linux kernel project could be considered “Wide Open”. However, both technically and culturally, Linux kernel development is sui generis and we have deliberately avoided using it as the basis for any archetype.

Open Source Archetypes, Page 17

Contextualizing a project like Linux is hard. There is a lot of history to a project that first launched over email in 1991. There are many “yes, but"s about decisions made 10 or even 25 years ago that would not replay the same way in 2020.

Yet this is important work. Linux represents not just the kernel, but also large, decentralized sub-units of other systems that integrate the kernel in order to make it useful (e.g. Ubuntu, Fedora, Debian, Arch Linux, you name it). These sub-communities include large entities and corporations, spanning multiple countries and organizations of various sizes.

The Linux kernel communities are worthy of a deeper look, possibly in order to define a new archetype.

How can Open Source Archetypes better fit the social/humanitarian sector? 🔗

The archetypes shared in the report largely focus on business sustainability. In other words, the report is biased towards Mozilla’s interest in funding the research in order to better understand how to support a commercially-successful Open Source project. To me, there seems like a gap in models that often work for Open Source projects perhaps like U-Report and Ushahidi.

This is an area of interest to me, and likely others in the UN and NGO space. The report could do more to address these kinds of projects.

How would you teach Open Source? 🔗

To conclude, the Open Source Archetypes report is an invaluable tool that provides me language and context for teaching others about Free and Open Source Software.

How would you teach Open Source? What models, research, or tools would you use to inform an Open Source mentorship or education programme? Share your thoughts below in the comments!

The Cryptographic Autonomy License is one of newest Open Source licenses on the block. The Open Source Initiative approved it in February 2020. This license also made ripples when it came through. But the question I had, and could not find a clear answer to, was why is it so interesting?

This blog post is my attempt to do a casual coffee-table review of the license. If you agree or disagree, I encourage you to leave a comment and share your opinion and why!

This short article covers three sections:

1. CAL-1.0 provisions: What basic Free Software assumptions are present in the license, much like other copyleft licenses.
2. What’s fresh!!: What is the hype? Ready for the key information? It is covered here.
3. Personal takeaways: My personal thoughts on this license and where it might be applicable.

CAL-1.0 provisions 🔗

I learned there are basic assumptions and expectations that are true for all Open Source licenses, per the Open Source Definition. Copyleft licenses also have different degrees of rigidity depending on context and use. So, what basic ingredients of a Free Software license are present in the Cryptographic Autonomy License?

Note: The number in parentheses before each line is the corresponding section number in the license text.

Basic legal provisions 🔗

• (6.0) Disclaimer of warranty, limit on liability: If someone uses the software and it causes unexpected disastrous side effects, the Licensor cannot be held responsible.
• (2.0) Receiving a license: Anyone can receive a CAL-1.0 license. To receive it, you just have to agree to its rules.
• (7.4) Attorney fees: If a case involving noncompliance with the CAL-1.0 is brought to court, loser pays legal fees for prosecution and defense.
• (7.3) No sub-licensing: You cannot add another license “on top” of the CAL-1.0.
• (3.0) Patent clause: Got patents? This license is equipped to interface with external patent licenses.

Permissive provisions 🔗

• (4.1) Access: Source code must be made available over a network with this license.
• (4.3) Attribution: Cite your sources. Retain all licensing, authorship, and/or attribution notices.

Copyleft provisions 🔗

• (4.1) Modified Work: Changes to the original Work make it a Modified Work. Same license rules apply to a Modified Work.
• (5.2) Reinstatement: A la GPLv3, for non-compliant derivative works, there is a 60 day grace period to come into compliance before your license is terminated.
• (4.5) Combined Work Exception: Software in the Larger Work as well as the Larger Work as a whole may be licensed under the terms of your choice.
• Network use: A la AGPL, it also includes a trigger for network use.

What’s fresh!! 🔗

The fresh take on this license from other licenses is all in 4.2. Maintain User Autonomy:

In addition to providing each Recipient the opportunity to have Access to the Source Code, You cannot use the permissions given under this License to interfere with a Recipient’s ability to fully use an independent copy of the Work generated from the Source Code You provide with the Recipient’s own User Data.

Section 4.2 Maintain User Autonomy: intro text

My non-lawyer take on this is that user data plays a much more prominent role in the terms of this license than other copyleft licenses. Just like the AGPL was a response to the changing world of network services and cloud computing, the CAL-1.0 is a response to the changing world of machine learning and data science.

The CAL-1.0 seems to define “user autonomy” in the context of actually using the software, versus something more holistic like Digital Autonomy. In other words, if you are running CAL-1.0 software, you cannot interfere with requests for personal user data from your users.

This might not sound so radical, but it really is. It is a radical way to assert users’ ownership of their data. If you are the end user of a distributed or cloud-based app licensed under CAL-1.0, you are enabled (to some degree) to request copies of personal user data without interference or obfuscation.

CAL-1.0 and Hatbrim Technologies 🔗

To better explain this, consider this made-up example.

I am a product manager at Hatbrim Technologies. Hatbrim develops an integrated calendar application, Holocal, to store events, meetings, and reminders. Holocal is an integrated application that includes a front-end component, back-end component, and a machine learning algorithm. The algorithm offers tailored suggestions to reduce my meeting load based on my common meeting patterns with other events or activities I have planned.

Oraculous, a competing company to Hatbrim Technologies, creates a fork of Holocal called OraCal. It is almost functionally identical to Holocal except it also adds an integration to other services from Oraculous. However, OraCal also modifies the calendar optimization algorithm. It adds a periodic random event suggestion based on events and activities in your calendar.

Meanwhile at Hatbrim… 🔗

Since I am a product manager at Hatbrim, I turn to my trusty team of developers and ask them to explore the OraCal fork of Holocal. I am curious to know how their calendar optimization method works, since Oraculous must also release OraCal under the Cryptographic Autonomy License (CAL-1.0). My team of developers review the OraCal code, try making changes to Holocal, but we are unable to replicate this feature of OraCal in our environment.

Eventually, one developer runs OraCal internally, but optimized for our data. Still no luck to reproduce the nifty calendar event suggestion feature! Fortunately, the CAL-1.0 offers a protection here. So, the developer sends an email to Oraculous to request her personal user data from OraCal provided to her. Because the CAL-1.0 has provisions to prevent foul play or modifying the data, the developer receives a copy of her data and realizes another Oraculous tool was scrubbing and appending data for calendar predictions before it returned to OraCal.

In this hypothetical scenario, our developer is ultimately able to understand how the Modified Work is changed and how Oraculous adapted the original Work. Under another copyleft license like any GPL variant or the Mozilla Public License, a licensee has no obligation to share any user data with an end user. For any reason. Unless they happen to be nice or because another legal authority or body holds them accountable to share user data.

CAL-1.0 personal takeaways 🔗

Did I mention I am not a lawyer and this does not constitute legal or financial advice? In case I did not, I am not a lawyer and this does not constitute legal or financial advice.

This advice and interpretation of the license is raw and unfiltered. But you only read something for the first time but once. So, with all other contemporary issues in the Free Software world going on, I thought it would be a fun exercise to draft this blog post as I read through the Cryptographic Autonomy License for the first time.

Ultimately, my takeaways after reading and reflecting on the license a few times is this:

1. Lack of transparency in motivation: Holo, the company behind the license, emphasizes all the good qualities of this license while sneakily dodging the fact that it is a mildly anti-competitive license for their business case.
2. Precedent-setting: This is the first approved Open Source license that explicitly does anything significant about data. It will be interesting to see if this inspires other licenses that make definitions on data.
3. Potentially powerful if picked up: If used more widely or in more popular projects, it has potential to disrupt the status quo of how Open Source thinks about user data and the autonomy of the end user.
4. No defining moment: To my knowledge, CAL-1.0 lacks a significant defining moment since its approval. It is unclear what real-world noncompliance litigation looks like. It lacks the battle-testing of other copyleft licenses.

I imagine I am not the only one who feels mutually excited and hesitant about the Cryptographic Autonomy License. I am not sure if it makes sense to apply to any of my work or to recommend as a default license to others yet. And licensing is only but one of many pathways in the Free Software legal and policy world. But nonetheless, it is an interesting Free Software development that is still maturing since February 2020.

Photo by Markus Spiske on Unsplash. Modified by Justin Wheeler.

This post identifies specific tasks the TeleIRC team identified as “good first issues” for Hacktoberfest hackers. They are in order of least difficult to most difficult. Golang developers especially are encouraged to participate!

Why work on TeleIRC for Hacktoberfest? 🔗

Before sharing how you can contribute for Hacktoberfest, what about why you should contribute?

TeleIRC originally launched in 2016. Since then, we have built up a community of users around the world. TeleIRC is also used in other larger Open Source projects like the Fedora Project and LibreOffice! Of course, it is still used in the Rochester Institute of Technology community where it was first developed.

Working on TeleIRC means you can contribute to a project that is actually used in the real world. Hundreds of user communities, some even the size of thousands of people, use TeleIRC. Your improvements and changes will help the many downstream users of our project. (P.S. – See the full list of who uses TeleIRC in our docs!)

With that out of the way… let’s talk about what there is to do!

#1: Large messages go to a pastebin 🔗

This corresponds to RITlug/teleirc#56.

• Goal: When a Telegram user writes a single line that exceeds the maximum number of characters for an IRC message (512 characters, per RFC 1459, section 2.3), send the string to a pastebin service.
• Success criteria: Any line greater than 512 characters is sent to a pastebin-like service.
• What we think: Note the difference between “lines” and “messages”. Telegram users can add line breaks to messages. TeleIRC should respect those line breaks as new IRC messages. So, only a single line that exceeds the maximum should go to a pastebin-like service.

#2: Telegram Poll handler 🔗

This corresponds to RITlug/teleirc#267.

• Goal: Send text representations of Telegram Polls to IRC. Currently, Polls are ignored by TeleIRC and do not appear in any way on IRC.
• Success criteria: If a Telegram user sends a Poll to a group, a text representation should appear in IRC.
• What we think: IRC users will not be able to participate in Polls. This is a platform limitation. However, IRC users should get some context about what a Poll includes, e.g. what the question is and what answer choices are available.

#3: Support more encoding types (e.g. CP1251) 🔗

This corresponds to RITlug/teleirc#332.

• Goal: Support more string encoding types than UTF-8.
• Success criteria: If a Telegram user writes a message in Cyrillic script, it should appear in Cyrillic script on IRC (if the server supports it, e.g. CP1251).
• What we think: This is one of the toughest issues we have and requires knowledge about string encoding methods. The current core developers are native English speakers and we do not use other languages that have non-Latin script. The GitHub issue has more info, but it will need additional research or knowledge about string encoding.

Need Hacktoberfest help? Come talk to us! 🔗

Want to work on any of these? Add a new comment to the GitHub Issue and let us know you are interested in working on it.

Have questions about the project or getting started? Come talk with the TeleIRC team! Of course, you can find us both on IRC (#rit-lug-teleirc on Freenode IRC) and Telegram (@teleirc).

Additionally, the TeleIRC team meets virtually every Sunday at 11:00 U.S. EDT / 15:00 UTC. Ask us for a calendar invite in our team chat if you would like one!

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

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

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

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

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

On the origins of Software Freedom 🔗

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

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

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

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

Freedom in 2020 🔗

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

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

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

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

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

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

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

Reconciliation and intersections 🔗

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

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

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

The name of this intersection is digital intersectionality.

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

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

What now? 🔗

Chadwick Boseman is gone. But we are not.

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

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

Special thanks to my early editors!

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

Overview 🔗

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

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

If you are hooked, read on.

The Sticky Idea 🔗

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

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

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

Open Source Accountability Goals 🔗

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

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

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

Facilitation of Authentic Participation discussion 🔗

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

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

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

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

Facilitation, Roosevelt-style 🔗

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

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

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

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

How did facilitation start? 🔗

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

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

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

Is there a next chapter to this story? 🔗

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

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

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

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

Closing thoughts 🔗

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

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

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

Download TeleIRC v2.0.0 now! 🔗

If you want to skip the text and get to the software, head to the GitHub v2.0.0 release for more info. If you want the story behind this release, read on!

Eight months later… 🔗

The conversation started in a university hallway after the first RIT Linux Users Group meeting in the Fall 2019 semester. Together, Tim Zabel, Nicholas Jones, and Justin Wheeler set out to rewrite TeleIRC from NodeJS to Go. This was done to address a growing backlog of challenging feature requests on TeleIRC, but also a way for us to gain more experience working with Go. Along the way, we also ended up facilitating an agile-inspired software release process adapted for open source.

So, what happened in the eight months after the first conversation? The team meet for weekly meetings each Saturday afternoon (at first in-person, later virtually), two new core contributors joined the team, and some drive-by contributors provided feedback andf added code to the new release. There were charts, whiteboards and dry-erase markers, and lots of Blue Jeans video calls. But after all this time, we made it to release day!

Thank you amazing volunteer contributors! 🔗

This endeavor was a shared commitment by our volunteer committer team. All five of the volunteer core maintainers spread patience and sustained effort over time. At the end, we made something really cool to show for this work.

A huge thanks to our core maintainers and all current and past contributors to TeleIRC. You have all contributed to the success (and motivation!) for this project. It is fun to work on cool projects with friends!

A proper shout-out goes to the core maintainers who joined the team over the last eight months working on this release:

• Kennedy Kong
• Kevin Assogba
• Nicholas Jones
• Tim Zabel

“I found a bug in TeleIRC v2.0.0!” 🔗

If you run into a problem, check out the TeleIRC documentation and open an issue if it does not answer your questions.

Get in touch! 🔗

If you have questions, get in touch with the developer community. You can find us on Telegram and on IRC (#rit-lug-teleirc on chat.freenode.net).

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

Full rewrite to Go 🔗

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

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

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

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

Run TeleIRC v2.0.0 as a compiled binary 🔗

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

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

Improved TeleIRC v2.0.0 documentation 🔗

End user feedback shaped and improved documentation during development.

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

Future roadmap for containers 🔗

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

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

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

When I was a kid, one of the most important lessons I learned was saying “thank you” when someones does something nice for you. So, a few years ago, I learned about this awesome little website called Happiness Packets. Its purpose is simple but powerful. Happiness Packets are open source thank-you cards you can send over email. You can send Happiness Packets to anyone for anything. Your message can be as short or as long as you like. You can put your name on it or keep it anonymous. The choice is yours. And now, I want to challenge you (yes, you) to the 2020 #HappinessPacketChallenge!

What are Happiness Packets? 🔗

Upstream describes it best. This comes straight from the Happiness Packets website:

People are generally much more loved than they think they are. Especially when things don’t go according to plan, other people almost never think as harshly of you as you might think of yourself. It’s easy for us to complain when bad things happen, and yet we’re often fairly silent when things are good. Open-source communities are no different, especially when our main communication channels are textual and virtual.

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. With Open-Source Happiness Packets, we’re trying to spread that feeling.

How does it work?

Openly expressing appreciation, gratitude, or happiness to other people can be difficult. This is especially true when you don’t know them very well. Many of us come from cultures in which people are not open by default about such feelings, and naturally feel uncomfortable or even creepy to share them.

Open-Source Happiness Packets is a very simple platform to anonymously reach out to the people that you appreciate or to whom you are thankful in your open-source community. Your message can be sent anonymously if you feel uncomfortable to share your name with the recipient. Of course, we encourage you to share your name, but it’s completely optional!

What are Open-Source Happiness Packets?

You can learn more about the Happiness Packets Challenge by browsing through the Twitter hashtag.

Take the challenge! 🔗

So, what is the #HappinessPacketChallenge? I challenge you to do the following: write one Happiness Packet a day, every day, for one week starting Monday, 27 April and ending Sunday, 3 May. At a minimum, this is seven times where you say “thank you” to someone else. Of course, nothing is stopping you from sending more if you want!

Maybe you are overwhelmed by the negativity on social media or the news channel. Especially today, when everyone is talking about one single thing: COVID-19. Whatever the platform is, the negativity can eat at you. For one week, this is your opportunity to choose something different. For all of the good things and people in your life, spend a few minutes of each day this week to make someone’s day. It seems simple—and it is! But the power you have to spread the positivity is a big power. So this is the challenge you have: to commit yourself to spreading your little packet of happiness every day for one week.

“But, I don’t know what to say…” 🔗

Having a hard time coming up with words or not sure who to thank? No worries. Your message can be as short or as long as you like. If you’re not sure who to thank, look at software you are already using. Look for names and emails of maintainers of open source software you enjoy. If you’re already contributing to open source, consider folks in your community! Thank someone who had a hand in helping you get started, or gave you a little bit of encouragement when you needed it most.

Maybe you have other ideas or reasons to thank others. (Heartbleed or Shellshock anyone?) Whatever the reason, don’t make an excuse to not say thanks! The options are limitless. If you have a lot to say, say it! If not, even a simple “thanks for all the work you do!” can go a long way to make someone’s day.

Share your Happiness Packets 🔗

The magical part of Happiness Packets is sharing happy moments with others. If you receive one, don’t be afraid to share it with the world! Tweet at @happinesspacket on Twitter. Use the #HappinessPacketChallenge hashtag. Encourage other people to send their own thanks. If you get one other person to take the challenge, that has an impact on seven more people! Imagine what would happen if all of those seven people decided to take the challenge too.

So, I hope you will join me this year in this fun tradition. Get ready from Monday, 27 April to Sunday, 3 May to send some happiness! And if you’re feeling bold, challenge someone you know directly.

Love Letter by Vectors Market from the Noun Project.

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

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

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

Video recording from FOSDEM 2020

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

Let’s frame this first. 🔗

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

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

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

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

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

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

Looking to yesterday for today 🔗

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

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

What freedoms do we want to protect? 🔗

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

1. Audit automated decision-making systems 🔗

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

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

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

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

2. Deliver accountability and responsibility 🔗

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

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

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

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

Myanmar and Facebook 🔗

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

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

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

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

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

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

3. Appeal a decision 🔗

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

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

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

Resume/CV filtering 🔗

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

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

Practical examples 🔗

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

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

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

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

Where do we go from here? 🔗

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

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

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

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

Why does this matter? 🔗

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

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

27 Sept. 1983: GNU Project announced 🔗

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

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

Today, we call these the Four Freedoms.

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

4 Oct. 1985: Free Software Foundation founded 🔗

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

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

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

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

25 Feb. 1989: GNU General Public License created 🔗

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

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

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

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

Is the past relevant to social movements today? 🔗

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

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

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

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

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

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

Your future is the new commodity. 🔗

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

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

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

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

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

Where are we today? 🔗

So, how have we responded to our changing world?

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

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

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

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

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

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

Photo by Shane Rounce on Unsplash.

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

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

Official conference website

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

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

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

At a glance: structure and key takeaways 🔗

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

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

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

Structure: Dialogue and discussion 🔗

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

I attended these sessions:

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

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

1. Open source is in an identity crisis. 🔗

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

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

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

2. Millennials are underrepresented. 🔗

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

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

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

Born digital 🔗

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

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

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

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

Is Free Software ready for the millennials? 🔗

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

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

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

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

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

The 2020s will be definitive 🔗

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

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

So, what will Free Software do?

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

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

Luis Villa

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

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

Add more chairs to the table 🔗

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

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

Free Software, but for kids 🔗

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

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

Talk with us, not at us 🔗

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

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

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

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

Teach early and teach often 🔗

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

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

Where are we going? 🔗

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

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

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

Our software freedoms are not enough 🔗

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

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

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

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

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

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

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

So, now what? 🔗

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

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

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

We do have the power. 🔗

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

So, what will you do?

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

Thanks folx! 🔗

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

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

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

What’s coming in TeleIRC v2.0.0? 🔗

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

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

TeleIRC v1.0.0 was an experiment. 🔗

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

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

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

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

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

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

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

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

A Go rewrite distinguishes our project. 🔗

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

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

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

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

Go has a better story for Kubernetes / OpenShift. 🔗

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

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

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

TeleIRC v2.0.0: Progress so far 🔗

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

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

When to expect TeleIRC v2.0.0 🔗

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

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

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

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

Get involved with TeleIRC! 🔗

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

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

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

Background photo by Daria Nepriakhina on Unsplash.

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

- Get in touch with other developers and projects;

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

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

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

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

fosdem.org/2020/about/

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

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

Sessions: Play-by-play 🔗

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

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

Building ethical software under capitalism 🔗

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

Deb Nicholson

Deb is making a regular appearance on my blog.

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

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

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

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

Growing sustainable contributions through ambassador programs 🔗

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

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

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

Shilla Saebi & Alison Yu

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

What is an ambassador program? 🔗

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

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

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

Who and what are ambassadors? 🔗

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

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

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

What do ambassadors do? 🔗

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

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

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

How to incentivize ambassadors? 🔗

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

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

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

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

Lessons learned 🔗

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

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

Future goals 🔗

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

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

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

Bradley M. Kuhn & Karen Sandler

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

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

Resisting in 2020 is not the same as in 2000 🔗

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

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

Stop shaming 🔗

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

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

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

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

Eriol Fox

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

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

Open source perception 🔗

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

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

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

Learn what design work looks like 🔗

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

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

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

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

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

Twitter thread! 🔗

Did I live-tweet this one? You bet.

What makes people come and what makes them stay 🔗

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

Gloria Dwomoh

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

Beyond FOSDEM 2020 🔗

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

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

Thanks folx! 🔗

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

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

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

Until next time!

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

chaoss.community/chaosscon-2020-eu/

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

Sessions: Play-by-play 🔗

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

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

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

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

Deb Nicholson

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

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

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

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

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

Sean Goggins & Remy DeCausemaker

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

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

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

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

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

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

Measuring Culture 🔗

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

Sharan Foga

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

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

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

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

Meet Cauldron! Your SaaS Software Development Analytics solution 🔗

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

Jose Manrique Lopez de la Fuente

I had no written notes other than “wow!”

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

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

I have some homework to do!

Language barriers for open source contributors 🔗

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

Isabella Vieira Ferreira

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

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

— Emmy Tsang (@emmy_ft) January 31, 2020

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

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

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

Metrics are more than the sum of their parts 🔗

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

Matt Broberg

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

Emerging Tech Open-Source Scoring System (ETOSS) 🔗

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

Cecilia Chapiro & Justin Wheeler

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

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

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

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

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

— Farbod Saraf (@farbodsaraf) January 31, 2020

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

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

— Emmy Tsang (@emmy_ft) January 31, 2020

Hey, it’s me!

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

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

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

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

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

Yo Yehudi

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

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

Diversity & Inclusion Badging Program 🔗

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

Matt Germonprez

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

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

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

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

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

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

Addendum: Events and inclusivity 🔗

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

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

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

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

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

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

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

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

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

Brian Proffitt

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

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

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

Beyond CHAOSScon EU 2020 🔗

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

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

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

Thanks folx! 🔗

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

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

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

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

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

sustainoss.org/summit-2020/

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

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

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

At a glance: structure and key takeaways 🔗

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

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

Speed breakout sessions 🔗

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

I attended these sessions:

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

Key takeaways 🔗

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

Inclusion is local 🔗

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

Rules for revising rules 🔗

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

Generalists transition to specialists 🔗

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

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

We got the power 🔗

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

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

Community-first governance models 🔗

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

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

Citizen assemblies in open source? 🔗

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

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

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

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

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

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

Principles of Authentic Participation 🔗

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

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

Authentic Participation Starts Early. 🔗

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

Authentic Participation Puts The Community First. 🔗

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

Authentic Participation Starts With Listening. 🔗

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

Authentic Participation Has Transparent Motivations. 🔗

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

Authentic Participation Enforces Respectful Behavior. 🔗

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

Authentic Participation Ends Gracefully. 🔗

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

Thanks folx! 🔗

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

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

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

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

However, the times are a-changing! Containers are entering as real players in the HPC space. Previously, containers were brushed off as incompatible with most HPC workflows. Now, several open source projects are emerging with unique approaches to enabling containers for HPC workloads. This blog post evaluates four container run-times in an HPC context, as they stand in July 2019:

• Charliecloud
• Shifter
• Singularity
• Podman

Research requirements 🔗

My research focused around a specific set of requirements. To receive a favorable review, a container run-time needed to meet three basic requirements:

• Support CentOS/RHEL 7.5+
• Compatibility with Univa GridEngine
• Support for very large numbers of users

Obviously there are security concerns with the third requirement. This is one reason containers have not made a strong showing in the HPC world yet. With the Docker security model, root access is a requirement to build and run containers. In a production HPC environment where users do not trust other users, this is a hard blocker.

Other HPC environments may differ. If you are an HPC administrator and also considering containers in your environment, consider my requirements. My research was exclusively framed through these three requirements.

Charliecloud 🔗

Charliecloud is an open source project based on a user-defined software stack (UDSS). Like most container implementations, it uses Linux user namespaces to run unprivileged containers. It is designed to be as minimal and lightweight as possible, to the point of not adding features that could conflict with any specific use cases. This can be a positive or a negative, depending on how complex your environment is.

However, I abandoned my research on Charliecloud early on after reading this PLOS research paper:

The software makes use of kernel namespaces that are not deemed stable by multiple prominent distributions of Linux (e.g. no versions of Red Hat Enterprise Linux or compatibles support it), and may not be included in these distributions for the foreseeable future.

The software is emphasized for its simplicity and being less than 500 lines of code, and this is an indication of having a lack of user-driven features. The containers are not truly portable because they must be extracted from Docker and configured by an external C executable before running, and even after this step, all file ownership and permissions are dependent on the user running the workflow.

Singularity: Scientific containers for mobility of compute, May 2017 (Gregory M. Kurtzer, Vanessa Sochat, Michael W. Bauer)

However, it is worth noting this paper was written in support of Singularity. It was also written by the Singularity project lead and others from the Singularity open source community. If you are conducting your own independent research, consider looking closer at Charliecloud, since at the time of writing it is still actively developed. The research paper was written in May 2017.

Edit: This situation already changed and Charliecloud is probably worth a deeper look:

This is a fantastic write up, one thing to mention is that abandoning the CharlieCloud research based solely on lack of support of the user kernel namespace is no longer a blocker. For example, PodMan now uses the same technology and it was released in RHEL8.

— Apptainer (formerly Singularity) (@SingularityApp) August 20, 2019

Shifter 🔗

Shifter is another container run-time implementation focused on HPC users. At time of writing, it is almost exclusively backed by the National Energy Research Scientific Computing Center and Cray. Most documented use cases use Slurm for cluster management / job scheduling. Instead of a Docker/OCI format, it uses its own Shifter-specific format, but this is reverse-compatible with Docker container images. It requires hosting a registry service and a Shifter Image Gateway.

The Shifter Image Gateway is a REST interface implemented with Python Flask. It pulls images from the registry service and converts them to the Shifter image format. MPI integration is supported but its implementation is MPICH-centric.

The downside to Shifter is lack of community. There are not many other organizations other than NERSC and Cray that appear to support Shifter. Documentation exists, but at writing time (July 2019), the last significant contribution was April 2018. Some bugs and feature requests are triaged, but there is not much of a maintainer presence in these issues. Most follow-up discussion to new issues are from a handful of outside contributors without commit access.

Additionally, there are several signs of stagnant development, such as NERSC/shifter#172 to add better MPI integration. However, the PR stalled out since it was first opened in April 2017. Furthermore, there is a high bus factor: most contributions and pull requests come from the same two developers, indicating low engagement from the wider HPC community. Code is regularly tested, but integration tests only exist for Slurm. For more details, check out the GitHub project pulse.

A detail worth noting is Shifter was one of the first real container run-times for HPC. A former Shifter collaborator branched off from Shifter to start Singularity (and eventually, a for-profit company to support it, Sylabs). It invites room for personal biases when evaluating Shifter and Singularity, specifically if you are not a newcomer in the HPC community.

Singularity 🔗

Singularity is the third and last HPC-specific player in the container run-time world. The vendor is Sylabs Inc. There are a few different factors that make Singularity interesting, and in my opinion, the most promising HPC container implementation.

General overview 🔗

Singularity v3.x.x is written almost entirely in Golang. It supports two image formats: Docker/OCI and Singularity’s native Single Image Format (SIF). As of September 2018, there are an estimated 25,000+ systems running Singularity, including users like TACC, San Diego Supercomputer Center, and Oak Ridge National Laboratory. Additionally, Univa announced a partnership with Sylabs in July 2018 to bring Singularity workflows to Univa GridEngine.

Sylabs offers Singularity (free and open source) and SingularityPRO (paid and proprietary). The commercial version comes with a support contract and long-term support for some releases (among other things).

Admin/root access is not required to run Singularity containers and it requires no additional configuration to do this out of the box. Containers are run under the Linux user ID that launches them (see Security and privilege escalation).

At a quick glance, Sylabs developers appear to be actively engaged in the Kubernetes development community, particularly around Red Hat technology. They also seem to keep their promises: in early 2018, blog posts show ambitious feature promises for the then-upcoming v3.0.0 release at the end of the year. Near the end of 2018, the release was delivered on-time with most/all of the promised functionality.

Image formats 🔗

The Singularity Image Format (SIF) is a single-image format (i.e. no layers involved). This was a design decision specifically for HPC workloads. SIFs are treated like a binary executable by a Linux user. Additionally, it is possible to create SIFs using the Definition File spec.

However, Singularity is also compatible with Docker/OCI images and OCI is given active development focus by upstream Singularity. Docker/OCI images are converted on-the-fly to a SIF. Docker/OCI images can be used locally or pulled from a remote registry like Docker Hub or Quay. To the user, if using a Docker/OCI image, the conversion is seamless and does not require additional configuration to use.

See this Sylabs blog post for a deeper dive on how SIFs were designed.

Flexible configuration 🔗

Singularity (uniquely?) offers advanced configuration options for HPC administrators. Some highlights are detailed here:

• Controlling bind mounts:
  • mount dev = minimal: Only binds null, zero, random, urandom, and shm into container
  • mount home = {yes,no}, mount tmp = {yes,no}: Choose to enable or disable these bind mounts globally
  • bind path = "": Bind specific paths into containers by default
  • user bind control = {yes,no}: Allow users to include their own bind mount paths or limit it to an admin-approved set of paths (above)
• Controlling containers:
  • limit container paths =: Possible to limit SIFs provided at a specific path and nowhere else

HPC community engagement 🔗

These notes only apply to Singularity free, not the proprietary SingularityPRO product.

The signals from their open source community engagement are positive and strong. They appear authentic and genuine to an open source commitment (i.e. not open-core business model). This is demonstrated in a few ways:

First, they have thorough user documentation, intended for end-users in HPC environments using Singularity. They have a less thorough but still useful admin documentation.

Second, all issues are triaged quickly and get feedback from core developers or outside contributors at a consistent pace. Pull requests don’t stagnate either: the oldest PR is less than six months old.

Third, code is regularly tested (1, 2). The code generally follows best practices (i.e. it is not atrocious to work with).

Fourth, there are also a handful of active contributors (both developers and in the community support channels) who come from outside of Sylabs, which indicates more engagement by a wider audience of people.

For more statistics, check out the GitHub project pulse.

Podman 🔗

tl;dr: Podman is an underdog that shows promise, but likely needs another one or two years of time for most HPC use cases.

Podman is a container run-time developed by Red Hat. Its primary goal is to be a drop-in replacement for Docker. While it is not explicitly designed with HPC use cases in mind, it intends to be a lightweight “wrapper” to run containers without the overhead of the full Docker daemon. Furthermore, the Podman development team is recently looking into better support for HPC use cases.

Podman is currently lacking for a HPC use case for some of these reasons:

1. Missing support for parallel filesystems (e.g. IBM Spectrum Scale)
2. Rootless Podman was designed to use kernel user namespaces which is not compatible with most parallel filesystems (might change in a year or two)
3. Not yet possible to set system site policy defaults
4. Pulling Docker/OCI images requires multiple subuids/subgids (might change in a year or two)

Where Podman does shine is providing a way to run and build containers without root access or setuid.

The same challenges and problems required for Podman to run OCI containers in an HPC environment are the same problems faced by Singularity to build SIF images without root in the HPC environment: mapping UIDs to subuids/subgids on the compute nodes. More interestingly, Buildah offers a promising way to enable users to build container images as Docker/OCI images all without root. It is plausible to use Buildah as the container image delivery mechanism and swap out the container run-time implementation (Podman vs. Singularity) depending on specific needs and requirements.

What do you think? 🔗

I hope other folks out there in the HPC world find this preliminary research useful. Do you agree or disagree with any parts of this write-up? Is something out-of-date? Drop a comment down below.

Special thanks and appreciation goes to Tim Zabel and Nic Hartley for their contributions this release cycle.

What’s new 🔗

• Bold usernames in message prefixes (#134, Nic Hartley)
• Include filetype in IRC string when a document is uploaded on Telegram (#139, Tim Zabel)
• Include zero-width space in username for join/part messages to group (#139, Tim Zabel)

Additionally, contributor documentation improved. I added contributor guidelines and instructions to set up a development environment. Also, our friends at Ura Design designed our new project logo. Thanks to Ura, we have an awesome project logo and stickers in time for Imagine RIT 2019 later this month!

They're here! Check out our new @uracreative logo and stickers for the #TeleIRC project. Grab some stickers at the @RITlug @Imagine_RIT festival on April 27! pic.twitter.com/KGjT4F0qdY

— RIT Linux Users Group (@RITlug) April 17, 2019

TeleIRC v1.3.1: sprint retrospective 🔗

Originally, we planned to release v1.4 at the end of this sprint. For a number of reasons, this did not happen. We decided to reduce our scope and finish strong with a bugfix release instead of the originally-planned feature release. This retrospective summarizes “lessons learned” for future project sprints with a team of university students.

Extended holidays are sprint bookends 🔗

In the last sprint, our university had a week-long break from classes. Most students use this time to visit family or travel outside of Rochester. Originally, we agreed to pause the sprint and resume when we returned. In retrospect, it didn’t work out like that.

It was harder to start again when we returned from the break. Instead of an extended holiday acting as a pause in an ongoing sprint, extended holiday breaks should divide two separate sprints. The breaks from classes are personal time; working on projects is not possible for everyone. The interruption caused by a break impacts productivity of the team. Therefore, future sprint planning will take the university calendar into consideration.

Adjustable sprint length to semester 🔗

Sprint lengths should have an adjustable length depending on what part of the academic semester the sprint is. For example, earlier this semester, we released v1.3 in a two-week sprint. For this v1.3.1 release, it was over a month. What happened? Should sprints have a variable length?

When working with an academic crowd, variable sprint lengths are worth considering. The first half of a semester typically has less assigned coursework. Final projects are not at play. Therefore, usually team members have more time to invest in the project at the start of a semester. Towards the end of the semester, coursework and class projects pile on and make it difficult to find bandwidth to work on side projects like TeleIRC.

The compromise is keeping our sprints short at the start of a semester and stretching them out as a semester goes on. This gives students more flexibility to work at a pace that encourages quality work but isn’t overwhelming with other responsibilities of being a student. Going forward, we will try variable-length sprints in the Fall 2019 semester.

Get involved with TeleIRC! 🔗

More opportunities are coming to participate with TeleIRC! The team is happy for new people to join us. Opportunities are available for short-term and long-term contributions.

Come say hello in our developer chat rooms, either on IRC or in Telegram! Watch for TeleIRC development reports on my blog for more announcements.

Background photo by Daria Nepriakhina on Unsplash.

What’s coming in TeleIRC v1.4 🔗

TeleIRC v1.4 is the next feature release of TeleIRC. The targeted release date for v1.4 is by the end of April 2019 (i.e. the end of the academic semester for students involved with the project). Following v1.4, the project will likely enter brief hibernation until Fall 2019 when the RIT academic semester begins again.

At the developer meeting on March 23rd, we discussed the scope of this sprint and what we felt is realistic for project maintainers to work on:

Primary goals 🔗

• Include limited characters from Telegram replies in relayed IRC message (RITlug/teleirc#51)
• Create doc page on development environment (RITlug/teleirc#77)
• QoL Improvements: show file-type of documents in IRC, insert ZWP character in join/leave messages (RITlug/teleirc#130)
• Allow user to configure more variables for IRC server connection (e.g. port, SSL certs, etc.) (RITlug/teleirc#113)

Secondary goals 🔗

• Add Telegram-side highlighting for IRC messages prefixed with username (RITlug/teleirc#44)
• Bold usernames on Telegram and IRC (RITlug/teleirc#19)

Recap of TeleIRC v1.3 sprint 🔗

The TeleIRC v1.3 release follows the v1.2.2 release on December 8th, 2018. This release is a significant change in how project development is done. For the first time, a special interest group inside of RITlug exists around the project. The team shifted to an agile-like development practice to fit inside of the RIT student academic schedule.

A special shout-out is earned by Tim Zabel for his support and participation as a core contributor during the v1.3 sprint.

Get involved with TeleIRC! 🔗

More opportunities are coming to participate with TeleIRC! We would love to have more people get involved and participate in the project. There is no formal commitment to contributing, although we ask for participation through a single sprint cycle.

Soon, we will have better new contributor on-boarding docs. Our weekly developer meetings are now happening over public audio/video call each Saturday at 15:00 US EDT, so anyone can join and participate.

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

Background photo by Daria Nepriakhina on Unsplash.

Read on to learn more about what’s coming in TeleIRC v1.3.

What’s coming in TeleIRC v1.3? 🔗

The developers’ meeting focused on identifying critical tasks to work on for the next sprint. The following open issues were identified as essential for v1.3:

• #41: Sending an image with a caption in telegram then editing the caption causes the image to get sent again
• #44: Add Telegram-side highlighting for IRC messages prefixed with username
• #53: multi-line messages should have each lined prefixed with the userid
• #102: Splitting of messages sent to IRC, prepending TG username to each one
• #112: Insert zero-width space in Telegram usernames sent to IRC
• #115: Image url reveals bot’s token
• #118: Refactor documentation into smaller pages (to make it more readable)

Of these, #53 and #102 will be closed by pull request #102. Michał Rudowicz contributed #102 and it should be merged during this sprint window. (Thanks Michał!)

Keep up with more development news by watching the v1.3 milestone on GitHub.

When is TeleIRC v1.3 coming? 🔗

TeleIRC v1.3 is projected for Saturday, March 2nd. For the selected issues, we felt four weeks was sufficient to accomplish and meet all existing goals. If we move faster than expected, we may move items from the v1.4 milestone up to this release.

How can I participate? 🔗

Want to help out or get involved with TeleIRC? We are happy to welcome you! Past contributors have come from all around the world.

Say hello in our Freenode IRC channel, #ritlug-teleirc, or join the Telegram group. You can also look through our “good first issue” tickets in GitHub. If something looks interesting, leave a comment of interest in the GitHub issue and a committer can offer more guidance.

If you are a user and want to share feedback or thoughts with the team, leave a comment on this blog post and they will be shared with the team.

Background photo by Daria Nepriakhina on Unsplash.

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

Speed breakout groups 🔗

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

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

Sustain OSS: High-level takeaways 🔗

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

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

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

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

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

Charitable participation in open source 🔗

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

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

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

Diversity and inclusion 🔗

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

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

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

Turning open source projects into sustainable ones 🔗

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

Design in open source 🔗

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

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

Financial sustainability models 🔗

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

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

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

Hour breakout sessions 🔗

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

Human aspect of governance 🔗

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

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

University engagement 🔗

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

In our session, two major topics were discussed:

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

• Research

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

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

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

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

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

Other takeaways 🔗

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

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

Skill share: conflict resolution 🔗

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

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

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

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

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

It’s not just about code.

Thank you 🔗

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

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

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

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

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

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

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.

Transparency is important to me. I wanted to make this announcement ahead of time to set clear expectations for the upcoming months. I am returning to Chicago, IL to work another internship at Jump Trading, LLC. From June to August, I am working at their Chicago office. I am excited to return and learn more from an amazing team of people.

I am not blocked by company policy from contributing to open source, so I won’t disappear completely. However, while I am still able to contribute to Fedora, I do not expect to keep up the level of activity that I contribute at now during my internship.

Away from May to August 2018 🔗

May is filled with other personal commitments, followed by a near immediate departure to Chicago in early June. Thus, I am stepping out of Fedora in early May. I hope to spend time with friends and family before departing for Chicago, so my estimate is a little generous to the benefit of being realistic. My internship ends around mid-August, so I hope to begin my normal levels of contribution around this time.

The only area I hope to stay partially active with is the Fedora Community Blog to continue my post as the editor-in-chief. While I still don’t expect being fully involved, I hope to help with editing and keeping things moving.

I’m looking forward to seeing familiar faces again in August at Flock 2018!

A series of heavy noreasters hit the US east coast over the last couple weeks. This coincided with my travel dates back to Rochester, NY. While we didn’t have flooding, we had a lot of snow. A lot of snow means canceled flights.

As I made my way through border control in Dublin, Ireland on March 7, I discovered my connection to New York City would likely be canceled. A meander from baggage claim to the check-in desk confirmed this. Fortunately, Aer Lingus had no issue putting me up in a hotel overnight with dinner and breakfast to catch the next flight to New York the next day.

While waiting in airport queues, a friend happened to retweet a local event happening in Dublin the next day.

For International Women's Day on Thursday, we'll be celebrating Female Firsts in medicine with @RCSILibrary https://t.co/RvIHtwAhys
Saturday, we have our @artandfeminism event in @UCC, celebrating our Irish and local female artists from 12-3pm https://t.co/ZMpKQOSR3q pic.twitter.com/0G7Kn3zpS6

— Wikimedia Community Ireland (@WikimediaIE) March 5, 2018

The event was a local Wikimedia meet-up to celebrate International Women’s Day. Participants would create and edit Wikipedia pages for influential women in the history of the Royal College of Surgeons in Ireland. After digging deeper, I found out the event was 30 minutes away from my hotel from 09:30 to 12:30. My flight was at 16:10.

I put in my RSVP.

Meet the Wikimedia Ireland community 🔗

In an opportunistic stroke of fate, I would spend my extended layover for my first time in Dublin learning and listening about role model women in the Irish medicine community. I didn’t know it yet, but I would also take part in writing some of the history too!

#WomenOnWalls 🔗

The first part of the morning was an introduction to editing on Wikipedia and establishing the focus for edits.

The Royal College of Surgeons in Ireland (RCSI) started a new campaign to promote influential women in the history of the university. There is a historical board room in a prominent place on its campus. Inside the board room, there are portraits of influential people in the history of RCSI. But all of them are men. This makes it difficult for women to have role models or inspiration of women like them who “made it” in science and medicine.

On the contrary, there was also no shortage of influential women in the history of RCSI. Part of the morning was an introduction to primary sources that explained the pivotal work of female Irish doctors and pediatricians throughout the 20th century. After hearing about these inspirational women, it was a wonder – why were none of them represented in the board room?

This was actually the focus for the edit-a-thon. Recently, RCSI commissioned new portraits for some of the influential women alumnae. Half of the portraits in the board room would be relocated and replaced by the new portraits. This was part of their #WomenOnWalls campaign.

Discovering Victoria Coffey 🔗

After an introduction to the sources available and how to edit on Wikipedia, we began the editing. Organizers encouraged participants to improve an existing page first, since most of the participants were first-time editors.

Since I had some experience with Mediawiki mark-up and do a lot of writing, I decided to write a new page. There were a list of suggested women alumnae to write about. After hearing about Victoria Coffey, I decided to focus my two hours of writing on her legacy.

Who is Victoria Coffey? 🔗

Victoria Coffey was an Irish pediatrician. She was an alumna of RCSI, and one of the first to research sudden infant death syndrome (SIDS). Coffey spent most of her time in medicine researching and studying congenital abnormalities in infants and pediatrics. Later in her life, she founded the Faculty of Paediatrics at the Royal College of Physicians of Ireland in 1981 and was the first female president of the Irish Paediatric Society.

Writing her Wikipedia page 🔗

With the help and guidance of the Wikimedia Ireland and RCSI staff, I found resources to research and learn more about Victoria Coffey. While some public sources were available, I was also provided with a primary source from a paid online Irish encyclopedia.

From there, I had the basis to begin writing a stub for her biography. I created an infobox to summarize some of her contributions, wrote a paragraph on her life, and left external links for someone to expand and write more in the future.

You can find her Wikipedia page online now. Since its creation, it was viewed nearly 100 times, edited five times, and edited by three people.

Thank you RCSI and Wikimedia Ireland! 🔗

In a strange and opportunistic stroke of fate, I was lucky to meet this local community and work with a room of inspiring women in medicine (students, alumnae, and faculty) on lowering the wiki gap of women on Wikipedia. It was a privilege to take part and learn a unique kind of history for Ireland in my short stay in Dublin.

Thank you for this great experience, RCSI and Wikimedia Ireland!

I’m not sure if this will make me anticipate flight cancellations more or less from now on.

Open source becomes more common every year, where it appears at government municipalities to universities. More companies turn to open source software too. However, some companies try to take it a step further, and instead of only using the software, they also support projects financially or with developers. Facebook’s open source program encourages others in Facebook to release their code as open source. They also work and engage with the community to support the projects too.

Christine Abernathy, a Facebook developer advocate and member of the open source team, visited the Rochester Institute of Technology on November 15, 2017. She gave the November edition of the FOSS Talks speaker series. Her talk explained how Facebook approaches open source and why it’s an important part of the work they do.

Facebook and open source 🔗

Abernathy explained that open source plays a fundamental role in Facebook’s mission to create community and bring the world closer together. The ideological match was a motivational reason for Facebook’s participation in open source.

Additionally, Facebook has unique problems and challenges to solve for their infrastructure and development. Open source provides a platform to share those challenges and help others avoid similar mistakes.

Open source also provided a way to accelerate innovation and create better software. It helped engineering teams produce better software and work more transparently. Today, Facebook’s 443 projects on GitHub have 122,000 forks, 292,000 commits, and 732,000 followers.

Lessons learned 🔗

Abernathy emphasized that Facebook has learned many lessons from the open source community and hopes to learn many more. She identified the three most important lessons that Facebook took from open source:

1. Share what’s useful
2. Highlight your heroes
3. Fix common pain points

Christine Abernathy visited RIT as part of the FOSS Talks speaker series. Every month, a guest speaker from the open source world shares wisdom, insight, and advice about the open source world with students interested in free and open source software. The FOSS @ MAGIC community is thankful to have Abernathy attend as a speaker!

My internship at UNICEF is unique: I support open source community engagement and research as my primary task for the MagicBox project. For years, I’ve done this in open source communities in my free time (namely SpigotMC and Fedora), but never in a professional role. As I navigate my way through this exciting opportunity, I plan to document some of the experience as I go through blogging. My intent is that my observations and notes will be useful to someone else in the humanitarian open source space (or maybe to a future me).

But first, what does “open source community engagement and research” really mean?

What am I actually doing? 🔗

“Community engagement” is a buzzword phrase for the open source movement in the 2010s. Often, we hear about “community engagement” or the work of those “leading communities”, but it’s an abstract concept. In other words, building communities of humans and people is hard. There is no one-size-fits-all solution for any community. Every community has its own unique needs and goals. This means different methods of management and communication work better for some communities than others. My job is to help light the way for what this pathway means for the MagicBox team.

Since I started in January, a lot of my time so far was spent learning. What is MagicBox? What are we trying to deliver to our stakeholders? To the open source community? How does our data pipeline piece together? All these questions and more, I’ve tried to answer to different levels of success.

What’s next? 🔗

Now, I’m beginning to take a more hands-on role with the work, with a clear vision of what I want to do. The next few posts to come will dive deeper into what I’m up to.

If you have questions or are interested in keeping up with what’s going on, feel free to leave a comment here or subscribe to my blog to automatically receive future updates.

Opinions and views in my blog are my own and do not reflect the views of my employer.

This week is the last week of the fall 2017 semester at RIT. This semester, I spent time with the MetaBrainz community working on ListenBrainz for an independent study. This post explains what I was working on in the last month and reflects back on my original objectives for the independent study.

Running my own ListenBrainz 🔗

The RIT Linux Users Group hosts various virtual machines for our projects. I requested one to set up and host a “production” ListenBrainz site. The purpose of doing this was to…

1. Test my changes in a “production” environment
2. Offer a service for the RIT Linux Users Group to poke around with

I spent most of this time working with our system administrator to set up the machine and adjust hardware specs for ListenBrainz. Once we fixed storage space and memory issues, it was easy to set it up and get ListenBrainz running. My experience writing the development guide made it easy to get set up and get working. On the first run, it worked!

Now, listen.ritlug.com is live.

Figuring out HTTPS 🔗

My next challenge for the site is to set up HTTPS. I tried using a reverse proxy in nginx to set up HTTPS, but I received 502 Bad Gateway errors. I realized I spent too much time figuring this out on my own and decided to ask for help in the MetaBrainz community forums.

Proposing new statistics 🔗

Halfway through the independent study, I realized I would fall short of my original objective of implementing basic statistics in ListenBrainz. To compromise, I wrote a proposal for new statistics to start in the project. My proposal looked at other proprietary platforms that compete with ListenBrainz to see some of their statistics. I also came up with some of my own.

I proposed this to the MetaBrainz community on the community forums. I’m awaiting feedback on my ideas. Once I get feedback, I plan to file new tickets for each statistic to track their implementation over time.

I don’t expect statistics being at the forefront of ListenBrainz for some time. A lot of work is going towards other areas of the project. But later in 2018, I expect more focus on the user-facing side of the project.

My statistic and Google BigQuery 🔗

My biggest blocker over the last month was Google BigQuery. I wrote a statistic to calculate play counts over a time period, but was asked to test my statistic. To test my statistic, I needed real data to work with.

Originally, I tried using the Simple Last.fm Scrobbler to submit listens to the local IP address for my development environment, but I wasn’t able to get the app to reach my ListenBrainz server. To get the data, I had to set up Google BigQuery credentials so I could make queries against data on the production site, listenbrainz.org.

I tried working through the Google BigQuery documentation. There’s a lot of documentation for using BigQuery as a developer, but it was confusing where to find the information I needed to set it up in my development environment. I tried creating a new project in the Google Cloud Platform, but I was confused because it prompted me to upload my own data instead of accessing data already in BigQuery.

Too late, I realized I spent too much time on my own and not asking for help. I submitted a pull request with the statistic I made and asked for help in the MetaBrainz community. I also offered to write documentation for setting this up once I learn how to do it.

Reflecting back 🔗

I looked back on my original objectives for the independent study, and I was satisfied and dissatisfied.

Not enough programming 🔗

I wanted this independent study to enhance my programming knowledge. I especially wanted to focus on Python because I wanted to become more familiar with the language. However, I actually didn’t do much programming during the independent study, to my own fault.

My biggest challenge was I bit off more than I could chew. I wanted to write code, and made a big goal before I knew the code base of the project. Even now, I still am not completely comfortable with the code yet. It’s a big project with a lot of things going on. I was able to understand the things I did work on, but there’s still a lot.

I realized that next time, I need to spend more time evaluating the code base of a project before writing out my milestones. I wish I set more realistic, smaller milestones for myself. My milestone of implementing basic reports was lofty given my existing programming knowledge.

Successes 🔗

One of my other objectives was to write documentation for the project. I felt I succeeded in this milestone, and actually found it enjoyable and interesting to do! I helped separate out documentation from the README into the dedicated ReadTheDocs site. I wrote the development environment guide and helped fix some build issues with the docs site. I also plan to write more for some of the other pain points I found, like Google BigQuery.

My last milestone was to create a use case for a data visualization course at RIT. While I didn’t implement my basic reports, I did create the proposal and make an effort to write new statistics. There’s a lot of potential now to work with the data in Google BigQuery and do front-end work with tools like D3.js and Plotly.js. I believe there’s significant potential to use ListenBrainz as a hands-on project for students to explore data visualization with real data. I hope to support my independent study professor, Prof. Roberts, with questions and logistics of using it as a tool for learning in the future.

Unexpected success 🔗

I also think I had an unplanned success too. I immersed myself in the community for ListenBrainz too. Over the last few months, I realized that many of my strengths are in community management and tooling. During my time in the community, I did the following:

• Fixed SELinux labels in Docker
• Contributed a pull request template
• Drafted contributing guidelines
• Fixed a PostgreSQL bug
• And more…

To the future! 🔗

This ends my independent study with ListenBrainz, but it doesn’t end my time contributing! I chose ListenBrainz because it’s a project I’m passionate about. An independent study allowed me to justify more time on it than a side project in my free time. I’m happy to have that opportunity, but I don’t want to end here!

I want to follow through on the statistics because I’m passionate about understanding music listening trends. I think there’s a lot of power for psychological research through music data. To this point, I filed a ticket to request tagging listens with “emotion” words that are synced back to MusicBrainz entities.

I won’t have as much time to work on the project without the course credit, but I hope to stay involved for the future. I love the project and I love the community. I’m thankful for the opportunity to work on this project as an independent study, and learn some things along the way.

My progress with ListenBrainz slowed, but I am resuming the pace of contributing and advancing on my independent study timeline. This past week, I finished out assigned tasks to discuss contributor-related documentation, like a Code of Conduct, contributor guidelines, and a pull request template. I began research on user statistics and found some already created. I wrote one of my own, but need to learn more about Google BigQuery to advance further.

Paving the contributor pathway 🔗

Earlier, I identified weaknesses for the ListenBrainz contributor pathway and found ways we could improve the pathway. This started with the development environment documentation. Now, I helped draft first revisions of our contributor guidelines, Code of Conduct reference, and pull request templates. Together, these three documents have two goals.

1. Make it easier to contribute to ListenBrainz
2. Have a better experience and have fun contributing!

Adding these documents addresses these goals. Additionally, the GitHub community profile also highlights these deliverables as ways to meet these goals. After getting feedback and seeing what others think, we make more revisions later (with some trial runs).

Back to SELinux context flags 🔗

Recently, I set my desktop back up and installed Docker for the first time on this machine; however, the development environment still failed to start. When I ran the script, it would eventually error out because of a permission denial. The web server image for ListenBrainz was failing.

After debugging, I noticed that I missed the SELinux volume tags for the ListenBrainz web server images in my original pull request, #257. When I created the pull request, I might have had cached data that let my laptop run the development environment without a problem. In either case, it was an easy fix and I knew what the issue was when it happened. Therefore, I submitted a new fix in #290.

Writing new user statistics 🔗

The most interesting part of my independent study is working with the music data to build and generate interesting statistics. I finally began exploring the existing statistics in ListenBrainz. The statistic queries use BigQuery standard SQL. BigQuery helps rapidly scan and scale data queries to help with performance (I have a lot to learn about BigQuery).

Two types of statistics 🔗

Additionally, ListenBrainz generates two types of statistics:

1. Site-wide statistics
2. User statistics

Site-wide statistics are metrics non-specific to a single user. There is only one site-wide query now. It counts how many artists were ever submitted to this ListenBrainz instance and returns an integer. There’s room for expansion in site-wide statistics.

On the other hand, user statistics are metrics specific to a single user. There’s a fair number already, like the top artists and songs in a time period and the number of artists you’ve listened to. These are a little more complete and offer more expansion for doing cool front-end work with something like D3.js.

Writing user statistics 🔗

Of course, I had to try writing my own. One helpful query I thought of was getting a count of the songs you listened to over a time period (e.g. “you listened to 500 songs this week!”). I haven’t tested it yet, but I have this in a local branch and hope to test it with real data soon.

def get_play_count(musicbrainz_id, time_interval=None): 
 
 filter_clause = "" 
 if time_interval: 
     filter_clause = "AND listened_at >=
     TIMESTAMP_SUB(CURRENT_TIME(), 
     INTERVAL {})".format(time_interval) 
 
 query = """SELECT COUNT(release_msid) as listen_count 
            FROM {dataset_id}.{table_id} 
            WHERE user_name = @musicbrainz_id 
            {time_filter_clause} 
            LIMIT {limit} 
         """.format( 
                 dataset_id=config.BIGQUERY_DATASET_ID, 
                 table_id=config.BIGQUERY_TABLE_ID, 
                 time_filter_clause=filter_clause, 
                 limit=config.STATS_ENTITY_LIMIT, 
            ) 
 
 parameters = [ 
     { 
         'type': 'STRING', 
         'name': 'musicbrainz_id', 
         'value': musicbrainz_id 
     } 
 ] 
 
 return stats.run_query(query, parameters)

Researching Google BigQuery 🔗

My next steps for the independent study are researching Google BigQuery. After going through the existing statistics and understanding how ListenBrainz generates them, an understanding of Google BigQuery is essential to writing effective queries. When I become more comfortable with the tooling and how it works, I want to map out a plan of statistics to generate and measure.

Until then, the hacking continues! As always, keep the FOSS flag high…

Recently, I discovered brightlight, a tool that changes backlight brightness. I decided to try it, and it worked with root privileges. However, I found there was no RPM package in Fedora for brightlight. I decided this was the right time to try creating a package in Fedora and learn how to create an RPM.

In this article, I’ll cover and share how I…

• Created the RPM SPEC file
• Built the package in Koji and Copr
• Worked through an issue with debug package
• Submitted the package to Fedora package collection

Pre-requisites 🔗

On Fedora, I installed these packages for all steps of the package building process.

sudo dnf install fedora-packager fedpkg fedrepo_req copr-cli

Creating the RPM SPEC file 🔗

The first step to create a RPM is to create the SPEC file. These are the specifications, or instructions, that tell RPM how to build the package. This is how you tell RPM to create a binary file from the package’s source code. Creating the SPEC file is likely the hardest part of the packaging process and its difficulty depends on the project.

Fortunately for me, brightlight is a simple application written in C. The maintainer made it easy to create a binary application with a Makefile. Building it was a matter of simply running make in the repo. So now I had a simple project to learn RPM packaging.

Finding documentation 🔗

Googling “how to create an RPM package” yields many results. I started with IBM’s documentation. However, I found it confusing and difficult to understand (although quite detailed; it might be more useful for a complicated app). I also found the package creation instructions on the Fedora wiki. The documentation here was good at explaining the composition and process, but I was still confused on how to begin.

Finally, I found the RPM Packaging Guidelines, written by the amazing Adam Miller. These instructions were helpful and included three excellent examples for Bash, C, and Python applications. This guide helped me better understand how to compose a RPM SPEC, and more importantly, how all the pieces fit together.

After this, I was able to write my first SPEC file for brightlight. Since it is so simple, the SPEC file is short and easy to understand. Once I had my SPEC file, I linted the file for errors. After cleaning a few mistakes, I created the source RPM (SRPM) and the binary RPM, then linted each for errors.

rpmlint SPECS/brightlight.spec
rpmbuild -bs SPECS/brightlight.spec
rpmlint SRPMS/brightlight-5-1.fc26.src.rpm
rpmbuild -bb SRPMS/brightlight-5-1.fc26.src.rpm
rpmlint RPMS/x86_64/brightlight-5-1.fc26.x86_64.rpm

Now, I had a valid RPM to send to the Fedora repositories.

Building in Copr and Koji 🔗

Next, I read the guidelines to becoming a Fedora packager. Before submitting anything, they encouraged packagers to test their packages by hosting the project in a Copr repo and building in Koji.

Using Copr 🔗

First, I created a Copr repository for brightlight. Copr is a service in Fedora’s infrastructure that builds your package and sets up a custom repo for whatever version of Fedora or EPEL that you choose. It’s handy to get your RPM hosted quickly and to share it with others for testing. You don’t need special approval to host a Copr.

I created my Copr project from the web interface, but you can also use the copr-cli tool. There is an excellent guide in the Fedora Developer portal. After I created my repo on the website, I built my package with this command.

copr-cli build brightlight SRPMS/brightlight.5-1.fc26.src.rpm

My packages successfully built for Copr and I was able to install it on my Fedora system easily.

Using Koji 🔗

Anyone can use Koji to test their package on multiple architectures and versions of Fedora or CentOS / RHEL. To test on Koji, you must have a source RPM. I wanted to package brightlight on all supported versions of Fedora, so I ran these commands.

koji build --scratch f25 SRPMS/brightlight-5-1.fc26.src.rpm
koji build --scratch f26 SRPMS/brightlight-5-1.fc26.src.rpm
koji build --scratch f27 SRPMS/brightlight-5-1.fc26.src.rpm

It took some time, but Koji built all the packages. Everything was fine for Fedora 25 and 26, but Fedora 27 failed. Koji scratch builds keep me on the right track and make sure my packages build successfully.

Problem: Fedora 27 builds failing! 🔗

Now I know that my Fedora 27 package was failing to build on Koji. But why? I discovered two relevant changes for Fedora 27.

• Subpackage and Source Debuginfo
• RPM 4.14 (specifically, the debuginfo package rewrite)

These changes mean that RPM packages must build with a debuginfo package. This is helpful for troubleshooting or debugging an application. In my case, this wasn’t critical or too necessary, but I needed to build one.

Thanks to Igor Gnatenko, he helped me understand what I needed to add to my package SPEC for it to build on Fedora 27. Before the %make_build macro, I added these lines.

export CFLAGS="%{optflags}"
export LDFLAGS="%{__global_ldflags}"

I built a new SRPM and submitted it to Koji to build on Fedora 27. And success! It built successfully.

Submitting the package 🔗

Now that I verified my package successfully built on Fedora 25 to 27, it’s time to begin the packaging process for Fedora. The first step to submitting a package is to create a new bug in the Red Hat Bugzilla to ask for a package review. I created a ticket for brightlight. Since this was my first package, I made an explicit note that this was my first package and I was seeking a sponsor. In the ticket, I linked to the SPEC and SRPM files in my git repository.

Getting into dist-git 🔗

Edit, 2022 Feb. 14th: It was pointed out on Twitter that the fedrepo-req tool is no longer used. See the documentation linked throughout this blog post for more guidance on best practices for today.

Igor Gnatenko sponsored me into the Fedora Packagers group and left feedback on my package. I learned of some other things specific for packaging C applications. After he sponsored me, I was able to ask for a repo in dist-git, Fedora’s collection of RPM package repositories that host SPEC files for all of Fedora.

A handy Python tool helps make this part easy. fedrepo-req is a tool that creates a request for a new dist-git repository. I submitted my request with this command.

fedrepo-req brightlight \
    --ticket 1505026 \
    --description "CLI tool to change screen back light brightness" \
    --upstreamurl https://github.com/multiplexd/brightlight

This created a new ticket for me in the fedora-scm-requests repo. The next day, an admin created the repository for me. Now, I was in business!

Working with dist-git 🔗

Next, fedpkg is the tool used for interacting with dist-git repositories. I changed directories into my git working directory and ran this command.

fedpkg clone brightlight

fedpkg then clones my package’s repo from dist-git. For the first branch only, you need to import the SRPM.

fedpkg import SRPMS/brightlight-5-1.fc26.src.rpm

fedpkg imports your package’s SRPM into the repo and sets up the sources for you. It’s important to use fedpkg for this because it helps provision the repo in a Fedora-friendly way (as compared to adding the files manually yourself). Once you import the SRPM, push the changes to the dist-git repo.

git commit -m "Initial import (#1505026)."
git push

Building the package 🔗

Once you push the first import to your dist-git repo, you’re ready to do a real Koji build of your project. To build your project, run this command.

fedpkg build

This builds your package in Koji for Rawhide, the unversioned branch of Fedora. You must build successfully for Rawhide before you can build for other branches. IF everything builds successfully, you can now ask for other branches for your project.

fedrepo-req brightlight f27 -t 1505026
fedrepo-req brightlight f26 -t 1505026
fedrepo-req brightlight f25 -t 1505026

Note about building other branches 🔗

Once you import the SRPM initially, remember to merge your master branch to other branches, if you choose to create them. For example, if you later request a branch for Fedora 27, you would want to use these commands.

fedpkg switch-branch f27
git merge master
git push
fedpkg build

Submitting update to Bodhi 🔗

The last step of the process is to submit your new package as an update to Bodhi. When you first submit your package as an update, it goes to the testing repositories. Anyone can test your package and add karma to the update. If your update receives +3 votes (or as Bodhi calls it, karma), your package automatically pushes to the stable repositories. Otherwise, it pushes after a week in the testing repositories.

To submit your update to Bodhi, you only need one command.

fedpkg update

This opens a Vim window with different configuration options for your package. Usually, you only need to specify the type (e.g. newpackage) and the ticket ID number for your package review. For a more in-depth explanation, there is an update guide on the Fedora wiki.

After saving and exiting the file, fedpkg submits your package as an update to Bodhi and eventually synchronizes to the Fedora testing repositories. I was able to install my package with this command.

sudo dnf install brightlight -y --enablerepo=updates-testing --refresh

We’re stable! 🔗

My package was recently submitted to Fedora 26 stable repositories and will soon enter Fedora 25 and Fedora 27 stable repositories. Thanks for everyone who helped me with my first package. I look forward to more opportunities to add more packages to the distribution.

Last week moved quickly for me in ListenBrainz. I submitted multiple pull requests and participated in the weekly developer’s meeting on Monday. I was also invited to take part as a mentor for ListenBrainz for the upcoming round of Google Code-In! In addition to my changes and new role as a mentor, I’m researching libraries like D3.js to help build visualizations for music data.  Suddenly, everything started moving fast!

Last week: Recap 🔗

The ListenBrainz team accepted my development environment improvements and documentation. This gave me an opportunity to better explore project documentation tools. I experimented with Sphinx and Read the Docs. Sphinx introduced me to reStructuredText for documentation formats. I’ve avoided it in favor of Markdown for a long time, but I see where reStructuredText is stronger for advanced documentation.

Since ListenBrainz is a new project, I plan to contribute documentation for any of my work and improve documentation for pre-existing work. One of the goals for this independent study is to make ListenBrainz a viable candidate for a future data analysis course. To make it easy to use and understand, ListenBrainz needs excellent documentation. Since one of my strengths is technical writing, I plan to contribute more documentation this semester.

You can see some of the new documentation already!

Google Code-In mentor 🔗

The MetaBrainz community manager, Freso Olesen, approached me to mentor for Google Code-In. Google Code-In is an opportunity for teenagers to meaningfully contribute to open source projects. Google describes Google Code-In as…

Pre-university students ages 13 to 17 are invited to take part in Google Code-in: Our global, online contest introducing teenagers to the world of open source development. With a wide variety of bite-sized tasks, it’s easy for beginners to jump in and get started no matter what skills they have.

Mentors from our participating organizations lend a helping hand as participants learn what it’s like to work on an open source project. Participants get to work on real software and win prizes from t-shirts to a trip to Google HQ!

MetaBrainz is a participating organization of Google Code-In this cycle. Because of my work with ListenBrainz, I will contribute a few hours a week to help mentor participating students with ListenBrainz. Beginner problems should be easy to help with since I’m still beginning too, and as I spend more time with ListenBrainz, I can help with harder problems.

I’m excited to give back to one of my favorite open source projects in this way! I’m grateful to have this chance to help out during Google Code-In.

Choosing easyfix bugs 🔗

After I figured out the development environment issues, I went through open tickets filed against ListenBrainz to find some to work on. I made a preliminary pass through all open tickets and left some comments for more information, when needed. The tickets I highlighted to look into next were

• LB-85: Username in the profile URL should be case insensitive
• LB-124: Install messybrainz as a a python library from requirements
• LB-176: Add stats module and begin calculating some user stats from BigQuery
• LB-206: “playing_now” submissions not showing on profile
• LB-212: Show the MetaBrainz logo on the listenbrainz footer.

Of these five, LB-124 and LB-212 are already closed. While drafting this article, I completed LB-124 in PR #266. This was part of a test to get the documentation building again because of odd import errors. Later, a new student also learning the project for the first time asked to work on LB-212. Since it was a good first task to explore the project code, I passed the ticket to him.

I want to do one more “easyfix” bug before going into the main part of my independent study timeline. I don’t yet feel comfortable with the code and one more bug solved will help. After this, I plan to pursue the heavier lifting of the independent study to explore data operations and queries to make.

Researching D3.js 🔗

Prof. Roberts introduced D3.js as a library to build interactive, dynamic charts and visual representations of data. I haven’t yet looked into much front-end work, but this was a cool project that I wanted to highlight in my weekly report. This feels like it could be a powerful match for ListenBrainz, especially since the data has high detail.

Upcoming activity 🔗

This next week, I won’t have as much time to contribute to ListenBrainz. On October 21, I’m traveling to Raleigh, NC for All Things Open. On October 24, I present my talk, “What open source and J.K. Rowling have in common”. Since I’ll be out of Rochester and missing other classwork, I expect less time on my ListenBrainz work.

This next week will be slower than the last two weeks. Hopefully I’ll learn something at the conference too to bring back for ListenBrainz.

Until then… keep the FOSS flag high.

One of the first rites of passage when working on a new project is creating your development environment. It always seems simple, but sometimes there are bumps along the way. The first activity I did to begin contributing to ListenBrainz was create my development environment. I wasn’t successful with the documentation in the README, so I had to play around and work with the project before I was even running it.

The first part of this post details how to set up your own development environment. Then, the second half talks about the solution I came up with and my first contribution back to the project.

Install dependencies: Docker 🔗

This tutorial assumes you are using a Linux distribution. If you’re using a different operating system, install the necessary dependencies or packages with your preferred method.

ListenBrainz ships in Docker containers, which helps create your development environment and later deploy the application. Therefore, to work on the project, you need to install Docker and use containers for building the project. Containers save you from installing all of this on your own workstation! Since I’m using Fedora, I run this command.

sudo dnf install docker docker-compose

Register a MusicBrainz application 🔗

Next, you need to register your application and get a OAuth token from MusicBrainz. Using the OAuth token lets you sign into your development environment with your MusicBrainz account. Then, you can import your plays from somewhere else.

To register, visit the MusicBrainz applications page. There, look for the option to register your application. Fill out the form with these three options.

• Name: (any name you want and will recognize, I used listenbrainz-server-devel)
• Type: Web Application
• Callback URL: http://localhost/login/musicbrainz/post

After entering this information, you’ll have a OAuth client ID and OAuth client secret. You’ll use these for configuring ListenBrainz.

Update config.py 🔗

With your new client ID and secret, update the ListenBrainz configuration file. If this is your first time configuring ListenBrainz, copy the sample to a live configuration.

cp listenbrainz/config.py.sample listenbrainz/config.py

Next, open the file with your favorite text editor and look for this section.

# MusicBrainz OAuth
MUSICBRAINZ_CLIENT_ID = "CLIENT_ID"
MUSICBRAINZ_CLIENT_SECRET = "CLIENT_SECRET"

Update the strings with your client ID and secret. After doing this, your ListenBrainz development environment is able to authenticate and log in from your MusicBrainz login.

Initialize ListenBrainz databases 🔗

Your development environment needs some databases present to work. Before proceeding, run these three commands to initialize the databases.

docker-compose -f docker/docker-compose.yml -p listenbrainz run --rm web python3 manage.py init_db --create-db
docker-compose -f docker/docker-compose.yml -p listenbrainz run --rm web python3 manage.py init_msb_db --create-db
docker-compose -f docker/docker-compose.yml -p listenbrainz run --rm web python3 manage.py init_influx

Your development environment is now ready. Now, let’s actually see ListenBrainz load locally!

Run the magic script 🔗

Once you have done this, run the develop.sh script in the root of the repository. Using docker-compose, the script creates multiple Docker containers for the different services and parts of the ListenBrainz server. Running this script will start Redis, PostgreSQL, InfluxDB, and web server containers, to name a few. But this also makes it easy to stop them all later.

./develop.sh

You will see the containers build and eventually run. Leave the script running to see your development environment. Later, you can shut it down by pressing CTRL^C. Once everything is running, visit your new site from your browser!

http://localhost/

Now, you are all set to begin making changes and testing them in your development environment!

Making my first pull request 🔗

As mentioned earlier, my first attempt at a development environment was unsuccessful. My system kept denying permission to the processes in the containers. After looking at system audit logs and running a temporary setenforce 0, I tried the script one more time. Everything suddenly worked! So the issue was mostly with SELinux.

With my goal to get my environment set up, I figured out a few issues with the configuration offered by the project developers. I eventually made PR #257 against listenbrainz-server with my improvements.

Labeling SELinux volume mounts 🔗

To diagnose the issue, I started with a quick search and found a StackOverflow question with my same problem. There, the question was about Docker containers and denied permissions in the container. The answers explained it was an SELinux error and the context for the containers was not set. However, temporarily changing context for a directory didn’t seem too effective and doesn’t persist across reboots.

Continuing the search, I found an issue filed against docker-compose about the :z and :Z flags for volume mounts. These flags set SELinux context for containers, with the best explanation I found coming from this StackOverflow answer.

Two suffixes :z or :Z can be added to the volume mount. These suffixes tell Docker to relabel file objects on the shared volumes. The ‘z’ option tells Docker that the volume content will be shared between containers. Docker will label the content with a shared content label. Shared volumes labels allow all containers to read/write content. The ‘Z’ option tells Docker to label the content with a private unshared label.

Therefore, I added the :z flag to all the volume mounts in the docker-compose.yml file. I submitted a fix upstream for this in listenbrainz-server#257!

Correct the startup port 🔗

In the README, it says the server will start on port 8000, but the docker-compose.yml file actually started the server on port 80. I included a fix for this in my pull request as well.

git push! 🔗

This post makes a debugging experience that actually took hours look like it happened in minutes. But after getting over this hurdle, it was awesome to finally see ListenBrainz running locally on my workstation. It was an even better feeling when I could take my improvements and send them back in a pull request to ListenBrainz. Hopefully this will make it easier for others to create their own development environments and start hacking!

Many students take part in independent studies where they work on their own projects. However, in the spirit of open source collaboration, I wanted to contribute to a project that already existed. That way, my work would be helpful to a real-world project where it would have a value even after the end of the semester. Additionally, I wanted  a project to help me sharpen my Python skill. And ListenBrainz was a fun, exciting candidate for this.

Objectives 🔗

The independent study proposal included three primary goals I hoped to meet during this independent study:

1. Add basic reports to ListenBrainz from listening history data for top songs / artists / albums of week, month, year, etc.
2. Create documentation to improve ease to use and develop for the ListenBrainz project
3. Offer as a use case for the data visualization course in fall 2018 with instructions on how to use the data

Add basic reports 🔗

Methods for generating basic reports, charts, and statistics about listening history are important. They help make ListenBrainz a more interesting platform for a casual music listener, not just a developer. Therefore, my goal was to add a way to add basic reports or specific metrics for presenting to the user in the front-end.

As a stretch goal, if I have extra time, I would work on generating content (e.g. charts / graphs / statistics) to show the user in the front-end.

Documentation 🔗

Documentation is something near and dear to me. I enjoy making it easier for other people to use a project or get started with contributing. Therefore, I will contribute some time as a technical writer and help improve documentation on the project. This includes improving existing documentation, like how to set up a development environment, or creating new content.

As an end deliverable, it would be nice to have someone who has never worked with the project run get a development environment set up, import some data, and see something presented to them. Good documentation is key to making something like this possible.

Use case for data course 🔗

RIT will offer a data visualization course in future semesters and it would be helpful if ListenBrainz could be a use case or even tool for the course. Then, students could work with ListenBrainz for creating different visualizations for the music data. And maybe contribute some of their visualizations back upstream! For this to happen, we need comprehensive documentation and complete features.

A focus includes making ListenBrainz a good fit for this course.

Learn more about ListenBrainz 🔗

For the next few months, until December, I will blog regularly about contributing to the ListenBrainz project and my progress. Additionally, more posts about MusicBrainz, other MetaBrainz projects, or music data may follow. I’m hoping to either create new or improve old documentation as well, so I plan to write often anyways!

For now, you can learn a bit more about ListenBrainz and other projects in the MetaBrainz family, like MusicBrainz.

• ListenBrainz
• GitHub: metabrainz/listenbrainz-server
• About MusicBrainz
• About MetaBrainz

Open source software has come a long way since the turn of the century. Each year, more and more people are embracing open source technology and development models. Not just people, though ­– corporations and governments are exploring open source solutions too. From the White House to the Italian army, open source is appearing more frequently in the public sector. But perhaps the newest addition to the list is the municipality of Tirana, Albania.

On June 11th, the local government in the municipality of Tirana migrated their private cloud to Nextcloud, an open source cloud and office productivity suite. The decision to move to an integrated cloud / office suite came after internal discussion about security and performance. Because Nextcloud is entirely open source, it stood out as a powerful option for the municipality to consider.

Why switch to Nextcloud? 🔗

The municipality was looking for ways to optimize on costs without sacrificing security. Many people deeply familiar with open source are already aware of the security benefits of using open source software. Instead of relying on a private firm to assure the code is secure, open source software benefits from letting anyone (or paying someone else) to audit the code, find flaws, and submit bugs or patches to get them fixed. This was something Ermir Puka and other members of the IT team in Tirana considered when choosing a cloud solution for the 600 employees of the municipality.

“The IT directory at the municipality of Tirana thought the movement to Nextcloud, which is an open source platform, gives us flexibility since we won’t be dependent from providers who offer proprietary solutions. We can also develop it ourself, according to our needs, if we have the staff with the necessary qualifications to do such a thing,” Puka said.

Nextcloud also stood out not only for its use as a file sharing tool, but also the other features that make it helpful as an office productivity suite. With Nextcloud, you can edit documents simultaneously with Collabora Online, share calendars with co-workers, use an intranet messaging system, and use it on your phone too. A large selection of open source apps are available to add to an Nextcloud installation.

According to European Commission Joinup, Tirana is one of the first municipalities in southeastern Europe implementing open source technology in the public sector. This continues the municipality’s growing interest in open source, following the recent announcement of their open data portal (see it at opendata.tirana.al) and decision to collaborate with the local open source community by contributing GIS data to OpenStreetMaps. “We also hope to give a good example in the region and maybe other municipalities can follow our example,” Puka added. This further shows the municipality’s dedication to saving money on software licenses, protecting user privacy, and innovating by using open source technology.

About Tirana 🔗

Tirana is located in Albania, in southeastern Europe, on the Mediterranean Sea just above Greece. The open source community in Tirana is growing each year. This is in part to the Open Labs Albania community in the city. Open Labs Albania is a not-for-profit hackerspace that promotes free and open source technologies, open data, open technological standards, and online privacy. You can read more about them in their manifesto.

This continues a trend of exciting news for open source in the region. Earlier this year, the first-ever overnight hackathon for the UN Sustainable Development Goals happened in March, with an emphasis on sustainable projects with open source licenses. They also host Linux Weekend, an annual mini-conference to help on-board students and interested technologists to Linux and open source. However, their most well-known event is Open Source Conference Albania (OSCAL), an annual conference gathering open source developers and community members from across the world. Together with the municipality, Open Labs has helped provide advice and support for some of the municipality’s research into using open source software.

Get in touch 🔗

If you’re interested in learning more or sharing your thoughts, you can view the public announcement on the European Commission website or visit the thread on the Open Labs forums.

The team consists of four people: Elio Qoshi, Redon Skikuli, Giannis Konstantinidis, and Anxhelo Lushka. Ura Design started from an idea. The team believed that many open source projects are full of capabilities and features, but their design can make it difficult for users to effectively use the software. This could be through user experience, branding, or accessibility. And the goal? To help bring these better design principles to open source projects at little to no cost. “In open source, there are amazing projects that are poorly communicated with the outside world. By communication, we mean visual communications, branding, even marketing. That is nonexistent for many reasons. There is a connection between communicating your project well and also getting contributors or users on board,” says Skikuli.

The Ura Design team helps open source projects improve their design so they can focus on great code.

How it works 🔗

Together, the four of them work with open source project owners to help them bring better design elements to their projects. The principles of ethical design are part of the goals and values of the project.

Some of their past projects include Mozilla, the Tor Project, Free Software Foundation Europe, Glucosio, and more. The team takes contract work with companies or communities with a budget, but for projects with less financial support, they’ll even do the work free. This is in part supported by their Patreon page, where anyone can subscribe or see updates from Ura Design.

Their Patreon page is part of the reason Ura Design is able to take on some projects at no cost. “Since there are working hours involved, we are asking for people to make small contributions to help us pay living costs, so we work for small projects who apply for free or minimal design support from us. This is our way of supporting some open source initiatives that we think are worth it,” says Skikuli. Right now, they have 22 backers to the project, which lets them cover most infrastructure costs. Some of the goals for the team now is to expand into photography to release work into the public domain.

Past projects 🔗

Ura Design has worked with many open source projects already. Some of their work covers projects at Mozilla, the Tor Project, Glucosio, GalliumOS, Open Labs Hackerspace, and more. You can see the full list of past works on their website.

Mozilla 🔗

For Mozilla, Qoshi had an existing relationship with Mozilla as a contributor. He was asked to help design and capture this connection inside of the localization community for Mozilla. The final design focused on two lions, one big and one small, looking at each other. “It was nice effort for contributors who have been mentoring others to get recognized for their contributions. Good design breaks off a conversation even for a project like this,” Qoshi said.

The Tor Project 🔗

Working with the Tor Project was a unique experience for Ura Design. The Tor Project was looking at rebranding the entire project. The end goal was to try to improve the accessibility of the project by incorporating good design elements.

Together with the Tor Project leadership, Ura Design helped lead the rebranding of the project. This included graphical assets, logos, and corporate identity. Today, you can see the new branding featured across Tor’s web presence online. There are still plans to continue to roll these changes out over the coming year.

Logobridge 🔗

The newest project from the team is Logobridge. From unused work or small samples, Ura Design releases several new logos into the public domain each month. People are encouraged to use them in their projects, for icons, for placeholders, or anything they want. There’s no restrictions on how the logos can be used. Anyone can download the source SVG files to use in vector imaging software, like Adobe Illustrator or Inkscape.

Most of the logos designed through Logobridge are supported by monthly subscribers to Ura Design. It was from this that they decided to start Logobridge. You can see all of the logos they have on their website.

Got projects? 🔗

Ura Design is still relatively new, but they hope to continue impacting open source projects through their work. To learn more about Ura Design, you can visit their website or read their blog. Additionally, you can follow them on Facebook or Twitter for other news and updates from the team. If you want to support their work, you can visit their Patreon page. And if you’re an open source project? The Ura Design team encourages you to get in touch!

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

Why Open Labs? 🔗

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

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

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

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

Why part of my heart is at Open Labs 🔗

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

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

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

Discover Open Labs 🔗

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

What exactly are Happiness Packets? 🔗

Fortunately, I don’t have to do a lot of work to explain this, because it’s all on the front page of the Happiness Packets website. Repeated below for your convenience:

People are generally much more loved than they think they are. Especially when things don’t go according to plan, other people almost never think as harshly of you as you might think of yourself. It’s easy for us to complain when bad things happen, and yet we’re often fairly silent when things are good. Open-source communities are no different, especially when our main communication channels are textual and virtual.

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. With Open-Source Happiness Packets, we’re trying to spread that feeling.

How does it work? 🔗

Openly expressing appreciation, gratitude, or happiness to other people can be difficult. This is especially true when you don’t know them very well. Many of us come from cultures in which people are not open by default about such feelings, and naturally feel uncomfortable or even creepy to share them.

Open-Source Happiness Packets is a very simple platform to anonymously reach out to the people that you appreciate or to whom you are thankful in your open-source community. Your message can be sent anonymously if you feel uncomfortable to share your name with the recipient. Of course, we encourage you to share your name, but it’s completely optional!

Take the challenge 🔗

So, what is the #HappinessPacketChallenge? I challenge you to do the following: write at least one Happiness Packet (or more!) every day for one week. At a minimum, this is only seven times where you say “thank you” to someone else in open source. Of course, you can send more if you want to.

If you open your social media feed or turn on the news channel, you probably see a lot of negativity. Whether it’s world events, politics, or other sad news, the negativity gets at you. For one week, this is your opportunity to have the opposite effect. For all of the good things and people you see, you can spend a few minutes of each day this week to make someone’s day. It seems simple—and it is! But the power you have to spread the positivity is a big power. So this is the challenge you have: to commit yourself to spreading that message every day for one week.

“I don’t know what to say.” 🔗

Having a hard time coming up with words or not sure who to thank? No problem. Your message can be as short or as long as you like. If you’re not sure who to thank, look at some of the software you’re using now. If you’re using a Linux distribution, start there! Look for the names and emails of maintainers of software you enjoy using. If you’re already contributing to open source, consider some of the people in your community! You can thank someone who had a special role in helping you get started or impacted why you decided to work on a project.

Maybe you have other ideas or reasons to thank others. Whatever the reason is, don’t make an excuse to say thanks! The options are limitless. If you have a lot to say, say it! If not, even a simple “thanks for all the work you do!” can go a long way to make someone’s day.

Share your happiness 🔗

The magical part of Happiness Packets is sharing happy moments with others. If you receive one, don’t be afraid to tell the world! You can tweet at @happinesspacket on Twitter. Use the #HappinessPacketChallenge hashtag. Encourage other people to send their own thanks. If you can get one other person to take the challenge, then you’re already making the days of seven more people! Imagine what would happen if all of those seven people decided to take the challenge too.

So, what are you waiting for? Get started! Go send a Happiness Packet now! And if you’re feeling bold, try challenging someone directly.

Love Letter by Vectors Market from the Noun Project

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

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

Organizing Linux Weekend 🔗

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

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

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

Albanian students learn Linux 🔗

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

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

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

Fedora contributors introduce community 🔗

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

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

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

Wrapping up 🔗

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

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

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

Find Fedora near you 🔗

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

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

The local hackerspace in Tirana, Albania might be small, but they make up for size in spirit. During the weekend of 18-19 March 2017, the Open Labs Hackerspace organized the first-ever 48 hour “open source” hackathon focused on the United Nations Sustainable Development Goals. The UN Sustainable Development Goals are seventeen objectives identified by the United Nations Development Programme (UNDP) to build a better world, starting in our own communities. Some of the goals include quality education, gender equality, decent work and economic growth, clean energy, and more. During the course of the hackathon, participants selected a goal, broke into teams, and worked on projects to make real change in their own neighborhoods. In the spirit of open source, all projects are made available under free and open licenses.

Organizing the hackathon in Albania 🔗

The board members of Open Labs oversee most of its operations and help guide members in hosting events and keeping the hackerspace busy. The current board members are Redon Skikuli, Jona Azizaj, Elio Qoshi, Kristi Progri, and Anisa Kuci. However, they emphasize that it’s strongly a community-based organization. Board members invite others to take part in the organization’s governance.

Open Labs board members. Pictured left to right: Jona Azizaj, Anisa
Kuci, Kristi Progri, Redon Skikuli, Elio Qoshi. (Justin Wheeler, CC-BY-SA 4.0)

When the opportunity came to take part in this event, the board members felt it was a great opportunity to try something new. While hackathon events are popular and well-known in the United States and elsewhere, this was foreign territory for the community. “At first, we were nervous because this type of 48 hour event was new for Open Labs but also for Albania. But we wanted to use this as a chance to introduce the open source philosophy to new people and to show what we do and why,” said Azizaj. The organizers hoped to appeal to a wider audience than only active community members too.

The visiting representative from the United Nations meets participants
and helps work with them on brainstorming ideas. © Eduard Pagria, used with permission

Organizing the hackathon was a challenge since many of the core team members were traveling the week before the event. However, community members and UN representatives were more than willing to help with organizing the hackathon. This event also required a level of coordination that was uncommon for the normal type of event organized in Open Labs. “When planning, we were hoping to reach out to non-members of Open Labs too. This way, more people are exposed to open source and its culture. This lets people who want to make change, but don’t know how, to understand what is available to help them,” said Skikuli. When the Friday before the event arrived, the team was ready for a weekend of open source, civic hacking.

On Saturday morning, approximately 30 people were present for the event kick-off. Open Labs members and United Nations representatives introduced the hackathon and the themes for attendees to focus on during the weekend. Attendees were a diverse group of people as well: there was a balance between technical and non-technical people, and the gender ratio was almost evenly split between males and females.

Working on projects 🔗

One participant, Edlina, worked with Augest to develop an application
that creates a feedback loop with students and teachers to NGOs and
governments to understand problems in schools and find ways to work
together without duplicating work. © Eduard Pagria, used with permission

The Open Labs organizers placed emphasis in networking between participants at the beginning. The event started with introductions and each participant made a note of whether they were a technical or non-technical contributor. After this, they wrote their names on sticky notes along with their preferred goals to stick on the wall. Participants were paired up with someone with a different background but with a mutual interest in a specific goal. “We separated participants into two groups: technical and non-technical. Our idea was the two sides would complement each other to share experiences to build a strong team,” said Azizaj. After the teams were formed, they began brainstorming and working on their projects. Mentors were available to offer support to participants and to introduce them to open source tools to help them prototype their projects.

World of Sounds 🔗

Silva Arapi, one participant, worked with her team on their project
“World of Sounds”. (Justin Wheeler, CC-BY-SA 4.0)

One participant, Silva Arapi, worked with teammates Dritan Sakuta, Hulemita Leka, Kristi Leka, and Klajdi Qehaja to address reduced inequalities. Their team project is called “World of Sounds”.  The application is a resource for parents of children with hearing or speaking disabilities. “World of Sounds is a platform to understand early on to improve education of parents and accessibility for children. This is very helpful for rural parts [of Albania],” Arapi explained.

She has been involved with the Open Labs community for almost a year and a half. It was her first hackathon but she also hadn’t seen an event like this in Albania before. “It was a new experience and something different. We get something done in 48 hours to have a social impact – why not participate?” Arapi balances her time leading the NextCloud efforts in Tirana while working towards her master’s degree in Information Security. She hopes to take part in another event at Open Labs like this again in the future.

Tackling gender equality in Albania 🔗

Another Open Labs community member came with an idea and a friend to try thinking through a specific issue she had seen in her community. Nafie Shehu is an Information Communication Technology student and has been involved with Open Labs for the past seven months. With her, she brought her friend Afrim Kamberi to help, for his first visit to Open Labs and an open source event in Tirana.

Shehu’s selected goal was gender equality combined with an experience of one of her friends. In some rural areas and villages in Albania, women have a more difficult time maintaining their rights. They rarely have financial independence, and as a result, this sometimes leads them to live a life they might not want. Sometimes, women are obligated into a non-consensual marriage and aren’t in a place to defend what they want for themselves. Her friend was in this situation and divorced later, but she didn’t know where to go after and had little resources of her own. Nafie heard about this story and it deeply affected her. She hoped to brainstorm ideas on how to improve this problem.

After research and looking at other solutions, she discovered similar attempts had been started to solve this problems. However, for various reasons, they were ineffective and weren’t thorough solutions to the problems. While this changed her own project development, she finished the hackathon determined to find ways to improve on what was already there and continue this even after the weekend ended.

Closing the hackathon 🔗

Towards the end of Sunday, participants put the last touches onto their projects. The deliverable product was prepared and all participants organized a short presentation to demo their project. “In the end, you get a real product, not just talking. It’s a real product that has an impact,” Progri explained. All of the various teams pitched their projects to the Open Labs community and to representatives from the United Nations.

Anxhelo Lushka helps two participants after midnight to help work
through some problems in their project. (Justin Wheeler, CC-BY-SA 4.0)

In the project presentations, teams were given specific criteria to present in the project.

1. Summary or main idea of the project
2. Sustainability of the project for implementation beyond the weekend
3. Recommendations for funding the project / creating a budget to carry it out
4. Reasons why they would support this if it wasn’t their own project

After the presentations, teams were given the option to send their information and projects to the UNDP via Open Labs. The UNDP will select one project and team to bring to the United Nations office in New York City to propose their project and seek support to develop it further.

That’s a wrap! 🔗

After a closing ceremonies and words of encouragement from Skikuli, the hackathon came to an end. Both participants and organizers felt it ended on a high note. “I love coming to these events to learn new things, meet new people, and they’re cool!” Arapi said. Additionally, the organizers hoped that participants left with valuable knowledge and resources that would go beyond this weekend. “We hope people understand the role open source had in this event and understand why the philosophy is so important,” Qoshi explained. “Some people might think the projects are the main part, but networking with people from different backgrounds goes beyond the event. These connections support sustainability for people working together. We hope these projects continue beyond this event.”

The presence of open source software and its philosophy was present throughout the event. Stickers and swag from various open source projects was available for participants to take. This included stickers from Mozilla, Fedora, LibreOffice, NextCloud, and more. “We hope attendees enjoyed the experience and had fun meeting new people. Later on, when they leave Open Labs and work on their own projects, we hope they will remember open source tools to build their work and create FOSS solutions,” said Azizaj.

What’s next for Open Labs? 🔗

This was a milestone event for the Open Labs community, but they have more on the horizon after the weekend of this event. Organizers, volunteers, and members are putting together the first Linux Weekend in Tirana from 25-26 March. This is a traditional barcamp-like model with talks and workshops by several local and international speakers. However, there are a couple of goals ahead that the team hopes to begin working at.

One of them is a book in time for the hackerspace’s fifth anniversary. The book would be an “open source handbook” in the Albanian language. Not only would it have the history of Open Labs, but it would introduce various open source projects and connect readers to resources so they could have an impact on a project. Additionally, the team is looking at policy in their government as a next step. Qoshi had a great deal to say on this: “It feels like we’re reaching critical mass and gaining momentum to influence local policy in Albania. We want to push for open policies and government, especially with the coming elections in June. This is a great opportunity to let people know our stances on policies. Pushing FOSS only in our space can’t be an insider secret—we need conversations with people coming from different views if we want change.”

You can learn more about the hackerspace online at their website.

Preface 🔗

When I started writing this in January, I read freenode’s “Happy New Year!” announcement. Even though their recollection of the year began as a negative reflection, the freenode team did not fail to find some of the positives of this year as well. The attitude reflected in their blog post is reflective of the attitude of many others today. 2016 has brought more than its share of sadness, fear, and a bleak unknown, but the colors of radiance, happiness, and hope have not faded either. Even though some of us celebrated the end of 2016 and its tragedies, two thoughts stay in my mind.

One, it is fundamentally important for all of us to stay vigilant and aware of what is happening in the world around us. The changing political atmosphere of the world has brought a shroud of unknowing, and the changing of a number does not and will not signify the end of these doubts and fears. 2017 brings its own series of unexpected events. I don’t consider this a negative, but in order for it not to become a negative, we must constantly remain active and aware.

Secondly, despite the more bleak moments of this year, there has never been a more important time to embrace the positives of the past year. For every hardship faced, there is an equal and opposite reaction. Love is all around us and sometimes where we least expect it. Spend extra time this new year remembering the things that brought you happiness in the past year. Hold them close, but share that light of happiness with others too. You might not know how much it’s needed.

First year of university: complete! 🔗

Many things changed since I decided to pack up my life and go to a school a thousand miles away from my hometown. In May, I officially finished my first year at the Rochester Institute of Technology, finishing the full year on dean’s list. Even though it was only a single year, the changes from my decision to make the move are incomparable. Rochester exposed me to amazing, brilliant people. I’m connected to organizations and groups based on my interests like I never imagined. My courses are challenging, but interesting. If there is anything I am appreciative of in 2016, it is for the opportunities that have presented themselves to me in Rochester.

Adventures into FOSS@MAGIC 🔗

My involvement with the Free and Open Source Software (FOSS) community at RIT has grown exponentially since I began participating in 2015. I took my first course in the FOSS minor, Humanitarian Free and Open Source Software Development in spring 2016. In the following fall 2016 semester, I became the teaching assistant for the course. I helped show our community’s projects at Imagine RIT. I helped carry the RIT FOSS flag in California (more on that later). The FOSS@MAGIC initiative was an influencing factor for my decision to attend RIT and continues to play an impact in my life as a student.

I eagerly look forward to future opportunities for the FOSS projects and initiatives at RIT to grow and expand. Bringing open source into more students’ hands excites me!

I <3 WiC 🔗

With a new schedule, the fall 2016 semester marked the beginning of my active involvement with the Women in Computing (WiC) program at RIT, as part of the Allies committee. Together with other members of the RIT community, we work together to find issues in our community, discuss them and share experiences, and find ways to grow the WiC mission: to promote the success and advancement of women in their academic and professional careers.

Also, hey! If you’re a female high school or university student in the Rochester area (or willing to do some travel), you should seriously check this out!

Google Summer of Code 🔗

Google Summer of Code, abbreviated to GSoC, is an annual program run by Google every year. Google works with open source projects to offer stipends for them to pay students to work on projects over the summer. In a last-minute decision to apply, I was accepted as a contributing student to the Fedora Project. My proposal was to work within the Fedora Infrastructure team to help automate the WordPress platforms with Ansible. My mentor, Patrick Uiterwijk, provided much of the motivation for the proposal and worked with me throughout the summer as I began learning Ansible for the first time. Over the course of the summer, my learned knowledge began to turn into practical experience.

It would be unfair for a reflection to count successes but not failures. GSoC was one of the most challenging and stressful activities I’ve ever participated in. It was a complete learning experience for me. One area I noted that I needed to improve on was communication. My failing point was not regularly communicating what I was working through or stuck on with my mentor and the rest of the Fedora GSoC community. GSoC taught me the value of asking questions often when you’re stuck, especially in an online contribution format.

On the positive side, GSoC helped formally introduce me to Ansible, and to a lesser extent, the value of automation in operations work. My work in GSoC helped enable me to become a sponsored sysadmin of Fedora, where I mostly focus my time contributing to the Badges site. Additionally, my experience in GSoC helped me when interviewing for summer internships (also more on this later).

Google Summer of Code came with many ups and downs. But I made it and passed the program. I’m happy and fortunate to have received this opportunity from the Fedora Project and Google. I learned several valuable lessons that have and will impact going forward into my career. I look forward to participating either as a mentor or organizer for GSoC 2017 with the Fedora Project this year.

Flock 2016 🔗

Towards the end of summer, in the beginning of August, I was accepted as a speaker to the annual Fedora Project contributor conference, Flock. As a speaker, my travel and accommodation were sponsored to the event venue in Kraków, Poland.

Months after Flock, I am still incredibly grateful for receiving the opportunity to attend the conference. I am appreciative and thankful to Red Hat for helping cover my costs to attend, which is something I would never be able to do on my own. Outside of the real work and productivity that happened during the conference, I am happy to have mapped names to faces. I met incredible people from all corners of the world and have made new lifelong friends (who I was fortunate to see again in 2017)! Flock introduced me in-person to the diverse and brilliant community behind the Fedora Project. It is an experience that will stay with me forever.

To read a more in-depth analysis of my time in Poland, you can read my full write-up of Flock 2016.

Maryland (Bitcamp), Massachusetts (HackMIT), California (MINECON) 🔗

2016 provided me the opportunity to explore various parts of my country. Throughout the year, I attended various conferences to represent the Fedora Project, the SpigotMC project, and the RIT open source community.

There are three distinct events that stand out in my memory. For the first time, I visited the University of Maryland for Bitcamp as a Fedora Ambassador. It also provided me an opportunity to see my nation’s capitol for the first time. I also visited Boston for the first time this year as well for HackMIT, MIT’s annual hackathon event. I also participated as a Fedora Ambassador and met brilliant students from around the country (and even the world, with one student I met flying in from India for the weekend).

Lastly, I also took my first journey to the US west coast for MINECON 2016, the annual Minecraft convention. I attended as a staff member of the SpigotMC project and a representative of the open source community at RIT.

All three of these events have their own event reports to go with them. More info and plenty of pictures are in the full reports.

• Going to Bitcamp 2016
• HackMIT meets Fedora
• SpigotMC goes to California for MINECON

Vermont 2016 with Matt 🔗

Some trips happen without prior arrangements and planning. Sometimes, the best memories are made by not saying no. I remember the phone call with one of my closest friends, Matt Coutu, at some point in October. On a sudden whim, we planned my first visit to Vermont to visit him. Some of the things he told me to expect made me excited to explore Vermont! And then in the pre-dawn hours of November 4th, I made the trek out to Vermont to see him.

Instantly when crossing over the state border, I knew this was one of the most beautiful states I ever visited. During the weekend, the two of us did things that I think only the two of us would enjoy. We climbed a snowy mountain to reach an abandoned fire watchtower, where we endured a mini blizzard. We walked through a city without a specific destination in mind, but to go wherever the moment took us.

We visited a quiet dirt road that led to a meditation house and cavern maintained by monks, where we meditated and drank in the experience. I wouldn’t classify the trip has a high-energy or engaging trip, but for me, it was one of the most enjoyable trips I’ve embarked on yet. There are many things that I still hold on to from that weekend for remembering or reflecting back on.

A big shout-out to Matt for always supporting me with everything I do and always being there when we need each other.

Finally seeing NYC with Nolski 🔗

In no short time after the Vermont trip, I purchased tickets for my favorite band, El Ten Eleven, in New York City on November 12th. What turned into a one-day trip to see the band turned into an all-weekend trip to see the band, see New York City, and spend some time catching up with two of my favorite people, Mike Nolan (nolski) and Remy DeCausemaker (decause). During the weekend, I saw the World Trade Center memorial site for the first time, tried some amazing bagels, explored virtual reality in Samsung’s HQ, and got an exclusive inside look at the Giphy office.

This was my third time in New York City, but my first time to explore the city. Another shout-out goes to Mike for letting me crash on his couch and stealing his Sunday to walk through his metaphorical backyard. Hopefully it isn’t my last time to visit the city either!

Finalizing study abroad 🔗

At the end of 2016, I finalized a plan that was more than a year in the making. I applied and was accepted to study abroad at the Rochester Institute of Technology campus in Dubrovnik, Croatia. RIT has a few satellite campuses across the world: two in Croatia (Zagreb and Dubrovnik) and one in Dubai, UAE. In addition to being accepted, the university provided me a grant to further my education abroad. I am fortunate to have received this opportunity and can’t wait to spend the next few months of my life in Croatia. I am currently studying in Dubrovnik since January until the end of May.

During my time here, I will be taking 12 credit hours of courses. I am taking ISTE-230 (Introduction to Database and Data Modeling), ENGL-361 (Technical Writing), ENVS-150 (Ecology of the Dalmatian Coast), and lastly, FOOD-161 (Wines of the World). The last one was a fun one that I took for myself to try broadening my experiences while abroad.

Additionally, one of my personal goals for 2017 is to practice my photography skills. During my time abroad, I have created a gallery on 500px where I upload my top photos from every week. I welcome feedback and opinions about my pictures, and if you have criticism for how I can improve, I’d love to hear about it!

Accepting my first co-op 🔗

The last big break that I had in 2016 was accepting my first co-op position. Starting in June, I will be a Production Engineering Intern at Jump Trading, LLC. I started interviewing with Jump Trading in October and even had an on-site interview that brought me to their headquarters in Chicago at the beginning of December. After meeting the people and understanding the culture of the company, I am happy to accept a place at the team. I look forward to learning from some of the best in the industry and hope to contribute to some of the fascinating projects going on there.

From June until late August, I will be starting full-time at their Chicago office. If you are in the area or ever want to say hello, let me know and I’d be happy to grab coffee, once I figure out where all the best coffee shops in Chicago are!

In summary 🔗

2015 felt like a difficult year to follow, but 2016 exceeded my expectations. I acknowledge and I’m grateful for the opportunities this year presented to me. Most importantly, I am thankful for the people who have touched my life in a unique way. I met many new people and strengthened my friendships and bonds with many old faces too. All of the great things from the past year would not be possible without the influence, mentorship, guidance, friendship, and comradery these people have given me. My mission is to always pay it forward to others in any way that I can, so that others are able to experience the same opportunities (or better).

2017 is starting off hot and moving quickly, so I hope I can keep up! I can’t wait to see what this year brings and hope that I have the chance to meet more amazing people, and also meet many of my old friends again, wherever that may be.

Keep the FOSS flag high.

On Tuesday, November 8th, 2016, the FOSS@MAGIC at the MAGIC Center at RIT held the annual Election Night Hackathon. Over 140 students from across campus and across departments gathered together to work on a range of civic projects as the election night results came in. This year’s hackathon was the sixth in a long-standing tradition of civic duty and open source collaboration.

Starting the Election Night Hackathon 🔗

For this year’s event, registration was a ticketed event because of the overwhelming interest in the election. At 5:00pm, the sign-in table popped up in front of the Student Innovation Hall, where the hackathon would take place. Students began lining up to receive their wristband for admission, food, and open source swag.

The space quickly became filled over the next hour as people began settling in for the night to work on projects (or maybe homework). On all sides were a range of projector screens with a range of sources for election night coverage. There would not be a lack of information through the night. In addition to the federal election, local and state elections throughout New York were also included on the projectors.

The Election Night Hackathon had no shortage of goodies provided by numerous open source organizations, companies, and supporters. The “swag table” featured plenty of stickers for people to add to their laptops or other devices. The Fedora Project, GitHub, Red Hat, the MAGIC Center, and more were available for attendees to pick their favorites out.

Projects 🔗

At the peak of the event, nearly 140 students, faculty, staff, and local citizens filled the MAGIC Center and overflow work spaces. Dan Schneiderman, the event coordinator and FOSS@MAGIC Research Associate and Community Liaison, led the event on a high note with a brief kick-off ceremony. Hackers were provided with a list of resources for building applications related to civic hacking. Shortly after the start, attendees began talking with one another to discuss project ideas or other topics to work on throughout the night. Professors and alumni provided mentorship, advice, and help for students planning projects.

Tyler Reimold worked on creating an open source server for real-time election updates in a Reddit thread. His Python-based project used the Huffington Post and Reddit APIs to build the application.

Adjunct professor at Monroe Community College  David M. Shein gathered a small group of hackers to build a website. The website, thankyousuffragists.org, honors and maps the graves of women around the country who campaigned for the right to vote. The early stage site allows people to add the locations of graves around the country to a map. “I personally loved how a number of our attendees were inspired by the crowds that stopped by Susan B. Anthony’s grave in Rochester, which then led to a project focused on honoring her work,” Schneiderman said.

Additionally, another project was the 2016 Election Viewer by Mark Repka. His Node-powered application delivered a state-by-state breakdown of election results throughout the night. Attendees were encouraged to check it out and provide feedback as he built the site to provide accurate coverage during the heat of the election coverage. You can view Mark’s application on his website, browse its own API, or find the source code on GitHub (MIT License).

Many other students worked on smaller projects or collaborated with professors on other ideas. Dr. Vullo at RIT opened a call for students to help him with a virtual reality idea powered by AFrame. Most of the projects and work from the evening was published on GitHub in the spirit of contributing civic hacking projects to the open source ecosystem.

And the winner is… 🔗

After seven hours of hacking and nail-biting, the election results were mostly called by midnight. With a short conclusion speech by Schneiderman, the hackathon began closing down in time for the next day of classes. “[My favorite part was] the collaborations and the mixing of students from majors that don’t usually get to work alongside each other. Attendance was a mix of computer science, marketing, political science, engineering, history, and visual arts,” Schneiderman said. Special thanks for the event go to the MAGIC Center at RIT for providing space and resources for the event. Additional thanks go to Red Hat for supporting the FOSS@MAGIC initiative so these events are made possible. You can find the full photo album from the event on 500px.

November 8th is a day that will stand in memory for a long time, and the Election Night Hackathon is a great opportunity for students to engage in discussion and collaboration with others in the community to identify issues in the civic area and try to build open source solutions to those problems. We’re looking forward to continuing the tradition next year for the next round of local, state, and federal elections.

Teams for purpose, teams for tracking 🔗

Team structure and designation are some of the most important ways to use organizations effectively. Since GitHub revamped teams, they are an effective way to categorize members and to assign privileges. You can decide who can create repositories, who can push code to what repositories, or who has admin rights on projects.

You should create teams that have a purpose and will work with real repositories. For example, if your club has various committees, you should create a team for each committee. Then, you can give each committee privileges to their own repositories and leave it to them to manage. Being smart with what teams you create is important. Teams with a purpose should exist to carry out certain tasks within the organization. Equip them with the means to do so.

It’s also helpful to create teams for tracking. In a university setting, students will graduate in a certain year and then they’ll be gone. For university clubs using GitHub organizations, create teams for every graduating class, staff and faculty, and alumni (e.g. “Class of 2019, Class of 2020, University staff, Graduated members, etc.). While it may seem trivial with a few people in the beginning, it is useful as the organization grows. If someone wonders why someone is part of a repository or if they are still participating in the club or organization, it is easy to see whether the student is still on campus or whether they are a graduated alumnus or alumna.

Use organization for on-boarding 🔗

Organizations are a powerful tool for bringing new people into your club or group. The moment someone receives an email inviting them to be a member of the GitHub organization, it holds a certain weight. “Wow, I’m officially a part of this thing!” It’s a great way to create an inclusive environment and enable new contributors to feel like they are a part of the team.

Having a team for newcomers or new recruits is helpful to have in place beforehand. The group doesn’t have any real permissions in the organization, but it is a temporary holding ground for new members while they figure out their position in the club. But this way, they get to be included in the member list and show off your organization’s logo in their profile if they choose.

Publicize your membership on GitHub 🔗

If someone is in your organization, make sure you encourage them to show it off! By default, GitHub sets the team member visibility to private. Unless a member of the organization sets themselves as public, they won’t appear as a part of the organization to visitors.

Publicizing your membership is an underestimated step in bringing new contributors in. It’s even helpful for older members too. By publicizing memberships, you are giving faces and real people to characterize your organization. If someone finds your organization in a search or in a link, it looks better to have rows of people associated with the group. The alternative of a team with what looks like no members implies your club is inactive. It can also make your club look smaller than it is. Additionally, individual team members also get to show off your organization on their individual profiles. This is helpful for anyone visiting their profile for activities or programming experience. For university students, this is helpful for applying for co-ops or internships.

To make a membership visible, the organization member has to go to the “People” page of the organization. On the page, next to their name, there is an option for “Public” or “Private” in a drop-down menu. Change it to “Public”.

Consider repository for tasks 🔗

While not essential, a repository for real-life tasks or issues in a club can be a helpful planning tool. It also makes it easy for people to see what the club or group is working on. This promotes the idea of transparent and open leadership. You can use labels to tag issues for specific types of work or committees. Milestones are useful for deadlines or goals the group is working towards. The new Projects feature may also be useful in a repository for real-life task management.

For an example of a repository like this, you can see the FOSSRIT/fossbox-tasks repository on GitHub. We even planned a dinner on GitHub!

Go forth and conquer! 🔗

Congratulations! You now have some basic knowledge and ideas on how to effectively use GitHub organizations for a club or small team. While this guide is not completely thorough, it helps give some starting points to consider when you’re setting up your organization for the first time. It’s also never too late to make changes later, if your organization is already formed.

If you have questions, comments, or feedback, I’d love to hear about it! Feel free to leave a comment below.

When people first think of “open source”, their mind probably first goes to code. Something technical that requires an intermediate understanding of computers or programming languages. But open source is a broad concept that goes beyond only binary bits and bytes. Open source projects hold great regard for community participation. The community is a fundamental piece of a successful open source project. For my experience getting involved with open source, I began in the community and worked my way around from there. At the age of fifteen, I was beginning my open source journey and I didn’t even know it.

Gaming introduces open source 🔗

One of my strongest memories of a “gaming addiction” was when I was fifteen and a younger cousin introduced me to the game Minecraft. The game was in beta then, but I remember the sandbox-style of the game entertaining the two of us for hours. But what I discovered was that playing the game alone became boring. Playing and mining with others made the experience more fun and meaningful. In order to do this, I learned I would have to host a server for my friends to connect to play with me.

I originally used the “vanilla” Minecraft server software at first, but it was limited to what it could do, and didn’t compare to other multiplayer servers in existence. They all seemed to be using something that offered more, so players could play games, cast spells, or do other unique things that would normally not be possible in the game. After digging, I discovered Bukkit, an open source Minecraft server software with an extensible API to let developers change the multiplayer experience. I soon became wrapped up with Bukkit like a child with a new toy. Except this toy had me digging through my computer to set up “port forwarding”, “setting NAT records”, and “creating static IP addresses”. I was teaching myself the basics of computer networking in the guise of creating a game server for my friends.

Over time, my Minecraft server hobby began to take up more and more time. More people began playing on my server and I began searching for ways to improve the performance of my server. After doing some digging, I discovered the SpigotMC project, shortened to just Spigot. Spigot was a fork of the Bukkit project that made specific enhancements to performance. After trialing it on my server, I discovered the performance gains were measurable and I would commit to using Spigot from then on.

Participating in SpigotMC 🔗

Before long, I began running into new challenges with managing my Minecraft server community, whether it was finding ways to scale or finding the best ways to build a community up. In October 2013, I registered an account on the Spigot forums to talk with other server owners and seek advice on ways I could improve. I found the community welcoming and accepting to helping me learn and improve. Several people in the community were owners of larger servers or developers of unique plugins to Spigot. In response to my detailed inquisitions, they responded with genuine and helpful feedback and support. Within a week, I was already in love with the people and helpfulness of the Spigot community.

I became an active participant in the forum community in Spigot. Through the project, I was introduced to IRC and how to use it for communicating with other server owners and developers. What I didn’t realize was a trend in my behavior. Over time, I began shifting away from asking all the questions. Almost as if in a role reversal, I became the one answering questions and helping support other new server owners or developers. I became the one in an advisory role instead of the one always asking.

In April 2014, the project lead of Spigot reached out to me asking if I would consider a role as a community staff member. Part of my responsibilities would be responding to reports, encouraging a helpful and friendly community, and maintaining the atmosphere of the community. With as much prestige and honor as my sixteen-year-old self could muster, I accepted and began serving as a community moderator. I remember feeling privileged to serve the position – I would finally get to help the community that had done so much to help me.

Expanding the open source horizon 🔗

Through 2014 and 2015, I actively served as a moderator of the community, both in the forums and the IRC network for Spigot. I remained in the Spigot community as the project steadily grew. It was incredible to see how the project was attracting more and more users.

However, my open source journey did not end there. After receiving my high school diploma in May 2015, I had set my sights on the Rochester Institute of Technology, a school I noted as having the country’s only Free and Open Source Software minor. By coincidence, I also noticed that my preferred Linux distribution, Fedora, was holding its annual contributor conference in Rochester, a week before I would move in for classes. I decided I would make the move up early to see what it was all about.

Flock 2015 introduces Fedora 🔗

The summer passed, and before I knew I was ready, I was packing up from my home outside of Atlanta, Georgia to leave for Rochester, New York. After fourteen hours of driving, I finally arrived and began moving into my new home. A day after I arrived, Flock was slated to begin, marking my first journey in Rochester.

At Flock, I entered as an outsider. I was in an unfamiliar city with unfamiliar people and an open source project I was only mildly familiar with. It was all new to me. But during that week, I discovered a community of people who were united around four common ideals. Freedom, Friends, Features, First: the Four Foundations of the Fedora Project were made clear to me. The community members at Flock worked passionately towards advancing their project during the talks and workshops. And after the talks finished, they gathered together for hallway discussions, sharing drinks, and enjoying the presence of their (usually) internationally dispersed team. Without having ever attended a Fedora event before, I knew that the Four Foundations and the community behind Fedora were the real deal. Leaving Flock that year, I vowed to pursue becoming a part of this incredible community.

Pen to paper, keyboard to post 🔗

The first major step I took towards contributing to the Fedora Project was in September 2015, during Software Freedom Day. Then Fedora Community Action and Impact Coordinator Remy DeCausemaker was in attendance representing Fedora. During the event, I reached out to the Fedora Magazine editorial team asking to become involved as a writer. By the end of September, I penned my first article for the Fedora Magazine, tying in my experience in the Spigot community to Fedora: run a Minecraft server using Spigot.

My first step getting involved with the Fedora community was an exciting one. I remember feeling proud and excited to see my first article published on the front page, not only helping Fedora, but also helping Spigot. I realized then that it was relatively straightforward to contribute this kind of content, and I would keep writing about software I was familiar with for the Magazine.

As I continued writing posts for the Fedora Magazine, I became aware of another team forming up in Fedora: the Community Operations, or CommOps, team. I subscribed to their mailing list, joined the IRC channel, and attended the first meetings. Over time, I became wrapped up and involved with the community efforts within Fedora. I slowly found one thing leading to another.

Today in Fedora, I am the leading member of the Community Operations (CommOps) team, the editor-in-chief of the Fedora Magazine, a Marketing team member, an Ambassador of North America, a leading member of the Diversity Team, and a few other things.

Advice for other students 🔗

When you’re first getting started, it can sometimes be tough and a little confusing. As students getting involved with FOSS, there are a few challenges that we might have to face. A lot of this can be with making the first steps into a new project. There are countless open source projects of various sizes and they all do things a bit differently from others, so the process changes from project to project.

One of the most obvious challenges with getting involved is your personal experience level. Especially when getting started, it can be easy to look at a large project or well-known project and see all the work devoted there. There are smart and active people working on these projects, and many times their contributions are quite impressive! One of the many concerns I’ve seen other students here face (including myself at first) is wondering how someone with beginning to moderate experience or knowledge can get involved, in comparison to some of these contributions from active contributors. If it’s a large project, like Fedora, it can be intimidating to think where to start when there’s so many things to do and areas to get involved with. But if you think of it all as one big project, it is intimidating and difficult for you to make that first step.

Break a bigger project into smaller pieces. Start small and look for something you can help with. A healthy open source project usually will have things like easyfix bugs that are good ones to start with if it’s your first time contributing. Keep an eye out for those if you’re getting started.

Another challenge you might face as a student or beginner to open source is something called imposter syndrome. For me, this was something I had identified with before I knew what it was. For a definition, I’ll pull straight from Wikipedia first: " Term referring to high-achieving individuals marked by an inability to internalize their accomplishments and a persistent fear of being exposed as a “fraud”.

Imposter syndrome can be a common feeling as you get involved with open source, especially if comparing yourself to some of those active and smart contributors that you meet as you become involved. But you should also remember you are a student – comparing yourself or your contributions to a professional or someone with years of experience isn’t fair to yourself! It’s not apple-to-apples. Your contributions as you get involved with open source are worthy and valuable to an open source project regardless of how deep, how many, or how much time you spend on the project. Even if it’s a couple of hours in the week, that’s saving others those couple of hours and it’s adding something into the project. A contribution is a contribution – it’s a bad idea to rate the worth of contributions to other contributions.

Those are some of the challenges that are useful to know and understand as you become more involved with FOSS. If you know the challenges you are up against, it makes it easier to handle them as they come.

There are also benefits to contributing to open source as a student as well. Contributing to open source is a great way for you to take knowledge and info you have learned from classes and begin applying it to real-world projects and gain experience. It’s one thing to take you to the next level as a student. If you are contributing to a project in the real world, that is unique experience that is helpful for you for future career outlooks as well.

It’s also a great networking opportunity. In open source, you meet many incredible and smart people. In my time in Fedora, I’ve met many contributors and had various mentors help me get involved. I’ve made new friends and met people who I normally would never have had the opportunity to meet.

There are also opportunities for leadership in open source projects. Whether it’s just one task, one bug, or even a role, you might find that sometimes all it takes is someone willing to say, “I’ll do this!” to have leadership on something. It might be challenging or difficult at first, but it’s a great way for you to understand working in team environments, how to work effectively even if you’re remote, and how to break down a task and work on finding solutions for complex problems.

Lastly, it’s important for younger people to become more involved with open source communities. As students and younger community members, we add unique perspective and ideas to open source projects. It’s important to a healthy community for an open source project and any open source project worth contributing to should be welcoming and accepting to students who are willing to spend time working on the project and helping solve those problems, whether they’re bugs, tasks, or other things. In short, there is absolutely a role for students getting involved with open source!

About Open Labs 🔗

Open Labs Albania is a non-profit organization and community based out of Tirana, Albania. Open Labs focuses on freedom, transparency, and decentralization to empower the community. They support and contribute to a variety of open source projects to tackle local problems. Sometimes, this even includes regional and international issues. Each year, the Open Labs team organizes their annual conference, OSCAL (Open Source Conference Albania). Hundreds of people from across Europe gather to “promote software freedom, open source software, free culture and open knowledge”. In 2016, over 50% of attendees and 70% of organizers were women, numbers unheard of anywhere else in the world.

The story of Open Labs in Albania is a growing but powerful story of people from a developing country working together to build real solutions to real problems. The story of their movement is motivating, insightful, and worth sharing.

About FOSS Wave 🔗

FOSS Wave is a group of open source developers and students dedicated to connecting other students into open source communities. They help develop students’ professional skills for the industry. The mentors have a “Boot Up” program where interested students reach out for a mentor. Mentors offer direct support to students on getting started. Program organizers also attend various universities to deliver workshops and talks about open source technology. Many mentors are female and speak about diversity in open source communities and give advice for women who want to get involved.

https://communityblog.fedoraproject.org/foss-wave-women-in-technology-part-2/

https://communityblog.fedoraproject.org/foss-wave-fedora-bangalore-india/

https://communityblog.fedoraproject.org/foss-wave-bangalore-uvce/

Virtual meetup 🔗

Over the next month, we hope to combat time zones (six hours in Europe and nine and a half with India) to find mutual times that work well for both communities. These are two separate virtual meetup opportunities, one with WiC and Open Labs, and another with WiC and FOSS Wave. We are trying to collect responses from members of both communities of when they would be available to take part in the meetup.

Are you a member of WiC, Open Labs, or FOSS Wave? Please make sure you fill in your available times in either poll so we can select a date soon!

• WiC + Open Labs meetup time poll
• WiC + FOSS Wave meetup time poll

I’m looking forward to these awesome communities meeting, sharing experiences, and learning about what other groups of students, women, and other great role models in tech are working on across the world. Hope to see you there too!

Deliverable items 🔗

The last deliverable items from my project are two (2) git patches, one (1) git repository, and seven (7) blog posts (including this one).

• Git patches (ansible.git and infra-docs.git)
• Git repository
• Blog posts

Closing plans 🔗

At the end of the summer, I was using a private cloud instance in Fedora’s infrastructure for testing my playbooks and other resources. One of the challenges towards the end of my project was moving my changes from my local development instance into a more permanent part of Fedora’s infrastructure. For these reasons, I had some issues with running them in a context and workflow specific to Fedora’s infrastructure and set-up (since I am not a sponsored member of the Fedora system administration group).

My current two patches were submitted to my mentor, Patrick. Together, we worked through some small problems with running my playbook in the context of Fedora’s infrastructure. There may still be some small remaining hoops to jump through for running it in production, but any remaining changes to be made should be minor. The majority of the work and preparation for moving to production is complete. This is also something I plan to follow up on past the end of the GSoC 2016 program as a member of the Fedora Infrastructure Apprentice program.

My patches should be merged into the ansible.git and infra-docs.git repositories soon.

Reflection on GSoC 2016 🔗

As the program comes to a close, there’s a lot of valuable lessons I’ve learned and opportunities I’m thankful to have received. I want to share some of my own personal observations and thoughts in the hopes that future students or mentors might find it useful for later years.

Planning your timeline 🔗

In my case, I spent a large amount of time planning my timeline for the project before the summer. Once the summer began, my original timeline was too broad for having smaller milestones to work towards. My timeline on the student application was more broad and general, and while it covered the big points, it was difficult to work towards those at first. Creating smaller milestones and goals for the bigger tasks makes them easier to work through on a day-by-day basis and helps add a sense of accomplishment to the work you are doing. It also helps shape direction for your work in the short-term and not just the long-term.

For an incoming Google Summer of Code student for Fedora (or any project), I would recommend creating the general, “big picture” timeline for your project before the summer. Then, if you are accepted and beginning your proposal, spend a full day creating small milestones for the bigger items. Try to map out accomplishments every week and break down how you want to reach those milestones throughout the week. I started using TaskWarrior with an Inthe.AM Taskserver to help me manage weekly tasks going into my project. But it’s important to find a tool that works for you. You should reach out to your mentor about ideas for tools. If possible, your mentor should also have a way to view your agenda and weekly tasks. This will help make sure your goals are aligned to the right kind of work you are doing for an on-time completion.

I think this kind of short-term planning or task management is essential for hitting the big milestones and being timely with your progress.

Regular communication 🔗

Consistent and frequent communication is also essential for your success in Google Summer of Code. This can be different depending on the context of how you are contributing to the project. For a normal student, this might just be communicating about your proposal with your mentor regularly. If you’re already an active contributor and working in other areas of the project, this might be spending extra time on communicating your progress on the GSoC project (but more on that specifically in the next section).

Regardless of the type of contributor you are, one thing is common and universal – be noisy! Ultimately, project mentors and GSoC program administrators want to be sure that you are spending the time on your project and making progress towards accomplishing your goals. If you are not communicating, you will run the highest risk of failing. How to communicate can vary from project to project, but for Fedora, here’s my personal recommendations.

Blog posts 🔗

Even for someone like me who spends a lot of time writing already, this can be a difficult thing to do. But no matter how hard it is to do it, this is the cornerstone for communicating your progress and leaving a trail for future students to learn from you as well. Even if you’ve had a difficult week or haven’t had much progress, take the time to sit down and write a post. If you’re stuck, share your challenges and share what you’re stuck on. Focus on any success or breakthroughs you’ve made, but also reflect on issues or frustrations you have had.

Taking the time to reflect on triumphs and failures is important not only for Google Summer of Code, but even looking past that into the real world. Not everything will go your way and there will be times where you will be face challenges that you don’t know how to resolve. Don’t burn yourself out trying to solve those kinds of problems alone! Communicate about them, ask for help from your mentors and peers, and make it an open process.

IRC check-ins 🔗

Whether in a public channel, a meeting, or a private one-on-one chat with your mentor, make sure you are both active and present in IRC. Make sure you are talking and communicating with your mentor on a regular basis (at a minimum, weekly). Taking the time to talk with your mentor about your challenges or progress is helpful for them so they know what you’re up to or where you are in the project. It also provides a chance for them to offer advice and oversight into your direction and potentially steer you away from making a mistake or going into the wrong direction. It is demotivating when you’ve spent a lot of time on something and then later discovered it either wasn’t necessary or had a simpler solution than you realized.

Make sure you are communicating often with your mentor over IRC to make your progress transparent and to also offer the chance for you to avoid any pitfalls or traps that can be avoided.

Hang out in the development channels 🔗

As a Fedora Google Summer of Code student, there are a few channels that you should be present in on a regular basis (a daily presence is best).

• #fedora-admin
• #fedora-apps
• #fedora-summer-coding
• Any specific channel for your project, e.g. #fedora-hubs

A lot of development action happens in this channels, or people who can help you with problems are available here. This also provides you the opportunity to gain insight into what the communication in an active open source project looks like. You should at least be present and reading the activity in these channels during the summer. Participation is definitely encouraged as well.

Balancing project with open source contributions 🔗

I think my single, most difficult challenge with Google Summer of Code was balancing my proposal-specific contributions with the rest of contributions and work in the Fedora Project. I believe I was a minority of Google Summer of Code students who applied for the program as an active member of the project almost a full year before the program began. Additionally, my areas of contribution in Fedora before GSoC were mostly unrelated to my project proposal. My project proposal mostly aligned with my intended degree and education I am pursuing. A lot of the technology I would be working with was new to me and I had minimal knowledge about it before beginning the summer. As a result, this presented a unique set of challenges and problems I would face throughout my project.

The consequences of this were that I had to spend a lot more time researching and becoming familiar with the technology before advancing with creating the deliverable items. A great resource for me to learn about Ansible was Ansible for DevOps by Jeff Geerling. But I spent more time on learning and “trying out the tech” than I had anticipated.

This extra time spent on research and experimentation were in tandem to my ongoing contributions in other areas of the project like Community Operations, Marketing, Ambassadors, the Diversity Team, and as of recently, the Games SIG. Balancing my time between these different areas, including GSoC, was the biggest challenge to me over the summer (along with a separate, part-time job on weekends). A separation of time to different areas of Fedora became essential for making progress on my project. What worked well for me was setting short-term goals (by the hour or day) that I wanted to hit and carry out. Until those goals were reached, I wouldn’t focus on anything other than those tasks.

Special thanks 🔗

I’m both thankful and grateful to those who have offered their mentorship, time, and guidance for me to be a member of the GSoC Class of 2016. Special thanks go to Patrick Uiterwijk, my mentor for the program. I’ve learned a lot from Patrick through these past few months and enjoyed our conversations. Even though we were both running around the entire week, I’m glad I had the chance to meet him at Flock 2016 (and hope to see him soon at FOSDEM or DevConf)! Another thanks goes to one of my former supporting mentors and program administrator Remy DeCausemaker.

I’m looking forward to another year and beyond of Fedora contributions, and can’t wait to see what’s next!

Flock, now in its fourth year, is a conference for Fedora contributors to come together, discuss new ideas, work to make those ideas a reality, and continue to promote the core values of the Fedora community: Freedom, Friends, Features, and First.

This year, I am attending as a contributor to the project, giving a talk, and leading a workshop!

Poland: New experience 🔗

Last year, I attended Flock 2015 without having much of an idea of what to expect. Flock 2015 was less than ten minutes away from my then future university, the Rochester Institute of Technology. I was a user of Fedora since 2013, but I had never figured out how to start contributing to the project. To take advantage of this experience, I made plans to move into school early so I could see what Flock was all about.

Fast forward a full year, and a lot has changed. Now, I spend many hours a week working on the Fedora Project in many places. I help lead the CommOps and Marketing teams. I organize and attend events on the US East Coast as an Ambassador. I’m a Google Summer of Code 2016 student for Fedora. When I walked into the conference center last year as a shy student, I never imagined that many of the people I met would become familiar faces in short time.

This year, Flock 2016 in Poland will be a different experience, and I am looking forward to seeing what it will bring. Do you have plans to attend? If so, allow me to share some details for sessions you will want to add to your schedule!

Evaluating our impact in education 🔗

At 17:30 UTC+2 on August 2nd, 2016, together with Jona Azizaj, we will lead a talk titled, “University Outreach – New task or new mindset?”

In early 2015, the Fedora Council proposed a new objective: the University Involvement Initiative. The purpose? Try to increase exposure of Fedora in university settings to gain new users, but also to hopefully gain new contributors. In order to carry this out, is it a new task, or does it need a new mindset? In this talk, we begin looking at the current mindset and marketing thoughts around attracting university students to Fedora. What is working? What isn’t?

We will look at personal experiences among the presenters with getting involved with Fedora as a student for an example. We will focus on how changing the ways we approach reaching out to students might be the best way to begin making an impact on students with Fedora.

If you are someone interested in reaching new audiences of students with Fedora, make sure you work this talk into your agenda.

CommOps Workshop 🔗

As of recently, I will also be leading the CommOps workshop on August 4th, 2016 at 13:30 UTC+2.

This year, for the first time, CommOps will be hosting its own workshop to tackle existing tasks and project items, offer a place for the community to add their own ideas and wishes for what they would like to see, and planning for the future growth of our sub-project. Flock offers a unique venue to do this as it brings together multiple people from different areas of Fedora in the same rooms. This is a great place for us to take advantage of the combined people power to accomplish tasks that would be hard otherwise.

The workshop will be designed to also try to keep remote contributors in mind, where possible, over IRC and possibly other means.

To help organize thoughts and ideas on the workshop in a public and open way, the workshop planned in the open on the wiki. We’re working with other CommOps contributors on shaping how the workshop will run. We hope to have you join us and see what we’re up to in CommOps land!

Thank you Red Hat 🔗

Finally, I want to offer my sincere gratitude and appreciation to Red Hat and the Flock sponsors for sponsoring my travel costs to Flock 2016. As a student, there would not be a way for me to afford making this trip on my own expenses. Thanks to the great folks behind Flock, I will be attending and hope to contribute my worth with the above talk and workshop, as well as throughout the entire conference.

Thank you for granting me this opportunity, and I look forward to seeing many other Fedora contributors next month in Poland!

Image courtesy Alexey Topolyanskiy – originally posted to Unsplash as Untitled.

Background for Fedora 🔗

Understanding the background context for how WordPress fits into the needs for Fedora is important. There are two sites powered by WordPress within Fedora: the Community Blog and the Fedora Magazine. Each site uses a different domain (communityblog.fedoraproject.org and fedoramagazine.org, respectively).

At the moment, there are not any plans to set up or offer a blog-hosting service to contributors (and for good reason). The only two websites that would receive the benefits of a multi-site network would be the Community Blog and the Magazine. For now, the intended scale of expanding WordPress into Fedora is to these two platforms.

Setting up the WordPress network 🔗

To test the possibilities of using a network for our needs, I used a development CentOS 7 machine for my project testing purposes. There are some guidelines on creating networks for reading first before proceeding. After reading these, it was clear the approach to take was the domain method. I moved to the installation guide on the development machine.

I wanted to document the process I was following for the multi-site network, so I created a short log file of my observations and information I found as I proceeded.

One of the time burners of this section was picking up Apache again. A few years ago, I switched my own personal web servers to nginx from Apache. Fedora’s infrastructure uses Apache for its web servers. It took me a little longer than I had hoped to get familiar with it again, mostly with virtual hosts and SELinux contexts for WordPress media uploads. Despite the extra time it took with Apache, I feel like this will save me time later when I am working on polishing the final deliverable or working with the Apache roles available.

In addition to this, I also picked out the dependencies for WordPress, such as the PHP packages needed and setting up a MariaDB database. After a while, I was able to get the WordPress network established and running on the development machine. It was convenient having a testable interface at my fingertips to work with.

WordPress network: Conclusion? 🔗

At the end of my testing and poking around, it appeared to me that there would not be an easy solution to using a WordPress network for Fedora. The network had the best ability when set up to use wildcard sub-domains, which wouldn’t be a plausible solution for us because of the two different domains. There were more manual ways of doing it (i.e. not in the WordPress interface) with Apache virtual hosts. However, I felt like it would be easier to write one playbook that handles a single WordPress installation, and can be run for both sites separately (or new sites).

Given that the factor of scale is two websites, I think maintaining two separate WordPress installations will be the easier method and save time and keep efficiency.

This week’s challenges 🔗

This week had a late start for me on Wednesday due to traveling on a short vacation with my family from Sunday to Tuesday. Coming back from the trip, I also have a new palette of responsibilities that I am assisting with in Community Operations and Marketing, following decause’s departure from Red Hat. I’m still working on finding a healthy balance of time and focus between other important tasks I am responsible for and my project work.

I’m hoping that having a full week will allow me to make further progress and continue to overcome some of the challenges that have arisen in the past few weeks.

Next week’s goals 🔗

For next week, I’m planning on focusing on my existing product and making it feel and run more like a “Fedora playbook”. I mostly want to work on saving unnecessary effort and being consistent by tapping into the existing Ansible roles in Fedora Infrastructure. This would make setting up an Apache web server, MySQL database, and a few other tasks more automated. It keeps the tasks and organization in a consistent manner as well since they are across Fedora’s infrastructure already.

By next Friday, the plan is to have a more idempotent product that runs effectively and as expected in my development server. Beyond that, the next step would be to work on getting my site into a staging instance.

Communicating between Ambassadors and Design 🔗

From our conversation, I learned that there was a disconnect between the Ambassadors and the Design team. As a sponsored Ambassador myself, I had never seen anywhere documenting the steps or process I should take to ask for art assets when needed for an event. There were also things I had not considered about what goes into the printing and production process for items too. Every region of the world seems to do things a little differently!

With the information I learned from our conversation in a CommOps meeting, I penned up a first draft of what the communication process should look like between Ambassadors and the Design team. The page is not official yet, and I posted a bit ago to the Design Team mailing list requesting feedback on the page. Hopefully, if the information passes approval from the Design Team, we can work on socializing this information with all Ambassadors across the four regions of the world. The end goal of this is to make it easier on both the Ambassadors and the Design Team by doing the following…

• Making it clear what to do as an Ambassador for requesting art assets / printed items
• Reducing strain / load on Design Team from repetitive situations / “common questions”
• Creating a faster and more efficient workflow for Ambassadors organizing events and Designers creating art and deliverables

Long-term, though… 🔗

In this discussion, we acknowledged a wiki page is not a long-term solution to this problem. There are now initiatives in the project to help bring greater unity and cohesion between different sub-projects. CommOps is definitely one of the biggest players to this. The future formation of FOSCo will help specifically towards communication between groups like Ambassadors, Design, and Marketing. Fedora Hubs will also contribute to making this process easier by having improved methods of communicating key information like this.

Communication by Lorenzo Stella from the Noun Project.

What is Vagrant? 🔗

Many people in the tech industry are already familiar with virtual machines (VMs) and using them for testing. If using a virtual machine is useful for testing and experimentation, Vagrant takes that idea and makes it a thousand times for powerful. Vagrant creates and configures a single virtual machine or several groups of inter-connected virtual machines. For someone trying to learn configuration management software like Ansible (or Puppet, or Chef, or Salt…), it features tight integration for creating virtual machines from playbooks.

Using Vagrant allows you to make quick, simple, and easy changes in a safe, local environment. Vagrant is also incredibly easy to set up, and in my experiences, it also ran well on a laptop. My trusty Toshiba Satellite with 8GB of RAM and an Intel i3 chip was able to handle three CentOS 7 virtual machines at once, and still manage to do other regular tasks.

Installing Vagrant for Fedora 🔗

Since I’m working with Fedora on my hardware while working on the Fedora Project over the summer, it would make sense for this guide to cover how to install and set up Vagrant inside of Fedora. However, I imagine it’s similar for most other distributions, so try adapting these commands for your own distribution.

The Fedora repositories have a Vagrant package available. To install it, run the following command.

$ sudo dnf install vagrant

This will pull down Vagrant and all the dependencies it needs to run. However, what it won’t do is pull down some of the many providers that it might need to use a virtual machine.

Vagrant and providers 🔗

For my testing, I used a centos7 box image from geerlingguy. This image creates a current, updated CentOS 7 virtual machine. In order to use it, you must have one of the two providers available: VMware or VirtualBox. Seeing as how VirtualBox is easier for me to install and use on my system, I chose to use VirtualBox as the “provider” for building and simulating the CentOS 7 box within Vagrant.

It took a bit of figuring out at first, but I found a current and well-documented guide on how to install VirtualBox on to a Fedora 22 or 23 system. For a more detailed explanation of how to do it, you can read the instructions, but for simplicity, I have the commands here to show how to add it to your Fedora system quickly.

$ sudo dnf upgrade
$ cd /etc/yum.repos.d/
$ sudo wget http://download.virtualbox.org/virtualbox/rpm/fedora/virtualbox.repo
$ sudo dnf install VirtualBox-5.0 binutils gcc make patch libgomp glibc-headers glibc-devel kernel-headers kernel-devel dkms
$ sudo /usr/lib/virtualbox/vboxdrv.sh setup
$ sudo usermod -a -G vboxusers your_username

From here,  VirtualBox  will be available as a provider within Vagrant.

Running a CentOS 7 image 🔗

Now that you have both Vagrant and VirtualBox installed, you can create a Vagrant virtual machine with this image. Navigate to a new directory you want to use for managing your virtual machines. Once there, you can use the following commands to start your CentOS 7 virtual machine.

$ vagrant box add geerlingguy/centos7
$ vagrant init geerlingguy/centos7
$ vagrant up --provider virtualbox

After a lot of downloading and then waiting for the first setup to finish, you should receive a notification that your virtual machine started! Huzzah! You can log in directly to it by typing vagrant ssh in the same directory you ran the above commands.

There’s a lot of cool things you can do to set up your virtual machines and configure how they start. For example, you can choose to use the VirtualBox GUI for running your virtual machines if you don’t want to SSH into it. You can tweak several different flags to alter the environment for the virtual machine. However, that is out of the scope of this guide, and there is a fair amount of documentation already online.

Provisioning with Ansible 🔗

The fun part (and what was really cool for me) was provisioning new virtual machines with Ansible. You can instruct Vagrant to seek an Ansible playbook when creating a new virtual machine. It will use the instructions of the playbook to configure, install, or tweak whatever is in the playbook, as if it’s being run for the first time. Or maybe it’s the second, the third, the fourth time you’ve run it. In either case, the idempotent nature of Ansible should help make sure you avoid repeating anything that doesn’t need repeating.

In order to tell Vagrant to search for an Ansible playbook, you will need to edit the Vagrantfile for wherever you initialized Vagrant. Open it up in your favorite text editor and add the following bits at the bottom, but before the final end statement.

config.vm.provision "ansible" do |ansible|
  ansible.playbook = "playbook.yml"
end

These short but sweet instructions tell Vagrant to look for a playbook.yml file when starting this virtual machine. It will then be easy to provision (i.e. configure / modify / change) the machine with your playbook later on.

Writing the playbook 🔗

For this blog post, I’ll offer a simple but clear example of a playbook you can use to start a Vagrant machine. This snippet specifically comes from Ansible for DevOps by Jeff Geerling, which I have (and am) using as a guide as I continue to learn more about Ansible (I highly recommend the book, consider getting a copy).

---
- hosts: all
  sudo: yes
  tasks:
  - name: Ensure NTP (for time synchronization) is installed.
    yum: name=ntp state=present
  - name: Ensure NTP is running.
    service: name=ntpd state=started enabled=yes

All this example playbook does installs NTP if it is not present on the system, and then start and enable it, if it is not already. This is a very simple example, but it’s good for getting started quickly.

Running the playbook 🔗

In the same directory as your Vagrantfile, create a playbook.yml with the above content. Once you have the YAML file there, running the following command will run the Ansible playbook and allow you to see how it runs.

$ vagrant provision

Now, Vagrant will take your playbook and instantly run it in your machine. If all goes right, your virtual machine will now have NTP installed and be syncing your clock to the Internet! While a simple task, it was a satisfying feeling for me to see this run, but also to imagine the other possibilities that this could be used for. It would be easy to run a playbook on one, two, ten, a hundred, a thousand servers, and have it do the same thing on all of them.

The automation was fascinating to me and began giving me ideas of how I could automate my infrastructure, as well as to creating one for WordPress (for my GSoC project).

Congratulations! By the end of this short but (hopefully) useful guide, you will have Vagrant virtual machines that are controlled and orchestrated by Ansible.

Bad puns aside, I am actually enormously excited to announce that I am participating in this year’s Google Summer of Code program for the Fedora Project. If you are unfamiliar with Google Summer of Code (or often shortened to GSoC), Google describes it as the following.

Google Summer of Code is a global program focused on bringing more student developers into open source software development. Students work with an open source organization on a 3 month programming project during their break from school.

I will work with the Fedora Project over the summer on the CommOps slot. As part of my proposal, I will assist with migrating key points of communication in Fedora, like the Fedora Magazine and Community Blog, to Ansible-based installations. I have a few more things planned up my sleeve too.

Google Summer of Code proposal 🔗

My proposal summary is on the GSoC 2016 website. The full proposal is available on the Fedora wiki.

The What 🔗

The Community Blog is becoming an important part of the Fedora Project. This site is a shared responsibility between CommOps and the Infrastructure team. Unlike most applications in the Fedora infrastructure, the Community Blog is not based off Ansible playbooks. Ansible is an open-source configuration management suite designed to make automation easier. Fedora already uses Ansible extensively across its infrastructure.

My task would consist of migrating the Community Blog (and by extension, Fedora Magazine) to an Ansible-based set up and writing the documentation for any related SOPs.

The Why 🔗

Ansible is a useful tool to make automation and configuration easier. In their current set up, the Community Blog and Fedora Magazine are managed separately from each other, and are managed by a single member of the Infrastructure team. By moving them to Ansible-based installations and merging the WordPress bases together, it provides the following benefits:

1. Makes it easier for other Infrastructure team members to fix, maintain, or apply updates to either site
2. Prevents duplicate work by maintaining a single, Ansible-based WordPress install versus two independent WordPress sites
3. Creates a standard operating procedure for hosting blog platforms within Fedora (can be used for other extensions in the future)

Thanks to my mentors 🔗

I would like to issue a special thanks to my mentors, Patrick Uiterwijk and Remy DeCausemaker. Patrick will be my primary mentor for the slot, as a member of the Fedora Infrastructure team. I will be working closest with him in the context of my proposal. I will also be working with Remy on the “usual” CommOps tasks that we work on week by week.

Another thanks goes out to all of those in the Fedora community who have positively affected and influenced my contributions. Thanks to countless people, I am happy to consider Fedora my open source home for many years to come. There is so much to learn and the community is amazing.

Getting started 🔗

As of the time of publication, the Community Bonding period is currently happening. The official “coding” time hasn’t started yet. Without much delay, I will be meeting up with Patrick and Remy later today in a conference call to check in after the official announcement, make plans for what’s coming up in the near future, and become more acquainted with the Infrastructure community.

In addition to our conference call, I’m also planning on (formally) attending the next Fedora Infrastructure meeting on Thursday. Shortly afterwards, I hope to begin my journey as an Infrastructure apprentice and learn more about the workflow of the team.

Things are just getting started for the summer and I’m beyond excited that I will have a paid excuse to work on Fedora full-time. Expect more check-ins as the summer progresses!

Bitcamp is a place for exploration. You will have 36 hours to delve into your curiosities, learn something new, and make something awesome. With world-class mentors and hundreds of fellow campers, you’re in for an amazing time. If you’re ready for an adventure, see you by the fire!

The Fedora Project attended as an event sponsor this year. At the event, we held a table in the hacker arena. The Ambassadors offered mentorship and help to Bitcamp 2016 programmers, gave away some free Fedora swag, and offered an introduction to Linux, open source, and our community. This report recollects some highlights from the event.

Getting to Bitcamp 2016 🔗

I left Rochester, New York around 4:00pm after my classes for the day had finished. Bitcamp check-in started at 7:00pm on Friday, April 8th. It was about a six hour drive for me to get there, and I got to Maryland right around 9:30pm.

Once I arrived, walking in was a crazy experience. Tables upon tables of hackers were lined up bu the hundreds. Most were already working on brainstorming. I meandered my way through the crowds to the Fedora table where Corey Sheldon, Mike DePaulo, and Chaoyi Zha were set up.

Meeting the hackers 🔗

Many other students came up to the table before the hackathon officially began. We interacted with several students and helped establish ourselves as mentors as well. Additionally, we also had a badge that attendees could scan to get added to their FAS account!

Once the event officially began, teams of people began working on their projects. Many people had grand ideas of projects to cram into the one weekend. For a brief time, the Ambassadors had a chance to rest from answering questions and helping people with their own hardware.

The hackers began settling into a groove for the evening.

Spending the night 🔗

As the day turned into night, the home stretch of the hackathon was beginning. Those with firm ideas were deeply focused on their projects. Others were taking their plans back to the drawing board to overcome unexpected difficulties. Things began settling down for the night. The same cycle repeated itself for both Friday and Saturday nights.

Around this time, we had waves of interested hackers in Fedora, open source software, and Linux approach the table. This time was great for personalized, one-on-one conversations with visitors. Many excellent connections happened during this time!

Mentoring 🔗

During Bitcamp, there were several opportunities and connections made between Fedora Ambassadors and university students.

For most of one night, Corey worked with one student who was aiming to do a full dual-boot installation on his laptop with Windows 10 UEFI. For a mixed variety of issues, he was unable to get Fedora working properly on his system. With the help of Corey, he was able to install and use Fedora on his laptop. He was very excited to finally get it working and was hoping to use it for development work in both classwork and personal projects. He was also a repeat visitor from BrickHack and remembered some of the booth members from the last hackathon.

Chaoyi traveled around the hacker space and worked with students looking to get help on web development projects. Chaoyi was able to give advice and help for students working with HTML, JavaScript / NodeJS, and Python. He traveled around the room for most of both nights teaching and showing students how to work on their projects and promoting the benefits of doing their work open source.

Mike also helped several students at Bitcamp, and like at BrickHack, his triple-booted MacBook with OS X, Windows, and Fedora was a popular item. Students with Macs often came and asked him about his setup and how he got it working. Mike was also able to help answer questions about developing in Fedora and share his experience working with tools available in Fedora for working on his projects for work and for fun.

Many students were looking for help with how to better get experience working on software for their future careers. As a student familiar with open source, I enjoyed talking to these students about how open source was a great resource for them. I explained how open source is a great way to get real world experience without working an “official” job, showed how they could make an impact on the world and start doing things, and why we do open source. It was gratifying the see these students get something out of our discussions and build something awesome in the open by the end of hackathon.

Overall, I feel like the Fedora Project’s impact was notable and concentrated at the event. I am extremely thankful and fortunate to have been sponsored to attend Bitcamp as an Ambassador for the Fedora Project.

This post is my quiz submission for the Spring 2016 semester Quiz #2.

HFOSS Spring 2016, Quiz #2 🔗

Expand each of the following acronyms. 🔗

1. IRC: Internet Relay Chat
2. FOSS: Free and Open Source Software
3. OLPC: One Laptop per Child
4. DVCS: Distributed version control system
5. FSF: Free Software Foundation
6. PR: Pull Request

What is the short, two-letter name for the OLPC computers used in the final project for this class? 🔗

• XO laptops

What is the one-word name for the interface used in the OLPC computers? 🔗

• Sugar (SoaS)

What is the grade level we are targeting our OLPC applications for? 🔗

• 4th grade students

Briefly define the following instructional theories, giving the role of the instructor in each. 🔗

• Didactic: Lecturing; instructor speaks to class about topic
• Dialectic: Similar to the Socratic seminar; discussion-based instructional teaching with interactions between the instructor and the class
• Constructivist: Teaching style that combines experiences with teaching to create a learning experience that lends power to the learner; the instructor acts as a facilitator rather than a traditional lecturer

Several elements are combined in different ways to form the Creative Commons licenses. Match each shorthand given in the list with the description of that license element below. 🔗

1. NC: Non-Commercial; You may not use the work for commercial purposes.
2. SA: Share-alike; You must convey the same rights “downstream” that were conveyed to you by “upstream”.
3. ND: No Derivatives; You may not make changes to the work.
4. BY: Attribution; You must attribute the contributions of the original or upstream creators of the work.

The presence of which license elements make a license “non-free” according to the FSF? 🔗

• (1) Non-Commercial; You may not use the work for commercial purposes.
• (3) No Derivatives; You may not make changes to the work.

Which license element is a copyleft? (give the letter, 1 pt) 🔗

• (2) Share-alike; You must convey the same rights “downstream” that were conveyed to you by “upstream”.

Name two projects that distribute a body of non-software, free culture data, and briefly name or describe the kind of data. 🔗

1. Fedora Project Documentation (CC-BY-SA 3.0): Provides documentation and instructions on using the Fedora operating system and how to achieve certain tasks using it
2. ManyBooks (mixed variety of CC licensed works): Provides downloads of freely licensed literature, novels, and books

List or describe “the four R’s” as a shorthand for the freedoms attached to software for it to be considered “free and open source”. 🔗

1. Read
2. Run
3. Revise
4. Redistribute

Bonus Questions 🔗

True or False: You cannot sell GPL’d software. 🔗

• False

True or False: You can fork a GPL licensed Project and release it under an MIT license? 🔗

• False

True or False: You can fork a MIT licensed Project and release it under an GPL license? 🔗

• True

When does a work become “copyrighted” by an author? 🔗

• When it is created

This post serves as the project proposal for me and my team’s Humanitarian Free and Open Source Software Development “Community Architecture” project (shortened to CommArch)!

In this project proposal, we take a preliminary look at the project we’re looking at analyzing, Tahrir, and the different criteria we are assigned to look at.

Team Members 🔗

Project 🔗

Tahrir by the Fedora Project

Description 🔗

Tahrir is a Pyramid app for distributing your own custom badges (based off of Mozilla Open Badges). The back-end is written in Python with an HTML/CSS and JavaScript front-end and the project is a smaller part of the Fedora Project.

Team Member Roles 🔗

Justin and Wilfried 🔗

1. Project Report I-R
2. git_by_a_bus

Stephen and Bobby 🔗

1. Project Report A-H
2. Calloway Coefficient of Fail

Source Code Repository URL 🔗

fedora-infra/tahrir

Upstream Mentors 🔗

Communication Methods 🔗

The following methods of communication are ordered in the most preferred way to the least.

1. IRC channel on freenode (#fedora-apps)
2. Issue tracker on GitHub
3. Mailing list via infrastructure@lists.fedoraproject.org

What are the easy parts? 🔗

• Project is fairly small (even though it is part of a larger project)
• People to ask for help when needed
• Git-by-a-bus is going to make analytics of contributors super easy
• Distribution of work will allow us to complete the project in a timely manner

What are the hard parts? 🔗

• Lack of a frame of reference for some team members who have never worked with open source projects in the past (e.g. we are unable to compare activity or its community to other projects)
• Since the project is a smaller project inside of a larger one (Fedora Project), it will be challenging to look at it in a modular sense
• Separation of dependencies from project requirements (Open Badges requirements and Tahrir requirements)

How will you overcome both? 🔗

Hard Stuff 🔗

• We have two people who are more advanced at hacking who can hopefully guide the two who aren’t through the project, effectively eliminating the lack of reference point.
• Three of our members are not people involved in the Fedora Project, and as such won’t be distracted by its involvement with Fedora and will only look at the project itself.
• Read up on the existing documentation and test the various endpoints of the project to identify what is needed with Open Badge and what the project is implementing itself.

This post is my quiz submission for the Spring 2016 semester Quiz #1.

HFOSS Spring 2016, Quiz #1 🔗

What is the name of the version control system we use in this course? 🔗

• Git

Bonus: Give the name for another version control system. 🔗

• Mercurial

We refer to sites that host source code as “forges”. What is the name of the primary forge used in this course? 🔗

• GitHub

Rearrange the following to make the best matches. 🔗

For the next several questions, rearrange the items in the column on the right, as necessary, so that they best match the names of key figures in the column on the left.

For example:

1. Randall Munroe
   1. Saturday Morning Breakfast Cereal
2. Zach Weiner
   1. XKCD
3. Walt Disney
   1. Mickey Mouse

…becomes…

1. Randall Munroe
   1. XKCD
2. Zach Weiner
   1. Saturday Morning Breakfast Cereal
3. Walt Disney
   1. Mickey Mouse

1. Andrew Tannenbaum
   1. Minix
2. Linus Torvalds
   1. Linux
3. Bruce Perens
   1. Debian Free Software Guidelines
4. Richard Stallman
   1. Free Software Foundation / GNU Project

We discussed several concepts involving rights, restrictions, and licensing. Match the term on the left with the most appropriate description on the right. 🔗

1. Trademark
   1. Lasts as long as used & defended
2. Copyright
   1. Life of the author plus 70 years
3. Patent
   1. 20 year term

1. Trademark
   1. Protects consumers from confusing one product with another
2. Copyright
   1. Arises as soon as a work takes tangible form
3. Patent
   1. Precedence is given to the first to file an application

List or describe “the four R’s” as a shorthand for the freedoms attached to software for it to be considered “free and open source”. 🔗

1. Read
2. Run
3. Revise
4. Redistribute

My Year in Review 🔗

With an hour left until the New Year, there never seemed a better time to begin writing my Year in Review article. While it is a stereotypical kind of thing to do, I also think it’s a great opportunity to reflect on the gifts, changes, and special occasions that this past year has presented to me. 2015 is special to me in many ways because it marks a significant milestone in my life of moving away from home and beginning my journey into full adulthood.

There are many important and special people in my life that have made this year incredible, and I want to reflect and make note of this.

</high school> <college> 🔗

This past May, I graduated from high school. Looking back, it’s interesting to see how much has changed in my personal life and even in my own interests. Some friends have come and gone, but there are an important core of people who have always been present in my life, and I am privileged to have been one to know them deeply over the past four years.

Interestingly enough, it wasn’t until my junior year when I realized that I wanted to spend my life working in computer science. I remember when I walked into the classroom of my AP Computer Science teacher asking how I could get going with only one year left. Now, here I am immersing myself in digital technology in countless different ways. I feel like I am where I am meant to be.

These four years haven’t been easy either. I worked hard to get to the place I wanted to go. Despite quite a few personal challenges, I was fortunate enough to afford an education here at the Rochester Institute of Technology. Just in the semester and a half that I have been enrolled here, I’ve met countless people who have affected my life and helped shape the direction of where I’m going in the world. Special shout-out to the FOSSbox and RITlug, and everyone involved with both.

Coffee and Doughnuts 🔗

For most of 2015, I worked a not-so-typical job at Dutch Monkey Doughnuts in my hometown. Dutch Monkey is an important part of my town and they have helped create a name for people visiting the region. They’re well-known for their homemade doughnuts and Counter Culture Coffee, both of which are legendary within their own right.

During my time at Dutch Monkey, I was able to attend workshops and classes at the Counter Culture Coffee Training Center in Atlanta. Throughout the eight or nine classes I took, I was able to further my understanding and appreciation for an extremely complex and fascinating beverage. My appreciation and love for coffee has become a part of my being. The coffee industry is a wild and exciting place, and it is very much an ethical hotbed of all kinds of issues. I joke to myself that if sysadmin doesn’t work out, the coffee industry could always make a good fallback…

I was also fortunate to have some awesome co-workers who helped make the 4am shifts a little more enjoyable. Special shout-out to Jordan Hughes for the long talks about music, the music industry, and so many other things. I learned a lot from you and you’ve had a big impact on my own music tastes.

MINECON and SpigotMC 🔗

This was single-handedly one of the most profound events of the year for me. If you weren’t aware, I am a community moderator for the SpigotMC project. I have been a moderator since April 2014. Spigot is my true first open-source project, even though I wasn’t a contributor of code, but a community builder (or so I like to think).

MINECON announced 🔗

In February of 2015, Mojang announced that MINECON 2015 would be happening in London, England. Instantly, I thought there would be no way I would ever be able to afford a trip overseas for a two-day convention. However, I found the application for a MINECON Agent, which is the small group of “interns” that volunteer to help set up and prepare MINECON for over 10,000 people with the Mojang team. The only benefit to being an Agent was a waived ticket cost (around $120 last year). I applied for the program, unsure of what would come of it, doubtful I would be able to go even if I were accepted.

April rolls around, and I finally hear back from Mojang! “Congratulations, you are now a MINECON Agent!” It was difficult to believe at first, but I wasn’t sure I would be able to go regardless.

Getting in gear for MINECON 🔗

I began talking with the rest of the team at SpigotMC. We were also getting in gear for MINECON 2015 and were planning to attend as an organization with our own booth. We had arranged to have a booth and most of the team knew who was going to be there. Michael, our project lead, would be in attendance, along with Matthew, the other lead developer; Jordan, another community moderator like myself; Cindy, our local wiki staff, IRC staff, and contributing developer, or also the official “Spigot Mom”; and Miguel, our witty Spigot volunteer who has an ambiguous position with Spigot. Cindy’s son Alex was also going to be in attendance.

I didn’t think I would be able to attend. However, a very unique set of events happened one after another, and suddenly, the possibility of me attending MINECON this year began to materialize. Thanks to awesome people behind Spigot, I was fortunate enough to make it out to this year’s convention. When I figured out that I would be going to London, I was beyond stoked.

Going to London and MINECON 🔗

I would be there from Saturday, July 4 to Wednesday, July 8, 2016. Saturday and Sunday were the days of MINECON. Together with the team, we helped represent the SpigotMC project among thousands of convention-goers. We had brochures, bracelets, and a video running in the booth for visitors to take and see. I met some incredible people from our community, and I am privileged and honored to have met some incredible people there.

Thanks to Michael being the incredible individual he is, we went to a few dinners and meet-ups with others in the Minecraft community. I met two of the major Minecraft developers, Nathan (Dinnerbone) and Erik (Grum) and countless others in the YouTube and development community. It was almost unbelievable. The entire time I was in London, the experience felt surreal. Six months before this, I would never have believed any of this would ever have happened.

The Monday and Tuesday we were there, Cindy, Jordan, Alex, and I went around London doing our proper duty as tourists. We went to see Big Ben, Westminster Abbey, rode a double-decker bus, went to the Queen’s castle, and indulged in what Jordan called a “proper British meal”. On Monday night, Jordan treated me to a short trip around London hopping between bars (although everything closed so early)! We ended up crashing in some late-night diner, had a meal, and headed back for the next round of sightseeing on Tuesday.

Thanks to the team 🔗

This was truly a life-changing experience that was bestowed upon me. I was honored and privileged to have met the other members of the Spigot team that I’ve been working with for the past two years. I wouldn’t trade my time in London for anything else, and I’m hoping that I’ll be able to help host the crew this upcoming MINECON if it ends up in the northeast US.

Open Source and Fedora 🔗

I have used the Fedora operating system on my laptop since December 2013. I began using it on my desktop I built in November 2014. I have used this operating system for almost two years and I never had thought too much about the community behind the Fedora Project. I knew that it was a large and complex community, but I was never sure where to take the first step. I had always wanted to be an Ambassador, but questioned my usefulness or whether I was a right fit for the program.

Flock to Fedora! 🔗

I learned that Flock, Fedora’s annual contributor’s conference, was to be hosted in Rochester, NY in 2015 from August 5th to the 9th. I would be moving right next door to Flock just a week after the conference! After contacting a pair of people who seemed knowledgeable about the details back in February 2015, little did I know I was setting in motion an entirely new track of events in my life. The two gents I emailed, Remy DeCausemaker and Prof. Stephen Jacobs (SJ), helped give me advice on travel details and how I would get myself into Rochester in time for Flock.

Come August, I am back from MINECON, packing my bags for Rochester, and ending my last few days at Dutch Monkey. When I arrived in Rochester with my mother, it was an exciting and new experience, something I had looked forward to for a long time. Once Flock rolled around, I was almost instantaneously immersed in the Fedora community, and over the course of the week, I would begin to feel a part of a Project that I had questioned how to enter for almost a year.

The talks were fantastic, the speakers were passionate, and the community was welcoming. I was jump started into Fedora at Flock 2015, despite walking in a stranger. At first, I questioned whether coming was such a grand idea. It was obvious everyone knew someone already and I was only an excited Fedora user and fan. These were the people who did all the heavy-lifting to make this operating system and its community run. What was I doing here?

I distinctly remember Pete Travis (randomuser in IRC) coming up to me, introducing himself and asking me a few questions. In retrospect, I probably looked like I was feeling a bit out-of-place. He and I began talking a bit about his role in Fedora and some of my little experience in open source. After he spoke to me, I began to feel a little more attached to the conference. After a while, I began speaking up at some of the talks I attended, or trying to share some of my perspective or thoughts as an outsider. These were the stepping-stones that got me involved with the project.

One thing about all else stands out to me about the conference. I remember Remy saying to me towards the end (with minor paraphrasing), “You should check out this Community Operations thing that’s coming up soon. It’s going to be awesome.”

Fedora Magazine 🔗

Over the course of the next few months at RIT, I started working with Paul Frields, Ryan Lerch, and a few others on the Fedora Magazine. I began contributing as a writer, with my first article about using Spigot on Fedora. As time went on, I began helping as an editor, revising and reviewing other people’s articles to help get them published for the Magazine. By the end of 2015, I believe I would come to establish myself as a permanent member of the editorial team behind the Magazine.

CommOps 🔗

Additionally, during the months after Flock, I would follow up on what Remy told me, and I checked out this whole Community Operations (shortened to CommOps) thing. It was in the early formation stages, but the core idea behind CommOps was that they were the supporting team to offer support to all the other sub-projects in Fedora. Or in my eyes, a team focused on building and supporting the community with resources and assistance. This was something I thought I could contribute to. My programming skills were not at a level where I’d feel comfortable hacking on to Fedora either on the Infrastructure or as a Packager. But CommOps was that kind of thing that hooked me from the start. I wanted to help build Fedora up, and I could see what exactly CommOps was trying to target and how it was wanting to fix the long-term issues.

Now, months later, my involvement with CommOps has resulted with many tickets filed and many tickets closed. It has been a productive time while I have been with CommOps, and I never feel like there is too little to do. Our horizon is vast and there is much work to be done… 2016 offers great promise to the success of our sub-project, which in turn offers great promise to the Fedora Project. I am looking forward to seeing where this year takes us. I am also happy to work with such an awesome and dedicated group of people as those behind the CommOps team. There are too many to name, but I’m thankful for the leadership of Remy to keep us all together, focused, and driven.

2016 🔗

2016 will have a lot of ground to cover over 2015, but there is a large potential for this to be done. My own personal story with open source continues to grow, and I am beyond excited for what the future may bring. I am exposed to a unique group of people and minds here at RIT, and I am actively pursuing the Free and Open Source Software (FOSS) minor.

This self-reflection has turned into a much longer post than I anticipated, but I think this reflection is necessary and useful for my own purposes. Taking a moment to reflect on the events of the past year helps remind me what it’s all about and why I’m doing what I’m doing, especially at the times where everything seems confusing and I begin to question what I’m doing. But the path is illuminated and I am driven to succeed. There are a lot of things at stake for me and my family, and I hope to be able to meet many personal goals and better support the people closest to me in my life.

I would also like to give a special thanks to all the people who have made this year so incredible for me, and for those who have ridden the ride with me. There are so many names to list, and it’s hard to come up with this list in the dark hours of the morning when I know I should be sleeping. But to all of those who play a special and important role in my life, I want you all to know that none of what has happened to me would be possible without your support. Your continued guidance, counsel, and companionship teaches me much and inspires me greatly. My only wish is that I will someday be able to repay all the good deeds that others have bestowed upon me. If not to the original giver, I hope to someday inspire others and help others in the same way you all have shown and taught me. Maybe this is less of a 2016 thing and more of a “crystal ball into the future” moment… but I think it’s worth mentioning regardless.

Thanks for a fantastic 2015. I’m looking forward to seeing where 2016 takes us next.

Today’s entry to the blog is sourced from a thread that I posted on the SpigotMC Forums. If you wish to join in the discussion about this, feel free to chime in on the thread or leave a comment on my blog. In this post, I covered licensing, licenses, and why your open-source software project should have a license. You can read my original post in this blog entry.

I’d like to share some personal and real-word advice to many of you contributing open-source resources to Spigot, but also to other open-source software projects you may work on even outside of just Minecraft or Spigot.

Licensing 🔗

What is licensing? Why does it matter? Why should you care? There are many reasons that licensing is an important part of a project you are working on. You are taking the time to write code and share it with the world in an open way, such as publishing it on GitHub, Bitbucket, or any number of other code-hosting services. Anyone might stumble across your code and find it useful.

Licensing is the way that you can control exactly how someone who finds your code can use it and in what ways.

Okay, why does it really matter? 🔗

Maybe you’ve been writing code for a really long time and you’ve never bothered with licenses and don’t feel the need to. I’d like to present two hypothetical situations that I see pop up all the time, one in Spigot and one in the greater open-source community.

Your Plugin 🔗

You have spent a lot of time writing an awesome resource and you pushed all of your code on GitHub! Woohoo, project complete! You package it up as a JAR and submit out to the open. Skip ahead a few months, and maybe you no longer have the time to contribute to your project. Or maybe someone has an awesome idea for a totally different plugin that uses similar functionality to what you have written.

A new person finds your code on GitHub and discovers that it has the perfect method or algorithm for his own project. Or maybe they want to continue your project with new, fresh energy! But you have no license for your code. By default, this means default copyright laws will apply to your code. This is an extremely limiting type of copyright enforcement and almost defeats the entire purpose of even open-sourcing your code. A law-abiding programmer might just give up on the project and look elsewhere, or maybe a not-so-law-abiding programmer will secretly copy and paste your code without attributing your work back to you. This helps neither you or the friendly programmer looking at continuing or forking your work.

In many cases, the SpigotMC Staff receive reports about people “copying” other peoples’ code. Having a licensed project makes reviewing these reports 10x easier. People without licenses or with ambiguous sources makes it extremely difficult to review and make decisions about whether projects are copies.

By licensing your code, you are protecting your own work and writing the rules to how people can use your code. If you are open-sourcing your code, usually the point is to have collaboration with others and give back to the community by allowing others to tinker, modify, or play with what you have created. Make it easier for others to contribute, help, or build new awesome things by choosing a license!

Your Project 🔗

For any open-source software project on the Internet, having a license is very, very important. For example, let’s say you write an important library or utility that can be used to make a developer’s life easier for making a user interface more friendly. Your program is well-designed and has usefulness outside of what even you intended to write it for.

Perhaps a large company stumbles across your code and also thinks it’s very useful for their own project. Maybe their project is proprietary or closed-source. Having a license in a situation like this suddenly becomes very important. Some licenses would permit this company to take the plugin or library, modify it to their own needs, and include it in their own product, while only leaving a small mention to you in the “Legal” section of their app. Maybe you’re okay with that! Maybe you’re not.

If you’re not, there are licenses that let you define how the code is used in a case like this. With some licenses, if the company decides to modify and use your code, they will have to open-source their changes that made as well. If they don’t modify anything, they just have to link back to your original source code. In some more extreme licenses, anything that touches your code also by extension has to be open source.

For a Minecraft example of this, let’s say you have a “Super Craft Bros.” plugin open-sourced on your GitHub. Hypixel stumbles across your code and decides they want to use it for their own servers. Let’s say your code is licensed under the Mozilla Public License 2.0. For this license, if they take your code and make no changes, they only have to give credit back to you. If they take your code and change it, they also have to open-source all of the changes they make to your code.

Now, the changes made by the bigger company can benefit many others instead of just the one company!

What licenses are there? 🔗

If you Google “open source licenses”, you may be overwhelmed. There are maybe close to the hundreds of different licenses for you to choose from. How can you pick one to settle on?! Fortunately, there are websites that do a great job of summarizing licenses to exactly what others can or cannot do with your code. A very popular site is tldrlegal.com, which provides bullet-point summaries of different licenses.

tldrlegal.com 🔗

Exploring that site is a great reference for picking a license. However, in this thread, I’m going to do a very quick summary of four of the most popular open-source licenses that exist. However, it is important to preface this with a statement: I am not a lawyer and this does not constitute legal advice. It is important for you to look more into a license that feels right for how you want to share your code and determine what others can do with it.

MIT License 🔗

The MIT License is almost universally regarded as one of the least strict licenses in open source. You can read more about it here.

You can:

• Use the work commercially (think of the big company example said earlier)
• Modify the original code
• Distribute the original code or distribute your modifications
• Sublicense the code (in other words, use it with code that has a different license)
• Use the code for private use

You cannot:

• Hold the original author liable for damages
  • So this can’t happen: “Oh noes! I accidentally exploded my entire server with your code! You must pay me monies to fix this nao!!!”

You must:

• Include a copyright notice in all copies or other uses of the work
• Include an original copy of the license with the original or modified code
  • You will always be credited for your work!

Apache License 2.0 🔗

The Apache License 2.0 is only slightly more restrictive than the MIT License, but it defines a few more rules than the MIT License. This can be useful if you want to make sure your work is given proper credit back to you and you care a little more about how it’s used. You can read more here.

You can and cannot do the same things mentioned above for the MIT License. So we will just highlight the changes!

You can:

• Same as MIT License
• Use patent claims (might be advanced for most of you, but can be useful for bigger projects)
• Place a warranty (lets you have a warranty on your code, if desired)

You cannot:

• Same as MIT License

You must:

• Same as MIT License
• Openly state changes you make from the original project
• Include the NOTICE (if the project has a NOTICE file, you have to keep it in copies / modified works)

Mozilla Public License 2.0 🔗

The next step up from the Apache License 2.0 is the Mozilla Public License 2.0. This license has the same basic rights as the Apache License 2.0, but it goes a little more in-depth about how the code can be re-used. This is my personal favorite license! You can read more here.

Most of the things for what you can and cannot do are the same as the Apache License (and thereby, the MIT License). So again, we’ll just highlight the changes.

You can:

• Same as Apache License 2.0

You cannot:

• Same as Apache License 2.0

You must:

• Same as Apache License 2.0
• Disclose the source (any changes made using MPL’d code must also be made open under the MPL!)
• Include the original (either the source code or instructions to get the original code must be provided)

GNU Public License v3 🔗

The GNU Public License v3, also known as the GPLv3, is one of the most well-known and strict licenses in open-source. It has very specific rules for how the code can be used and shared, and leaves a lot of control over to the author. In a sense, it’s “after” the MPL 2.0, but it also has some key differences. You can read more about it here.

Again, we will highlight the changes from the Mozilla Public License 2.0.

You can:

• Same as Mozilla Public License 2.0 (except sublicensing)

You cannot:

• Same as Mozilla Public License 2.0
• Sublicense the code (this is a big concept worth understanding if you use the GPLv3)

You must:

• Same as Mozilla Public License 2.0
• Include original copyright (must be retained in all copies or modified works)
• Include install instructions (you must document how to install the software)

Go forth and conquer! 🔗

Congratulations! You now know a little bit more about licensing, open-source licenses, and how to use them. Hopefully this will help emphasize why and how licenses are important in open-source software. In many ways, the license you choose to use can even be more important than any lines of code you write. That might sound absurd, but when it comes to deciding how your code can be reused, modified, or distributed, it’s something that can be vitally important to your project.

Those of you without a license, please consider choosing one, or talk to other teammates of your projects about what license you all want to use. If you code in the open, make sure you are protecting yourself and paying attention to how you want other people to use your code.

This blog post is part of an assignment for my Humanitarian Free and Open Source Software Development course at the Rochester Institute of Technology. For this assignment, we are tasked with reading Chapter 3 of Steve Weber’s “The Success of Open Source”. The summary of the reading is found below.

Who 🔗

• Steve Weber, professor at the University of California, Berkeley

What 🔗

• “The Success of Open Source”

Where 🔗

• Excerpt of reading found in the HFOSS ofCourse resources or available for purchase on Amazon

When 🔗

• August 22nd, 2005

The Gist 🔗

You’re in a social setting. Someone says “Hey, did you ever read X?” You quickly respond “Oh heck yeah! X was {awesome,terrible}!” The person next to you in the circle says “Oh snap, I didn’t read X. What was it about…?” You have exactly 3 lines, MAX, to prove you are not a hipster—and “The Gist” is those 3 lines.

Chapter 3 of “What is Open Source?” essentially aims to define what open source development is as a “thing”, describe the process in which it works, the problems it tries to solve, and how it does them. He lightly touches on many core concepts of open source, such as licensing, who is a contributor and what makes someone a contributor in open source, and how the new method of collaboration has positives and negatives—something that reflects human nature.

The Good 🔗

The three best things I took out of this excerpt were:

• The eight general principles of what people do in the open source process (starting on pg. 73)
  • I thought this was a good analysis and breakdown of how things tend to work in open source, and is something I think I will end up referring to even in the future.
• Analyzing Linus Torvalds’ role as the “Benevolent Dictator for Life” in the Linux project and how that is reflective of some open source communities
• How exactly open source licensing tries to build a positive and open social structure beneficial to the user (pg. 85)
  • Licensing is something I’m passionate about in particular with open source, and the author’s words resounded with my own thoughts about licensing. It’s leaving me wanting to develop my own thoughts and opinions on open source licensing further.

The Bad 🔗

My least favorite things from this excerpt were:

• BSD-style licenses are prohibitive to real collaboration (pg. 63)
  • I disagree with this, especially as it seems to have a particular favoring towards the GPL. While I may also represent the opposite bias, I don’t think these licenses necessarily make a project “not vitally collaborative on a very large scale” as the author states.
• Principle #8 of the open source process: “Talk a lot” (pg. 81-82)
  • I agree, talking happens a lot in open source… on hot topic, controversial topics. Usually this happens on the development lists more than other things. But what are “other things”? For larger projects, there are more areas that are important, such as Marketing, Translations / Globalization, on-boarding new contributors, and more. There are not enough people talking in these groups. I think that strictly from a code perspective, topics are many and discussion is much. But on other areas of a project? Unless you have people being paid full-time to work on it, volunteers are far and few in between.
  • I also partly disagree with the vehemence of open source discussion. I do not think we can disagree lists like the Linux Kernel Mailing Lists are not the most friendly of places. But there are projects that have clearly defined codes of conduct and how to behave. In my experience in Fedora, the community was beyond welcoming to me when I began contributing, and I never experienced any of the harshness or close-mindedness that is sometimes associated with open-source development. I think the example the author used then may have been the norm, but over the years, I think others have seen that the harshness is not sustainable and closes the door on adding new, valuable insight from potential contributors, and they try to reflect this in their own projects.
• Lastly, I hope dzho will let me pass on the third “bad” thing for the list, as the above two topics were the only things that distinctly stuck out to me.

The Questions 🔗

Three questions I had after reading the chapter were:

• Eleven years have passed since the book was published. What does the author think of the open source scene in 2016?
• In particular, are open source communities largely as harsh as he originally described or does he feel like a new era is beginning or begun in terms of the inclusiveness of open source projects?
• What made you believe that BSD-style licenses are contradictory to real collaboration in open source?

Your Review 🔗

Imagine you are on Yelp, Amazon, eBay, Netflix, or any other online community that has customer reviews. This is the message that you want to leave behind, to represent yourself, and inform (or warn) others. You should add a quick rating system of your choosing (X/Y stars, X thumbs up) as part of the review.

★ ★ ★ ★ ☆

Overall, I rate this article four out of five stars. I think it did a fairly effective job of analyzing open source in the twenty-first century. While some small sections of the book may have changed in the eleven years since original publication, most of the content is still very much relevant and very much important. I would share this chapter with a friend or another student who was seriously considering getting involved with open source. That goes without saying, I might explicitly add a few extra comments of my own to the small subset of the chapter that I disagreed with.

This past year, I enrolled as a student at the Rochester Institute of Technology in Rochester, NY. For me, this is quite a distance from my hometown just outside of Atlanta, GA. Part of the motivation that led me to choose RIT as my university of choice was its participation in Free and Open Source Software education and communities. RIT is one of the few schools in the United States to offer a minor in Free and Open Source Software.

As part of my time here at RIT, I plan to take on the minor. This semester marks the first milestone of this specific track for me. I am taking the Humanitarian Free and Open Source Software (HFOSS) course, and the first assignment for our class was writing a blog post about getting introduced into the class.

HFOSS: My expectations 🔗

Going into the HFOSS course, I was reluctant because of my inexperience with programming as a whole. The course is definitely strongly focused towards a programming aspect, but it is not strictly dedicated to firing out open source code.

On the contrary, this course is an introduction to “FOSS” as a whole. What is it? What tools are used in open source? How do people communicate and contribute? Why work in the open? These are all questions that the course seems targeted towards answering. In order to answer these questions, many methods will be used, some ancillary to the programming that is necessary for many free and open source projects.

I expect this course to be a challenge because I know that I can’t escape working on a large project or two this semester that will push my abilities and require me to adapt to meet the requirements. I am not as worried about learning the tooling, culture, or common practices that go along with open source because I am moderately familiar with them already. That goes without saying, I am not a master of it all. In the big picture for this class, I feel like I will have a head-start in some areas, while in others I will have to double up to keep up.

HFOSS: What I plan to contribute 🔗

This semester, I’m also hoping to contribute back to the class as well as take something out of it. With some of my experience with open source tooling and understanding of how other projects work, I hope to share my own experiences when and where needed. Additionally, I am paying extra attention for open source communities or projects where I might be able to contribute especially closer to the end of the semester, to fulfill the humanitarian aspect of the course.

By default, the course is targeted towards the One Laptop Per Child (OLPC) program. Towards the end of the semester, the final project is creating a game on the hardware used on these machines with a spin towards 4th grade math curriculum in New York State. Another project I am a contributor of, the Fedora Project, has close ties to the OLPC program and helps develop the desktop environment used on the machines, Sugar on a Stick.

However, there is flexibility about what the final project could be on a per-student basis. Therefore, I am looking out for a particular project that I might feel a personal connection or passion towards where I feel I could help make an impact.

This sets the course and itinerary for the trip… we’ll see where I land as the semester progresses.