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.

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.

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

The blog post I wrote comes from this place in my life. It writes in a voice I would not write in today. It also does not accurately reflect my current perspectives. However, instead of tossing it, I figured to publish it unfinished with this disclaimer would be no different.

Unmodified text: The Integral of a Community 🔗

Many times I’ve sat down to write about the same topic in this same seat. Many times I’ve been filled with the same unique feeling. It’s difficult to put into words. It’s easier to understand it and describe it in my head. But it’s easier to describe it to others when I’m still feeling this feeling. It’s harder to come back to it later and write about it.

This “feeling” is something powerful and organic. I believe it is derived from a core part of what makes us human. In part, it’s a form of social stimulation, but it’s also a little more. The “feeling” is what I’m beginning to term the integral of a community.

integral: (adjective) ˈin(t)əɡrəl,inˈteɡrəl/ - necessary to make a whole complete; essential or fundamental.

From Oxford Dictionaries

What is a community? 🔗

Communities are a fundamental part of our daily lives. We all belong to a community in one form or another. In my view, community is a loosely-defined word that gives rise to many forms. Our immediate family is a community. Our workplaces are a community. Our friends are a community. Our schools are a community. Our homes are a community.

Maybe we feel different about some of the above examples of a community. Your feelings on your familial community may be different from mine. Maybe we feel different about our school communities. But regardless of where you fall, there is a community that you are attached to. Maybe you don’t realize it, maybe you do. But this community holds a special part in your heart. It is, by definition, integral to what makes you, you.

Going forward, it is important to establish your own personal definition of this integral community. Whatever group of people you feel most comfortable with. It doesn’t matter what size. It could be one person or it could be twenty. It could be a hundred. But this community is fundamentally important to you.

What is integral of a community? 🔗

Several different components comprise a different community. They are formed around a range of different topics. Communities can be based around blood ties. Your family. They can be based around a shared interest, like art or technology. You may belong to a community based on your profession, such as a group of educators. Or perhaps you belong to a community full of differences. All of its members come from different backgrounds, professions, races, or anything. Maybe it’s because of close geographical location. Maybe it’s because of a former close geographic location. It depends on the community you identify with.

With such wide difference, it can be curious what makes a community so incredible for you. What components are integral to you? If you break down the outer shell, the answer becomes more clearly visible.

You identify with a community when you share a mutual interest, passion, or engagement with the others in your community.

When you feel most interconnected to your community is when you can feel or understand this most.

< more here >

My community 🔗

My community is the free and open source software community at the Rochester Institute of Technology. There are several individuals who have built this community from the ground up to make it what it is. It has endured its fair share of hardships and challenges. It has celebrated victories and achievements among its members. In the stereotypical application of the phrase, it feels like family.

Our communal responsibility 🔗

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.

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.

On November 7, 2017, members of the RIT community came together for the annual Election Night Hackathon held in the Simone Center for Student Innovation. This year marked the seventh anniversary of a civic tradition with the FOSS@MAGIC community. As local and state election results come in across nine projectors, students and professors work together on civic-focused projects during the night. Dan Schneiderman, the FOSS@MAGIC Community Liaison, compiled lists of open APIs that let participants use public sets of data made available by governments at the federal, state, and local level.

The hackathon officially began at 5:00pm and went until 10:00pm. Plenty of pizza and drinks were provided to fuel participants during the evening.

Open source with open government 🔗

Each year, the hackathon welcomes students and faculty to analyze civic problems happening in the local community, state, or country, and then propose a project to address them. MAGIC Center faculty help students choose open source licenses to share their projects. Organizers encourage students to use a site like GitHub to publish and share their code.

Second Avenue Learning, an educational game company in Rochester, demonstrated their Voter’s Ed app that replays historic elections, keeps voters up-to-date on current ones, and lets them simulate their own using open data and HTML. It also allows users to examine key issues and hot topics related to national level events. The company, represented by the founder Victoria Van Voorhis and two employees (one an RIT alum) held a design discussion for new features to prototype with students and the community. Sean Sutton and Paul Ferber (RIT faculty) provided subject matter expertise to the application.

While people began their projects, coverage of the local and state elections were displayed across nine different projectors. As the night progressed, votes from local and state elections rolled in. Rochester coverage was enhanced, since Monroe County is one of three counties in New York that releases public data for election coverage. Some participants even used the local Henrietta data for their own projects.

LibreCorps internship 🔗

Pratik Shirish Kulkarni, a second-year computer science major from Mumbai, India, presented the current status of his FOSS@MAGIC LibreCorps internship. LibreCorps placed Pratik with UNICEF Innovation in Manhattan, where he worked on MagicBox, a set of big data APIs and technologies used to chart Zika outbreaks and connectivity across schools in Africa.

Pratik demoed some of the work, which he is continuing part-time on campus this semester, funded by UNICEF. Another internship to work on the project is currently posted in Handshake.

Where can I vote? 🔗

Third-year student Chris Bitler created a tool to make it easier to get to the polling booth. His web application, “Where can I vote?”, takes a specific election and your address, and gives you directions from your address to the closest polling location. It uses the Google Civic Information API to find election data and calculate a specific address’s voting district and candidates.

Chris was exploring for project ideas in the beginning of the hackathon, but quickly found the civic data API returned interesting data about polling locations. “After seeing that, I gave some thought to how some people don’t know their polling location and how a simple website could be useful for that,” Chris said. His web application was motivated by simplicity, so anyone could navigate without being lost in information.

In the spirit of open source, Chris open sourced his project on GitHub under the MIT License.

Linkybook: Local election data in real-time 🔗

Another project during the night focused on tracking local election data in Chautauqua, Monroe, and Suffolk Counties. RIT and FOSS@MAGIC alumni Nathaniel Case continued work on his monroe-elections application during the night. The site shows data for all races in the three counties.

During the night, his web application updated in real-time as the results from the local elections began to appear. Election results for the races is quick to understand and read. Additionally, referendum results and other non-partisan elections are available.

Nathaniel open sourced his project on GitHub under both the DBAD and GPLv3 licenses.

Join us next time! 🔗

The night ended after a quick round of project demos and finishing up project work. FOSS@MAGIC has more events planned in the near future. On November 15th, Christine Abernathy from Facebook’s Open Source Program talks about how Facebook approaches open source and how they’ve solved engineering problems with it.

You can learn more about the FOSS@MAGIC initiative on their website. Participation on the mailing list is welcome.

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.

More and more students are learning about the world of open source through video games. Games like FreeCiv let players build empires based on the history of human civilization while games like Minetest emulates Minecraft in an open source block-building sandbox. Students are encouraged to dig deeper into games like this, and projects like SpigotMC empower kids to write plugins to extend their favorite games. However, the tools in open source to build the actual games do not share the same prominence. Rochester Institute of Technology student Matt Guerrette hopes to help change that with his open source gaming engine, Hatchit.

Introducing Hatchit 🔗

Hatchit was a project started between Matt Guerrette and fellow student Arsen Tufankjian together in February 2016. After working with game engines for other classes, they both found challenges over how popular game engines are designed for developers. They noted that these game engines were more design-oriented. It lacked some technical details they were looking for when working on their own personal or academic projects. Together, they had the idea to build their own open source gaming engine with a goal of exposing more of the technical sides of the process to developers. “We want to give you more access to the programming side of the game engine,” Matt explains.

Hatchit is written in C/C++ and licensed in a mix between GPL and LGPL. Originally, the project was started to take advantage of the DirectX APIs for development. However, Guerrette and Tufankjian ran into an unexpected event while they were getting started. Nvidia released the Vulkan APIs in competition to the DirectX APIs. Originally, they had attempted to support both APIs simultaneously, but later opted to focus on Vulkan.

Inspiration for Hatchit 🔗

Guerrette remembers a specific type of task he wanted to accomplish with Hatchit. In the game editor, he wanted to be able to construct a render pass instead of having the engine handle it internally. An earlier project had motivated the need for this feature. By being able to create the render passes in real time, a developer would be able to create something like a custom shader that bends vertices into straight, geometric shapes in real-time. His earlier project, Mineshaft Mayhem, demonstrates this concept with how the mineshaft seems to be warping and turning, but the tunnels are actually straight in the editor.

You can find more videos of Guerrette’s work on his YouTube channel.

What’s happening now 🔗

Since starting the project, Tufankjian graduated and is now working at Amazon Game Design. Over the summer, the community started to show interest in the project. They’ve received a pull request from one member outside of the core developer team and have several issues filed against the different repositories for the engine.

Matt has a few milestones set ahead for the project this year. One of the biggest tasks he is working on is getting the Vulkan renderer multi-threaded design implemented and working. This vastly speeds up the render time when working on projects and is also proving one of the greatest challenges so far. In addition to the multi-threaded design, he hopes to have game objects and components serialized with JSON. This would make it easier for the editor application to modify game data and manipulate configurations with Qt.

Looking at FOSS and Hatchit 🔗

Guerrette is not unfamiliar with open source, but this is his largest undertaking yet with an open source project. While working on the project, using an open source development model has made it easier to receive feedback, work with community contributors outside of the RIT community, and also handle some technical aspects well.

Benefits of working in the open 🔗

Working on the project on GitHub has proved to benefit the project in a variety of ways. One of the most clear ways this helped is having people file issues and raise concerns over parts of the code. In one case, someone filed an issue against an older library that made a mathematical error in its calculations. “Having the world’s eyes on your project to catch errors is a good thing,” Matt said. Guerrette found the freedom to use other open source libraries and dependencies for the engine especially useful. All the licenses were compatible and presented no issue to work with.

Some technical challenges were also made easier with open source tooling. One of the greatest challenges for the Hatchit team was writing the build system to use build system generator software and maintain compatibility with both Windows and Linux. Locally linking dependencies in the project was inconvenient and made the project unnecessarily huge. With git, they used submodules to link dependencies in the repository and build them from source when compiling Hatchit. “Being able to link dependency repositories has been really useful, especially for developing on Windows,” Matt found. Additionally, some of the continuous integration features on GitHub and other services made it easy to quickly test new changes for compatibility.

Challenges of open source 🔗

Along the way, some challenges came by developing in the open that the team worked to resolve. With the convenience of using git submodules also came a difficulty of tracking upstream changes. On occasion, a dependency might break in the project. The team then has to check if the project has updated or changed upstream or if a fix needs to be made locally in their project.

Additionally, community outreach is a challenge Guerrette is hoping to focus on as the new project lead. He shares development updates on his YouTube channel and occasionally will stream his development on livecoding.tv. One thing is working on to make it easier for new contributors to get involved is recommending them to try building the engine from the source code. This gives potential developers experience with compiling the engine and walks them through a variety of documentation available with the project.

Get involved 🔗

The Hatchit team is working further on the game engine and are looking for community participation. To get involved, Guerrette recommends checking out the lHatchit Gitter chat and to review the README file on the main repository. Any contributions are welcome, either in the form of pull requests or filing issues.

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.

How to be hacker 🔗

You may ask yourself, how does one become a hacker? How do you become 1337? The answer might be simpler than you think. Old traditions, cheesy ’90s movies, and the information era.

On April 17th, I joined up with hacker Brendan Whitfield (beWhitty) and wannabe hacker Mike Nolan (nolski) to enjoy in a traditional viewing of 1995’s Hackers. The movie is described as the following.

A young boy is arrested by the U.S. Secret Service for writing a computer virus and is banned from using a computer until his 18th birthday. Years later, he and his new-found friends discover a plot to unleash a dangerous computer virus, but they must use their computer skills to find the evidence while being pursued by the Secret Service and the evil computer genius behind the virus.

Among the students of the FOSS@MAGIC program, the movie is like a cult classic. Within my first semester with the group, I became familiar with many notorious quotes and lines from the movie. Other students, now alumni, also encouraged a viewing.

There was no better time than the present.

Why be hacker 🔗

The cultural influence of the ’90s is clearly present in the movie. When we were viewing it, the movie was clearly written by a writer with as much experience with computers as the actors playing the parts. The stereotypes were laid thicker than molasses with the crossing of the “high school troublemaker” and the “tough punk” to define the hacker “mentality” of the characters. The director probably used a nephew, niece, or other cousin who “sat in front of a computer all day” as the inspiration for driving the characters and plot forward. It would be surprising if anyone who had ever used a computer or knew anything more than just using them for text documents and spreadsheets was involved in the creative process.

So, why bother seeing the movie at all? For all of the reasons mentioned above. Anyone in the technology or a digitally-oriented field would cringe at how the movie portrays the hacker mentality. And that’s why it’s so great. It is hard to imagine a viewing of the movie taken seriously. For our viewing, there were severe outbreaks of laughter and countless moments of cringe-worthy comedic relief, all wrapped up in a good time for a Friday night.

Now we are hackers 🔗

After listening to many references of this movie during the past year and wondering what it meant exactly when “the pool is on the roof”, I have graduated to the status of full hacker along with fellow FOSSboxer nolski.

To demonstrate our understanding of the movie, we had a brief showing of our own in the #rit-foss channel on the freenode IRC network.

[23:00:52] <nolski> jflory7: beWhitty and I have decided that we are dropping out of college and starting a bar themed after the movie hackers
[23:45:26] <nolski> jflory7 and I are now official hackers.
[23:45:39] <nolski> We have experienced the movie Hackers
[23:46:17] <CrashOverride> nolski, beWhitty: Mess with the best
[23:46:20] <CrashOverride> Die like the rest
[23:47:28] <Guest81889> u on my turf CrashOverride?
[23:47:47] <CrashOverride> Guest81889: you are not 1337 enuf
[23:49:56] <Nikon> You're in the butter zone now, baby.
[23:50:11] <ThePlague> Never fear
[23:50:15] <ThePlague> I is here
[23:51:21] <Acid-Burn> Never send a boy to do a woman's job.
[23:51:25] <CrashOverride> I don't play well with others.
[23:52:12] <CrashOverride> Hack the planet! Hack the planet, nolski!
[23:52:23] <nolski> Hack the planet CrashOverride!
[23:52:46] * nolski is finally 1337 enuf
[23:54:50] <nolski> scp god@gibson:/.workspace/.garbage. ~/1337h4x0rsfilez/
[23:54:53] <ThePlague> THEY GOT THE GARBAGE FILE!
[23:55:50] <nolski> beWhitty++
[23:55:56] <nolski> jflory7++
[23:56:02] <nolski> hackers++
[23:56:09] <ThePlague> nolski: Type "cookie", you idiot.
[23:56:17] <nolski> cookie
[23:57:14] <CrashOverride> HACK THE GIBSON
[23:57:16] <CrashOverride> ThePlague--
[00:02:41] <CrashOverride> My crime is that of curiosity. I am a hacker, and this is my manifesto.

I am submitting this blog post as my Meetup #3 for the Humanitarian Free and Open Source Software Development course at the Rochester Institute of Technology. I hope to help spread the hacker culture perpetuated by this film by possibly planning a late night screening of Hackers at the NASA Space Apps Challenge 2016 at RIT, if possible.

BrickHack 2016 and Fedora 🔗

This year, I attended with the Fedora Project team, which included people like Remy DeCausemaker, Mike DePaulo, Charles Profitt, Ralph Bean, and Ryan Scott Brown. In addition to the Fedora crew, many of my friends and fellow students were there, like Mike Nolan and Brendan Whitfield. There were countless others that made the weekend awesome and incredible.

For pictures and more details, read my full report on the Fedora Community Blog.

https://communityblog.fedoraproject.org/brickhack-2016-event-report/

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 “Final Project”.

In this project proposal, we take a look at the game idea we are looking at completing for this project, based on the New York 4th grade math curriculum. Our game idea is based off of a minigame from Logical Journey of the Zoombinis, a puzzle-solving educational game.

Team Members 🔗

Project 🔗

PyCut, a pizza-making puzzle game

Description 🔗

PyCut will be a simple puzzle game to teach children basic units of measurement and guiding them to think creatively to solve a problem. Our game is inspired by the Pizza Pass level of Logical Journey of the Zoombinis (1996). The purpose of the game is to use pizza creation as the activity to teach these skills.

Team Member Roles 🔗

Stephen, Justin, and Wilfried 🔗

All team members will be responsible for contributing to the code via pull requests on GitHub. Testing, refactoring, and refining the code is also everyone’s responsibility.

We are currently working on the details of which team members are responsible for the specific aspects of our project. We will have a better idea of this after completing the development plan later this week.

Source Code Repository URL 🔗

jflory7/PyCut

Communication Methods 🔗

The following methods of communication are ordered in the most preferred way to the least. These are the tools we will use internally while working on the project.

1. Our Slack team (IGME582)
2. Issue tracker on GitHub
3. In-person communication for when we meet up as a team (FOSShours have been designated for in-person collaboration)

What are the easy parts? 🔗

• Project seems pretty easily scoped. We have a curriculum to work with and we have inspiration from the original Zoombinis minigame.
• We have a lot of resources to reach out to for help when needed. #rit-foss on freenode, past developers for the HFOSS project, and more.
• Two experienced Python developers (Wilfried, Stephen), two members familiar with open source project collaboration (Justin, Wilfried) on the team.
• We have multiple previous projects to use as examples (see: FOSSRIT).

What are the hard parts? 🔗

• None of us ever created a game for Sugar on a Stick before. We aren’t sure of the scope of this task, so it will be difficult to estimate a time frame for completion.
• Ensuring that our activity meets the learning objectives of 4th graders. As college students, it may be very easy for us to assume that some elements of the game are easy, but may actually be difficult for 4th grade students. Keeping it within that scope will be a challenge.

How will you overcome both? 🔗

• Communication and setting milestones
  • We are confident that we can pace out our project effectively and get it done on time.
• Past resources and inspiration
  • Again, we have countless resources to refer to and get help from. As we run into problems, we have plenty of options for resolving them.

A. Describe software project, its purpose and goals. 🔗

Tahrir is a project that allows its users to create their own Open Badges – graphical icons that show that a user has attended a particular event, completed a specific challenge, or any number of other accomplishments.

B. Give brief history of the project. When was the Initial Commit? The latest commit? 🔗

The Mozilla OpenBadges project’s wiki page was created in November of 2010, mentioning a few other projects that used a badge system and encouraging people to contribute to that project. Once Mozilla’s OpenBadges project was established, Fedora Infrastructure team member and Red Hat employee Ralph Bean created the first commit for the Tahrir project in April of 2012. Since then, twenty-two contributors have worked on the project, with commits as recently as March 2nd, 2016.

C. Who approves patches? How many people? 🔗

There did not seem to be an established, formal process for who has the privileges or authority to approve patches, but based on the most recent pull requests, the following users have been actively responsible in the past year for approving patches.

• Chaoyi Zha (cydrobolt)
• Ralph Bean (ralphbean)
• Patrick Uiterwijk (puiterwijk)
• Trishna Guha (trishnaguha)
• Remy DeCausemaker (decause)
• Pierre-Yves Chibon (pypingou)

D. Who has commit access, or has had patches accepted? How many total? 🔗

Based on total contributions, Ralph Bean and former contributor David Gay (oddshocks) made more contributions to the project than any other users. However, the list of users listed above (being able to approve patches) also seem to have commit access as well. From the outside, it is difficult to determine user permissions, but the contextual evidence provided from issues and pull requests seems to support this conclusion.

In total, the project has had twenty-two contributors.

E. Who has the highest amounts of “Unique Knowledge?” 🔗

Based on the diversity of commits and git_by_a_bus results (at the bottom of this post), Ralph Bean appears to have the highest amounts of unique knowledge for Tahrir.

F. What is your project’s “Calloway Coefficient of Fail?” 🔗

Your source is configured by editing flat text config files. +20

Score: 20 points of fail

G. Has there been any turnover in the Core Team? 🔗

Has the same top 20% of contributors stayed the same over time? If not, how has it changed? 🔗

In the first two years of the project, David Gay (oddshocks) had a greater number of lines of code contributed to the project, and had some huge activity spikes in July of 2013. Since then, Bean and Uiterwijk have taken up a lot more of the work, and Gay hasn’t contributed since October of 2014.

Overall, Bean has been the greatest (and most consistent) contributor to the project.

H. Does the project have a BDFL, or Lead Developer? 🔗

Bean would be the closest thing to that. He guides the development of the project. After the project stabilized and all the core functionality was implemented, any further contributions seem to be minor bug fixes for the overall QOL of the project.

As a team, we could not necessarily speak to Bean’s role as a BDFL during the development process, especially without any chat logs from relevant IRC channels or email lists.

At the project’s current state, he seems to be keeping the project going along in a healthy direction and fixing the minor bugs that come up as they’re reported or patched.

I. Are the front- and back-end developers the same people? What is the proportion of each? 🔗

Tahrir is created under the GitHub organization of the Fedora Infrastructure team. As a result, even though there is a core group of developers working on Tahrir, it wouldn’t be an invalid assumption to say someone else in Fedora Infrastructure could take the code, change it for something that arose in production, and deploy it back into production.

As a result of the “DevOps” sort of relationship between the Fedora Infrastructure team and most of the projects on their GitHub, it is difficult to draw a firm conclusion about which developers work on the front end and which developers work on the back end. The unique circumstances of being an “open source project inside of an open source project” skews the answer to this question.

J. What have been some of the major bugs, problems, and/or issues that have arisen during development? Who is responsible for quality control and bug repair? 🔗

To categorize the issues reported against during Tahrir’s lifetime, we categorized the issues into three categories: Concerning (15 or more comments on issues), Eyebrow raising (10 - 14 comments on issues), and Intriguing (5- 9 comments on issues). These three categories are intended to be representative of the issues that caused the most conversation and interest by many developers or other members of the community.

Concerning 🔗

• #152: Tried to get undefined file at undefined and got an HTTP undefined (18 comments)
• #168: Link to 3d-printer spec files (22 comments; you can 3D print badges… whoa!)

Eyebrow Raising 🔗

• #117: Match_all not working on tags view just yet. (12 comments)
• #141: Emit a fedmsg when a new leader is crowned! (11 comments)
• #244 : Stuck on a white page after OpenID login (11 comments)

Intriguing 🔗

• #21: Admin view not properly escaped (8 comments)
• #69: Render badge descriptions from .rst to html (6 comments)
• #70: Fix error code images (5 comments)
• #101: Fallback avatar looks bad on user view (too small). (5 comments)
• #108: Export badges is broken in staging (9 comments)
• #112: Implement opt-out mechanism (7 comments)
• #176: Ask badges relate to username, but that’s not working (5 comments)
• #319: Libravatar badge not being awarded (5 comments)
• #339: Represented Fedora at event not awarded (5 comments)

Quality Control 🔗

Looking through the 145 closed pull requests, it’s clear to see that once again, Bean is leading the quality control and testing on Tahrir pull requests. There are a few pull requests where Uiterwijk and Chibon either submit code and the other one reviews and approves it. In these edge cases, it seems to be the contributions of more experienced members of the Infrastructure submitting code and getting another experienced member to check the submitted code.

For new contributors or contributions from non-consistent contributors, Bean seems the be the defacto “King of PRs” for Tahrir.

K. How is the project’s participation trending and why? 🔗

Based on activity graphs of the lifetime of the project, the most participation and development of Tahrir occurred in the summer months of 2012 and 2013. This can likely be attributed that the heaviest development work was happening in these time periods while Tahrir was being built and shaped into what it is.

Once a stable point was reached and most issues were resolved, development greatly slowed, likely because the developers moved  on to new projects, while a subset of the original core developers remained active as maintainers after the stable point was reached.

L. In your opinion, does the project pass “The Raptor Test?” Why or why not? 🔗

Would the project survive if the BDFL, or most active contributor were eaten by a Velociraptor? 🔗

For the purposes of this question, we will assume Bean is the lead contributor at the current point in the project’s life cycle.

If he were eaten by a velociraptor, the project would still be able to survive even in his absence. Since the core development work has already been accomplished and the main development work now is resolving issues and maintaining the existing codebase (as compared to writing new features), it’s safe to assume there are others in the Fedora Infrastructure team who would be able to keep up this project and make sure its longevity is guaranteed (although I am sure that the Infrastructure team would suffer a great loss without the wisdom and mad wizardry that Bean provides).

The fact that Tahrir is “nested” inside of another open source project (Fedora) likely attributes to the likelihood that Tahrir would survive the sudden absence of its most active developer.

M. In your opinion, would the project survive if the core team, or most active 20% of contributors, were hit by a bus? Why or why not? 🔗

This question is more difficult to answer than the previous question because of the relationship the top 20% of the contributors have to Tahrir, Fedora, and other open source projects. The top 20% of contributors mostly consist of the core Fedora Infrastructure team members, who are also responsible for working on other projects within Fedora, maintaining the servers and services that power the infrastructure, and working on apps such as Tahrir.

In the event that the top 20% of Tahrir’s contributors were all hit by a bus, it’s difficult to know if Tahrir would be able to sustain. Because of the work the core developer circle does throughout the Fedora Project, it would be very difficult for others to pick up the cumulative amount of work that is shared among the Infrastructure team now. The documentation and stability of the code would be useful attributes for the prospect of someone new picking up maintaining the code, but in a broader view, the amount of work that would need to be picked up across the board creates new issues within itself.

For these reasons, if the top 20% of contributors to Tahrir were to disappear, it’s difficult to forecast the future of Tahrir (and other projects managed by the Fedora Infrastructure team).

N. Does the project have an official “on-boarding” process in place? 🔗

Can include new contributor guides, quick starts, communication leads who focus specifically on newbies, etc… 🔗

While there is no on-boarding process in place specific to Tahrir, there is a process for the Fedora Infrastructure team, which would in turn lend itself to Tahrir. Some of the advice given includes how to be a successful contributor and introducing yourself on their mailing list.

O. Does the project have documentation available? Is it extensive? Does it include code examples? 🔗

The project does have documentation in the README file for installing, running, and developing on Tahrir, but they are not an extensive set of “documents” or wiki pages that explain the entire process. The guide does seem to assume the person reading the documentation is capable enough to run a few commands in a command line or install Python dependencies with tools like pip.

For anyone who knows anything about Python, this documentation will be plenty, but if you are a new developer looking at getting started for the first time, you may have a learning curve with figuring out what all the commands you are instructed to do actually do on yourself.

There do not seem to be code examples for Tahrir (if there are, their presence is not clearly stated).

P. If you were going to contribute to this project, but ran into trouble or hit blockers, who would you contact, and how? 🔗

If we wanted to contribute to Tahrir, it seems like the best points of contact are either the #fedora-apps channel on Freenode or the Infrastructure mailing list. IRC appears to be the preferential way of getting help.

Q. Based on these answers, how would you describe the decision making structure / process of this group? 🔗

Is it hierarchical, consensus building, ruled by a small group, barely contained chaos, or ruled by a single or pair of individuals? 🔗

In the current state of the group, decision making seems to favor the lazy consensus sort of voting; that is, if there are no objections or negative feedback on a feature addition or a bug fix, it is assumed there is not an issue and development presses forward. However, there seems to be an informal, undocumented precedent that every contributor must get their code signed off by at least one other member of the Fedora Infrastructure team (even if the contributor is an experienced, active member of the Infrastructure team).

In short, the development and community architecture of Tahrir seems to be greatly left to Bean and the rest of the Fedora Infrastructure team. In the event of new ideas or “topics worth discussion”, usually there is activity either in IRC or on the mailing list before heavy development goes forward.

R. Is this the kind of structure you would enjoy working in? Why, or why not? 🔗

The system that the Fedora Infrastructure team appears to follow seems to be documented and regimented, so getting involved isn’t difficult and the community appears supportive of new developers. For me, I believe the community architecture surrounding the Tahrir project is a friendly and welcoming environment for any level of contributor of open source to get involved with and hack on a cool project.

Community Architecture: Git by a Bus Summary Results 🔗

Note: values smaller than 10 have been truncated in the interest of space.

Note: the scale of the bars is relative only within, not across, tables.

Top 100 Projects by highest estimated unique knowledge 🔗

Top 100 Projects by highest estimated shared knowledge (devs still present) 🔗

Top 100 Projects by highest estimated risk 🔗

Top 100 Devs by highest estimated unique knowledge 🔗

Top 100 Devs by highest estimated shared knowledge (devs still present) 🔗

Top 100 Devs by highest estimated risk 🔗

Top 100 Files by highest estimated unique knowledge 🔗

Top 100 Files by highest estimated shared knowledge (devs still present) 🔗

Top 100 Files by highest estimated risk 🔗

Community Architecture: Git by a Lion Pie Chart Results 🔗

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

Opening the doors for WiCHacks 🔗

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

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

WiCHacks begins 🔗

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

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

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

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

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

Accidentally discovering something awesome 🔗

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

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

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

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

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

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

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

Closing out WiCHacks 2016

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

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

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

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

WiCHacks 2016: In retrospect 🔗

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

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

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

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

For the next homework assignment in my Humanitarian Free and Open Source Software Development (HFOSS) course, we were tasked with running a smoke test of the XO laptops we are assigned for class. Some of the laptops are notoriously more broken than others. Seeing as how some of these date to around ten years ago, it’s easy to understand how they have been become more defunct over the years.

Part of my assignment was to run some basic tests and practices on my XO laptop to make sure it would be capable for most core functionalities. This article will serve as my step-by-step smoke test report on my XO laptop, which I have affectionately named Hedron.

Beginning the smoke test: Start up 🔗

The first part of the one hour smoke test guide is to make sure the laptop starts up as expected and functions correctly while starting up. This part of the smoke test took the shortest amount of time.

• Does the XO start up? Yes
• Do the power LED and backlight work? Yes
• Does the activity ring show after booting? Yes
• Does it automatically connect to a known WiFi network? Yes

In short, the bare minimum requirement (i.e. “does it work?”) was met.

Running activities in the smoke test 🔗

For the most part, every activity I ran had the expected behavior that the smoke test walk-through gave. Since there were more things working than there was not, I have a short list of the things that weren’t working below.

• eToys Activity: Not installed
• Read Activity:
  • Cannot scroll through PDFs (scroll bar non-responsive)
  • Cannot close and open a new document
  • Terminal Activity doesn’t parse anywhere near readable
• TurtleArt Activity: Not installed
• Wikipedia Activity: Cannot search for articles

Transfer files to USB 🔗

Transferring files between the XO and a USB drive worked well. However, I didn’t actually do this from the SoaS interface, but I switched over to the GNOME2 environment to accomplish this. Perhaps this was cheating, but it was the most effective way to easily move media between flash media and the XO.

My use case was trying to put a yum-utils RPM file on the machine. Oddly enough, the XO doesn’t come with yum-utils prepackaged, which makes it difficult to navigate when it comes to updating the XOs to new repository locations.

Smoke Test Collaboration 🔗

On Friday, a group of us met in the Simone Center lobby to work on testing some of the group activities on the XOs. We hit three different activities, and the process we used is documented below.

To begin, we all connected to the same WiFi network (rit) since the WPA2 Enterprise network on RIT’s campus didn’t play nicely with some of the XOs. There were four of us, so we split into pairs to try the activities since they didn’t work well with more than one other person.

The four of us that met were:

• Stephen
• Wilfried
• Bobby

Chat 🔗

We were able to successfully open a chat room and talk with each other on our local connection. There were a few inconsistencies like messages being delivered late and other minor mishaps, but overall, the functionality behaved as expected.

Distance 🔗

Wilfried and Stephen were able to successfully get the Distance activity to work between their XOs. However, Bobby and I were unable to get them to initiate with each other in the time that we were working on this. We weren’t sure if this was a network hiccup or an actual deficiency on the XO.

Write 🔗

We were able to use the Write activity to write in the same notepad as another user. Despite being slow and lackadaisical, it did actually work as expected.

Suspension 🔗

The final test I ran on the XO was shutting the laptop and seeing if it would resume from its former point when I reopened the XO. It was able to do this as expected.

In short, I think I lucked out and received one of the most functional devices in the class. After comparing the class inventory to mine, it seems like Hedron the XO is in pretty good shape.

Step 1: Identifying the bugfix 🔗

møte 🔗

When I started this homework assignment, there was originally one project I had in mind. As a non-code contributor to the Fedora Project, I frequently interact with Fedora’s own implementation of Meetbot. Meetbot is an IRC bot that adds meeting functionality to IRC channels. It makes it easy to highlight important info and summarize the meeting into a tidy HTML summary afterwards.

Fedora has a custom front-end for the Meetbot bot. This project is called møte and is developed by Fedora contributors Chaoyi Zha, Ralph Bean, and many others. One of its features is clustering Fedora sub-projects into teams and sorting their meetings together with JSON mappings.

Some Fedora sub-projects do not have their alias or meeting names set in these JSON files, making it difficult for their own team members or the general public from finding the records of their meetings. This inadvertently reduces transparency. Seeing as Fedora is an open project not only in code, but also in action, it made sense to try to clarify these mappings in a better way.

FOSSProfiles 🔗

More recently than møte, I am working with Prof. Stephen Jacobs this semester with FOSS@MAGIC. I am on an independent study on Open Source Journalism to help assist with marketing and growing additional exposure for the program. The website for the program is dated in its current form, and one of the goals this semester is to get it rewritten with a more modern, up-to-date layout and information.

One thing we want to have on the site is profiles of our students, alumni, mentors, and faculty. A Jinja-powered HTML generator for student profiles was made over a year ago, titled FOSSProfiles. In this project, students add their information to the repo in the form of YAML files. A user runs a Python script, and the program generates a raw HTML template with all of the students’ information in the repository. Wow! Useful.

When I went to try running it, I immediately ran into an issue and the program spat out a stacktrace at me. After troubleshooting the program and reading logs, I found two issues:

1. Student biography lines could not be over 140 characters
2. Python script did not support Python3

Step 2: Doing the bugfix 🔗

møte 🔗

My commits ranged throughout the month of January and I tried to accomplish a number of things. Before I cloned the repo and started making changes, I crawled around møte for a while to find any teams or meetings that may not have been added.

Thanks to the power of fedmsg, I was able to make a week of observations about teams that were frequently meeting in Fedora. As I observed for a week about what teams were active or inactive, I made bookmarks to their meeting pages to revisit later on.

After comparing the teams that were present in møte to the meetings I observed in a week, I began adding aliases and mappings for the teams that were lacking in the name_mappings.json file. I also added a new category to the category_mappings.json file for the Fedora Community Operations team (where I spend a lot of my own time in Fedora).

The Fedora teams I helped identify and add to møte are as follows.

• CommOps
• EMEA (Europe, Middle East, Africa) Ambassadors
• Fedora Council (formerly known as Fedora Board)
• LATAM (Latin America) Ambassadors
• Fedora Magazine editorial board meetings

During my time of my bugfix, I made 13 commits to the repository. I’m not planning to stop there, either – there’s a few more teams I hope to try adding to møte in the near future, like the Fedora Workstation, Server, and Cloud special interest groups.

Also in the process of contributing, I discovered a handful of problems and reported them in the issue tracker (see: #75 and #83).

You can see my bugfix changes live in møte here! Thanks Chaoyi for helping mentor me along in contributing.

FOSSProfiles 🔗

140 char maximum 🔗

My first step with this bugfix was in troubleshooting the stacktrace I was given running the program in Python2. The stacktrace confirmed the error was that a profile biography was over 140 characters long, and I began sorting through all existing profiles to find any that were over the limit. After a little bit of searching, I found that wilfriedE.yaml was the one over the 140 character limit. This was an easy correction and after making changes, I was able to run the program with Python2.

Python3 support 🔗

Lastly, I wanted to add support for Python3 to this program so it would run in a modern and current workstation. This in particular required a lot of research for me to look into as I had never programmed in Python before.

My first problem with running the script in Python3 was an ImportError for a specific module, ifilter. After searching for an answer, I found an easy fix. It was supported by default in Python3! To fix this error was as simple as removing the line.

Secondly, after fixing the ImportError, I found a certain string was required to be encoded as UTF-8 before Python3 was able to handle it. After looking up the encode() method and figuring out how it worked, I simply encoded the string to UTF-8. That wasn’t so bad…

Step 3: Post-bugfix analysis 🔗

For me, the most fun part was the optional part of the assignment to the end. As part of the assignment, we could add our projects to OpenHub. OpenHub is an aggregator of open source projects that makes it easy to discover, track, and compare open source projects across the web.

I added a project page for møte and FOSSProfiles and claimed my contributions as a contributor.

I’m also playing around with other projects in OpenHub… you can find my profile here.

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.