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

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

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

The Hardest Goodbyes 🔗

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

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

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

Finding “Home” Across an Ocean 🔗

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

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

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

The Weight of Context Switching 🔗

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

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

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

The Anchor and The Code 🔗

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

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

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

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

My creative engineering spark is still very much alive.

Taking it One Day at a Time 🔗

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

(One more yak shaved.)

This post is also an experiment in using AI generated summaries to provide useful, at-a-glance summaries of key Fedora topics. Parts of this content may display inaccurate info, including about people, so double-check with the source material.

Source material: discussion.fedoraproject.org/t/report-from-infra-and-releng-hackfest-at-flock2024/128743

Key Topics 🔗

• Standards for OpenShift app deployments: There’s a need for consistency in deploying applications to OpenShift. The group discussed creating best practices documentation and addressing deployment methods across various applications.

• Infra SIG packages: The workshop reviewed the “infra-sig” package group and identified a need to:

  • Find owners for orphaned packages.

  • Onboard new maintainers using Packit.

  • Remove inactive members from the group.

• Release engineering packages: The group agreed to add a list of release engineering packages to the infra-sig for better management.

• Proxy network: Discussion about potentially migrating the proxy network from httpd to nginx or gunicorn remained inconclusive. Further discussion is needed.

• AWS management with Ansible: The feasibility of managing AWS infrastructure with Ansible is uncertain due to limitations with the main Amazon account.

• Onboarding improvements: The group discussed ways to improve the onboarding process for new contributors, including documentation updates, marketing efforts, and “Hello” days after each release.

• OpenShift apps deployment info: A tutorial on deploying applications to OpenShift was presented and will be incorporated into the documentation.

• Future considerations: The group discussed upcoming challenges like GitLab Forge migration, Bugzilla migration, and a new Matrix server.

• Retiring wiki pages: The group needs to decide where to migrate user-facing documentation from the wiki. Additionally, someone needs to review and archive/migrate/delete existing wiki pages in the “Category:Infrastructure” section.

• Datagrepper access for CommOps: A solution was proposed to provide CommOps with access to community metrics data by setting up a separate database in AWS RDS and populating it with recent Datagrepper dumps.

• ARA in infrastructure: While AWX deployment offers similar reporting features, setting up ARA remains an option if someone has the time and interest.

• AWX deployment: Roadblocks related to the public/private Ansible repository structure were identified. A proof of concept using AWX will be pursued to determine if repository restructuring is necessary.

• Zabbix integration: The group discussed moving forward with Zabbix to replace Nagios. Action items include setting up a bot channel for alerts, adjusting alerts based on comparison with Nagios, and considering an upgrade to the next LTS version.

Action Items 🔗

• Create comments in each application playbook explaining its deployment method.

• Move all apps using deploymentconfig to deployment with OpenShift 4.16.

• Look into deploying Advanced Cluster Security (ACS) for improved visibility into container images.

• Create a “best practices” guide for deploying applications in OpenShift clusters.

• Find individuals interested in helping with orphaned packages and onboarding new maintainers for the infra-sig package group.

• Create a list of release engineering packages for inclusion in the infra-sig.

• Continue discussions on migrating the proxy network and managing AWS infrastructure with Ansible.

• Update onboarding documentation, implement marketing strategies for attracting contributors, and organize “Hello” days for new members.

• Archive/migrate/delete wiki pages in the “Category:Infrastructure” section.

• Work on tickets to set up a separate database for CommOps Datagrepper access.

• Investigate the feasibility of setting up ARA in infrastructure.

• Stand up a proof of concept for AWX deployment and discuss potential repository restructuring.

• Set up a Zabbix bot channel for alerts, adjust alerts based on comparisons with Nagios, and consider upgrading to the next LTS version.

Overall, the workshop was a success, with productive discussions and a clear list of action items to move forward.

Note: The workshop lacked remote participation due to network limitations. The source material encourages readers to express interest in helping with the action items.

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

But breaking records is not what this letter is about.

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

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

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

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

Freedom, Friends, Features, First!

— Justin

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

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

About Outreachy 🔗

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

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

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

Pre-Requisite Tasks: Raising the Outreachy bar 🔗

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

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

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

2. Set up a personal blog

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

4. Promote your intro blog post on social media

5. Write an onboarding guide for Outreachy 2025 applicants

How were initial contributions personalized? 🔗

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

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

Portfolio-driven submissions for Outreachy 🔗

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

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

How did a portfolio help? 🔗

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

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

Our philosophy: You win, we win. 🔗

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

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

myself

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

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

1. Get real experience in a real project.

2. Build their own brand as open source contributors.

3. Gain confidence at collaborating in a community.

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

Share your Outreachy mentoring experience! 🔗

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

The media report this season is warmer,
The scientists discover the planet is hotter,
While glaciers slide into the sea.

It is the birth of spring,
After a dark, lonely winter,
Yet the warmth is not warming.

In this moment,
The spring in March comes like the summer in May,
Leaving this July to the imagination.

A shiver of emotions,
Ripples from my brain down my spine,
As I wonder of the future.

But as I drive forward with bright blue skies overhead,
The world erupting in the color and life of an early spring,
My worried mind is suddenly soothed.

Yes,
The world is warmer, the planet is hotter,
And there is so much that we must all do.

Yet in this moment, I feel a peace,
Surrounded in the fragrance of spring flowers,
As the warm sun gently caresses my face.

Joy is an ingredient for enlightened action,
It fills my goblet full of passion and zest,
And suggests to me my true motivations.

In this moment, I am here,
One with the breath of the wind,
Dissolved into the colors of the spring afternoon.

In this moment, I am here,
And I am reminded,
To never let despair rob me of my joy.

Photo by Julian Hochgesang on Unsplash. Modified by Justin Wheeler. CC BY-SA 4.0.

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

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

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

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

about adopting a theme 🔗

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

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

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

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

storytelling is my theme 🔗

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

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

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

building my storytelling habit back 🔗

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

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

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

Happy New Year, reader.

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

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

So, here goes.

Me? Not represented? 🔗

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

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

Noticing the white narrative. 🔗

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

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

The paradox of the white narrative 🔗

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

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

No savior complexes. 🔗

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

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

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

Dr. Martin Luther King Jr.

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

Where do we go from here? 🔗

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

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

Photo by Rishabh Dharmani on Unsplash. Modified by Justin Wheeler.

Ctrl+Alt+Delete, wired and tied,
My threaded process: splintering and fragmenting.

Ctrl+Z, nostalgic and longing,
The memory buffer: flooded and overloaded.

Ctrl+F, buried and lost,
The information needed: but information never found.

Ctrl+N, weary and tired,
A new page and new chapter: for a new time.

Ctrl+X, selective and wise,
My mental clipboard: freed from excessive context.

The control we have, digitally finite,
Within our fingertips, but limited to our bandwidth.

The promised digital frontier, hopeful yet anguished,
Two sides of a coin, but can there be a third side?

Life within a binary is never so rich,
The answer we seek is simply the answer we find.

Motherboard, hard drive; CPU, RAM,
Infrastructure built, realities shaped.

Remove one part, replace another,
Expansion upgrades, faulty hardware replacements.

Our modern digitalism is a mirror of our constructions,
No utopia or dystopia; just a reflection peering back at us.

The question falls to you, whether to plug in or disconnect,
Whether to accept a life with both hotspots and no-signal zones.

systemctl stop NetworkManager

Breathe.

systemctl start NetworkManager

Photo by Steve Johnson on Unsplash. Modified by Justin Wheeler. CC BY-SA 4.0.

These words speak power. Their power comes in their ability to pull someone out from the busy stream of life and reach deep into their heart. As if to be plucked out of the chaos, even for just a moment. They are words that are easy to read, easy to write. But to say them with meaning, to deliver them with sincerity to another human being… it is something that many of us would struggle with. (Perhaps the bias may be toward men who typically aren’t steered by the society towards navigating these emotional waters.)

Making of the shells 🔗

It amuses and perplexes me how something that can be so positively powerful can feel out of reach for many of us. Throughout our relatively short time on this planet, it is easy (and sometimes necessary) to create a shell around ourselves. A big, hard, strong shell that protects us from the hurt, the pain, and the sadness that sometimes bubbles and oozes out from the earth. Fear of our neighbors becomes an insecurity that is targeted and exploited by the political powers of our day.

So of course, the world can feel cold. Or even dead. But those shells that we carry and build over our life can also be cold and hard themselves. When we are surrounded by coldness and hardness, it is naturally difficult to expect that compassion to flow like a river out from the world. The shells cover over our hearts with coldness and hardness, so if enough time passes inside the shell, we might conclude that the world is a cold and hard place.

Leaving the shells 🔗

But the only mistake in our human existence is to never leave the shell. Sometimes it is necessary and sometimes it is required. There are awful things that ooze out of the cracks of our fragile yet interdependent society. But if we make the shell our home, we sacrifice the warmth of the sun. We refuse the possibility of the beauty, the love, and compassion that also exists in our planet. We can find beauty in the smallest of things and most unusual of places. But if we are stuck in the shell, we are hidden from what is uncomfortable and difficult, but also what is joyful and empowering.

May we all come to know our shell, and also to know when we are in our shell. If we stay in it too long, we might forget what it is to take it off. What it feels like to feel joy. What it feels like to feel love. To accept love and give love. The most powerful, transformative, and awe-inspiring experiences on this planet called Earth will pass over us if we allow our hearts to harden.

Choose to love, not to hate.

Choose to trust, not to fear.

Always forgive, but never forget.

Follow the joyous path of light, and avoid the cynical path of darkness.

Know when to wear our shell for necessary protection, and know when to take it off for being vulnerable and human.

Breathe.

Background context 🔗

This reflection came after a bike ride. The rides are typically my most reflective time. There are no screens, no notifications, no distractions. It is me. The path. And my breath. After a week when I was feeling overwhelmed and stressed, this reflection came from a meditative mood and my desire to use my blog as a place to express myself better. (I think writing this post was more therapeutic than the tweet I was originally writing.)

A special thanks to Thich Nhat Hahn and this El Ten Eleven track for guiding my thoughts while writing:

While I was pondering this reflection, my employer announced layoffs a couple weeks ago. While there is a lot that could be said about that, what I will say is that a certain root was pulled; the foundation of trust built between leadership and employee was shaken. Only further action and time will show the full impact on the company and my remaining colleagues. Nonetheless, a very recent negative experience with regard to trust also expanded my perspective of how trust is defined and what its role is in a community.

Brené Brown on trust 🔗

Later, I came across a sound bite of an interview with Brené Brown about trust (and more). Toward the end of the interview, she talks about her book, Braving the Wilderness (which I haven’t read, but seems interesting). She explained what the wilderness is and a tool that we can keep with us (“BRAVING”) to stay grounded in ourselves and also what trust means.

She also had a powerful definition of belonging, which put forward the idea that belonging is internal to ourselves and even is a spiritual practice; belonging is not defined externally or given to and taken from us by others.

Below is my summary of “BRAVING” and the wilderness, together with notes and thoughts about how community leaders can act honestly and authentically, both when times are good and when times are hard.

Trust: Remember “BRAVING” 🔗

There are seven elements to building, developing, and measuring trust. Each of these seven elements are a resource for being honest, authentic, and genuine in both easy and hard times. You can remember these seven elements as an acronym: “BRAVING”.

B: Boundaries 🔗

You set boundaries. When you don’t know what they are, you ask. You are clear about what is okay and what is not.

R: Reliability 🔗

You do what you say and you say what you do. The hard thing is that you are not hustling for worthiness, so you are not completely over committing and not delivering.

A: Accountability 🔗

You don’t back channel and blame. You hold people accountable in a straightforward way.

V: “Vault” 🔗

You do not use stories that are not yours as social currency. You keep them in “the vault.” Using others’ stories as a bid for connection causes others to trust you less. This is the other side of confidentiality.

I: Integrity 🔗

You choose courage over comfort and practice your values. You choose what is right over what is fun, fast, and easy. Your accomplishments stand out when you operate from a place of discomfort, or outside of your comfort zone.

N: Non-judgment 🔗

You can ask for help without feeling judged. I can ask for help without judging myself.

G: Generosity 🔗

When something happens, you assume positive intent. Give someone a chance, or the benefit of the doubt, before launching into anger.

Braving the wilderness 🔗

What is the wilderness? It is those times when we stand alone, the times when we go out on a limb, the times we walk away from what we know in our ideological bunkers and beliefs.

“BRAVING” is a tool to help us manage the wilderness. There will be times when standing alone feels too hard, too scary, and we’ll doubt our ability to make our way through the uncertainty. Someone, somewhere, will say, “Don’t do it. You don’t have what it takes to survive the wilderness.” This is when you reach deep into your wild heart and remind yourself, “I am the wilderness.”

Photo by Artem Sapegin on Unsplash. Modified by Justin Wheeler.

This thought emerged to me, as I stood under the warm stream of water in the same shower I had used countless times over the last ten years. Over those previous ten years, so much of my life has changed. The biggest change is that my life was my own now. I have the power to make decisions with regard to my life. I also have the resources and means to act on those decisions. So, now I have more direct influence over the everyday things around me; there is no parent or guardian to delegate decision-making. As I chart my own path and mark my course, I realize that there were two separate paths I was walking on all this time.

Those two separate paths were my personal life and my career. I walked both paths, but both paths were distinctly separate and isolated from the other. There are brief moments where the two paths intersect. Generally, though, I found that my lives at home and work are two different planes of existence. So, a question remained placed neatly in my mind for a number of years. Should these two paths be unified into one or should they remain separate?

Thus… the middle path. 🔗

The shower thought suggested the two paths did not have to either join or split. Instead, I could pursue a middle path where I live genuinely and authentically to myself, without splitting myself into two alternate egos. The middle path allows me to keep one foot in my personal life and one foot in my professional life. The middle path allows me to be the same self in the one life that I live.

It is a beautiful reflection, although it is much easier to conceptualize than to act upon. Or easier said than done! For so long, I segmented my life at home and life at work into two boxes. Now, in order to find the middle path, I have some work to do. I have to first unpack the boxes of my mind, reorganize and reorient, and then repack into one, bigger box.

My challenge for the next decade of life is to find the balance between these two worlds. I continue to sail further into my adult years and farther from my child years. So, the continuity of separation must end. Now, I hope to direct my life in such a way that I find the middle path and live harmoniously with family, friends, and my hobbies while also being passionate and committed to my work and craft. When aptly balanced, this leaves room for spiritual growth. It allows me to lead my life toward positive change to achieve a more just, more humane world.

Om mani padme hum!

Photo by Luke van Zyl on Unsplash. Modified by Justin Wheeler.

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

Highlights from Proton product roadmaps 🔗

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

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

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

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

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

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

Proton Mail & Proton Calendar 🔗

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

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

Proton VPN 🔗

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

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

Proton Drive 🔗

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

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

proton.me/blog/proton-drive-roadmap

Photo by Slidebean on Unsplash. Modified by Justin Wheeler.

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

Survey says: What? 🔗

At some point, after we opened the survey, a question emerged about how to handle an unruly response. In the ongoing responses, our data manager noticed one response that was objectively harmful. The person was strongly against the D.E.I. initiative that organized the survey. The response was written in a hostile tone, made insulting and derogatory comments about groups of people, and was entirely opposed to the project spending any time and resources on diversity, equity, and inclusion. The question asked to our group was whether we would include this response in the published data, or whether we would omit it.

There were two perspectives. Some elected to remove this response from the final report and any published data. Others felt it was important to wait and see if this response would become a pattern as we ran the survey. I found myself in the second group that felt it was important to wait and see first. I want to unpack this rationale, both for future me and perhaps someone else reading.

On discarding the survey response 🔗

There were good points about removing the harmful response.

Firstly, the response used harmful language and was likely triggering. This particular response included angry rhetoric that was reflective, to a degree, of the social and political “climate” of our world today. Including the response in our final reporting could also be giving it a platform, which would arguably be a harmful act. It would validate that input as acceptable input. Our group was not in disagreement that the response was harmful and not behavior the community should tolerate.

Second, the response did not provide actionable insight or useful asks to the project and community. It was written in an aggressive, angry tone towards the reader and did not offer workable suggestions other than ending and divesting from all D.E.I. work immediately. Given this was not an acceptable option, there wasn’t much there for us to learn or understand about CHAOSS from this individual response. So, why include or save this response?

There is an option to ignore feedback by intentionally discarding it, but what if the individual feedback represents a larger trend?

What is community culture? 🔗

It is important to be aware of threats to community culture. What is community culture? My improvised definition is any organizational culture oriented towards the care, well-being, and thriving of others (including the self) within a single, shared community environment. Regardless of other values and goals in a project, the shared culture of the project can either lean towards a collective, communal-oriented approach or an independent, individual-oriented approach. The communal approach that prioritizes the well-being of all instead of a privileged view could also be considered as community culture. Many traditional “Open” projects skew toward a strong community culture.

On monitoring survey responses for a pattern 🔗

Coming back to the survey response, what if omitting the data leaves holes in the story of your community? If there is not just one, but several of these kinds of responses, what comments does that make about the community culture? Is there already a strong community culture, or is there resistance and challenges to building a more cooperative, caring environment? There is real work to do at both ends of the spectrum, but what that work might look like depends on which side you are on.

I posit that omitting the “unhappy” or harmful responses can create a dangerous blind spot to toxicity within a community culture. When it comes to direct, interpersonal interactions with others (e.g. meetings, emails, chats, etc.), stewards of the community culture need to take direct action against visible challenges and threats to the community culture. If someone starts swearing out at someone in a meeting, that is a hard-to-miss action. It is visible, and anyone could observe it or even record it.

In anonymous surveys, you might find a more subtle layer of the community culture than what is shown by the actions of a small few. There can be greater trust that someone’s comments will not be tied back to their identity, so some responders may feel emboldened with their words and true opinions.

Don’t discard a blind spot. 🔗

The point of this is that especially in larger communities, it is worth noting negative and harmful responses and not totally ignoring them. Communities that organize in more decentralized ways will always have supporters, users, and contributors from both the core and the periphery. The core project membership may not interact or engage often with the periphery often, so there can be a blind spot to parts of the project that identify with the community but are a few degrees removed from the inner ring of the project community.

Noting whether something is indicative of a larger pattern is important. If your community has a ton of jerks, you need to know that your community is full of jerks so that you don’t waste time persuading people otherwise, when the lived experience is very different.

In the original conversation with the CHAOSS Project team, this data scrubbing question emerged in the process of running the survey instead of after the data collection concluded. The survey later closed and our data manager confirmed that the flagged response from earlier was the only one of its kind. As a group, we then felt more confident in discarding that one outlier as an anomaly since the survey was open to the general public.

Feature photo by JESHOOTS.COM on Unsplash. Modified by Justin Wheeler.

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

CHAOSS accomplishments & learnings 🔗

Three achievements and aspirations stand out over the past year:

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

Processes & workflow 🔗

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

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

Community of Practice 🔗

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

Sharing results with CHAOSS and beyond 🔗

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

According to expectations 🔗

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

As expected 🔗

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

Surprises 🔗

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

Changes for the CHAOSS team next year 🔗

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

1. Packaging our work
2. Dissemination of our work

Packaging 🔗

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

Dissemination 🔗

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

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

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

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

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

Origins of Technical Assistance at the Venture Fund 🔗

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

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

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

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

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

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

Martijn van de Weerdt, Founder, AW3L

How the DPG Standard unified the mentoring streams 🔗

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

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

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

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

Rumee Singh, Co-Founder, Rumsan

Further, farther, together 🔗

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

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

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

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

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

Antonella Perrone, COO, Xcapit

Contribute to Technical Assistance knowledge and mentoring 🔗

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

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

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

one, two
I fell in love with you
Caught me by surprise

three, four
My focus was on you
There was me, you, & the road

five, six
I took each breath
Felt each beat of my heart

seven, eight
I realized Your rhythm
Pulled into Your pace

nine, ten
I became my breath
Centered at Your feet

one, two

Photo by David Marcu on Unsplash. Modified by Justin Wheeler.

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

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

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

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

History of the CrystalCraftMC forums 🔗

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

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

Why the forums closed 🔗

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

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

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

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

What now for CrystalCraftMC? 🔗

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

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

Long live CrystalCraftMC.

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

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

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

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

Defining investments. 🔗

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

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

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

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

How do these investments impact sustainability? 🔗

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

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

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

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

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

The four metrics are detailed below:

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

Contribution Attribution 🔗

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

chaoss.community/metric-contribution-attribution/

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

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

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

Contributors 🔗

Question: Who are the contributors to a project?

chaoss.community/metric-contributors/

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

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

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

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

Collaboration Platform Activity 🔗

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

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

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

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

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

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

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

Labor Investment 🔗

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

chaoss.community/metric-labor-investment/

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

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

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

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

What next? 🔗

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

From What is Fedora all about?

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

Background photo by Omid Armin on Unsplash.

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

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

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

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

New to Open Source at UNICEF? 🔗

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

https://jwfblog.wpenginepowered.com/2021/07/unicef-open-source-mentorship/

Innovation Fund support models 🔗

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

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

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

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

Legal & policy 🔗

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

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

Building and leveraging from the community 🔗

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

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

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

Innovation Fund case study: Cloudline and upstream engagement 🔗

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

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

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

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

Going upstream 🔗

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

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

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

What is next for the Innovation Fund? 🔗

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

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

In those moments, I think about how lost I truly was. Running away from anxiety and an unhappy past by keeping myself busy. Overthinking and ruminating on all my social interactions with others. In many ways, living in under the shadow of generational codependency. Yet through all of that, I still maintained a simple desire to be good and help others.

I think of the interactions that you and I had in those same moments. I am brought back to that evening, laughing in our hearts and hearing each other as we sipped wine under the setting sun on the river. A late-night taxi trip back to the hotel after a night out with old and new friends. The gifts you shared with me.

They are memories I do not only see in my mind, but also feel with my whole being. Even this long after they have passed. For that, I remain grateful.

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

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

Context brief: what is a committee? 🔗

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

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

Challenges of a committee 🔗

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

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

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

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

What is a better design for community engagement? 🔗

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

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

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

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

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

Why? 🔗

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

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

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

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

Blogs were (mostly) safe spaces where we could share our thoughts and views. We were often influenced to think we were sharing our thoughts and views with the world, but really we were writing to a known audience. We were writing to the people who read our blogs; unless you were a 2006 Internet celebrity or mom blogger, our audiences were small and narrow. Perhaps both to our benefit and to our detriment.

How does this compare to today? Most online content by the masses is condensed into bite-sized thoughts: tweaked for the tweet, fed to the feed, and longing for the likes. Our thoughts and ideas are in competition in a race where attention is sparse. But to blame this solely on social media is not fair either. More consumers and producers exist today than we had fifteen years ago. We have more means to produce content today than our bandwidth-challenged dial-up connections at the turn of the new millennium. Social media went mainstream in our society because it was at the right place, at the right time.

As we progress further along in this decade, the art of blogging as a vehicle for human expression becomes sidelined further in nostalgia. Maybe in part because we have less collective time than we did before. Perhaps also because we became lost in this mirage of how we are supposed to appear and how we are supposed to act when our lives are lived out in this strangely self-controlled yet algorithmically influenced existence. Blogging, as a form of expression dating back to the earliest times in the Internet, exists partially outside this algorithmic existence.

Yet it still exists. For me, my blog is still online. But my blog maintains an absence of these kinds of emotional, artful expressions that better show me as a human being, not just a contributor or participant in some technology projects or communities.

So, lost somewhere in that cyclical loop of (self-defeating?) nostalgia, I push my thoughts out into the sea of the Internet; a message in a bottle without a final destination. Just a thought: here for a moment and gone in the next.

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.

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

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

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

Multi-sensing > accommodations 🔗

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

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

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

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

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

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

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

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

A visit to Tiranë in June. 🔗

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

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

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

Is the future in Stockholm? 🇸🇪 🔗

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

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

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

Here, for now. 🔗

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

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

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

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

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

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

UN Roadmap for Digital Cooperation 🔗

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

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

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

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

UN Roadmap for Digital Cooperation, June 2020

Open Source Mentorship enables digital cooperation. 🔗

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

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

The era of disc jockeys and long LPs are past. While human-curated playlists continue to exist, they are in steep competition with weekly playlists of tailored content. Every week, a personal digital deejay runs your music life. This digital deejay knows what you are vibing right now, what were the hot skips, and what might be your new moods for the week. It is hard for any human to compete with that level of curated music freshness.

But this did not answer my question. Who curated this playlist, that I felt so intently in my heart? In this way, I realized it did not matter if it were a real human being who hand-dragged the songs from one album to another, or if it were a machine learning algorithm that uniquely picked songs only for me. The algorithm is still human, in a world which is also structured, shaped, and changed by humans.

Perhaps it was the human essence of this algorithm that compelled the playlist into my feed. A long time ago, someone would have called something like this fate. But I felt a warmth that this playlist helped me feel a sense of my own humanity, in a time where I was feeling so many different things. Call it machine learning, call it fate, call it biased human activity, and you are right.

The break-up of robot humans known as Daft Punk earlier this year was heart-wrenching. Two humans who conveyed the humanity of machines to me through their music. They shared a perspective in my life that I did not know I was looking to hear. Despite the break-up, their message remains clear in my heart. Their message is an acknowledgement that what is robot is also human.

So if algorithms and computers are human by their association to humans, what does this speak of the humans who create the robots? Are there computer humans? Computer humans who live their life as if on a script? Computer humans who struggle with memory storage or retention? If Daft Punk claims the title to being robot human / human robot, then it might also be inferred that there are robotic, programmed humans who take calculated steps to create the world they want, irrespective of others.

Indeed, computer human.

I hope we may aspire to Daft Punk’s vision of human-is-robot/robot-is-human instead.

No culture can live if it attempts to be exclusive.

Mahatma Gandhi

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

Twitter: @jwf_foss

Why should you vote for me? 🔗

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

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

Who am I? 🔗

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

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

What are my qualifications? 🔗

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

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

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

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

Interview responses 🔗

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

Q1: What should OSI do… 🔗

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

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

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

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

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

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

Q3: When a license decision involves a topic… 🔗

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Am I ready to let someone new in?

Balkans and Bosnia. 🔗

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

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

Patterns. 🔗

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

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

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

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

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

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

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

Preface 🔗

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

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

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

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

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

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

Free Software sustainability is here to stay. 🔗

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

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

sus·tain·a·bil·i·ty

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

Oxford U.S. dictionary

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

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

The maintainer and the corporation 🔗

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

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

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

Free Software will have its ethics interrogated. 🔗

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

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

Ethical Source? 🔗

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

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

“Join, or Die.” 🔗

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

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

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

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

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

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

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

“The world the children made.” 🔗

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

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

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

What now? 🔗

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

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

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

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

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

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

Open Source Archetypes (May 2018)Download

This article covers the following topics:

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

How Open Source Archetypes align with my experience 🔗

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

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

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

How I use Open Source Archetypes at UNICEF 🔗

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

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

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

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

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

Unanswered questions 🔗

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

My unanswered questions are below.

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

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

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

Open Source Archetypes, Page 17

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

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

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

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

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

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

How would you teach Open Source? 🔗

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

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

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

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

This short article covers three sections:

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

CAL-1.0 provisions 🔗

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

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

Basic legal provisions 🔗

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

Permissive provisions 🔗

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

Copyleft provisions 🔗

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

What’s fresh!! 🔗

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

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

Section 4.2 Maintain User Autonomy: intro text

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

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

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

CAL-1.0 and Hatbrim Technologies 🔗

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

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

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

Meanwhile at Hatbrim… 🔗

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

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

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

CAL-1.0 personal takeaways 🔗

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

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

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

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

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

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

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

Why work on TeleIRC for Hacktoberfest? 🔗

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

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

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

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

#1: Large messages go to a pastebin 🔗

This corresponds to RITlug/teleirc#56.

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

#2: Telegram Poll handler 🔗

This corresponds to RITlug/teleirc#267.

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

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

This corresponds to RITlug/teleirc#332.

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

Need Hacktoberfest help? Come talk to us! 🔗

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

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

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

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

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

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

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

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

On the origins of Software Freedom 🔗

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

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

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

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

Freedom in 2020 🔗

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

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

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

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

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

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

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

Reconciliation and intersections 🔗

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

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

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

The name of this intersection is digital intersectionality.

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

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

What now? 🔗

Chadwick Boseman is gone. But we are not.

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

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

Special thanks to my early editors!

El Ten Eleven is a duo consisting of Kristian Dunn on strings and Tim Fogarty and drums. Plus several loop pedals! El Ten Eleven’s debut self-titled album released on September 20th, 2005 (even though Dunn says the album released in late 2004). This makes 2020 the 16th anniversary of their debut album in the twenty-first century post-rock scene.

This entry in Tergiversate reviews the history and background of the album and offers a personal perspective on one of my favorite music albums. Let’s take a look at El Ten Eleven!

My background on El Ten Eleven 🔗

If Last.fm is trustworthy, I have 39,355 listens of El Ten Eleven, out of a total listen count of 348,043. 18,605 listens were of the self-titled album specifically. It takes two lead positions in my music library: my most-listened artist and album of all-time. I discovered El Ten Eleven on December 19th, 2012.

In 35 minutes, El Ten Eleven tells a great story. It is an album that means a great deal to me.

El Ten Eleven, track-by-track 🔗

El Ten Eleven songs have no lyrics (not counting Emile Mosseri collaborations). The only given meaning is in the song titles. The rest is up for audible interpretation.

But if you are a curious music nerd like me, the artist’s thinking behind a song is interesting to understand. This blog post documents what I know about this album. My experiences come from reading other music journalism sites on the Internet and even talking to Kristian Dunn after concerts time to time! (He is a cool dude. He signed my brick.)

1: My Only Swerving 🔗

This song was written in tribute to Traveling through the Dark, a 1998 poem by William E. Stafford (confirmed here). The track title gets its name from a line towards the end of the poem.

I thought hard for us all—my only swerving—,

then pushed her over the edge into the river.

Traveling through the Dark, William E. Stafford

Dunn ran an “Ask Me Anything” (A.M.A.) on Jan 22, 2018 via Patreon. In the A.M.A., Dunn lamented how the song failed as a tribute to the poem. He believed the song was not dark enough to match the poem.

3: Lorge 🔗

Dunn’s mother passed a short time before the album was recorded. The album is dedicated to her memory. Lorge is the middle name of Dunn’s mother. The album reflects on the emotions that follow the death of a loved one.

4: 1969 🔗

In a phone interview with Fogarty, he believed this song title came from Dunn’s birth year, 1969.

7: Fanshawe 🔗

The song is a tribute to The New York Trilogy’s The Locked Room novel, which features a character named Fanshawe. In the Patreon A.M.A., he acknowledged the connection to the character and book.

8: Connie 🔗

Connie is the shortened form of Dunn’s mother’s first name, Constance.

Why I care 🔗

El Ten Eleven deals with loss. As the album transitions from beginning to end, it moves towards acceptance. But acceptance of loss is not easily attained. Loss also comes with difficult emotions.

In psychology, there are five stages of grief. They can happen in any order and go between each other, but it always ends with acceptance. The abbreviated five stages are regret, denial, anger, sadness, and acceptance. El Ten Eleven offers a musical experience of the life-cycle of grief.

El Ten Eleven empowered me. In times of discomfort or anxiety, this album is always my go-to. It continues to be a cornerstone for me in challenging moments in my life.

Where to find El Ten Eleven 🔗

Check below for links. If you have no preference, Bandcamp purchases are the most effective way for your money to go to supporting the band.

• Bandcamp
• Spotify
• iTunes
• Google Play
• Amazon

If you would be kind, please drop some claps to my friend’s interview with the band on Medium!

Curious where the name “Tergiversate” came from? Check out the dictionary definition.

Two years passed since we last met in Bolzano. I remember you traveled in for a day to join the 2018 Fedora Mindshare FAD. You came many hours from your home to see us, and share your experiences and wisdom from both the global and Italian Fedora Community. And this week, I learned that you, Gabriele “Gabri” Trombini, passed away from a heart attack. To act like the news didn’t affect me denies my humanity. In 2020, a year that feels like it has taken away so much already, we are greeted by another heart-breaking loss.

But to succumb to the despair and sadness of this year would deny the warm, happy memories we shared together. We shared goals of supporting the Fedora Project but also learning from each other.

So, this post is a brief reflection of your life as I knew you. A final celebration of the great memories we shared together, that I only wish I could have shared with you while you were still here.

Ciao! 🔗

We had a unique privilege of meeting first in person before meeting online. At Flock 2015, of course I remember coming to your Fedora-Join session. This was my first introduction to the volunteer-supported mentorship community that exists in Fedora. Even though there was one particularly disruptive audience member, I remember learning from you and noting your long-time experience in the Fedora Community.

After that, we would come to know each other better. As I began a new chapter of my life at my university, we would become frequent collaborators. The Fedora Marketing team was always interesting to me, as part of the group of people who helped our community talk about and share the Fedora Project with others. Underneath your gentle mentorship, I learned the focus areas and history of the Fedora Marketing team.

At some point in 2015 or 2016, you asked me if I would like to chair a Marketing Team meeting. Thus began an early step in my journey from a participant to a facilitator. In a tragically ironic way, it strikes me how I did not see your guidance as mentorship at the time. I always saw our conversations as two friends discussing a shared hobby or interest. Such is the subtle art of teaching and mentorship.

Your many contributions 🔗

You were a cornerstone community member of Fedora for many years. Since our connection was from Fedora, it is worth noting the many contributions you made over the years. Long before Fedora or Linux were anything I knew about.

You and Robert Mayr co-authored a book together about Fedora 9, I think for the Italian Linux community. You were a one-time steward of the Fedora Join and Marketing teams. You were an influential member in shaping what Mindshare is today, from the days of the Fedora Outreach Steering Committee, the Fedora Ambassador Steering Committee before that, and grassroots community organizing in Italy even before that.

Beyond the source 🔗

But perhaps the memories I treasure most are the ones that don’t have much to do with Fedora at all. I remember learning that “in real life” you were a co-owner of a heating and air conditioning business in Italy. For many years, my family ran a heating and air conditioning company of our own. This was an experience I could always understand. I remember the times when you would go offline for some time. Then I would hear from you eventually, and you would tell me how the busy season kept you away from helping out in Fedora. And in a few words in IRC private messages, I simply knew and smiled.

We would meet at Flock events, but I find Flock is usually tough to get 1x1 time with others. I remember the day you came up and joined us in Bolzano for the 2018 Mindshare FAD. On a weekend day in March, you came and sat in a wine cellar converted to a conference room, where we spent the day recounting pain points and how Mindshare would address them.

And then, our small group went out for dinner. The food we ate and words we said are now faded memories, but the experience lives warmly in my heart as I think about what your life meant to me.

I was saddened to find no photographs or pictures of us together. But I went looking for our last conversations and found these final messages on IRC:

**** BEGIN LOGGING AT Sun Dec  4 17:49:56 2016

Dec 04 17:49:56 <jflory7>   That would be fantastic... I'll definitely let you know if I have plans to visit Italy. :)

Dec 05 07:00:32 <mailga>    jflory7 hope it happens. :)

**** ENDING LOGGING AT Wed Dec  7 00:28:51 2016

I never got to take you up on your offer to visit your home and meet your family. But I am happy that I had the opportunity to partially fulfill that old promise of meeting together in Italy.

Why write this? 🔗

I didn’t write this post with an outline, or a template. These words came to me while sitting with my own emotions and feelings. I am writing this because this is an effective coping mechanism for me to process what is lost, but also how to move forward from the loss.

The Fedora Project has given me a lot over the last five years. I have met many wonderful people and contributed to things that matter a great deal to me. But Fedora has also taught me about loss. There are many lessons in life that have nothing to do with work, code, software, or engineering, but have everything to do with how we look at the world.

In the wake of losing you, I think of the kind words and memories we shared that I did not tell you were important to me. I think of how the opportunity is permanently missed for me to share my appreciation of your kindness and friendship. The tragedy of youth is perhaps that I failed to fully appreciate our connection until after you passed.

When writing this, I came to realize something for me. And this will be different for everyone. But I like to think for Gabrielle and me, Fedora was never just about building an operating system. It was about collaborating with other people, human beings, on a digital infrastructure project that mattered, and to share kindness unto others – especially beginners and newcomers.

Rest in peace, amico.

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

Overview 🔗

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

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

If you are hooked, read on.

The Sticky Idea 🔗

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

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

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

Open Source Accountability Goals 🔗

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

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

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

Facilitation of Authentic Participation discussion 🔗

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

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

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

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

Facilitation, Roosevelt-style 🔗

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

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

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

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

How did facilitation start? 🔗

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

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

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

Is there a next chapter to this story? 🔗

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

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

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

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

Closing thoughts 🔗

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

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

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

Download TeleIRC v2.0.0 now! 🔗

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

Eight months later… 🔗

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

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

Thank you amazing volunteer contributors! 🔗

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

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

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

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

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

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

Get in touch! 🔗

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

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

Full rewrite to Go 🔗

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

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

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

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

Run TeleIRC v2.0.0 as a compiled binary 🔗

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

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

Improved TeleIRC v2.0.0 documentation 🔗

End user feedback shaped and improved documentation during development.

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

Future roadmap for containers 🔗

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

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

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

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

What are Happiness Packets? 🔗

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

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

The feeling that you made a difference, that your work matters and has value, and that the people you work with are happy to work with you, is an awesome feeling. With Open-Source Happiness Packets, we’re trying to spread that feeling.

How does it work?

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

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

What are Open-Source Happiness Packets?

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

Take the challenge! 🔗

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

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

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

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

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

Share your Happiness Packets 🔗

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

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

Love Letter by Vectors Market from the Noun Project.

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

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

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

Video recording from FOSDEM 2020

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

Let’s frame this first. 🔗

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

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

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

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

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

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

Looking to yesterday for today 🔗

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

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

What freedoms do we want to protect? 🔗

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

1. Audit automated decision-making systems 🔗

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

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

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

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

2. Deliver accountability and responsibility 🔗

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

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

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

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

Myanmar and Facebook 🔗

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

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

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

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

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

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

3. Appeal a decision 🔗

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

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

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

Resume/CV filtering 🔗

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

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

Practical examples 🔗

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

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

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

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

Where do we go from here? 🔗

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Why does this matter? 🔗

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

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

27 Sept. 1983: GNU Project announced 🔗

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

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

Today, we call these the Four Freedoms.

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

4 Oct. 1985: Free Software Foundation founded 🔗

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

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

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

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

25 Feb. 1989: GNU General Public License created 🔗

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

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

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

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

Is the past relevant to social movements today? 🔗

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

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

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

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

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

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

Your future is the new commodity. 🔗

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

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

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

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

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

Where are we today? 🔗

So, how have we responded to our changing world?

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

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

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

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

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

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

Photo by Shane Rounce on Unsplash.

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

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

Official conference website

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

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

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

At a glance: structure and key takeaways 🔗

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

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

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

Structure: Dialogue and discussion 🔗

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

I attended these sessions:

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

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

1. Open source is in an identity crisis. 🔗

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

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

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

2. Millennials are underrepresented. 🔗

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

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

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

Born digital 🔗

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

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

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

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

Is Free Software ready for the millennials? 🔗

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

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

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

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

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

The 2020s will be definitive 🔗

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

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

So, what will Free Software do?

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

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

Luis Villa

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

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

Add more chairs to the table 🔗

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

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

Free Software, but for kids 🔗

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

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

Talk with us, not at us 🔗

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

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

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

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

Teach early and teach often 🔗

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

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

Where are we going? 🔗

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

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

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

Our software freedoms are not enough 🔗

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

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

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

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

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

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

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

So, now what? 🔗

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

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

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

We do have the power. 🔗

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

So, what will you do?

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

Thanks folx! 🔗

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

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

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

This blog post is a story roughly covering 2010 to 2014 on the meaning, values, and promise of open source. This story impacted a community of hundreds of thousands of people, mostly adolescent children, teenagers, and young adults. It is a tale about the simultaneous success and failure of the GNU Public License (GPL).

From the beginning: Bukkit, Minecraft, and the GPL 🔗

In the beginning, in December 2010, there was Bukkit.

Bukkit is an up-and-coming Minecraft Server mod that will completely change how running and modifying a Minecraft server is done - making managing and creating servers easier and providing more flexibility. Learning from the mistakes made by other mods, Bukkit aims to be different and fill the void left by them: built from the ground up we’ve focused on performance, ease-of-use, extreme customisability and better communication between the Team and, you, our users. The overall design of Bukkit has been inspired by other mods and our experience as Minecraft players just like yourselves, giving us a unique perspective and advantage going into the creation of the Bukkit Project.

About Us, Bukkit.org

Bukkit was an open source server for Minecraft. It provided an API for developers to create plugins that extended Minecraft in unique and fun ways. While Bukkit was not the first open source Minecraft server, it was the first organized project. Bukkit launched with the GNU Public License (GPL) v3 license.

From 2011 to 2014, Bukkit was the de-facto standard for running a Minecraft multiplayer game server. Over time, more Bukkit servers (and derivatives) were used than the official server software distributed by Mojang. Mojang is the company responsible for Minecraft development.

Hard work on Bukkit recognized 🔗

The project’s success was also recognized by Mojang too. At the first-ever Minecraft convention in 2011, MINECON, four Bukkit lead developers were hired by Mojang to work on Minecraft. All but one of the hired employees then departed from Bukkit. That one developer who remained active in Bukkit would depart from Mojang mysteriously in 2013.

Had a great time working for Mojang but it's time for me to pursue other interests. As of yesterday, I am no longer working for Mojang.

— EvilSeph (@EvilSeph) October 2, 2013

However, there was always one caveat. Bukkit was an open source project licensed under the GPLv3. However, it also reverse-engineered some parts of the Minecraft game code to build its server code and API. This was never a problem for Bukkit or Mojang:

“When we started up Bukkit in December of 2010, we decided we wanted to do things right. Right from the beginning we wanted to be sure we were bringing about a positive change to Minecraft, one that Mojang themselves would approve of. To that end, we set up a meeting with Mojang to get a feel for their opinions on our project and make sure we weren’t doing anything they didn’t like. The gist of the meeting was that Mojang “liked what we were doing” but not how we had to go about doing things. Unfortunately, we both knew that we had no alternatives, so we continued along - albeit now with the reassurance that our project would most likely not be shut down any time in the future.”

EvilSeph (Warren Loo), “Bukkit: The Next Chapter”

Nobody ever raised a copyright issue over the reverse-engineered code from Minecraft in Bukkit. Yet, for years, the GPL code released by Bukkit included bits from official Minecraft code.

Act 1: The Minecraft EULA 🔗

An alternative perspective on the Minecraft EULA is in this Guardian article. “Minecraft: how a change to the rules is tearing the community apart.”

All was fine for a number of years. Bukkit was a volunteer-led project even after some of its core developers were hired to work at Mojang. However, in 2014, unrelated tension started to grow in the Minecraft community.

The tension was about the language used in Minecraft’s End User License Agreement (EULA). The EULA used ambiguous language over the monetization of Minecraft multiplayer servers:

“The one major rule is that you must not distribute anything we‘ve made. By “distribute anything we‘ve made” what we mean is “give copies of the game away, make commercial use of, try to make money from, or let other people get access to our game and its parts in a way that is unfair or unreasonable”."

2014: account.mojang.com/documents/minecraft_eula

While many open source projects flourished around Minecraft, a huge game server industry also co-existed in this ecosystem. Multiplayer server owners running Bukkit (or derivative projects, like Spigot) created web stores for their servers. Players paid real money to buy in-game perks for a specific multiplayer server. Using open source plugins, players paid for things like item packages with diamond swords or virtual currency to spend in-game.

This behavior was allowed to flourish for years. However, the EULA was discreetly edited in December 2013. In mid-2014, someone in the community noticed the changed language. They tweeted and tagged a Mojang employee asking if this meant multiplayer servers had to stop selling in-game items for real money. In as much detail that a 2014 tweet with a 140-character limit allowed, the Mojang employee confirmed the EULA language did technically forbid that.

Panic! In The Bukkit Server 🔗

“Then, everything changed when the Fire Nation attacked.”

The community erupted into chaos. Suddenly, a community that had mostly co-existed peacefully was at a virtual war with each other. The situation was understandable from both ends, if for different reasons.

Anyone could start their own multiplayer server. So it was possible for malicious servers to scam players (usually young children) of money. Usually this happened by failing to deliver on the purchases or closing down after a period. Frequently, Mojang was contacted for help (usually by angry parents) about game servers Mojang did not control.

At the same time, many good people built (probably unwise) business models around the permissive nature of Minecraft intellectual property. The open source software made it easy to extend Minecraft in ways Mojang did not intend.

Act 2: The Bukkit cards are revealed 🔗

Tension was already high between the the trinity of business owners, open source developers, and Mojang. By 2014, Mojang was a multi-million dollar company (even before their multi-billion Microsoft buyout). The EULA tension placed a heavy burden on the open source developers, who received pressure from both ends.

Then, the unexpected happened on August 21st, 2014. The Bukkit project lead, Warren Loo (EvilSeph), announced the end of development on the Bukkit project:

.@CraftBukkit: It's time to say goodbye - http://t.co/LRG2uiMbDe

— EvilSeph (@EvilSeph) August 21, 2014

Read the full announcement from Bukkit team

Bukkit gets “owned” 🔗

This was sad news. But the real shock came an hour later when the lead developer of Minecraft at Mojang shot back on Twitter:

Warren over at bukkit seems to have forgotten that the project was bought by Mojang over two years ago, and isn't his to discontinue.

— Jens Bergensten (@jeb_) August 21, 2014

Two other former Bukkit developers working at Mojang chimed in too:

We took ownership of the Bukkit github repos & project. We'll see what happens from here.

— Erik Broes (@_grum) August 21, 2014

To make this clear: Mojang owns Bukkit. I'm personally going to update Bukkit to 1.8 myself. Bukkit IS NOT and WILL NOT BE the official API.

— Nathan Adams (@Dinnerbone) August 21, 2014

It was now revealed that the Bukkit open source developers hired by Mojang in 2011 had given up their personal copyright and rights to their open source contributions as part of their employment contracts. The open source developer and business owner communities both learned this abruptly over a 140-character tweet.

The community was confused, upset, and angry.

“The decision to keep the acquisition of the Bukkit codebase a secret was made between Mojang and Curse, which only recently came to light. I was completely unaware that I had spent the last two years of my life as a Bukkit Administrator, and successor to the project lead, under the illusion that the project was independently ran. Had I known back then perhaps my choice would have been different, perhaps not. It’s easy to speculate on what might have been, but unless faced head on with the choice, the decision is not always clear.”

TnT, “So long, and thanks for all the fish”

What is known now was that for about three years, the volunteer-driven open source project was “owned” by company valued for millions of dollars that did little to support the open source project that helped build a community around the game. The only visible contribution made by Mojang to Bukkit was the explicit permission to continue their endeavor in the legal gray area.

Act 3: DMCA take-down of Bukkit 🔗

On September 5th, 2014, a lead developer not hired by Mojang, who had contributed over 15,000 lines of code to the project, invoked a Digital Millennium Copyright Act (DMCA) take-down on all of his personal contributions to the project (and all derivative projects). In a day, all the source code for a project used ~3x more than Mojang’s official server software disappeared from the Internet.

It is easy to understand why this lead developer did what he did. To find out the last few years of your life spent volunteering on a game project that was secretly owned by a multi-million dollar company is a shattering experience. It’s essentially free labor. But at the same time, this was a project used by hundreds of thousands of people around the world. It was more than a project; it was also a community.

One of the lead developers of Bukkit said this of the project in their resignation letter to the community:

“The Bukkit Project is so much more than CraftBukkit, getting updates out and providing API. It’s about giving the community a place where they feel welcomed and can program to their hearts’ content with the use of our product. The Bukkit API gave people the ability to change the behavior of Minecraft, but it would have meant nothing without the contributions from the plugin developers in the community.”

feildmaster

The DMCA take-down wasn’t just a take-down of the software; it also was a take-down of a community. The overnight disappearance of Bukkit left a huge power vacuum full of bitterness, personal harassment, and doxing. (Don’t forget this was also the era of #GamerGate.)

Who was this community? 🔗

The project I participated with, Spigot, was a fork of Bukkit created in 2012. Like Bukkit, Spigot was also hit by the DMCA take-down, although the Spigot team worked out a clever legal workaround to continue development.

A huge plugin community and third-party software around Bukkit’s API grew around both Bukkit and Spigot. The unusual thing was, with few exceptions, most of the leaders of these communities were young adults in their 20s, teenagers, or even 11 year old kids. Open source wasn’t a strongly understood concept in this community. It was just what everyone did. The messaging around licensing was not always great, but working in the open was the nature of how this gaming community operated.

The spirit of open source died 🔗

For this community, the promise and glory of open source died. For years, the Bukkit developer team shared their belief in open source with the community:

“Bukkit chose to go the open source route with our API for several reasons. Not only is open source awesome, but we knew that there were many talented individuals within the Minecraft community that could help us evolve, mature and grow our project much faster than we could have ever dreamed on our own.”

EvilSeph (Warren Loo), “Bukkit Project Changes and Improvements”

But with the complications of a project doomed to failure under the GPL that never should have been, combined with the hidden secret of ownership and DMCA take-down of open source code, the promise of open source both helped and failed this community.

Who was right? Who was wrong? 🔗

On one hand, the lead developer who issued the DMCA take-down was able to vent the frustration faced by those who discovered their secret “free labor” agreement with Mojang (at a great personal cost, as he was harassed, stalked, and received death threats). On the other hand, the collective community faced the end of an era brought about extraordinary circumstances that actually voided the GPL as a valid license:

“A license is a contract. There are many reasons why a contract would be void, and many conditions that make a contract invalid from the get-go. One such condition is being “tricked” into the agreement, which would include agreeing to work on a project under false pretenses. As stated above, an open source project being secretly purchased by a company, in hopes to have that company’s game be improved through it, is as close to a loophole for free labor as you will find. Free labor was outlawed in this country a while ago. We had a whole war about it.”

/u/VideoGameAttorney, “My Response to Vubui, Mojang, and the hundreds (yes, hundreds) of you who asked me to weigh in on this.”

The only conclusion I can muster on this saga is from that same Reddit thread: “But at the end of the day, don’t just believe one side is “good” and the other “bad” here. These things are rarely so simple.”

Why did I write this? 🔗

Because I keep coming back to this story, across my life. I was writing an event report about a copyleft licensing conference I went to in February 2020, when I recapped this same story to someone there in-person. It wasn’t the first time I told this story at a conference though. It’s such an interesting case study of copyleft licensing.

Because it is in the open source gaming world and the largest demographic of this particular gaming community is under 30 years old, many folks who have been “around the block” in open source are unaware of this story.

But as my first open source community and also something I invested nearly a whole decade of my life into (as have countless others), this experience shaped my outlook on open source and community in an unusual way. It’s an experience I can’t forget. Even if I only have an abrupt ending to this story, it’s a story that I think deserves to be told, in respect to those who invested far more time, energy, money, and tears in this than I ever have.

What’s coming in TeleIRC v2.0.0? 🔗

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

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

TeleIRC v1.0.0 was an experiment. 🔗

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

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

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

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

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

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

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

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

A Go rewrite distinguishes our project. 🔗

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

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

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

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

Go has a better story for Kubernetes / OpenShift. 🔗

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

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

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

TeleIRC v2.0.0: Progress so far 🔗

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

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

When to expect TeleIRC v2.0.0 🔗

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

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

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

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

Get involved with TeleIRC! 🔗

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

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

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

Background photo by Daria Nepriakhina on Unsplash.

(Dr. Gordon, if you find this: I hope you don’t mind, I mean the best!)

What are some ways in which media interlocks with other institutions? What does this interlocking suggest about the role of media in society? 🔗

Media is a fundamental aspect to other institutions, if media is considered a form of communication. Media is defined broadly: pictures, videos, interactive content, games, social media, and journalism, to name a few. Media interlocks with other institutions as a tool that fits into other categories of work, in an intersectional way.

To use social media as an example, the government of Iran is an example of how a totalitarian institution manipulates media to influence popular opinion and perspective, and also to drown out voices of activists and those fighting for social justice. The Washington Post is a newspaper owned by the world’s wealthiest man, who also runs one of the companies that wields increasing reach over many aspects of our digital life. The relationship of media institutions as reliable and trustworthy platforms of information and perspective is jeopardized by the corrupting role of power, often in the form of money and capital.

Identifying how the role of media is influenced by power is a vital skill to be a consumer of information in the 21st century. At an unprecedented rate, we consume information more than any other generation before us. The availability of information at our fingertips on the Internet and the advent of ephemeral media requires us to process more information than our brains can handle. In lieu of a surplus of media, content, and information, it is important to be able to question our media, its motives, and to understand biases that may be at play to persuade us to view a topic or issue a particular way.

Justin Wheeler (Dec. 13, 2019)

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

- Get in touch with other developers and projects;

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

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

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

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

fosdem.org/2020/about/

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

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

Sessions: Play-by-play 🔗

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

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

Building ethical software under capitalism 🔗

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

Deb Nicholson

Deb is making a regular appearance on my blog.

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

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

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

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

Growing sustainable contributions through ambassador programs 🔗

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

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

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

Shilla Saebi & Alison Yu

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

What is an ambassador program? 🔗

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

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

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

Who and what are ambassadors? 🔗

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

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

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

What do ambassadors do? 🔗

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

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

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

How to incentivize ambassadors? 🔗

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

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

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

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

Lessons learned 🔗

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

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

Future goals 🔗

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

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

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

Bradley M. Kuhn & Karen Sandler

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

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

Resisting in 2020 is not the same as in 2000 🔗

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

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

Stop shaming 🔗

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

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

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

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

Eriol Fox

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

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

Open source perception 🔗

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

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

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

Learn what design work looks like 🔗

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

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

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

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

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

Twitter thread! 🔗

Did I live-tweet this one? You bet.

What makes people come and what makes them stay 🔗

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

Gloria Dwomoh

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

Beyond FOSDEM 2020 🔗

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

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

Thanks folx! 🔗

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

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

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

Until next time!

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

chaoss.community/chaosscon-2020-eu/

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

Sessions: Play-by-play 🔗

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

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

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

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

Deb Nicholson

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

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

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

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

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

Sean Goggins & Remy DeCausemaker

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

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

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

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

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

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

Measuring Culture 🔗

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

Sharan Foga

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

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

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

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

Meet Cauldron! Your SaaS Software Development Analytics solution 🔗

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

Jose Manrique Lopez de la Fuente

I had no written notes other than “wow!”

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

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

I have some homework to do!

Language barriers for open source contributors 🔗

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

Isabella Vieira Ferreira

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

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

— Emmy Tsang (@emmy_ft) January 31, 2020

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

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

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

Metrics are more than the sum of their parts 🔗

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

Matt Broberg

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

Emerging Tech Open-Source Scoring System (ETOSS) 🔗

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

Cecilia Chapiro & Justin Wheeler

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

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

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

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

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

— Farbod Saraf (@farbodsaraf) January 31, 2020

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

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

— Emmy Tsang (@emmy_ft) January 31, 2020

Hey, it’s me!

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

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

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

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

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

Yo Yehudi

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

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

Diversity & Inclusion Badging Program 🔗

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

Matt Germonprez

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

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

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

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

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

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

Addendum: Events and inclusivity 🔗

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

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

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

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

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

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

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

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

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

Brian Proffitt

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

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

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

Beyond CHAOSScon EU 2020 🔗

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

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

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

Thanks folx! 🔗

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

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

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

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

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

sustainoss.org/summit-2020/

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

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

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

At a glance: structure and key takeaways 🔗

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

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

Speed breakout sessions 🔗

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

I attended these sessions:

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

Key takeaways 🔗

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

Inclusion is local 🔗

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

Rules for revising rules 🔗

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

Generalists transition to specialists 🔗

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

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

We got the power 🔗

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

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

Community-first governance models 🔗

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

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

Citizen assemblies in open source? 🔗

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

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

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

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

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

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

Principles of Authentic Participation 🔗

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

However, for the reader’s convenience, the six principles we drafted are below:

Authentic Participation Starts Early. 🔗

This came out of discussions about organizations showing up with mature, fully-baked contributions over which the community had no input.

Authentic Participation Puts The Community First. 🔗

This reflected the general consensus that when an organization and the community want different things, the community needs to come first.

Authentic Participation Starts With Listening. 🔗

This was Duane’s reflection of some comments about folks showing up to projects with no historical context and telling them everything they were doing wrong.

Authentic Participation Has Transparent Motivations. 🔗

Without a shared understanding of the motivations, it’s impossible to resolve differences of opinion effectively. No hidden motives.

Authentic Participation Enforces Respectful Behavior. 🔗

This is about organizations taking responsibility for the behavior of their representatives.

Authentic Participation Ends Gracefully. 🔗

No sudden withdrawal of resources without notification and an exit plan. Clear documentation that would allow the community to pick up projects when a company decides to withdraw support.

Thanks folx! 🔗

To wrap up this Sustain OSS report, a few thank-yous are in order:

• Stephen Jacobs: For always being supportive for yet another trip abroad and helping me push my career forward in a number of ways (and footing the bill!)
• Mike Nolan: My co-conspirator, partner in FOSS, and comrade in arms
• The Principles of Authentic Participation group: I didn’t plan to facilitate at Sustain and I was nervous about it, but you all were wonderful. We had a fruitful discussion and I’m looking forward to the follow-up.

Sustain OSS 2020 continues to give me a lot to think about and consider. I’m fortunate to have attended. I hope this event report gives additional visibility to some of the conversations held in Brussels this year.

DevConf.CZ 2020 is the 12th annual, free, Red Hat sponsored community conference for developers, admins, DevOps engineers, testers, documentation writers and other contributors to open source technologies. The conference includes topics on Linux, Middleware, Virtualization, Storage, Cloud and mobile. At DevConf.CZ, FLOSS communities sync, share, and hack on upstream projects together in the beautiful city of Brno, Czech Republic.

devconf.info/cz/

This is my third time attending DevConf CZ. I attended on behalf of RIT LibreCorps for professional development, before a week of work-related travel. DevConf CZ is also a great opportunity to meet friends and colleagues from across time zones. This year, I arrived hoping to better understand the future of Red Hat’s technology, see how others are approaching complex problems in emerging technology and open source, and of course, to have yummy candy.

Sessions: Play-by-play 🔗

Event reports take many forms. My form is an expanded version of my session notes along with key takeaways. Said another way, my event report is biased towards what is interesting to me. You can also skim the headings to find what interests you.

Diversity and inclusion meet-up 🔗

Would you like to meet other attendees who stand under the umbrella of “Diversity and Inclusion” or would you like a introduction into what Diversity and inclusion is and why it’s a good thing? this is the session for you! All are welcome!

Imo Flood-Murphy

This was a short, informal session ran by Imo to network and get a high-level introduction to diversity and inclusion in open source. Everyone in the room introduced themselves and gave a short explanation of who they were or what projects they represent. I appreciated the opportunity to meet others and better understand how Red Hat approaches diversity and inclusion.

A suggestion for next time is to allow more unstructured time for conversations. I think fun icebreakers get folks comfortable in a short amount of time to help make connections for the rest of the weekend.

Lessons learned from testing over 200,000 lines of Infrastructure Code 🔗

If we are talking that infrastructure is code, then we should reuse practices from development for infrastructure, i.e.

1. S.O.L.I.D. for Ansible.

2.Pair devops-ing as part of XP practices.

3. Infrastructure Testing Pyramid: static/unit/integration/e2e tests.

Lev Goncharov

Lev shared best practices on building sustainable, tested infrastructure. Infrastructure-as-Code (IaC) was important to how T-Systems scaled their infrastructure over time.

My key takeaways:

1. Smaller components:
   1. More sustainable
   2. Easier to maintain
   3. Easier to test
2. Ansible Roles encourage best use practices for Ansible
3. Spreading knowledge is essential (if nobody understands it, the code is broken)
4. Code review creates accountability
5. Use static analysis tools (Shellcheck, Pylint, Ansible Lint)
6. Write unit tests (shUnit2, Rspec, Pytest, Testinfra, Ansible Molecule)

Content as code, technical writers as developers 🔗

In the open-source project Kyma, documentation is an integral part of code delivery. We, the project’s Information Developers, believe that using the same tools and methodology as your good old code developers, we can create comprehensive and accurate documentation. During our talk, we’ll share the whys and hows of our approach, showing you that the “developer” in “Information Developer” isn’t there just because it sounds cool. We’ll prove that creating documentation goes beyond linguistic shenanigans and salvaging whatever information there is from a trainwreck that is the developer’s notes. Testing solutions, finding our way around Kubernetes, tweaking the website, engaging with the community are just a few examples of what keeps us busy every day.

Barbara Czyz, Tomasz Papiernik

“Information Developers” is a cool phrase I learned. Barbara and Tomasz explained the value of technical writing and asserted documentation should live close to project code.

My key takeaways:

1. Documenting processes like release notes enables others to join with less barriers
2. Docs-as-Code (DaC): Visibility of docs across development process is important
   1. Placing docs with code encourages feedback loops and avoids silos
3. Put links to docs in visible places (e.g. API messages, console messages)
4. Management aside: Emphasize/incentivize value of technical writing in your team
5. Remember bridges across skill areas is possible (technical writers can also be community-oriented people too)

Uncharted waters: Documenting emerging technology 🔗

We can’t help but feel the lure towards the hot new thing, especially when it comes to technology. Part of that lure is the breaking of ground, venturing into the unknown, and working on solutions to new problems. But a lot of the same things that make emerging technology fun and exciting to work on are exactly why it can be difficult to document. These challenges are quite different to those associated with mature products.

This talk is for anyone working on new products and emerging technology, or just interested in learning about fast-moving documentation. It is for the developer as much as it is for the writer, since it usually falls to them to write the early docs before a writer is added to the team.

Andrew Burden

This was the talk I didn’t know I needed to go to.

Lately I work with “emerging technology,” which means different things to different people. Regardless of what emerging tech means to you, Andrew focused on how to write documentation in a fast-paced environment with “pre-release” technology, where things change fast and suddenly. Normally this is an excuse to not write docs, but Andrew showed, yes! It is possible to write good docs, even when context changes fast and often.

Key considerations of fast-paced technical writers 🔗

An even balance of these considerations helps get into a user’s mindset:

1. Scope / scale of release
2. Release schedule
3. Developer meetings / face-time
4. Exposure with $TECHNOLOGY
5. Deployment experience with $TECHNOLOGY

Surviving the information wall 🔗

The “information wall” is the endless wall of information and things to know about a project. If information is endless, how do technical writers survive?

• Take notes: Be like a scientist
• Take notes about your notes
• Be organized with your notes

Obviously Andrew was getting at the value of note-taking. Practicing note-taking skills is critical to keep up with the pace of change.

“Multi-Version Syndrome” 🔗

Sometimes you are writing features for things that will not be released in the next release. There is a risk of losing information across multiple releases (e.g. publishing the wrong thing too soon, or the right thing too late). Clarify the release schedule as you go. A good safeguard against losing information is to rigorously understand release cycle cadence and priority.

If your product isn’t mature yet, anticipate change instead of avoiding it.

Access to technology is critical 🔗

Technical writers are often User 0. To understand the technology, you need access. There are interactive and non-interactive ways of getting access. Interactive ways are preferred because they are always reproducible.

• Interactive
  • Deploy your own
  • Get someone else to deploy it for you (but lose install context)
• Non-interactive
  • Live demos
  • Demo videos
  • Asciicinema (CLI-oriented)

Other takeaways 🔗

• Screenshots have high maintainability cost; avoid if possible
  • Sometimes good stop-gaps until something more maintainable
• Where to begin? Make a table-of-contents for the Minimum Viable Product
  • Never underestimate outlines (ahem, like how I wrote this blog post…)
• Avoid documentation scramble near release day:
  • Make lists / check-lists
  • Take more notes
  • Pre-release checklist
  • Think now, and for the future
• Audit your docs: On-boarding new people is a powerful opportunity to test out your docs

Thanks Andrew for a deep dive on this narrow but important topic.

Community management: not less than a curry 🔗

Every volunteer joins an Open Source community for a reason. The reasons could range from technical gains to finding his/her/their passion. This community of diverse volunteers require a leader who can not just mentor them with their interests but also a manager managing the community activities in terms of community engagement and planning. A community manager is not less than a candle of light and in this presentation, I would be highlighting my learnings and experiences about starting a community from scratch around a project and maintaining a healthy community management practices.

Prathamesh Chavan

Prathamesh designed an activity to help the audience understand community management. My key takeaway was community management is about connecting and understanding others as their authentic self.

In the activity, Prathamesh passed papers and pens to the audience. His session had three steps. Between each step, all attendees traded papers with another attendee:

1. Define a project idea (why, how, what)
2. Identify challenges to idea (i.e. questions)
3. Answer challenges

It reminded me of a similar workshop I attended before. This inspired me to work on my own workshop idea for a future conference.

Cognitive biases, blind spots, and inclusion 🔗

Open source thrives on diversity. The last couple of years has seen huge strides in that aspect with codes of conduct and initiatives like the Contributor Covenant. While these advancements are crucial, they are not enough. In order to truly be inclusive, it’s not enough for the community members to be welcoming and unbiased, the communities’ processes and procedures really support inclusiveness by not only making marginalized members welcome, but allowing them to fully participate.

Allon Mureinik

Allon recognizes the importance of diversity, but asking for improved diversity is one side of the coin. A friend recently shared a powerful quote with me: “If diversity is being invited to the party, inclusion is being invited to dance.” Allon’s message was to dig deeper on including marginalized people in our project communities.

He identified ways we accidentally make our communities less inclusive because of our cognitive/unconscious biases. Everyone has blind spots! Allon suggested ways to be more conscious about inclusion in open source:

• Knowledge barriers
  • Procedural knowledge, not just technical
    • How do you submit code? File a bug? Make meaningful contributions? These need to be documented
  • Documentation fosters inclusivity
• Language barriers
  • Working proficiency in English not universal
  • Conversations have extra barriers (e.g. communicating complex ideas, understanding advanced words)
• Time barriers
  • Work schedules no longer 9 to 5
  • Remember other folks in different time zones
  • On giving feedback: Fast is not a metric! Be smart
    • Merging PRs while others are away, or shortly after opening it
    • Allow time for input on non-trivial changes
• Transparency barriers
  • If not in the open, it didn’t open
  • Negative example: Contributor makes a PR, reviewer has face-to-face conversation with contributor, reviewer merges PR without public context
  • Default to open: in many ways
    • If you can’t be open, at least be transparent

Diversity in open source: show me the data! 🔗

How diverse is your work environment? Diverse communities are more effective, they allow us to share the strengths of the individuals who make up the community. Have you ever looked around and noticed that most of our Open Source communities are predominantly male? Why do you think that is? We’ll use gender diversity as a case study and share some intriguing data points. Let us convince you why it’s so important.

Regardless of your gender, we would love for you to join us! We will also give you some tips on how you can make a difference.

Serena Chechile Nichols, Denise Dumas

Serena and Denise divided the talk into two sections: metrics and action. The way they presented, they brought the audience on the same page by visiting a variety of metrics and then transitioned to an empowering discussion about changing trends we see.

Next time, I hope to see expanded messaging by defining diversity beyond only women. Diversity was frequently tied to gender participation metrics in open source. While women are underrepresented, there are additional aspects of identity that can compound discrimination. Race, socioeconomic status, nationality, sexual orientation, and more also play a part in understanding challenges collectively faced in inclusion work.

The data 🔗

• Gender differences by # of contributors:
  • GSoC 2018: 11.6% female-identifying contributors
  • OpenStack: 10.4% female-identifying contributors
  • Linux kernel: 9.9% female-identifying contributors
• U.S. Dept. of Labor: 22.2% of technical roles filled by women
  • 2014-2019: More women entering tech jobs at companies like Apple, Microsoft, Google, etc.
• Years of experience by gender (<9 years):
  • 66.2% female
  • 52.9% non-binary/queer
  • 50.1% male
• GitHub user and developer survey:
  • 95% male
  • 3% female
  • 1% non-binary

Let’s make things better 🔗

Serena and Denise asserted diversity creates change. All changes come with challenges. Diversity can increase the friction in the process, but that is okay. They emphasized the need for multiple perspectives see past our initial biases (conveniently covered by Allon in the previous talk).

This transitioned to questions, comments, and thoughts from the audience. One interesting point was using the phrase, “we don’t do that here” to create and set norms. I gave a suggestion to look at projects you already participate in and see if there is a diversity and inclusion effort there already. If there is, see if there are ways to help and get involved. If not, consider starting one (or network with the Open Source Diversity community).

To wrap up, one recurring theme of Serena and Denise’s talk is to make time to step back and evaluate the bigger picture. Questioning our biases is an important skill to practice. We need the space and time to recompute!

Candy Swap 🔗

Do you have a unique sweet dessert or candy from your country or hometown? Do you love to try new and exciting foods from around the world? Spend an hour with fellows as we share stories and candies from the world with each other. Participants are invited to bring a unique confectionary or candy from their country or city to share with multiple other people. Before going around to try yummy things, all participants explain what item they bring and any story about its origins or where it is normally used. After sharing, everyone who brought something rotates around to try candies brought by others. After all participants have had a chance to sample, the rest of the community is invited to come and try anything remaining.

Jona Azizaj, Justin Wheeler

I am biased when I say this is one of my favorite parts of conferences I go to. Jona originally proposed the candy swap for DevConf CZ. After unexpectedly adding DevConf CZ to my travel list for 2020, we teamed up to share the sweet tradition from Fedora Flock to DevConf CZ! This is one of my favorite conference traditions because I get to know other attendees in a context outside of technology. And food is always an easy way to win me over.

Instead of listening to me, see what other people have to say about it:

Time for the international candy swap! There are so many things to love about #DevConf_CZ but the geographic diversity of attendees might be my favorite part. Thank you for organizing, @jonatoni & @jflory7! pic.twitter.com/rU1ETp5aTa

— Mary Thengvall (she/her); mary-grace.bsky.social (@mary_grace) January 25, 2020

The "sweetest" activity of #devconf_cz: Today at 3 PM! 🍬🍫
Join Candy Swap, share candies, sweets and stories with others from around the world! https://t.co/OlfdmgGa3a pic.twitter.com/Jnlqi3lsaq

— DevConf.CZ (@devconf_cz) January 25, 2020

Candy Swap time at #DevConf_CZ 😍 pic.twitter.com/zFCNnXZoJf

— Jona Azizaj👩🏻‍💻 🥑 @jonatoni@mastodon.social (@jonatoni) January 25, 2020

Well I experienced this for the #Flock 2019. It's a great opportunity to know the tastebuds of diverse people and enjoy! :D

— Aal (Alisha)🌻 (@withloveaal) January 26, 2020

From Outreachy to cancer research 🔗

Outreachy program is helping women and other underrepresented people to make first steps in tech career. Picking a project, making first open source contributions, working on assigned project and learning from advanced people. But what happens when this three months are over? Can Outreachy be a lifechanging experience?

I will share my story of conversion from a chemist and full time parent into a Fedora Outreachy intern and how I found my place as a junior software developer in cancer genomics research at IRB Barcelona.

Lenka Segura

This was a favorite of the weekend. “Fedora Outreachy intern Lenka Segura on how Outreachy opened the door for her career to cancer research at IRB Barcelona!”

I put effort into live-tweeting a Twitter thread. Get the full scoop there!

Connect and grow your community through meetups 🔗

Open source communities collaborate in a multitude of ways - chatting on irc, submitting issues and contributing code on GitHub, discussing and sharing ideas on reddit and other social channels. Face to face gatherings add another dimension to that, where community members can learn and share their experiences. Local meetups provide a venue for people with similar interests to socialize and connect. However, organizing meetups is not trivial. How do we encourage and motivate the community to arrange meetups, and to keep the momentum? In my one year with the Ansible community, we have doubled the number of active meetups in Europe. These meetups are community driven, rather than Red Hat. Find out how we use metrics to analyze the situation and needs, and the steps we are taking to reach our goals of connecting with even more community members. Learn from our mistakes and challenges (100 RSVPs and only 20 turned up?), plus some tips to make your meetups more inclusive.

Carol Chen

Carol explained the role of local meet-ups around the world in building communities around software projects. She emphasized that single metrics are not always useful, so it is more helpful to evaluate on multiple areas. The most useful takeaway for me was the 5 W’s: why, who, what, when, where.

• Why? Common curiosity (noticing something new in your community)
• Who? Connections and networking
• What? Concise, compelling content
  • Consider venue travel (how to make it worth their while?)
  • Provide alternatives to git-based submissions
  • All talks don’t have to be technical! Diversify to appeal to wider audiences
    • Announcements for future events, work-life talks
    • We are more than just the technology we work with
• When? Consistency
  • Helps with venue scheduling
  • Helps retain attendee focus and build habits

Carol also gave suggestions for common points to think about for improved inclusion. All of these need active, not passive inclusion.

• Special needs / disabilities
• Food allergies
• Beverage preference (often alcohol/non-alcoholic)
• Language
• Traffic-light communication stickers
• Photography lanyards
• Gender pronouns

Beyond DevConf CZ 🔗

While the sessions are excellent and fulfilling (and sometimes frustrating when you miss a good talk with a full room), DevConf is also more than the sessions. It’s also the people and conversations that happen in the “hallway track.” It was nice to see many old friends and make new ones.

I spent a few extra days before and after DevConf CZ in Brno. In some of that time, my colleague Mike Nolan and I rehearsed in-person for our FOSDEM talk the following weekend (to come in a future blog post). I also enjoyed coffee and waffles with Marie, Sumantro, and Misc!

A few memories of a great week in Brno

Until next time! 🔗

I learn a lot and have a lot of fun at DevConf CZ. I’m happy to return for a third year. Hats-off to the organizers and volunteers who pulled it all off. Each year, DevConf gradually makes improvements. It’s nice to see inclusion prioritized across the board.

Thanks also goes out to RIT LibreCorps for sponsoring my trip. Extra thanks to Jona Azizaj!

I never intend to adjust myself to injustice.

“I’m proud to be maladjusted.” https://t.co/TFBiWBy6Xc

— Be A King (@BerniceKing) December 12, 2019

Where Byfield was accurate 🔗

While I don’t agree with all of Byfield’s sentiments, he identified some key challenges that still hold truth today: a predisposition to focus on differences and not similarities, an outreach approach centered on ethics and not software, and the importance of opportunities for intersectional interaction.

Predisposition towards difference 🔗

First, Byfield notes the differing age groups of the activist communities and the tendency for viewing others by their differences first, not their similarities. He seems to attribute the tendency to view others by differences first as a characteristic of older generations; however, this is not necessarily the full truth.

As a member of the young activist community, this explanation is too simplistic of the underlying cause. There is also a political motivation by established power to sow division among the population of a nation-state. It makes community organizing more difficult and presents diversity as an issue to “solve” instead of a source of greater unity and common strength.

This is exemplified by the social media algorithms of today that reward sensational content (judged on likes, views, clicks, or other user feedback) and share it widely across a huge platform. In 2006, it was difficult to imagine the relationship social media would have in the lives of an everyday person; today, a great deal of social power is granted to those who understand how to leverage social media, either for good (e.g. social activism) or harm (e.g. deceptively persuading large parts of a nation-state’s population leading up to a national election).

The politics of division are within the fabric of our political systems; this is a challenge for modern-day activism and community organizing to overcome. In identifying this as a challenge, Byfield is correct that a differences-first approach makes it harder to share and spread the importance of FOSS in other activism circles, especially as technology becomes an increasingly relevant way of how we experience our lives and how our systems of law and justice are enforced.

Outreach on ethics, not software 🔗

Second, Byfield suggests an ethics-based approach to outreach is more effective than a software-based approach. This is also correctly noted, even if perhaps overemphasized. The jargon and language of the technology world is not accessible to the large majority of the global population. While some degree of technology literacy might be expected in some populations, much of the existing FOSS community is deeply rooted in technology. Sometimes this limited perspective is counterproductive.

This revisits the rebranding of “Free Software” as “open source” in 1997. For many subsets of the wider open source community in 2019, the default approach to open source software is merely a secondary thought for how to collaboratively work on technology. This is part of the outcome of the Open Source Initiative’s gamble in 1997 by beginning to emphasize the business sensibility and practicality of open source, and de-emphasize the social roots of Free Software (or rather, try and position itself as some sort of translator between these two “worlds”, as if they cannot be spoken of together in the same room).

As such, those who work on open source software projects are not necessarily predisposed to assume the role of an activist. Truly if Free Software is to take root outside of technology, then those who see the ethical values of Free Software need to better organize and promote the values of FOSS externally. This will contribute to the diversity of Free Software activism by helping non-technology activists add FOSS as a tool to their existing work.

Intersectional movement building is the future 🔗

Thirdly and finally, and perhaps most importantly, Byfield suggests the importance of intersectional interactions between Free Software communities and other activist communities. This is a fundamental requirement for the growth of Free Software as a social movement. Those of us in Free Software see the world around us informed by a background informed by technology; this background is emphasized in a world that is generating new, advanced technology at an unprecedented rate. However, while software and technology are important parts of the world around us, they are not the world around us. They are one part of a greater picture of fighting for a common good and welfare for all people. There are others in similar niches who have a deep understanding of their problem space and how they want to approach a challenge.

“One group may be working against child poverty, another for recycling, but the people in these organizations can almost be transferred from one to the next.”

Peter T. Brown, Free Software Foundation Executive Director (2006)

Just like a healthy garden, cross-pollination of these niches is vital to help others understand how we can help each other in accomplishing our mutual goals (this also feeds into why the politics of division explained above is so pervasive and difficult). Bringing Free Software technologists to activist communities where there is not an overwhelming Free Software background (and vice versa) is vital to building an intersectional social movement that strengthens the social impact of Free Software, not just open source.

Where Byfield didn’t go far enough 🔗

Byfield made one assumption on how activists have “their own share of insularity” and that the presence of connections between two movements does not mean they could immediately connect their existing beliefs with new ones. Fioretti’s challenge was in others understanding why they should listen to him; there was a lack of foundational knowledge of open source and technology that is normally assumed of someone who works as a software engineer.

Indeed, attention is a currency in the world of an activist. It is not enough for a FOSS advocate to expect others to listen to you on an appeal of technology. Part of the work in sharing is understanding who you are sharing with; if FOSS wants to take deeper roots in the activist community, it needs to understand the backgrounds of activist communities and be creative in how to appeal the mission of FOSS to the mission of their work. Where you can build in-roads together with others through common initiatives is the beginning of grassroots community organizing. So, while Byfield is right that there is an almost competitive nature of ideas in activism, it is not enough to write insularity off as a fixed aspect of nature. To not acknowledge this is to deny the influence of capitalist power structures in the humanitarian sector as they pertain to sustainable funding.

What are today’s challenges? 🔗

Some of today’s challenges are about inclusion and power.

Inclusion builds power 🔗

Diversity and inclusion (D&I) are important but poorly understood; not only are D&I about including people of different identities in technology, but also people with backgrounds outside of technology. FOSS stands to benefit by including more people who do not necessarily have a strong technology or engineering background. The goal is to inspire different perspectives to contribute in meaningful ways to build sustainable technology.

Instead of seeing diversity and inclusion initiatives as problematic or unneeded, D&I groups in FOSS communities stand to be the most effective people at building community and influence.

Power and governance 🔗

In the activist / humanitarian / non-profit world, there is a power struggle for sustainability as it pertains to funding. Funding models in non-profit work (usually sustained by grants, sponsors, and donors) encourage solutions that get funded, not necessarily solve problems the most effective way. Many organizations struggle with how to achieve sustainable funding without being so dependent on the expiration date of a grant’s funding.

We need more representative governance models in open source communities that reflect the interests of the communities around them, not necessarily an individual, a company, or group of companies. Building governance models that empower people within a community to make decisions and reduce the corrosive influence of money from humanitarian work.

Where do we go from here? 🔗

This blog post is an active reflection of my own thoughts and perspectives of Free Software, activism, and humanitarian work. If you are interested in pushing this conversation further, find me in Brussels, Belgium for any of the following three conferences and let’s chat further:

• 30 January 2020: Sustain Summit
• 31 January 2020: CHAOSScon
• 1-2 February 2020: FOSDEM

If you want to discuss this further, you can also drop a line in our online discussion community, fossrit.community.

Photo by Walid Berrazeg on Unsplash

However, the times are a-changing! Containers are entering as real players in the HPC space. Previously, containers were brushed off as incompatible with most HPC workflows. Now, several open source projects are emerging with unique approaches to enabling containers for HPC workloads. This blog post evaluates four container run-times in an HPC context, as they stand in July 2019:

• Charliecloud
• Shifter
• Singularity
• Podman

Research requirements 🔗

My research focused around a specific set of requirements. To receive a favorable review, a container run-time needed to meet three basic requirements:

• Support CentOS/RHEL 7.5+
• Compatibility with Univa GridEngine
• Support for very large numbers of users

Obviously there are security concerns with the third requirement. This is one reason containers have not made a strong showing in the HPC world yet. With the Docker security model, root access is a requirement to build and run containers. In a production HPC environment where users do not trust other users, this is a hard blocker.

Other HPC environments may differ. If you are an HPC administrator and also considering containers in your environment, consider my requirements. My research was exclusively framed through these three requirements.

Charliecloud 🔗

Charliecloud is an open source project based on a user-defined software stack (UDSS). Like most container implementations, it uses Linux user namespaces to run unprivileged containers. It is designed to be as minimal and lightweight as possible, to the point of not adding features that could conflict with any specific use cases. This can be a positive or a negative, depending on how complex your environment is.

However, I abandoned my research on Charliecloud early on after reading this PLOS research paper:

The software makes use of kernel namespaces that are not deemed stable by multiple prominent distributions of Linux (e.g. no versions of Red Hat Enterprise Linux or compatibles support it), and may not be included in these distributions for the foreseeable future.

The software is emphasized for its simplicity and being less than 500 lines of code, and this is an indication of having a lack of user-driven features. The containers are not truly portable because they must be extracted from Docker and configured by an external C executable before running, and even after this step, all file ownership and permissions are dependent on the user running the workflow.

Singularity: Scientific containers for mobility of compute, May 2017 (Gregory M. Kurtzer, Vanessa Sochat, Michael W. Bauer)

However, it is worth noting this paper was written in support of Singularity. It was also written by the Singularity project lead and others from the Singularity open source community. If you are conducting your own independent research, consider looking closer at Charliecloud, since at the time of writing it is still actively developed. The research paper was written in May 2017.

Edit: This situation already changed and Charliecloud is probably worth a deeper look:

This is a fantastic write up, one thing to mention is that abandoning the CharlieCloud research based solely on lack of support of the user kernel namespace is no longer a blocker. For example, PodMan now uses the same technology and it was released in RHEL8.

— Apptainer (formerly Singularity) (@SingularityApp) August 20, 2019

Shifter 🔗

Shifter is another container run-time implementation focused on HPC users. At time of writing, it is almost exclusively backed by the National Energy Research Scientific Computing Center and Cray. Most documented use cases use Slurm for cluster management / job scheduling. Instead of a Docker/OCI format, it uses its own Shifter-specific format, but this is reverse-compatible with Docker container images. It requires hosting a registry service and a Shifter Image Gateway.

The Shifter Image Gateway is a REST interface implemented with Python Flask. It pulls images from the registry service and converts them to the Shifter image format. MPI integration is supported but its implementation is MPICH-centric.

The downside to Shifter is lack of community. There are not many other organizations other than NERSC and Cray that appear to support Shifter. Documentation exists, but at writing time (July 2019), the last significant contribution was April 2018. Some bugs and feature requests are triaged, but there is not much of a maintainer presence in these issues. Most follow-up discussion to new issues are from a handful of outside contributors without commit access.

Additionally, there are several signs of stagnant development, such as NERSC/shifter#172 to add better MPI integration. However, the PR stalled out since it was first opened in April 2017. Furthermore, there is a high bus factor: most contributions and pull requests come from the same two developers, indicating low engagement from the wider HPC community. Code is regularly tested, but integration tests only exist for Slurm. For more details, check out the GitHub project pulse.

A detail worth noting is Shifter was one of the first real container run-times for HPC. A former Shifter collaborator branched off from Shifter to start Singularity (and eventually, a for-profit company to support it, Sylabs). It invites room for personal biases when evaluating Shifter and Singularity, specifically if you are not a newcomer in the HPC community.

Singularity 🔗

Singularity is the third and last HPC-specific player in the container run-time world. The vendor is Sylabs Inc. There are a few different factors that make Singularity interesting, and in my opinion, the most promising HPC container implementation.

General overview 🔗

Singularity v3.x.x is written almost entirely in Golang. It supports two image formats: Docker/OCI and Singularity’s native Single Image Format (SIF). As of September 2018, there are an estimated 25,000+ systems running Singularity, including users like TACC, San Diego Supercomputer Center, and Oak Ridge National Laboratory. Additionally, Univa announced a partnership with Sylabs in July 2018 to bring Singularity workflows to Univa GridEngine.

Sylabs offers Singularity (free and open source) and SingularityPRO (paid and proprietary). The commercial version comes with a support contract and long-term support for some releases (among other things).

Admin/root access is not required to run Singularity containers and it requires no additional configuration to do this out of the box. Containers are run under the Linux user ID that launches them (see Security and privilege escalation).

At a quick glance, Sylabs developers appear to be actively engaged in the Kubernetes development community, particularly around Red Hat technology. They also seem to keep their promises: in early 2018, blog posts show ambitious feature promises for the then-upcoming v3.0.0 release at the end of the year. Near the end of 2018, the release was delivered on-time with most/all of the promised functionality.

Image formats 🔗

The Singularity Image Format (SIF) is a single-image format (i.e. no layers involved). This was a design decision specifically for HPC workloads. SIFs are treated like a binary executable by a Linux user. Additionally, it is possible to create SIFs using the Definition File spec.

However, Singularity is also compatible with Docker/OCI images and OCI is given active development focus by upstream Singularity. Docker/OCI images are converted on-the-fly to a SIF. Docker/OCI images can be used locally or pulled from a remote registry like Docker Hub or Quay. To the user, if using a Docker/OCI image, the conversion is seamless and does not require additional configuration to use.

See this Sylabs blog post for a deeper dive on how SIFs were designed.

Flexible configuration 🔗

Singularity (uniquely?) offers advanced configuration options for HPC administrators. Some highlights are detailed here:

• Controlling bind mounts:
  • mount dev = minimal: Only binds null, zero, random, urandom, and shm into container
  • mount home = {yes,no}, mount tmp = {yes,no}: Choose to enable or disable these bind mounts globally
  • bind path = "": Bind specific paths into containers by default
  • user bind control = {yes,no}: Allow users to include their own bind mount paths or limit it to an admin-approved set of paths (above)
• Controlling containers:
  • limit container paths =: Possible to limit SIFs provided at a specific path and nowhere else

HPC community engagement 🔗

These notes only apply to Singularity free, not the proprietary SingularityPRO product.

The signals from their open source community engagement are positive and strong. They appear authentic and genuine to an open source commitment (i.e. not open-core business model). This is demonstrated in a few ways:

First, they have thorough user documentation, intended for end-users in HPC environments using Singularity. They have a less thorough but still useful admin documentation.

Second, all issues are triaged quickly and get feedback from core developers or outside contributors at a consistent pace. Pull requests don’t stagnate either: the oldest PR is less than six months old.

Third, code is regularly tested (1, 2). The code generally follows best practices (i.e. it is not atrocious to work with).

Fourth, there are also a handful of active contributors (both developers and in the community support channels) who come from outside of Sylabs, which indicates more engagement by a wider audience of people.

For more statistics, check out the GitHub project pulse.

Podman 🔗

tl;dr: Podman is an underdog that shows promise, but likely needs another one or two years of time for most HPC use cases.

Podman is a container run-time developed by Red Hat. Its primary goal is to be a drop-in replacement for Docker. While it is not explicitly designed with HPC use cases in mind, it intends to be a lightweight “wrapper” to run containers without the overhead of the full Docker daemon. Furthermore, the Podman development team is recently looking into better support for HPC use cases.

Podman is currently lacking for a HPC use case for some of these reasons:

1. Missing support for parallel filesystems (e.g. IBM Spectrum Scale)
2. Rootless Podman was designed to use kernel user namespaces which is not compatible with most parallel filesystems (might change in a year or two)
3. Not yet possible to set system site policy defaults
4. Pulling Docker/OCI images requires multiple subuids/subgids (might change in a year or two)

Where Podman does shine is providing a way to run and build containers without root access or setuid.

The same challenges and problems required for Podman to run OCI containers in an HPC environment are the same problems faced by Singularity to build SIF images without root in the HPC environment: mapping UIDs to subuids/subgids on the compute nodes. More interestingly, Buildah offers a promising way to enable users to build container images as Docker/OCI images all without root. It is plausible to use Buildah as the container image delivery mechanism and swap out the container run-time implementation (Podman vs. Singularity) depending on specific needs and requirements.

What do you think? 🔗

I hope other folks out there in the HPC world find this preliminary research useful. Do you agree or disagree with any parts of this write-up? Is something out-of-date? Drop a comment down below.

Use alt tags for Markdown images 🔗

Often an embedded picture in Markdown looks something like this:

![Screenshot_2019-06-14.jpg](https://example.com/Screenshot_2019-06-14.jpg)

When you render the Markdown, you see your picture. However, you don’t see the Screenshot_2019-06-14.jpg string. You might wonder what its purpose is or why bother changing it at all. But imagine for a moment if instead of seeing your picture when you rendered your Markdown, you only saw Screenshot_2019-06-14.jpg where your picture should be. Screen reader users often encounter this problem.

So instead, describe your Markdown image so a person that uses a screen reader can also follow the conversation:

![A flowchart describing how user data flows from a publisher, to a proxy, and to a group of subscribers](https://example.com/Screenshot_2019-06-14.jpg "A flowchart describing how user data flows from a publisher, to a proxy, and to a group of subscribers")

It takes an extra few seconds of your time, but it is one small way you can help make a better Internet for everyone.

P.S. – The text wrapped in quotation marks between the parentheses adds the title HTML attribute to your image, so the text appears as a tooltip when you mouse over the image. The more you know!

Photo by Roman Kraft on Unsplash

This article introduces Ehlers-Danlos Syndrome, its symptoms, how to support someone living with EDS, and simple actions anyone can take to help.

Ehlers-Danlos Syndrome: What is it? 🔗

Ehlers-Danlos Syndrome is an inherited, genetic disorder caused by a defect in how the body produces collagen. Collagen is a protein that the body uses and depends on for producing connective tissue. It’s like the “glue” of the human body, keeping skin together and in proper form.

Hyper-mobility is one of the most common symptoms. “Double-jointed” is one way to describe hyper-mobility, but it’s not really the same thing. Moderate to severe chronic joint pain is common. Depending on the classification of EDS, there are a variety of chronic symptoms, ranging from frequent tearing of muscles to heart disease.

Ehlers-Danlos Syndrome is not easily visible from the outside. You can look at someone who has EDS and never realize they live with a disability. For these reasons, it’s known as an invisible illness. Invisible illnesses come with an extra challenge as the person with the disorder or disability physically looks fine, but may suffer from extraordinary amounts of pain that an observer can’t see.

For a moment, imagine you’re fighting the flu and obviously not feeling well. When you give an excuse for work or school, someone tells you, “Oh, just shake it off, how bad can it be?” Obviously, you’d think they’re crazy—you have the flu! You can hardly get out of bed! But what if this was the way things were, if you were told this whenever you were sick? This is a glimpse of what it’s like living with an invisible illness.

Today, not much is known about Ehlers-Danlos Syndrome. There isn’t much research on it and there is no known cure (although stem cell research seems the most promising solution). Those living with EDS usually use external support (e.g. wheelchairs, bracing, etc.) or different forms of therapy to help manage the illness.

Living with Ehlers-Danlos Syndrome 🔗

Those living with EDS face daily struggles that affect how they are able to live their life. There are countless testimonies online about what it’s like to live with Ehlers-Danlos Syndrome. Some days, the pain is crippling to the point where it is almost impossible to leave bed. You can read stories from those living with EDS at the following pages:

• rarediseaseday.org
• librarianinblack.net

Supporting someone with EDS 🔗

If you know someone living with Ehlers-Danlos Syndrome, it’s difficult to know how to support them. Since not much is known, one of the most important steps you can take as a caretaker is to learn what you can about EDS and how your loved one is specifically affected by it.

Reaching out to online communities or searching for resources are some ways to help you develop your own personal “toolbox” for helping your loved one. The Ehlers-Danlos Society has information you can read about being a caretaker and how to help someone with EDS and yourself.

Work on developing your own listening skills and mutual, two-way communication. You need to develop patience as both you and your EDSer learn and experience life with EDS. Counseling on how to best communicate can be a valuable resource. Be willing to accept your own feelings and emotions too. Your feelings are not invalidated as a caretaker either, and accepting this will help both you and your EDSer.

Above all, remember that your loved one is more than their illness. There’s more to life than Ehlers-Danlos.

What you can do now about EDS 🔗

Information is valuable. Information is never easier to find than in the twenty-first century. But imagine not being able to know: to search Google and not find an answer about something you face everyday. For something like “how to feel better” or even how long you’ll live. Information and research is one of the key needs of the Ehlers-Danlos community around the world. The Ehlers-Danlos Society is a 501c3 non-profit organization that drives research and education initiatives, awareness campaigns, advocacy, community-building, and care for EDS patients.

You can consider making a direct donation. A recent deliverable was the 2016 Ehlers-Danlos Society International Symposium, with the goals of updating the diagnostic criteria of EDS and developing standards of care that are missing in professional medical practices.

Shop on Amazon? If not a direct donation, consider using AmazonSmile to have part of your Amazon costs donated to the Ehlers-Danlos Society. Amazon will donate 0.5% of the price of your eligible AmazonSmile purchases (side note, they’re listed by their previous name, “Ehlers-Danlos National Foundation” in AmazonSmile).

Zebra by m. turan ercan from the Noun Project

Dedicated to someone who taught me to see life from another perspective

Special thanks and appreciation goes to Tim Zabel and Nic Hartley for their contributions this release cycle.

What’s new 🔗

• Bold usernames in message prefixes (#134, Nic Hartley)
• Include filetype in IRC string when a document is uploaded on Telegram (#139, Tim Zabel)
• Include zero-width space in username for join/part messages to group (#139, Tim Zabel)

Additionally, contributor documentation improved. I added contributor guidelines and instructions to set up a development environment. Also, our friends at Ura Design designed our new project logo. Thanks to Ura, we have an awesome project logo and stickers in time for Imagine RIT 2019 later this month!

They're here! Check out our new @uracreative logo and stickers for the #TeleIRC project. Grab some stickers at the @RITlug @Imagine_RIT festival on April 27! pic.twitter.com/KGjT4F0qdY

— RIT Linux Users Group (@RITlug) April 17, 2019

TeleIRC v1.3.1: sprint retrospective 🔗

Originally, we planned to release v1.4 at the end of this sprint. For a number of reasons, this did not happen. We decided to reduce our scope and finish strong with a bugfix release instead of the originally-planned feature release. This retrospective summarizes “lessons learned” for future project sprints with a team of university students.

Extended holidays are sprint bookends 🔗

In the last sprint, our university had a week-long break from classes. Most students use this time to visit family or travel outside of Rochester. Originally, we agreed to pause the sprint and resume when we returned. In retrospect, it didn’t work out like that.

It was harder to start again when we returned from the break. Instead of an extended holiday acting as a pause in an ongoing sprint, extended holiday breaks should divide two separate sprints. The breaks from classes are personal time; working on projects is not possible for everyone. The interruption caused by a break impacts productivity of the team. Therefore, future sprint planning will take the university calendar into consideration.

Adjustable sprint length to semester 🔗

Sprint lengths should have an adjustable length depending on what part of the academic semester the sprint is. For example, earlier this semester, we released v1.3 in a two-week sprint. For this v1.3.1 release, it was over a month. What happened? Should sprints have a variable length?

When working with an academic crowd, variable sprint lengths are worth considering. The first half of a semester typically has less assigned coursework. Final projects are not at play. Therefore, usually team members have more time to invest in the project at the start of a semester. Towards the end of the semester, coursework and class projects pile on and make it difficult to find bandwidth to work on side projects like TeleIRC.

The compromise is keeping our sprints short at the start of a semester and stretching them out as a semester goes on. This gives students more flexibility to work at a pace that encourages quality work but isn’t overwhelming with other responsibilities of being a student. Going forward, we will try variable-length sprints in the Fall 2019 semester.

Get involved with TeleIRC! 🔗

More opportunities are coming to participate with TeleIRC! The team is happy for new people to join us. Opportunities are available for short-term and long-term contributions.

Come say hello in our developer chat rooms, either on IRC or in Telegram! Watch for TeleIRC development reports on my blog for more announcements.

Background photo by Daria Nepriakhina on Unsplash.

What’s coming in TeleIRC v1.4 🔗

TeleIRC v1.4 is the next feature release of TeleIRC. The targeted release date for v1.4 is by the end of April 2019 (i.e. the end of the academic semester for students involved with the project). Following v1.4, the project will likely enter brief hibernation until Fall 2019 when the RIT academic semester begins again.

At the developer meeting on March 23rd, we discussed the scope of this sprint and what we felt is realistic for project maintainers to work on:

Primary goals 🔗

• Include limited characters from Telegram replies in relayed IRC message (RITlug/teleirc#51)
• Create doc page on development environment (RITlug/teleirc#77)
• QoL Improvements: show file-type of documents in IRC, insert ZWP character in join/leave messages (RITlug/teleirc#130)
• Allow user to configure more variables for IRC server connection (e.g. port, SSL certs, etc.) (RITlug/teleirc#113)

Secondary goals 🔗

• Add Telegram-side highlighting for IRC messages prefixed with username (RITlug/teleirc#44)
• Bold usernames on Telegram and IRC (RITlug/teleirc#19)

Recap of TeleIRC v1.3 sprint 🔗

The TeleIRC v1.3 release follows the v1.2.2 release on December 8th, 2018. This release is a significant change in how project development is done. For the first time, a special interest group inside of RITlug exists around the project. The team shifted to an agile-like development practice to fit inside of the RIT student academic schedule.

A special shout-out is earned by Tim Zabel for his support and participation as a core contributor during the v1.3 sprint.

Get involved with TeleIRC! 🔗

More opportunities are coming to participate with TeleIRC! We would love to have more people get involved and participate in the project. There is no formal commitment to contributing, although we ask for participation through a single sprint cycle.

Soon, we will have better new contributor on-boarding docs. Our weekly developer meetings are now happening over public audio/video call each Saturday at 15:00 US EDT, so anyone can join and participate.

Come say hello in our developer chat rooms, either on IRC or in Telegram!

Background photo by Daria Nepriakhina on Unsplash.

Unfortunately, as I write later in this blog post, the “window of inspiration” to finish this draft has closed. So I figured it better to publish it as-is than to let it waste.

Unmodified text: “Nothing will be the same” 🔗

The sun slowly slips into the horizon, darkening the sky as the street lamps and buildings illuminate. On the main road through the city, the taxi works its way through the evening weekday traffic in Sarajevo, Bosnia and Herzegovina. My luggage is stowed in the backseat and I’m seated next to the driver, an older gentleman in his late 40s or early 50s. Unlike other countless taxi rides, the car wasn’t silent inside. The driver was curious. Through gestures, signing, and broken English, we shared stories with each other, about the past, the present, and the future. He asked me about America and the election, and if Americans are really like what is shown in the news. I asked him about life in Sarajevo, and he told me about the problems with employment and people searching for work.

Behind his weathered face, there were eyes that had seen some of the worst tragedy in the region. He lived in the city during the Siege of Sarajevo in the 1990s and remembered Srebrenica in 1995. He lived through years where hate and spite penetrated the hearts of neighbors. Yet, through it all, the man was cheerful and still hopeful. Even from our conversation, he had a resounding hope about the people of Sarajevo. In thirty minutes, I understood a different kind of history in the region than I had during the four years earning my high school diploma.

This is one memory that persists from my experiences over the past five months. On January 17th, 2017, I moved across the oceans to Dubrovnik, Croatia. I studied in Dubrovnik from January until the middle of May.

During the semester and after, there were incomparable experiences that opened my eyes to a world that previously I only imagined. With my experiences with writing, there is a window that is open for a short time. The window is your inspiration. If you look out the window and see something incredible, you are filled with inspiration and you want to capture it. But when you step away, the window only remains open for a short time after. If you miss the opportunity, the window will close and the writing will never reflect it in the same way. This is my cumulative attempt at trying to capture the last five months of my life.

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 🔗

Read on to learn more about what’s coming in TeleIRC v1.3.

What’s coming in TeleIRC v1.3? 🔗

The developers’ meeting focused on identifying critical tasks to work on for the next sprint. The following open issues were identified as essential for v1.3:

• #41: Sending an image with a caption in telegram then editing the caption causes the image to get sent again
• #44: Add Telegram-side highlighting for IRC messages prefixed with username
• #53: multi-line messages should have each lined prefixed with the userid
• #102: Splitting of messages sent to IRC, prepending TG username to each one
• #112: Insert zero-width space in Telegram usernames sent to IRC
• #115: Image url reveals bot’s token
• #118: Refactor documentation into smaller pages (to make it more readable)

Of these, #53 and #102 will be closed by pull request #102. Michał Rudowicz contributed #102 and it should be merged during this sprint window. (Thanks Michał!)

Keep up with more development news by watching the v1.3 milestone on GitHub.

When is TeleIRC v1.3 coming? 🔗

TeleIRC v1.3 is projected for Saturday, March 2nd. For the selected issues, we felt four weeks was sufficient to accomplish and meet all existing goals. If we move faster than expected, we may move items from the v1.4 milestone up to this release.

How can I participate? 🔗

Want to help out or get involved with TeleIRC? We are happy to welcome you! Past contributors have come from all around the world.

Say hello in our Freenode IRC channel, #ritlug-teleirc, or join the Telegram group. You can also look through our “good first issue” tickets in GitHub. If something looks interesting, leave a comment of interest in the GitHub issue and a committer can offer more guidance.

If you are a user and want to share feedback or thoughts with the team, leave a comment on this blog post and they will be shared with the team.

Background photo by Daria Nepriakhina on Unsplash.

I thought sharing it on my blog might be interesting for others. Don’t read into this too much – it was a quick analysis from a single primary source and a few secondary references.

What is Fedora Modularity? 🔗

The Fedora Project is a common Linux operating system which ships software in “packages”. Since June 2015, project members built a pipeline to ship modular versions of existing packages, known as Modularity. Modularity allows someone to use different versions of the same software (e.g. a programming library) on the same system without dependency conflicts.

In a way, Fedora Modularity shifts some responsibility from the Linux distribution (as a provider of known, good combinations of co-dependent packages) to the sysadmin (as a decision-maker to use different combinations of software versions in their environment). It’s more flexible for a variety of deployment requirements. I see it as a net-positive win for the sysadmin experience since its final release.

Why did Modularity fail in 2017? 🔗

However, in this post-mortem from December 2017, a project lead (Stephen Gallagher) announced Fedora Modularity efforts are scrapped for a total redesign. Even though it was not a final release, it was regarded as a failure because of the late status of the project, since its proposal in mid-2015. The post-mortem explained the amount of effort required by all software packagers was significant and also noted the wide amount of engagement necessary from different stakeholders. New requirements and steps to packaging guidelines were not understood by the community of software packagers, and project milestones were not met because of low participation in the packager community.

Their report reveals the amount of moving parts Fedora Modularity must account for. It demonstrated a flawed understanding of user and developer needs during initial feedback from the beta’s implementation. In other words, the level of complexity for the project exceeded the amount of employee resources available to accomplish the project. The redesigned model (proposed in the reflection) pivoted by utilizing existing tools and infrastructure to support the new features, which required less changes for new software package updates. Thus, the packager community was better able to participate in providing new functionality in existing packages.

Additionally, sufficient documentation of new guidelines was unavailable to users, stemming from lack of engagement and feedback by existing users. This was later remedied with user experience testing through events like Test Days, which allowed any community member to try out new features and functionality with their own packaging workflows.

Since the project was finally implemented in late 2018, it was better received in the community than the failed launch in December 2017. Most success since the first failure came by simplifying project requirements (e.g. by leveraging how existing infrastructure was designed instead of reinventing the pipeline) and getting more user feedback on a regular basis (e.g. with community outreach events like Test Days and classroom sessions hosted live on YouTube).

Gallagher, S. (2017). Modularity is Dead, Long Live Modularity! Fedora Community Blog. Retrieved from https://communityblog.fedoraproject.org/modularity-dead-long-live-modularity/

I created this for the RIT Linux User’s Group (a.k.a. RITlug). RITlug welcomes student-led projects for members to work on together. RITlug executive board members want to better encourage students to share and join projects for collaboration with the community (in the spirit of FOSS). To do this, the executive board members will create and offer both a template website and template documentation tools to introduce students to project development process. Then, students are better able to sustain a more diverse community around their projects.

“Start writing ReStructuredText already!” 🔗

The philosophy with this small project is: “Start writing ReStructuredText already!” I use Sphinx with ReadTheDocs as a deployment option across different organizations. I want a common base to later customize for a specific project’s needs.

The whole point of this project is to save time kicking off a new project’s recently-established documentation effort.

Sphinx Travis CI testing configuration included 🔗

Complex documentation tool chains need simple validation of successful builds. This avoids long periods where documentation may not build and the public docs are out of date. It also better engages core contributors to monitor and take care of their documentation.

A Travis CI configuration is included. Fork this repository and enable the repo on travis-ci.org to start running builds.

Add a star on GitHub 🔗

Does this sound helpful? Check it out and add a star at justwheel/sphinx-docs-opinionated-quickstart. The project is licensed under the BSD 3-Clause License; feel free to fork it and form your own opinions too.

Photo by Jānis Skribāns on Unsplash.

The shared context is the most valuable piece of the conference. As a first-time attendee, I was blown away by the depth and range of topics covered by attendees. This blog post covers a narrow perspective of Sustain OSS through the sessions I participated and co-facilitated in.

Speed breakout groups 🔗

The morning started with speed breakout groups of between six to twelve people. Several attendees acted as facilitators for discussion on special topics. Every attendee could about half of all groups. I took extensive notes in the following groups:

• Charitable participation in open source
• Diversity and inclusion
• Turning open source projects into sustainable projects / companies
• Design in open source
• Open source financial sustainability models

Sustain OSS: High-level takeaways 🔗

To save you time, these are my high-level takeaways across all breakout groups I participated in:

• Open source isn’t something just done in people’s free time

• Complex systems can enable systemic bias in terms of what “open source” means

• Sustainability as topic of first priority / consideration, not an afterthought

• There is no “silver bullet” solution to any of these challenges; they all require adaption to work across communities, projects, and organizations

Charitable participation in open source 🔗

This breakout group focused on the connection between charitable organizations and free software projects. It was facilitated by the esteemed Karen Sandler of the Software Freedom Conservancy.

Overall, the conversation was split among creating ethical software, finding sustainable funding models, and balancing how much control to relinquish as a managing organization of an open source project. Some felt pride and ideology were strong drivers for contributors to ideological projects (which also mirrors my experience at UNICEF). These could be key motivations to understand for contributors. Additionally, the challenge around sustainable funding models was common across charitable foundations focused on free software. Grant funding is a common strategy employed by charitable organizations, but the short-term nature of grants puts additional strain on resources to continue searching for new funding. Lastly, for charitable organizations overseeing or supporting free software projects, there was uncertainty over how much control should be left to projects. Attendees generally expressed a desire to let projects do what they want, but it sometimes came at the risk of additional overhead for the organization when everyone does something of everything. The concern over toxic communities came up, and how some issues remain buried until farther along in a relationship with a project. One successful solution employed was to hold monthly meetings among all member projects of an organization to address difficulties.

One interesting detail that captured my attention: one attendee noted how extensive effort into fundraising campaigns targeted to members of a foundation actually increased member engagement with the foundation.

Diversity and inclusion 🔗

My biggest takeaway from this session was the danger in thinking of open source as something we do in our free time. This can be exclusive to different genders, races, and socioeconomic statuses. Some “free time” is more equal than others. The actionable piece for me is to be more conscious in building and growing communities to support different levels of contribution in a community.

The question I wanted to explore after reflecting is to ask of those who feel disadvantaged:

• What factors makes a project more or less inviting for you?
• What can we do better when designing for participation in our communities?

Turning open source projects into sustainable ones 🔗

My notes weren’t thorough on this session, but there was an interesting point on trademark that came up during discussion of the Commons Clause. One participant was pursuing trademark law to enforce commercial protections and sustainability. They gave an example of a large corporation advertising support with a major open source project (e.g. a major software/hardware vendor supporting a specific NodeJS version). They wanted to use this as a way to create a more financially sustainable model for some projects.

Design in open source 🔗

This breakout group focused on sustainable design and design practices in open source communities. The role of designers in technical projects was also discussed and how we can build technical communities to be more inclusive for designers. It was facilitated by Elio Qoshi.

My takeaways from this breakout were that established ways of working can be unfriendly to designers and there is a need to emphasize diversity across different roles in a project or organization. Certain tools, platforms, or other mechanisms for contributing have poor user interfaces. They can push people away because of barriers to contributing with a frustrating user experience. Next, the need for diversity in roles was noted, with an example of engineers leading project management. Sometimes bias or oversights afforded as an engineer accidentally excludes others like designers or writers from contributing to our project. We should endeavor for people to spend more time on their preferred and most effective methods of contribution.

Financial sustainability models 🔗

This breakout session focused on the traditional sense of sustainability: in finances and resources. Attendees discussed different models used to fund open source projects and foundations. The session was facilitated by the founder of the MusicBrainz project, Robert Kaye.

The model used by MetaBrainz essentially as a data broker was interesting and unique. MetaBrainz offers commercial data usage at a cost, and companies using their data have a strong need for the data and see value in it. Through other parts of their model since changing three years ago, they had significant gains in their revenue and were able to increase paid staff working on the projects.

The Amazon invoice cake is also an amusing story, but you should ask Robert directly about it.

Hour breakout sessions 🔗

After lunch, attendees participated in two hour-long breakout sessions to explore specific topics in greater detail.

Human aspect of governance 🔗

Longer form notes are available below. I won’t go into detail since it has its own document with notes and highlights.

Human aspects of open source governance - Sustain OSS London 2018Download

University engagement 🔗

Together with Josh Greenberg of the Alfred P. Sloan Foundation, we co-facilitated a spontaneous session on how universities can engage with open source communities and vice versa.

In our session, two major topics were discussed:

• Education (e.g. curriculum, institutions, programs, etc.)

• Research

We asked all participants why they decided to participate and what questions they had, even though we weren’t able to answer all of them:

1. How do we get the word out?
2. What research is most valuable for open source?
3. How to long-term sustain projects?
4. How to actually do and support research?
5. How to engage both students and faculty?
6. How to harness / enable institutions to make positive contributions to ecosystem?

For education, we agreed that introducing and teaching open source in curriculum better serves students and the institution (both financially and in career satisfaction). Many technology companies today are participating in open source and it is an important skill to have for students entering the workforce. For research, students are already doing research and proposing topics, so better student engagement in open source is better for research.

Our takeaways were to better engage with existing organizations working on these problems for years already (e.g. POSSE), shifting the perspective of universities to be stewards of FOSS, and using collegiate hackathons as a way to better engage with undergraduate students.

One additional point that stood out to me was the emphasis across all breakout participants for a need of good communication skills to be successful. In many cases, the companies hiring top tech talent (from our breakout attendees) listed this as most desirable skill. Technology and new skills can be learned, but teaching good communication skills and how to work collaboratively are not easily learned.

Other takeaways 🔗

One takeaway I couldn’t fit elsewhere was my changed perspective on “technical” vs. “non-technical” work. The phrase “non-technical work” implies an “other space where development does not occur”. Does the phrase place unequal priority on technical work? One action item is to avoid using “non-technical work” as an umbrella term, and instead call these areas by what they are: design, documentation, writing, marketing, community building, etc.

For me, I still want an umbrella term for these things, but I’m open-minded for better alternatives to non-technical.

Skill share: conflict resolution 🔗

The last event of Sustain OSS was a 1x1 skill share. Roughly half of the attendees identified a “skill” they could teach someone else in the room. The other half of attendees paired with someone teaching a skill they wanted to learn more about. I paired with Jono Bacon on a short breakout on conflict resolution.

Jono detailed steps of working through and resolving conflict, including how to identify root problems, how to make steps to resolve them, and some personal philosophy of how we build and maintain relationships with others.

An important first step is to identify the critical point: this could be an ongoing crisis, dealing with interpersonal conflict, or dealing with burnout. When someone is explaining a problem, listen fully to them and understand what they are saying. Let them get it off their chest. Is there something else causing this behavior? Tap into the cloud of ranting and determine what the root cause is.

Once common ground is established, make a plan to resolve it. Jono’s advice was to create written next steps and be explicit about expectations. This way, everyone is on the same page of what the next steps are and everyone involved has signed off on these next steps (this creates a sense of commitment and the next steps become written as “law”). Encourage others to restate the goals of conflict resolution in their own words. Once you have written goals and expectations, the crucial next step is follow-up. Check in on a regular basis with the person or people involved. Try to be neutral and unbiased when listening to others in these conversations. Go in with an open mind.

Lastly, we contextualized conflict resolution in personal philosophy of how we build and maintain relationships with others – both in and out of our open source projects. Sometimes the best way to address difficult interpersonal problems is to stop avoiding them and simply address them. Much easier said than done, but otherwise there is no escaping the perpetuated cycle of conflict if someone doesn’t make a first step.

It’s not just about code.

Thank you 🔗

To wrap up this Sustain OSS report, a few obligatory thank-yous are needed:

• Sloan Foundation / Ford Foundation: For the financial support I needed to attend and participate in the event – this is never something I take for granted and I am happy to have received a scholarship to attend and participate

• Josh Greenberg @ Sloan Foundation: For helping me get over some imposter syndrome and co-facilitate the university engagement breakout session with me – thanks for the gentle push

• Robert Kaye @ MetaBrainz: For being generally awesome and finally giving me someone to nerd out about all these crazy ideas of how free culture and music can actually be related!

• Stephen Jacobs: For always being supportive for yet another trip abroad and helping me map a strategy to get the most out of Sustain OSS

Sustain OSS gave me a lot to think about and consider. I’m glad and fortunate to have attended. I hope this event report gives additional visibility to some of the conversations held in London this year.

The entry is lifted out of my journal with minimum edits. I thought about fully revising it or updating it before publishing. Many parts I would write in a different way now, but I decided to let it be. It reflects my perspective at that particular moment and time at 19 years old. It is more personal than other posts I’ve published and maybe it’s a little uncomfortable for me to share, but I felt like it was worth doing anyways.

entry002: 2017-02-12 🔗

Picking up the pen to write in this is always difficult because it feels like there’s too much to say. Part of the problem is that I don’t write frequently enough, which I’ll try to improve. Not everything worth saying needs to be publicly lambasted.

I left the apartment for coffee after again reading the story of Seth Vidal, a founding developer of YUM and a one-time Fedora superstar. Seth was killed in a hit-and-run accident while cycling in 2013.

What strikes me so much about Seth isn’t just the work or code he left behind, but his legacy. There is no shortage of blog posts dedicated in his memory, with many written by folks I see regularly in Fedora. He is held in a high respect and regard not only because of his work, but how he worked with people. He was clearly a sincere friend of many in the community and always knew how to use and share his brilliance to bring out the same brilliance of those he worked with. He wasn’t afraid to speak his mind, but he always did so courteously and in a way where there was a next step or improvement. As one memoir quoted him as saying with a cocked head and a smile, “Are you sure that’s what you want to do? Because I’m pretty sure it’s not.”

It’s odd for me to read about Seth and how connected to him I feel, despite his death occurring well before I was anywhere near where I am now. Maybe it’s because I, like [thousands] of others, use his software. But more likely is because I see the type of impact and legacy is something I wish to share. Not having so many people write memoirs of my passing, but more about how many lives, communities, and people he touched. I see a man you could approach with anything, whether he knew you or not, and he would give you his honest opinion to help drive or motivate you to success. It may not be what you want to hear, but it will be what you need to hear. Again, delivery of that message is critical, and Seth seemed to be pretty good at it.

I may not know Seth, nor will I ever, but his legacy gives me a strong reminder about what I hold important and how I want to carry out my presence in the projects I’m involved with. If more people want more Seth Vidal’s in the world, then we need to [understand] his values, compare them to our own, and build those values into our own being. This is part of the idea of actively shaping and adapting our values, and never settling with the way we are because we think we know these things. If the mind is open and willing, we are always learning, and thus, always changing.

In summary? Seth’s light fades out and burns into embers, but it never dies. His legacy will always be there, for friends to remember and strangers to learn from. Amidst all of this panicked writing I have to do after DevConf and FOSDEM, Seth’s legacy levels me and reminds me of what’s important. Sometimes what’s really important is logging off and going for a bike ride, or a coffee with notebook and pen, or sharing precious time with loved ones. Seth, you may be gone and have no memory of me, but I have your memory, and I hope you are with me too.

Justin Wheeler

Making graphs is easy. Making intuitive, easy-to-understand graphs? It’s harder than most people think. At the Rochester Institute of Technology, the ISTE-260 (Designing the User Experience) course teaches the language of design to IT students. For an introductory exercise in the class, students are tasked to visualize any set of data they desire. Students David Kim, Jathan Anandham, Justin Wheeler, and Scott Tinker used the MusicBrainz database to look at how five different Queen songs went mainstream in different ways.

Five factors of Queen 🔗

Our mini data science experiment decided to look at five unique data points available to us via MusicBrainz Works:

• Number of recorded covers
• Number of artists who covered a song
• Release year
• Year of last recorded cover
• Time elapsed between release year and year of last recorded cover

Originally, we looked at songs from different artists, but decided to look at five recordings from the same artist. With Queen being a notoriously famous band, there were several data points to work with in terms of how often a song was covered.

Making sense of the data 🔗

A few explanations are necessary for some of the data, especially the difference in number of covers and number of artists. Don’t Stop Me Now, Fat Bottomed Girls, and We Will Rock You had the same number of recorded covers as number of artists who have covered the song. Why were Another One Bites the Dust and Bohemian Rhapsody different?

As it turns out, Another One Bites the Dust had more covers than the number of artists who have covered the song. This happens because some artists have covered the song twice (e.g. once on a studio release and another on a live recording release). On the other hand, Bohemian Rhapsody had more artists covering it than number of covers because some recordings featured multiple artists on the same cover (e.g. the 1992 live performance with Elton John and Axl Rose).

The data opens many interesting questions. Why have some songs persisted longer than others (in terms of recent covers)? Have these songs impacted culture and society in different ways? How have they permeated culture? Is there geographical bias in the data?

This exercise was an exploratory assignment, but we had fun visualizing it and ended up learning an interesting pattern in music data.

Check out the presentation and paper 🔗

If you’re interested for the full details, the slides and a short paper about the presentation are available online. They provide deeper context for the research and the visualization details based on different design concepts.

You can see what else David Kim, Jathan Anandham, Justin Wheeler, and Scott Tinker are up to on LinkedIn. Thanks for tuning in to this adventure into music data analysis, powered by MusicBrainz!

Photo by Matthias Wagner on Unsplash.

Growing up with easy access to the Internet grants the privilege of experiencing effortless knowledge and high availability of information. Wikipedia is an example of 21st century cooperation and collaboration. For many, it represents a beacon of free information and self-education. Some might credit it for charting wider participation in the movement towards free content and open resources.

Yet Wikipedia remains a tool of power and privilege, absent for many as societal myths perpetuate in the lives of children. As children are exposed to the Internet at earlier ages, their comprehension and correlation to the real world is in the context of living in a digitized society. In simpler words, everything they ever know always has technology, tablets, smart-phones, and smart devices present. There is no split experience of going from have-nots to haves.

For me, the split experience was my experience. As I became older, information became within click’s reach and a moment of patience. In prior generations, factual information existed in factual places, such as a library or a home study (for those privileged to own encyclopedias in their homes as children). Caught without any reference to support or dissent against a societal myth, the truth remained far enough out of reach for only the most motivated (and privileged) to continue searching for truth.

Today, this process takes seconds. From devices in pockets to sitting at desks. Desks now conveniently feature a computer workstation over “old school” writing utensils, books, and paper. Externally-verified information is available for those who seek truth or supporting evidence to define their own understanding of truth (additionally, misinformation is equally spreadable depending on prior motivations, but will not be covered in this short opinion).

If the answers are so near and available, it enables increased self-awareness among youth. The Internet’s ludicrous goals of a more interconnected species came not boldly, but subtly. It crept into our culture and perception of the world. As more gratis and factual information (academic work, scientific research, investigative reporting, and others, often under free licenses) creeps into the search-able Internet, answers remain convenient with a few taps on an LCD screen. Perhaps today’s youth, privileged to early Internet exposure, have subconsciously understood their perception of information as naturally free and available (with different understandings of what is true or false). For those searching for secularism, the true science remains easy to find and discover.

And thus, the root of the issue. What is the role of privilege? What early childhood development possibilities are created within information-rich societies? Are children better able to cast away their own doubts and suspicions? Do they avoid buying into a system designed to feed from them?

But what of the contrary? What is the experience to go without this privilege? It can be lack of access to information. The perception of information is opposite of naturally free and available, but costly and hidden. The odds are stacked higher against you because of poor accessibility to tools and resources.

But is access to free knowledge like Wikipedia truly inaccessible for even the most impoverished? Since even some of the poorest countries have better access to smart-phones than piped water, exposure to the wider Internet (including Wikipedia) is inevitable. But the timing is late. The critical period of early childhood development is missed. Early childhood development has three phases: conception, the first 1000 days (birth to three years old), and pre-school / pre-primary years. The brain of a child is most sensitive, almost like a sponge, in those first 1000 days. Researchers defend this period’s impact on child-society and community cohesion as critical, even influencing the neurobiology of peace.¹ So then what of those who have the privilege of exposure to technology in those first 1000 days? What of the billions, nearly trillion, dollars of advertising that slip through the cracks of what these children are exposed to? Are we subtly being written before language is even learned?

In this way, the open and closed systems compete in the Internet state. There are positive and negative qualities from both free information and black-box systems in information-rich societies. Wikipedia is a privilege, but it is only one small part of something bigger. A privilege of truth. A privilege of access. A privilege of self-liberation.

¹ Britto, Pia. “Building Brains, Building Futures.” Online webinar, UNICEF, 24 January 2018. Keynote address.

Photo by Clem Onojeghuo on Unsplash.

$ vagrant provision
==> default: Running provisioner: ansible...
    default: Running ansible-playbook...

PLAY [all] *********************************************************************

TASK [Gathering Facts] *********************************************************
fatal: [default]: FAILED! => {"changed": false, "module_stderr": "Shared connection to 192.168.121.3 closed.\r\n", "module_stdout": "\r\n/bin/sh: /usr/bin/python: No such file or directory\r\n", "msg": "MODULE FAILURE", "rc": 127}
	to retry, use: --limit @playbook.retry

Problem: Python 3 by default 🔗

This error appears because Fedora 28 does not provide a Python 2 binary by default. Only Python 3 is provided on the base cloud image. I verified this by SSHing into the Vagrant box.

[jflory@vagrant-host vagrant]$ vagrant ssh
[vagrant@localhost ~]$ dnf list installed | grep -i python

Annoyingly, I must install Python 2 manually in the box each time it fails to provision. Surely, there is an easier way? Fortunately, StackOverflow came to the rescue.

Solution: ansible.extra_vars 🔗

It’s possible to tell Vagrant where the Python binary is located. You can pass the path to the python3 binary manually in your Vagrantfile.

# Provisioning configuration for Ansible.
config.vm.provision :ansible do |ansible|
  ansible.playbook = "playbook.yml"
  ansible.extra_vars = { ansible_python_interpreter:"/usr/bin/python3" }
end

Adding these changes to your Vagrantfile allows Ansible to successfully run on the Fedora Vagrant guest. Python is successfully located.

This is an annoying workaround, but it solves the issue and lets you successfully test and iterate changes on Fedora systems. Here’s hoping the Fedora cloud image maintainers add a default binary for /usr/bin/python to point to /usr/bin/python3 in the future.

Across this spectrum of bold headlines and addicting scrolling, I began to wonder about identity. What determines how we choose to identify where we originate from? What makes us decide to disassociate from our birthplace? What parts of our culture make us proud and content and what parts are like fresh wounds withheld from time and space needed to heal? I started to wonder about my own identity and what it means to me to be defined as an American.

I fight a growing sense of dissatisfaction and disbelief of what I read happening each day. As I read about the United States and how its citizens are represented on a global stage, a feeling of repulsion sinks into my stomach. Society greatly shaped my perspective of what it meant to be an American as I grew up. What is around me now is contradicting: the qualities of inclusiveness and diversity espoused to the identity of being an American are the same qualities I feel are under attack.

One afternoon as I walked back to my Chicago apartment, I passed a Mexican restaurant. As I walked by, I searched for a menu to measure how authentic it would be compared to offerings in Atlanta (I’ve notoriously had a difficult time finding authentic Mexican food north of Virginia). However, I was disappointed, as the choices fell into the category of American-Mexican food and not the authentic dishes I craved.

But even though I continued on and left the food behind me, the restaurant didn’t leave my mind. As I continued to ponder on what it means to be American, I couldn’t get this restaurant, and countless others like it, out of my mind. One of the most unique observations of my travels is how culturally homogeneous so many countries are. From my experience living in Europe and visiting India, the difference of cultural diversity from my American experience was impossible to miss. Each country was mostly shaped by its dominant ethnic group. To see a Nicaraguan in Croatia or a Swede in India would be a memorable encounter because it was outside of preconceived expectations. But in America, I board a New York City, Chicago, or Washington DC subway, and I always remain pleasantly surprised at how unique and different all the passengers are.

But what of the Mexican restaurant? If my train rides reflect this unique cultural identity, what is the significance of the Mexican restaurant and why can’t I forget it?

Suddenly, I realize perhaps American culture is several shards of all other cultures that assimilate here. Instead of the restaurant being an imitation of the real thing, what if it is as real and independent of an experience as the original? Instead of being a clone or a derivative, what if they are their own original craft and subculture? In a way, they are mostly unique – many of the fusions of culture, from food to celebrations, and architecture to film are only found in this sort of combination here.

These pieces of foreign culture are transplanted seeds, taken from their native soil and planted into a new environment. It requires adaption and perhaps creativity too. But these pieces of culture, whether they are motivated to be imitations or not, are created from a place of love and genuine human connection. They stem from a desire to celebrate who we are and where we come from. Furthermore, they offer an opportunity to share these things with others and to pass along the memories and experiences to others in the hopes that they too will see the world from a different perspective, if only for a passing moment.

As I continue to read past another day of headlines, I feel hopeful knowing this spirit of America, although challenged today, remains and exists. In a city like Chicago, it would almost be impossible to miss this range of diversity. While some choose to wrap words of hate and fear around the red, white, and blue stripes of the American flag, I try to remain mindful to keep this flag closer to me too, and wrap it around my values of love and compassion for others, and what it means to me to be an American in this political era.

Managing an open source project is challenging work. The challenge grows as a project grows. Eventually, a project may need to meet different requirements and span across multiple repositories. These problems aren’t technical, but are important to solve to scale a technical project. Business process management methodologies such as agile and kanban bring a method to the madness. Developers and managers can make realistic decisions for estimating deadlines and team bandwidth with organized development focus.

At the UNICEF Office of Innovation, we use GitHub projects boards to organize development on the MagicBox project. MagicBox is a full-stack application to serve and visualize data for decision-making in humanitarian crises and emergencies. The project spans multiple GitHub repositories and works with multiple developers. With GitHub project boards, we organized our work across multiple repositories to better understand development focus and team bandwidth.

Here’s three tips from the UNICEF Office of Innovation on how to organize your open source GitHub projects with the built-in project boards on GitHub.

Bring development discussion to issues and pull requests 🔗

Transparency is a critical part of an open source community. When mapping out new features or milestones for a project, the community needs to see and understand a decision or why a specific direction was chosen. Filing new GitHub issues for features and milestones is an easy way for someone to follow the project direction. GitHub issues and pull requests are the cards (or building blocks) of project boards. To be successful with GitHub project boards, you need to use issues and pull requests.

The UNICEF MagicBox team uses GitHub issues to track on-going development milestones and other tasks to revisit in the future. The team files new GitHub issues for development goals, feature requests, or bugs. These goals or features may come from external stakeholders or from the community. We use the issues as a place for discussion on those tasks too. This makes it easy to cross-reference in the future and visualize upcoming work on one of our projects.

Once you begin using GitHub issues and pull requests as a way of discussing and using your project, organizing with project boards becomes easier.

Set up kanban-style project boards 🔗

GitHub issues and pull requests are the first step. After you begin using them, it may become harder to visualize what work is in progress and what work is yet to begin. GitHub’s project boards give you a platform to visualize and organize cards into different columns.

There are two types of project boards available:

• Repository: Boards for use in a single repository
• Organization: Boards for use in a GitHub organization across multiple repositories (but private to organization members)

The choice you make depends on the structure and size of your projects. For the UNICEF MagicBox team, we use boards for development and documentation at the organization level, and then repository-specific boards for focused work (like our community management board).

Creating your first board 🔗

Project boards are found on your GitHub organization page or on a specific repository. You will see the Projects tab in the same row as Issues and Pull requests. From the page, you’ll see a green button to create a new project.

There, you can set a name and description for the project. You can also choose from templates to set up basic columns and sorting for your board. As of writing, the only options are for kanban-style boards.

After creating the project board, you can make adjustments to the project board as needed. You can create new columns, set up automation, and add pre-existing GitHub issues and pull requests to the project board.

Now, you may notice new options for the metadata in each GitHub issue and pull request. Inside of an issue or PR, you can add it to a project board. If you use automation, it will automatically enter a column you configured.

Build them into your workflow 🔗

After you set up a project board and populate them with issues and pull requests, you need to integrate them into your workflow. Project boards are effective only when actively used. With the UNICEF MagicBox team, we use the project boards as a way to track our progress as a team, update external stakeholders on development, and estimate team bandwidth for reaching our milestones.

If you are an open source project and community, consider using the project boards for development-focused meetings. Additionally, it helps to remind yourself and other core contributors to spend five minutes each day updating progress as needed. If you’re at a company using GitHub to do open source work, consider using project boards as a way to update other team members and encourage participation inside of GitHub issues and pull requests.

Once you begin using the project board, yours may look like this!

Open alternatives 🔗

GitHub project boards require your project to be on GitHub to take advantage of this functionality. However, there are other open source alternatives available. You can use tools to replicate the same workflow explained above. GitLab Issue Boards and Taiga are good alternatives that offer similar functionality.

Go forth and organize! 🔗

Now, you can bring a method to the madness for organizing your open source project. These three tips for using GitHub project boards encourage transparency in your open source project and make it easier to track progress and milestones in the open.

Do you use GitHub project boards for your open source project? Have any tips for success that aren’t mentioned in the article? Leave a comment below to share how you make sense of your open source projects.

Transparency is important to me. I wanted to make this announcement ahead of time to set clear expectations for the upcoming months. I am returning to Chicago, IL to work another internship at Jump Trading, LLC. From June to August, I am working at their Chicago office. I am excited to return and learn more from an amazing team of people.

I am not blocked by company policy from contributing to open source, so I won’t disappear completely. However, while I am still able to contribute to Fedora, I do not expect to keep up the level of activity that I contribute at now during my internship.

Away from May to August 2018 🔗

May is filled with other personal commitments, followed by a near immediate departure to Chicago in early June. Thus, I am stepping out of Fedora in early May. I hope to spend time with friends and family before departing for Chicago, so my estimate is a little generous to the benefit of being realistic. My internship ends around mid-August, so I hope to begin my normal levels of contribution around this time.

The only area I hope to stay partially active with is the Fedora Community Blog to continue my post as the editor-in-chief. While I still don’t expect being fully involved, I hope to help with editing and keeping things moving.

I’m looking forward to seeing familiar faces again in August at Flock 2018!

This article explains changes I made to how I use social media and my smart phone since deleting my accounts. Hopefully you find these tips useful too.

1. Social media on-the-go is a no 🔗

Today’s world is full of content. Videos, friend requests, likes, comments, memes, notifications. We are always connected and online. An endless amount of media, pop culture, and content is at our fingertips. Sometimes this is helpful and convenient, like a quick message to a friend.

But a constant connection can be a drug too. When a convenient escape from a moment always exists in your pocket, this encourages a default reaction of opening the phone and scrolling through Facebook, Twitter, Instagram, Tumblr, or anything that offers a momentary distraction or something “more interesting” than whatever we are currently doing. Ultimately, we turn to social media on our smartphones for a short blast of dopamine.

Remove the “convenience” factor 🔗

I took two steps to break this habit. First, acknowledge there are negative effects to social media usage. I also had to acknowledge that self-discipline and self-moderation is hard. I knew the negative effects of social media usage, but despite knowing this, it was still hard to avoid. So, the second step is to make the self-discipline easier: drop the apps from your phone.

When I deleted Facebook and eventually Instagram apps from my phone, they were no longer convenient. To check either one, I had to use a mobile web app or a computer. The mobile web apps were tedious and slow, and a computer was not always accessible. When the “convenience” factor was gone, it became easier to disconnect from the online world because it simply wasn’t there.

Anything that required me to use social media could wait until it was convenient – usually when I am sitting down at a computer.

Soup is on, phone is off 🔗

I also took steps to increase my awareness of my usage. If having a dinner with friends or colleagues, I turned my phone off before entering the restaurant or meeting the group. My phone is off at the moments I turn to it at the dinner table. Powering it back on is inconvenient. Whatever distraction I was looking for would have to wait five minutes for the phone to boot.

“Right, it’s off for a reason,” I would think as I slipped the phone back into my pocket.

2. Data-driven observations: Scientific method for phones 🔗

After deleting my social media accounts, I wanted to understand: how often do I use my phone? What applications steal most of my attention? How much is too much? I decided to take a scientific approach and run an experiment.

I took a quantitative approach. I measured my usage by application to understand how much time I spent on different apps. I discovered QualityTime, an application that met my requirements. QualityTime measures your total daily screen usage, how much time you use on all applications, and how many times you unlock your phone screen in a day. [Note: Since this article was written, both iOS and Android introduced phone usage metrics. No app is required for this anymore, but QualityTime still offers some useful features.]

After installing QualityTime, I used the default quota of two and a half hours a day as the suggested maximum daily use. I was surprised I came close to or past 2.5 hours every day. Now, I see what applications take most of my time. Then, I make adjustments based on the feedback I see. I started to think things like…

Is this application worth the two hours a day? What am I getting out of this?

I need to cut back here, over four hours is way too much.

Now, I had data to inform my lifestyle changes or alert me when I need to make changes. When I saw my daily usage by the numbers, I better understood my own habits. It increased my awareness into how I use my phone and manage my digital life.

And often, awareness is the best foundation for making incremental changes to our life and how we manage our time.

3. What you see is what you find 🔗

What and who do you allow in your social media life? Your “feed”, for any application or app, is powerful. Your feed is a daily dose of perspective and thoughts delivered directly to your phone. What you see in social media is what you will find reflected back in the world around you.

In my case, I still use Twitter as my primary social media presence. Since deleting my Facebook and Instagram, I also become more aware of my Twitter timeline. I never followed many people by some standards – 200 people or so. First, I realized I missed content from half of those people because of how Twitter tailors what I see. Second, I become more aware of the actual content from the people I followed.

Change configuration settings of your mood 🔗

Since the November 2016 elections, social media is a “black box”. You will find many different things. You find empowering optimism, cynical pessimism, and some things between the two. As I found out, content on my timeline has a tangible, noticeable effect on my daily perspective. If someone I follow launches a cynical Twitter thread about a current event, that cynicism translates into my own view.

We cannot pretend that what we read on the screen has no effect on our real lives.

Less is more 🔗

So, I became a “jerk”. I reduced who I followed on Twitter to about 50 people. Then I sought out people from various aspects of my life—technology, spirituality, friends and family—that have a positive impact to my daily outlook. I put a filter on what I filter in my feed: I looked for inspirational wisdom, people who would motivate me to enlightened action. I turned away from anger, angst, hate, and cynicism.

However, there is a balance between naïvety and cynicism. We can choose optimism without being naïve. Additionally, we can choose skepticism without being cynical. The point is not to drown out reality or hide away in a bubble. We must be realistic about what is happening in the world and stay hopeful. To stay motivated. To not wake up, read through your feed, and curl back depressed into bed.

My best advice is be conscious of what you filter in your social media feed. Your feed is close and personal. It is powerful. And what you see digitally is often what you find reflected back at you in non-digital life.

Considering Facebook deletion? 🔗

Considering to cut the plug? Check out this excellent article from Recode about how to responsibly cut down on Facebook. Even if full deletion is not what you are after, it suggests helpful tips on spending less time there.

Good luck! 🔗

These lessons are fundamental to me and changed how I manage my digital life. Beyond the digital world, I notice the beginnings of change. I am more present in the things I do and spend my time with. Now, when I go out with friends and family, I appreciate the time spent with them without a hole burning in my pocket.

I hope these lessons are also helpful to you too. Additionally, if you have any other tips or comments for others, please drop a comment below!

Featured image arranged by Justin Wheeler.

friends by Ilaria. Bernareggi, thumbs up by mikicon, Facebook by Saloni Sinha, and more by Ilaria Bernareggi from the Noun Project.

The next album to spotlight in Tergiversate is Abysma by Los Angeles-based Geotic, a.k.a. Will Wiesenfeld. Abysma is the ninth studio album released by Geotic. It debuted on March 31, 2017. The album could be described as a cross between an electronica and indie pop. For Wiesenfeld’s first début on a record label with his side project Geotic, he makes a bold and eccentric presence with Abysma.

Why Abysma? 🔗

Abysma was an accidental discovery during a significant experience of my life. At the time, I subscribed to Google Play Music and I would sometimes receive recommendations for new music to listen to. On March 31, 2017, Google Play suggested Abysma as a new release I might like.

At the time, I was living in Dubrovnik, Croatia on a study abroad exchange. The album quickly became one of my favorites for the remaining two months I spent abroad. After returning to the US, I chose not to renew my subscription. Since I never purchased the album, it was conveniently forgotten after I returned.

Months later, in October, I reviewed some of my top albums from 2017 on Last.fm. I came across Geotic on the list and remembered Abysma. I decided to buy the album and add it to my library. Since then, the album returned to a regular spot on my listening queue.

Thus, perhaps it makes sense that I strongly associate this album to my time living abroad. Frequently, this album was the backdrop to afternoon walks near the Old City of Dubrovnik, long bus rides to Bosnia or Albania, or for studying the week before final exams. Regardless, this album rekindles my imagination for some of my own unique experiences. Therefore, it made sense to include this album in a Tergiversate column.

Themes 🔗

Deciphering Abysma is a challenge. Most of the record is ambient, with some songs featuring brief, synthesized, and heavily modified vocals. The album artwork is the next biggest hint to themes and meanings of the album.

The following are two themes I identified in Abysma:

• Own worst enemy
• Overcoming hardship

Both themes play a supporting role in each other,.

Own worst enemy 🔗

One of the primary themes of the album is recognizing our least desirable qualities of ourselves and letting them overpower our other positive qualities.

Artwork 🔗

The album artwork sets the foundation for this theme, combined with various hints from song titles and mood from each track. The artwork features a sun-bathed, empty room with a rainbow-colored body lain across the floor.

The body appears lifeless as it peers outside the bright window. The body is a metaphor for the bright and wonderful qualities we own, but the room represents a trap. Despite the wonderful qualities inside, we lock ourselves into boxes or rooms where we are unable to see past the walls. We only have a window into the great wonders of life – yet somehow we are not in that picture.

Songs 🔗

The mood of the album contributes to that idea. Sunspell, the opening track, creates the initial view of the album. The album is reminiscent of a bright, cheery atmosphere, but it seems remote and disconnected at the same time. The sunlight captivates us and puts us under a spell – in the spell, the bright lights of others and the world we see strike us and blind us.

The following tracks continue to build this atmosphere, leaning towards an introspective and oblique feel. Echoing words of “it all makes sense” on Nav feed this idea of deep, intrinsic wonder to ourselves. As the album grows in its mysterious nature, so does the feeling of mental isolation. As Abysma progresses, Geotic puts on a lens of closer and closer self-introspection.

Admittedly, not all the qualities in this lens are the best ones. The theme reaches its climax in Perish Song. The song title leaves little room for second guessing. In the long, drawn-out waves of the synthesizer and delicate piano keystrokes, a listener is left with understanding of a type of depression. It’s reminiscent of the days when our thoughts are self-destructive and harmful.

What it all means 🔗

Whether by design or by accident, Geotic forces the listener to find a level of acceptance of their own mind. Throughout life, we sometimes make ourselves our own biggest enemy and showstoppers. Even though we are all filled with a natural bright and illuminating nature (like a child), we can lose sight of that version of our self. This theme is present because we become aware of ourselves when listening. Everyone has been their own hardest critic, and Abysma is a gentle reminder that sometimes we are hardest on ourselves.

Lingering thoughts remain whether the harsh self-criticism is worthy or not, but this is quickly answered at the close of the record.

Overcoming hardship 🔗

In a quick turnaround, the last song of the album, Valiance, introduces the second theme and integrates into the different pieces of the previous theme.

The second theme builds on the idea that even in our worst qualities and lowest moments (e.g. Perish Song), we are able to overcome the battle with our mind and find our own peace. After all, the body on the album cover reflects light and echoes the colors of the rainbow – we always possessed the qualities, but perhaps did not recognize them within us.

Valiance 🔗

The high notes and intense energy of Valiance are a contrast to some of the introspective atmospheres earlier in the album. While Valiance is also introspective, it changes the lens. Instead of looking in at our worst qualities, it’s a change in perspective to look at our better qualities. The song almost seems to externalize the hidden energy inside the body on the album cover.

Valiance is a reminder of our ability to find peace with our mind and create our own happiness. It tells and affirms that we can overcome our hardships, whether imposed on us by ourselves or by others.

What it all means 🔗

One line from the lyrics of Perish Song are significant. It plays back into the second theme:

The heat of the sun,

Is there if you want.

We decide whether we want to feel the warmth and heat of the sun in our life. We are the ones that make a choice to how we receive the world and our experiences in life.

As a whole, this theme plays into the previous theme because it takes a stark change in direction. But it plays together beautifully. The negative and difficult recognition of our own self as an enemy is challenging. It reminds of our shortcomings, our regrets, our missed opportunities. It becomes easy to pin the blame on ourselves. Not only that, but the awareness can introduce a concern of not being able to overcome our failures.

Yet, the album ends elegantly, brightly, and brilliantly. The closing reminds us that we should always choose the heat of the sun in our life. When we shape our perspective of the world and the people around us, we make a choice for how we receive and interact with it. To make a positive impression of the world and those around us, we must become comfortable with ourselves first. We have to find peace with our own mind before we can find peace with any others.

The closing of Abysma reminds us of that, in a layered progression from recognizing our worst qualities to acknowledging they can always be overcome. Recognizing our worst qualities is challenging, but it’s a challenge we can overcome when we live in the light and warmth. When we choose happiness, love, and compassion, these qualities reflect and echo back to us in life.

Where to find Abysma 🔗

Most albums reviewed in Tergiversate focus on the complete album, not each song. Consider making your first listen from top to bottom instead of picking single songs. My experience in music is that great albums offer the most when enjoyed in a single, immersive experience.

• Bandcamp (preferred, directly supports artist)
• Spotify
• iTunes
• Google Play
• Amazon
• SoundCloud

Curious where the name “Tergiversate” came from? Check out the dictionary definition.

A series of heavy noreasters hit the US east coast over the last couple weeks. This coincided with my travel dates back to Rochester, NY. While we didn’t have flooding, we had a lot of snow. A lot of snow means canceled flights.

As I made my way through border control in Dublin, Ireland on March 7, I discovered my connection to New York City would likely be canceled. A meander from baggage claim to the check-in desk confirmed this. Fortunately, Aer Lingus had no issue putting me up in a hotel overnight with dinner and breakfast to catch the next flight to New York the next day.

While waiting in airport queues, a friend happened to retweet a local event happening in Dublin the next day.

For International Women's Day on Thursday, we'll be celebrating Female Firsts in medicine with @RCSILibrary https://t.co/RvIHtwAhys
Saturday, we have our @artandfeminism event in @UCC, celebrating our Irish and local female artists from 12-3pm https://t.co/ZMpKQOSR3q pic.twitter.com/0G7Kn3zpS6

— Wikimedia Community Ireland (@WikimediaIE) March 5, 2018

The event was a local Wikimedia meet-up to celebrate International Women’s Day. Participants would create and edit Wikipedia pages for influential women in the history of the Royal College of Surgeons in Ireland. After digging deeper, I found out the event was 30 minutes away from my hotel from 09:30 to 12:30. My flight was at 16:10.

I put in my RSVP.

Meet the Wikimedia Ireland community 🔗

In an opportunistic stroke of fate, I would spend my extended layover for my first time in Dublin learning and listening about role model women in the Irish medicine community. I didn’t know it yet, but I would also take part in writing some of the history too!

#WomenOnWalls 🔗

The first part of the morning was an introduction to editing on Wikipedia and establishing the focus for edits.

The Royal College of Surgeons in Ireland (RCSI) started a new campaign to promote influential women in the history of the university. There is a historical board room in a prominent place on its campus. Inside the board room, there are portraits of influential people in the history of RCSI. But all of them are men. This makes it difficult for women to have role models or inspiration of women like them who “made it” in science and medicine.

On the contrary, there was also no shortage of influential women in the history of RCSI. Part of the morning was an introduction to primary sources that explained the pivotal work of female Irish doctors and pediatricians throughout the 20th century. After hearing about these inspirational women, it was a wonder – why were none of them represented in the board room?

This was actually the focus for the edit-a-thon. Recently, RCSI commissioned new portraits for some of the influential women alumnae. Half of the portraits in the board room would be relocated and replaced by the new portraits. This was part of their #WomenOnWalls campaign.

Discovering Victoria Coffey 🔗

After an introduction to the sources available and how to edit on Wikipedia, we began the editing. Organizers encouraged participants to improve an existing page first, since most of the participants were first-time editors.

Since I had some experience with Mediawiki mark-up and do a lot of writing, I decided to write a new page. There were a list of suggested women alumnae to write about. After hearing about Victoria Coffey, I decided to focus my two hours of writing on her legacy.

Who is Victoria Coffey? 🔗

Victoria Coffey was an Irish pediatrician. She was an alumna of RCSI, and one of the first to research sudden infant death syndrome (SIDS). Coffey spent most of her time in medicine researching and studying congenital abnormalities in infants and pediatrics. Later in her life, she founded the Faculty of Paediatrics at the Royal College of Physicians of Ireland in 1981 and was the first female president of the Irish Paediatric Society.

Writing her Wikipedia page 🔗

With the help and guidance of the Wikimedia Ireland and RCSI staff, I found resources to research and learn more about Victoria Coffey. While some public sources were available, I was also provided with a primary source from a paid online Irish encyclopedia.

From there, I had the basis to begin writing a stub for her biography. I created an infobox to summarize some of her contributions, wrote a paragraph on her life, and left external links for someone to expand and write more in the future.

You can find her Wikipedia page online now. Since its creation, it was viewed nearly 100 times, edited five times, and edited by three people.

Thank you RCSI and Wikimedia Ireland! 🔗

In a strange and opportunistic stroke of fate, I was lucky to meet this local community and work with a room of inspiring women in medicine (students, alumnae, and faculty) on lowering the wiki gap of women on Wikipedia. It was a privilege to take part and learn a unique kind of history for Ireland in my short stay in Dublin.

Thank you for this great experience, RCSI and Wikimedia Ireland!

I’m not sure if this will make me anticipate flight cancellations more or less from now on.

This article covers Horizontal Pod Autoscaling, what it is, and how to try it out with the Kubernetes guestbook example. By the end of this article, you will…

• Understand what Horizontal Pod Autoscaling (HPA) is
• Be able to create an HPA in Kubernetes
• Create an HPA for the Guestbook and watch it work with Siege

What is Horizontal Pod Autoscaling? 🔗

Horizontal Pod Autoscaling (HPA) is a Kubernetes API resource to dynamically grow an environment. To help simplify things, consider it in three pieces:

• Horizontal: Think of horizontal growth, i.e. adding more nodes to your available pool (unlike vertical, which would be adding more memory / CPU to your existing nodes)
• Pod: Your deployable units in Kubernetes
• Autoscaling: Automatically scaling out when needed

To help visualize it, imagine you have a Python Flask web server that reads and writes data to a Redis back-end. Your web server is the front-end for all of your incoming traffic. You run it with three pods in Kubernetes, with 512MB of RAM and 50m of CPU. Now, suddenly, BuzzFeed writes an article about your app, Kanye West name drops the app in a TV interview, and the president of the United States retweets a link to your site.

Oops.

Now you have a serious problem on your hands, where your tiny application is overloaded. Three pods aren’t cutting it anymore. You get woken up at 3:00am to hastily adjust the number of replicas and rapidly scale your infrastructure. While you’re wondering how this happened, you also wonder… isn’t there an easier way? Could I have avoided this panicked, pre-dawn scaling crisis? Yes, there is! At least, somewhat.

Building to scale 🔗

By creating and managing your deployments with HPAs, your application grows horizontally to handle the load. As the CPU utilization rises, HPAs trigger the addition of more pods to scale automatically. Previously, you could create a Horizontal Pod Autoscaler that would begin scaling when cumulative CPU utilization was at 60%. You could also tell it to scale to a maximum of 500 pods, but no less than three. So then, when the Apocalypse of Viral Sharing happened to your web application, it could have grown dynamically.

If you want to dive deeper in the technical implementation of HPAs, you can read more in the Kubernetes documentation.

Create a Horizontal Pod Autoscaler 🔗

Now that you understand how a Horizontal Pod Autoscaler (HPA) is helpful, how do you create one? Like any other resource in Kubernetes, define HPAs in a YAML definition file. Here’s a template for getting started.

---
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
  namespace: my-app-space
  labels:
    app: my-app
    tier: frontend
spec:
  scaleTargetRef:
    apiVersion: apps/v1beta1
    kind: Deployment
    name: my-app-deployment
  minReplicas: 2
  maxReplicas: 20
  targetCPUUtilizationPercentage: 60

This is the minimal spec you need to deploy an HPA. It’s not that different from other Kubernetes resources you may have seen.

Explaining the configuration 🔗

Let’s look at what some of the specific lines are.

• spec.scaleTargetRef.name: Name of resource to scale (e.g. name of a deployment)
• spec.minReplicas: Minimum number of replicas running when CPU use is minimal
• spec.maxReplicas: Maximum number of replicas running when CPU use peaks
• spec.targetCPUUtilizationPercentage: Percentage threshold when HPA begins scaling out pods

When starting out for the first time, tweak these values based on the amount of traffic you expect to receive or what your budget is. Load testing your application is one way to see the HPAs do their job.

Obliterating the Guestbook 🔗

But this guide wouldn’t be complete without a live demo to try. You can create one with an existing application and put it to the test. This section assumes you have a running Guestbook application in your Kubernetes environment. As a quick refresh, the Guestbook is a three-part application:

• PHP web application for writing messages into a virtual guestbook
• Primary Redis node for writing new messages from web page
• Replica Redis nodes for reading the data into web page

We’ll add an HPA as a fourth part to scale the PHP web application for new traffic.

Create the HPA for Guestbook 🔗

Now, create a new HPA spec file for the guestbook.

---
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: guestbook-frontend
  namespace: guestbook
  labels:
    app: guestbook
    env: production
    tier: frontend
spec:
  scaleTargetRef:
    apiVersion: apps/v1beta1
    kind: Deployment
    name: guestbook-frontend
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 75

Put this into a file and create the HPA with kubectl.

$ kubectl apply --record -f guestbook-frontend-hpa.yaml

Now, the Horizontal Pod Autoscaler is operational and monitoring the CPU utilization of your deployment.

Load test with Siege 🔗

To force the HPA into action, we’ll use Siege, an HTTP load testing and benchmark utility. Siege is a multi-threaded load testing tool and has a few other capabilities included to make it a good option for putting some force onto a simple web app.

First, put various permutations of the URL in a plaintext file. By doing this, Siege can randomly scan the URLs in he text file and ping them in “Internet mode” by randomly selecting a URL from the list for each request. This could look like the following…

http://my-guestbook.example.com/
http://my-guestbook.example.com/index.html
http://my-guestbook.example.com/guestbook.php
http://my-guestbook.example.com/guestbook.php?cmd=get&key=messages

Once this is done, you can fire up Siege to begin load testing. In this case, to get fast results, we’ll use 255 concurrent users for five minutes, using Internet and benchmark modes.

$ siege --verbose --benchmark --internet --concurrent 255 --time 10M --file siege-urls.txt

You should see Siege begin to rapidly send requests to your Guestbook application. Now that the action is in progress, you can slowly observe your CPU utilization begin to climb. Watch it slowly change by using watch.

$ watch -d -n 2 -b -c kubectl get hpa -l app=guestbook

During the five minute load test, you should notice CPU usage rise and then new replicas will appear. Depending on what your original requests and limits are for the deployment, you will see different results. Next, try setting the deployment’s requests / limits to lower values if nothing seems to happen while testing.

Learn more about Horizontal Pod Autoscaler 🔗

Horizontal Pod Autoscalers are a stable resource in Kubernetes and are available for you to begin playing around with now. To learn more, read the documentation or see another example in the official walkthrough.

Open source becomes more common every year, where it appears at government municipalities to universities. More companies turn to open source software too. However, some companies try to take it a step further, and instead of only using the software, they also support projects financially or with developers. Facebook’s open source program encourages others in Facebook to release their code as open source. They also work and engage with the community to support the projects too.

Christine Abernathy, a Facebook developer advocate and member of the open source team, visited the Rochester Institute of Technology on November 15, 2017. She gave the November edition of the FOSS Talks speaker series. Her talk explained how Facebook approaches open source and why it’s an important part of the work they do.

Facebook and open source 🔗

Abernathy explained that open source plays a fundamental role in Facebook’s mission to create community and bring the world closer together. The ideological match was a motivational reason for Facebook’s participation in open source.

Additionally, Facebook has unique problems and challenges to solve for their infrastructure and development. Open source provides a platform to share those challenges and help others avoid similar mistakes.

Open source also provided a way to accelerate innovation and create better software. It helped engineering teams produce better software and work more transparently. Today, Facebook’s 443 projects on GitHub have 122,000 forks, 292,000 commits, and 732,000 followers.

Lessons learned 🔗

Abernathy emphasized that Facebook has learned many lessons from the open source community and hopes to learn many more. She identified the three most important lessons that Facebook took from open source:

1. Share what’s useful
2. Highlight your heroes
3. Fix common pain points

Christine Abernathy visited RIT as part of the FOSS Talks speaker series. Every month, a guest speaker from the open source world shares wisdom, insight, and advice about the open source world with students interested in free and open source software. The FOSS @ MAGIC community is thankful to have Abernathy attend as a speaker!

My internship at UNICEF is unique: I support open source community engagement and research as my primary task for the MagicBox project. For years, I’ve done this in open source communities in my free time (namely SpigotMC and Fedora), but never in a professional role. As I navigate my way through this exciting opportunity, I plan to document some of the experience as I go through blogging. My intent is that my observations and notes will be useful to someone else in the humanitarian open source space (or maybe to a future me).

But first, what does “open source community engagement and research” really mean?

What am I actually doing? 🔗

“Community engagement” is a buzzword phrase for the open source movement in the 2010s. Often, we hear about “community engagement” or the work of those “leading communities”, but it’s an abstract concept. In other words, building communities of humans and people is hard. There is no one-size-fits-all solution for any community. Every community has its own unique needs and goals. This means different methods of management and communication work better for some communities than others. My job is to help light the way for what this pathway means for the MagicBox team.

Since I started in January, a lot of my time so far was spent learning. What is MagicBox? What are we trying to deliver to our stakeholders? To the open source community? How does our data pipeline piece together? All these questions and more, I’ve tried to answer to different levels of success.

What’s next? 🔗

Now, I’m beginning to take a more hands-on role with the work, with a clear vision of what I want to do. The next few posts to come will dive deeper into what I’m up to.

If you have questions or are interested in keeping up with what’s going on, feel free to leave a comment here or subscribe to my blog to automatically receive future updates.

Opinions and views in my blog are my own and do not reflect the views of my employer.

Home is a suitcase 🔗

I began the third year of my degree and moved for the fifth time in two years when I made it back to Rochester in August. This time, I found somewhere to ideally live longer than only a few months of the year. I moved into a house with a few other roommates with more space than I’ve had before. For the first time in a while, it’s somewhere I’ve made to feel like home.

This move came months after I ended a semester of a study abroad program and lived in a city for an internship. Most of 2017 made my suitcase feel like a home, but it afforded many unique experiences.

Croatia: Study abroad 🔗

From January to May 2017, I participated in a study abroad program with my university to Dubrovnik, Croatia. RIT has full campuses in both Zagreb and Dubrovnik. This made planning the semester abroad easy, but also encouraged me to go somewhere I might not have gone otherwise.

My choice to study in Croatia was well-rewarded. On paper, I earned 12 credit hours, but I took away more than what I learned in class. My most important lessons came in the form of midnight bus rides to Albania, photograph exhibits capturing genocide in Sarajevo, and hugs from normally faraway friends in Czechia. My time abroad began a process in finding myself that has continued since my time in Europe.

DevConf 2017 / Fedora Diversity FAD 🔗

At the beginning of the year, the Fedora Diversity Team held a “Fedora Activity Day” (FAD) event in Brno, Czechia. If you’re outside of the Fedora community, think of a FAD as a focused, in-person team sprint. Together with our team in-person and remote, we mapped out our goals and plans for 2017 and set out to continue the work we began nearly three years ago.

In addition to the work we accomplished together, it was fulfilling for me to see my teammates that span three continents. I spent a week with not only my teammates but also my friends. The days we get to spend together are a privileged few in the year, and it was fulfilling and motivating for me to spend some of our time together in a way that wasn’t Pagure tickets or IRC meetings.

Read more about our team sprint in this event report:

https://communityblog.fedoraproject.org/fedora-diversity-fad-2017/

FOSDEM 2017 🔗

In February, I attended the Free and Open Source Software Developers European Meeting (FOSDEM) for the first time. FOSDEM is the largest open source conference in Europe, bringing together over 8,000 open source enthusiasts, contributors, and leaders from around the globe.

I had the privilege to attend as a member of the Fedora community, so my time was between the Fedora booth to meet the community and catching interesting talks. I also gave a talk of my own on the main track, What open source and J.K. Rowling have in common! I gave this talk to a smaller audience at DevConf, but the FOSDEM audience was considerably larger.

In retrospect, my original talk topic is relevant but I have ideas on how I could have delivered my message more effectively. Regardless, it was a learning experience for me to present in front of a new audience. Public speaking opportunities filled my youth, both in theater and in presentations, but I had never presented to a technical audience before (let alone on a non-technical topic). The experience at FOSDEM helped build my understanding and I hope to return with a new topic someday in the future.

Exploring the Balkans 🔗

Outside of open source and Fedora, my time in Croatia included a lot of time outside of Croatia. When many of my roommates went to explore the wonders of Western Europe, I lost my heart in the shadows of the Balkan mountains. My spring break was a solo trip split between Sarajevo, Bosnia and Hercegovina and Tirana, Albania.

Sarajevo 🔗

The three days I spent in Sarajevo were short but significant. I was truly alone on this visit and it was up to me to make the most of it. Originally, I was skeptical to go alone, but I knew that I would never have a better opportunity to go. My fascination with Sarajevo stemmed from a year of studying European history in high school, and knowing the cultural significance of Sarajevo as a meeting point of western and eastern cultures. In the end, I decided to go, and I was rewarded for it.

Most of my trip in Sarajevo consisted of museums. I visited various museums, ranging from eighteenth to twentieth century history. The most rewarding for me were the Galerija 11/07/95 and the Tunnel of Sarajevo. The gallery documented the Srebrenica genocide in July 1995 by the Serbian armed forces. The exhibit was eye-opening and perspective-shifting. The Tunnel of Sarajevo, sometimes called the Tunnel of Hope, is another perspective-shattering experience. The museum introduces the tunnel used during the siege of Sarajevo during the 1990s, when Serbian forces surrounded the city for an almost four-year siege. The tunnel was the only way for citizens and resistance forces to contact the outside world and keep the resistance alive. A small part of the tunnel is preserved, and the other artifacts make it a gripping experience (not to mention it’s a short drive out of the city, so you also have a chance to mentally prepare and later unpack the experience).

Tirana 🔗

I visited Tirana, Albania four times on my trip abroad. In Tirana, my heart was captured by the people there. For years, I read about the Open Labs Hackerspace community based in Tirana and I always imagined an opportunity to see it in person. I actually remember my first encounter with their community was an Ada Lovelace Day event report. And somehow, the circumstances shifted where I was able to meet their community and immerse myself in the culture, if only for a short time.

During my times in Tirana, I participated in the first-ever 48 hour hackathon to support the UN’s Sustainable Development Goals (SDGs), the first edition of Linux Weekend, and the annual Open Source Conference Albania (OSCAL).

https://fedoramagazine.org/students-fedora-linux-weekend-2017/

India 🔗

At the end of my study abroad experience in Croatia, a unique opportunity presented itself to me. I did not buy my return airfare back to the US before I left for Croatia. When price-checking for my trip back, I noticed it was a few hundred dollars extra if I decided to spend a week in India before flying back to the US.

I booked the tickets.

The last day of my classes finally came, and the next day, I was traveling further east, to Mumbai (or Bombay, if you prefer). I had the great fortune of having two great friends who invited me to the homes of their families during my trip. I visited Bee in Mumbai and Amita in Pune, all split across a single week!

My trip to India was eye-opening. For years, I’ve had a fascination with Eastern culture and philosophy, but it was something completely different to experience. Bee and her family took me to the Global Vipassana Pagoda, a personally fulfilling experience for me. We visited the Bandra–Worli Sea Link, Shree Mahalakshmi Temple, and several other places in Mumbai. I remember walking through the streets more than anything.

In Pune, Amita and her family showed me their favorite places. I had a chance to meet many other Fedora friends in Pune too. One of my favorite memories of Pune was a historic gurdwara. Amita took me and the others in our group to visit. For a moment, I finally got to see something I’ve only read about right in front of my eyes. The history and reverence in these places was absorbed into my mind.

I never expected an Indian visa stamp in my passport in 2017, yet it happened. I’m equally filled with wonder at how the circumstances unfolded as I am grateful this experience sneaked into my year.

Chicago: Urban experience 🔗

After my semester abroad and visiting India, I was whisked back to the United States, only to pack up once again for another new experience. From June to August, I lived in Chicago, Illinois to work an internship at Jump Trading. Chicago had a feeling of nostalgia for me because much of my father’s family has origins tracing back to Chicago. But I would find myself losing more of my heart in Chicago than I realized.

The internship 🔗

I worked with a fantastic team of people on exciting projects. Professionally, my time in Chicago was motivating and empowering. I was provided the opportunity to learn and also contribute. I walked in with a dreadful feeling of imposter syndrome and left feeling more confident in my own learning abilities. Docker, Kubernetes, and time-series data became a part of my daily work life, when I had little to no knowledge before then.

By the time my internship finished, I helped contribute to our team’s goal of standing up Kubernetes and contributing a few patches in Kubernetes projects like Minikube. I have great mentors to thank for not only direct, technical assistance but also motivational mentorship and empowerment too.

Everything else 🔗

There was more to Chicago than only the work too. Before long, I felt like a true Chicagoan, traveling the subways into the Loop, catching free concerts in Millennium Park, and indulging in the Chicago tradition of deep-dish pizza.

Unlike other cities I’ve visited, like New York City, Chicago felt easier to integrate into. The culture was notably “slower” than the fast-pace life of NYC, London, or Washington DC. I discovered Middle Eastern markets that became a regular part of my weekends, made friends with the baristas at a local coffeehouse, and had the privilege of hosting friends from three continents for short stays.

I left Chicago and was offered a new contract for the following summer in 2018. I’m looking forward to be back in June again.

Year of Fedora 🔗

2017 was full of time and effort spent in the Fedora community. In addition to the Diversity FAD, I was elected to the Fedora Council (on my third attempt), attended the annual Fedora contributor conference, Flock, and also narrowed my scope for contributions.

When I began contributing to Fedora, I was contributing to many things. Marketing, community operations, Fedora Badges, Fedora Magazine, Ambassadors, Games SIG, Join SIG, the Diversity Team, and maybe a few more things. After a while, I realized my contributions carried great width but poor depth. In 2017, I “reconfigured” my time in Fedora to focus in on the areas where I felt my time yielded the highest impact. This is Fedora CommOps and the Diversity Team.

I resigned as Fedora Magazine editor-in-chief and also formally stepped down from other teams. It made me sad, but I knew it was the right decision for me. I’m happy to spend more time working in fewer projects at a greater depth and focus than I had before.

Flock 2017 🔗

Flock, Fedora’s annual contributor conference, was held from Aug. 29 to Sep. 1 in Cape Cod, Massachusetts. Every year, Flock is an empowering experience for me because of the face-time I get with the people I spend much of my year working with remotely. This year was no different, and many new faces were mixed in with the old ones.

The highlights for me were in three forms: the CommOps session, the Diversity Team session, and the Fedora Magazine session. Together with Sachin Kamath, we led the CommOps session. You can read more about our session here:

https://communityblog.fedoraproject.org/metrics-docs-flock-2017/

The Diversity Team and Magazine sessions were also valuable for both teams to get feedback from the rest of the community. In the Diversity Team session, we had many active participants outside of our team that reminded us the importance of narrowing our focus for higher impact. I also attended other interesting sessions held by the community, like the future of fedmsg by Jeremy Cline.

CommOps FAD 🔗

Towards the end of 2017, I worked together with our team in CommOps to organize our own team sprint, or FAD, in 2018. We successfully planned the event and organized it in Brno, Czechia, similar to last year’s Diversity FAD.

More details on this will be found in its own event report!

ListenBrainz indie study 🔗

In my fall semester of 2017, I took on an independent study to further explore the ListenBrainz project. ListenBrainz is an open source social platform to document the music you listen to over time. If you’re familiar with Last.fm or Libre.fm, it’s a similar concept, but the focus is more on the data than the social features. ListenBrainz is supported by the MetaBrainz Foundation, also the guiding body for the more well-known MusicBrainz project.

In my independent study, I had a chance to contribute documentation and community tools (like issue / PR templates), as well as explore how the project gathers and builds metrics. I didn’t make my original milestone of major code contributions to the project, but I better understood the community and tried to help in the areas of low coverage, like documentation.

The experience was insightful for me and provided me an excuse to work on something that I am genuinely passionate about. Music is a powerful part of human culture, and the MetaBrainz Foundation takes a serious approach to documenting music, especially in a technical sense. ListenBrainz represents an opportunity for us to better explore and understand ourselves through our music listening habits. I hope someday that ListenBrainz will be a platform for data journalism and research about music. That’s my dream.

Opensource.com community moderator 🔗

At the beginning of 2017, I was brought on board as an Opensource.com community moderator. Together with other community moderators and site staff, I help contribute new content and source new writers to the site. My invitation to the community moderator team came shortly after the announcement that I received the 2017 People’s Choice Award. When Rikki Endsley invited me to the team, it felt like a natural alignment to my passion for storytelling.

All Things Open 2017 🔗

I was invited to All Things Open, an annual open source conference in Raleigh, by the Opensource.com team. The day before the conference, I met the rest of the team and other community moderators at the Red Hat HQ in Raleigh. We spent the day locked into a room together to hash out plans and goals for the next year. It was a productive opportunity for the team to work together and also a great opportunity to meet the other members of the community.

Some of my best takeaways from this experience were catching coffee with other community moderators, meeting Jim Whitehurst to talk about Opensource.com, and giving my talk, What open source and J.K. Rowling have in common, for the final time.

I hope I have the opportunity to go again next year to meet the awesome team behind Opensource.com. (If you haven’t considered before, come and write for us too!)

Happiness Packet Challenge 🔗

Another unusual milestone for my 2017 was the first rendition of the Happiness Packet Challenge. I was introduced to the Happiness Packets website in 2016. Happiness Packets are an easy way to say thank you to someone who has had a positive impact on you. I came up with a challenge to my friends and network to write one Happiness Packet a day, every day, for a week.

I followed up with the team behind the project to evaluate the impact of this idea, and I was pleasantly surprised. Here’s the number of messages sent for the two weeks prior to the Happiness Packet Challenge, followed by the week of the challenge:

• Week starting 2017-03-27: 2 sent
• Week starting 2017-04-03: 35 sent
• Week starting 2017-04-10 (challenge week): 72 sent

You can read more about the challenge in my original blog post. Keep an eye out for it again in 2018.

https://jwfblog.wpenginepowered.com/2017/04/happiness-packets-challenge/

Living openly 🔗

Earlier in this post, I alluded to how I felt like I began to find myself when I was abroad. My study abroad experience was the beginning of a longer process that leads into present day.

In April, I went public with my depression, both to help take a weight off my shoulder and to be a voice for others who are afraid to speak up. I was always concerned of the reaction from publishing something like that, but I was met with nothing but loving-kindness from friends and strangers. It gave me new confidence to live more openly and wear my values in the open.

The story continued in October, when I decided to delete my Facebook and Instagram accounts.

https://medium.com/@jflory7/cut-the-plug-deleting-facebook-and-instagram-6cbe7c86d9c9

I considered this for a couple of years before, but I pulled the trigger in October. Like many others, it felt almost too much of a task to disconnect myself from this huge network of people and friends. But the negative impacts of it were draining me and trapping me. Since I deleted my accounts, I’ve noticed a positive impact in overall levels of happiness and awareness. However, I don’t think the social media accounts alone are the reason for this.

In the near future, I hope to do a follow-up post to my decision to cut away from the Facebook and Instagram machines. Keep an eye out for more.

2018 🔗

It’s already February in 2018 when I finished this post. This year, I thought it would be the year when I get the post out closer to the new year, but somehow I always slip. In either case, it gives me a chance to take in some of the new opportunities and excitement of the new year before reflecting and looking back.

This year, I’m working an internship with UNICEF to help lead on open source community engagement and supporting the non-technical areas of their MagicBox platform. In the one month I’ve been doing this, I feel like I have tens of articles I could write about, but the experience is still maturing for me.

I also have another round in Chicago to look forward to over the summer. I’ll get to work with the same team as last year on similar projects, and I’m looking forward to going back.

As for the rest, who knows what’s to come? So many things that made 2017 what it was were the things I didn’t expect. The surprises in life are the salt to the regiment of daily life, and add flavor and spice in unexpected ways. I have no idea what my 2018 Year in Review will look like, and that’s okay. I’m looking forward to seeing what will make it in.

Thank you 🔗

Above all, every year, I think back on the people who positively impacted my life and contributed to the “flavor” of my year. A close friend reminded me recently that we all stand on the shoulders of giants. And isn’t it true? We all have our great mentors, great friends, and unexpected sages that help us find our own footing on this great path of life. We become ourselves from the various pieces impacted on us by others.

I’m thankful for all of the people who have made my year into the experience it was. The list is too long to write and I fear I would leave someone out – even significant impacts were made by people who had a short-term role in this last year.

A long time ago, my open source experience was jump-started by someone who did something kind and exceptional for me. It was a continuing trend since that moment. My only aspiration is to pay forward the good will that so many have bestowed unto me.

Thanks for making it this far down, and I hope to see you in 2018. Or who knows – maybe it will just be me reading this far down for next year, when I go to write my next year in review. Hi future me!

Why Demon Days? 🔗

Demon Days has a sentimental value to me. When I was younger, a close friend gifted me a copy of the album on CD, marking the first physical piece of music merchandise in my collection. Ever since the first CD, my collection has expanded across many artists, genres, and mediums, from CDs, to 7" and 12" vinyl records, and even a signed brick (a story to save for another time).

More importantly, Gorillaz represents a distinct departure in my music listening habits from my youth. Gorillaz opened my perspective to new sounds and genres, and the diverse range of sounds that Damon Albarn uses in the Gorillaz albums helped me discover new music. Gorillaz is the root of my independent music discovery, when I began to explore the rich palettes of sound, passion, and insight that music offers.

Even though Demon Days was the first album that felt like my own finding, its meaning and purpose have grown with me over time. Every year, there’s a period of my life where I find the album on repeat, or I’ll suddenly realize that I need to listen to a very specific song from the album immediately. I departed from other artists and albums from my youth, but Demon Days is one that clings on with a contemporary relevance, captures my imagination, and fills my heart with hope.

Thus, no other album felt worthy of receiving the title of “first” in this series.

Themes 🔗

The album sits at a pivotal moment in human history: the dawn of the 21st century is still breaking. A world of technology begins to immerse our culture, the world is at a war with questionable purpose, and an air of suspense hangs above for the thoughtful philosopher.

Damon Albarn attacks this moment in a poetic and creative genius that addresses four themes, but doesn’t paint a picture of despair. The four themes, as aptly detailed by the Demon Days Wikia page, are…

1. Desensitizing children / the innocent
2. The Iraq war
3. Environmental damage
4. Defacement of mass culture

New direction 🔗

Unlike the earlier album, this album marks the beginning of a new era for Damon Albarn and Gorillaz. Albarn’s music reaches a new level of maturity that was not as present in previous works.

Another analysis of the album from Reddit pins a deep insight into the meaning of the album. One exceptional excerpt from that thread:

Within this album, which is a popular music album, Damon spins a soundscape which explores the world in true existential crisis and tries, genuinely tries, to instruct the listener towards a positive outlook. It is unflinchingly hateful and rejecting of the forces at work which prevent personal growth and one by one exposes the Orwellian nightmare of living under a violent government and an apathetic society.

One piece 🔗

Perhaps the most powerful part of Demon Days is its composition as a singular unit. While many of the songs stand up on their own as mainstream singles, the album is best received as the sum of its parts. Albarn described the album in an interview as a story that takes the listener through the night. Intro sets the tone at the beginning of the darkness, and the self-titled track at the end paints a bright, luminescent color for the album.

Powerful ending 🔗

The ending of the album remains the most powerful part of the album for me, particularly Don’t Get Lost in Heaven and Demon Days. The album deals with themes of a world in decline. It is not discreet in its implied meaning and Albarn offers his perspective on the pitfalls that humanity sets for itself.

Yet, the ending of the album isn’t a reflection on the hateful, spiteful, and damaging parts of society and culture.

The ending reminds the listener of the breaking rays of sunlight, cutting through the darkness of the night. In line with its storyline of journeying through the night and facing different demons, the album closes itself with a positive picture of hope, love, and inspiration. I believe Albarn was aware that the message of urgency and themes of darkness in other songs from the album were difficult to swallow. But he was acutely aware that the embers of hope and love should never be extinguished if these demons of the world are to be overcome.

The ending of the album is what took me through 2017. One of the highlights of my year was seeing Gorillaz live in Chicago in July, as they started their international tour for the Humanz album. I was speechless and filled with a boundless joy when the concert ended with Don’t Get Lost in Heaven and Demon Days. These two songs aged and were reborn with new meaning and passion for the world we explore in 2017 and beyond. I’ve felt that for some time, but seeing Gorillaz perform at their first show in years and also ending with these songs? It only confirmed this resolve in meaning to me.

Where to find Demon Days 🔗

If you only know some of the singles from the album, or if you have never listened at all, please consider a full listen from top to bottom. Some albums can be enjoyed in pieces, but Demon Days is a package deal, and it offers the most when it’s listened to in a single, immersive experience.

• Spotify
• iTunes
• Google Play
• Amazon
• YouTube

Curious where the name “Tergiversate” came from? Check out the dictionary definition.

Share your 2017 “Year in Review” 🔗

To communicate with the rest of the Fedora community what we worked on in 2017, the Fedora Community Operations team (CommOps) encourages every sub-project of Fedora put together their own “Year in Review” article on the Fedora Community Blog. The CommOps team has created an easy to use template to document your top three highlights of 2017 and one goal for 2018.

Read the original announcement of the 2017 “Year in Review” on the Fedora Community Blog. Contributors are encouraged to work with their sub-projects to come up with the three 2017 highlights and one 2018 goal. These are only set as a minimum. If your sub-project has a lot to say or has many big tasks for 2018, include more highlights or more goals! The only requirement is to meet the minimum, but there is no limit for what you wish to include.

https://communityblog.fedoraproject.org/fedora-2017-year-in-review/

Where to find “Year in Review” posts 🔗

All “Year in Review” articles end up on the Fedora Community Blog. See examples from 2015 for some inspiration. To find new posts, find them in the “Year in Review 2017” tag.

Start discussing this now and craft your own “Year in Review” post for 2017! Sub-projects are encouraged to have a draft in the Community Blog before the end of February.

The Rochester Mini Maker Faire is an annual event at the Joseph A. Floreano Riverside Convention Center in Rochester, NY. Each year, makers, creators, artists, and more from all over upstate New York and beyond show their crafts and creations to the community. Open source software and hardware are popular items at the Rochester Mini Maker Faire, with countless Raspberry Pis, Arduino boards, and open source projects powering many electronic projects.

On November 18th, the Free and Open Source Software initiative at the RIT MAGIC Center and the RIT Linux Users Group presented projects and their communities at the Faire. Students from both communities demonstrated projects made with Raspberry Pis or larger undertakings on other open source projects.

Looking good: Magic mirror and Raspberry Pi 🔗

Students from the FOSS@MAGIC initiative presented the Magic Mirror, a mirror that combines your digital world into your reflection. A Raspberry Pi and salvaged monitor screen sit behind a piece of one-way glass. Through the glass, the mirror shows the time, daily weather report, calendar updates, and more along with your reflection.

Taylor Bowling and Solomon Rubin, two students at RIT, worked together on the project in spring 2017. The frame for the mirror was hand-built for the project. Using this guide, the two created a pair of them for the upcoming RIT MAGIC Center.

Community course-ware with LearnIt 🔗

Another student, Wilfried Hounyo, demonstrated his open source course-ware platform, LearnIt. LearnIt is a platform for topic-based, community-contributed courses and tutorials. Similar to other platforms like Udacity or Coursera, LearnIt enables anyone to host their own learning platform and build a community around it.

Wilfried’s inspiration for LearnIt came from working with the FIRST Robotics community in high school. LearnIt’s original goal was to build an open platform for learning and teaching within the FIRST Robotics community. This way, anyone around the country could create their own lessons for anyone to view and follow. After working on the project, Wilfried decided to make the platform ambiguous for any project, so anyone could use LearnIt for building a learning community around any topic or subject area.

A demo is available here and the source is on GitHub.

Linux operating system for RIT 🔗

Members of the RIT Linux Users Group also presented TigerOS, a custom Linux operating system for students, faculty, and staff of Rochester Institute of Technology. One of the project goals is to offer an installer based on major across all RIT majors. After picking your major, TigerOS installs and configures all the software used by the department or major.

Did you know #RITlug is working on a custom operating system for @RITtigers? Check out #TigerOS at the @ROCHMakerFaire, table #91! #Rochester #MakerFaire pic.twitter.com/aipHh8APz6

— RIT Linux Users Group (@RITlug) November 18, 2017

Development on TigerOS began when student Aidan Kahrs picked up an abandoned project from past RIT students. After building a team, they set out to revive the project over the last year. To date, an early beta is available and efforts are going towards building an automatic CI build system and updating to Fedora 27.

To learn more about TigerOS, visit their website.

Spy Pi 🔗

RITlug also presented the Spy Pi at the Rochester Mini Maker Faire. The Spy Pi is a discreet camera embedded inside a picture frame powered by a Raspberry Pi. Taylor Bowling also helped lead this project.

In the picture, R2D2 is carried away by the Jawas in Star Wars: A New Hope. Taylor added two orange LED lights into one of the hooded characters and attached an infrared motion sensor, webcam, and Raspberry Pi into the picture frame. Whenever someone walks in front of the picture frame, the LED “eyes” light up and the webcam takes a picture that’s stored to the Raspberry Pi.

Taylor designed the project himself and wrote simple Python scripts to automate using the sensors. His code is available on GitHub.

See you next year! 🔗

This year was the third year for FOSS@MAGIC and first year for the RIT Linux Users Group to exhibit at the Rochester Mini Maker Faire. Both communities look forward to showing off our projects and what we’re working on again at Imagine RIT in May and again next year at the Faire.

To learn more, visit the websites for FOSS@MAGIC and the RIT Linux Users Group.

Tergiversate: New articles in 2018 🔗

Tergiversate takes the form of a column on my blog. New posts will appear in the Music category. Since this is a personal undertaking, I did not want to commit to a publishing schedule, but I hope to cover one to two albums a month.

The album columns will not always be a review or an analysis, but rather a spotlight or highlight on albums that have a special or intrinsic value to me. I hope to cover both new releases from current-day artists as well as introduce older albums from some of my favorite artists.

The first articles in the series will appear in January 2018.

Recommendation swapping welcome 🔗

I plan to start with music that I’m familiar with. However, if you want me to consider an album, I’m happy to swap recommendations. I’m always looking for new music, so if you want to point something out to me, you’re welcome to leave a comment or reach out to me somewhere else.

I’m excited to launch Tergiversate. Music is an important part of my life and I’m excited to extract the best highlights from a world polluted by noise.

Curious where the name “Tergiversate” came from? Check out the dictionary definition.

Music by Sandy Priyasa from the Noun Project.

This week is the last week of the fall 2017 semester at RIT. This semester, I spent time with the MetaBrainz community working on ListenBrainz for an independent study. This post explains what I was working on in the last month and reflects back on my original objectives for the independent study.

Running my own ListenBrainz 🔗

The RIT Linux Users Group hosts various virtual machines for our projects. I requested one to set up and host a “production” ListenBrainz site. The purpose of doing this was to…

1. Test my changes in a “production” environment
2. Offer a service for the RIT Linux Users Group to poke around with

I spent most of this time working with our system administrator to set up the machine and adjust hardware specs for ListenBrainz. Once we fixed storage space and memory issues, it was easy to set it up and get ListenBrainz running. My experience writing the development guide made it easy to get set up and get working. On the first run, it worked!

Now, listen.ritlug.com is live.

Figuring out HTTPS 🔗

My next challenge for the site is to set up HTTPS. I tried using a reverse proxy in nginx to set up HTTPS, but I received 502 Bad Gateway errors. I realized I spent too much time figuring this out on my own and decided to ask for help in the MetaBrainz community forums.

Proposing new statistics 🔗

Halfway through the independent study, I realized I would fall short of my original objective of implementing basic statistics in ListenBrainz. To compromise, I wrote a proposal for new statistics to start in the project. My proposal looked at other proprietary platforms that compete with ListenBrainz to see some of their statistics. I also came up with some of my own.

I proposed this to the MetaBrainz community on the community forums. I’m awaiting feedback on my ideas. Once I get feedback, I plan to file new tickets for each statistic to track their implementation over time.

I don’t expect statistics being at the forefront of ListenBrainz for some time. A lot of work is going towards other areas of the project. But later in 2018, I expect more focus on the user-facing side of the project.

My statistic and Google BigQuery 🔗

My biggest blocker over the last month was Google BigQuery. I wrote a statistic to calculate play counts over a time period, but was asked to test my statistic. To test my statistic, I needed real data to work with.

Originally, I tried using the Simple Last.fm Scrobbler to submit listens to the local IP address for my development environment, but I wasn’t able to get the app to reach my ListenBrainz server. To get the data, I had to set up Google BigQuery credentials so I could make queries against data on the production site, listenbrainz.org.

I tried working through the Google BigQuery documentation. There’s a lot of documentation for using BigQuery as a developer, but it was confusing where to find the information I needed to set it up in my development environment. I tried creating a new project in the Google Cloud Platform, but I was confused because it prompted me to upload my own data instead of accessing data already in BigQuery.

Too late, I realized I spent too much time on my own and not asking for help. I submitted a pull request with the statistic I made and asked for help in the MetaBrainz community. I also offered to write documentation for setting this up once I learn how to do it.

Reflecting back 🔗

I looked back on my original objectives for the independent study, and I was satisfied and dissatisfied.

Not enough programming 🔗

I wanted this independent study to enhance my programming knowledge. I especially wanted to focus on Python because I wanted to become more familiar with the language. However, I actually didn’t do much programming during the independent study, to my own fault.

My biggest challenge was I bit off more than I could chew. I wanted to write code, and made a big goal before I knew the code base of the project. Even now, I still am not completely comfortable with the code yet. It’s a big project with a lot of things going on. I was able to understand the things I did work on, but there’s still a lot.

I realized that next time, I need to spend more time evaluating the code base of a project before writing out my milestones. I wish I set more realistic, smaller milestones for myself. My milestone of implementing basic reports was lofty given my existing programming knowledge.

Successes 🔗

One of my other objectives was to write documentation for the project. I felt I succeeded in this milestone, and actually found it enjoyable and interesting to do! I helped separate out documentation from the README into the dedicated ReadTheDocs site. I wrote the development environment guide and helped fix some build issues with the docs site. I also plan to write more for some of the other pain points I found, like Google BigQuery.

My last milestone was to create a use case for a data visualization course at RIT. While I didn’t implement my basic reports, I did create the proposal and make an effort to write new statistics. There’s a lot of potential now to work with the data in Google BigQuery and do front-end work with tools like D3.js and Plotly.js. I believe there’s significant potential to use ListenBrainz as a hands-on project for students to explore data visualization with real data. I hope to support my independent study professor, Prof. Roberts, with questions and logistics of using it as a tool for learning in the future.

Unexpected success 🔗

I also think I had an unplanned success too. I immersed myself in the community for ListenBrainz too. Over the last few months, I realized that many of my strengths are in community management and tooling. During my time in the community, I did the following:

• Fixed SELinux labels in Docker
• Contributed a pull request template
• Drafted contributing guidelines
• Fixed a PostgreSQL bug
• And more…

To the future! 🔗

This ends my independent study with ListenBrainz, but it doesn’t end my time contributing! I chose ListenBrainz because it’s a project I’m passionate about. An independent study allowed me to justify more time on it than a side project in my free time. I’m happy to have that opportunity, but I don’t want to end here!

I want to follow through on the statistics because I’m passionate about understanding music listening trends. I think there’s a lot of power for psychological research through music data. To this point, I filed a ticket to request tagging listens with “emotion” words that are synced back to MusicBrainz entities.

I won’t have as much time to work on the project without the course credit, but I hope to stay involved for the future. I love the project and I love the community. I’m thankful for the opportunity to work on this project as an independent study, and learn some things along the way.

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.

My progress with ListenBrainz slowed, but I am resuming the pace of contributing and advancing on my independent study timeline. This past week, I finished out assigned tasks to discuss contributor-related documentation, like a Code of Conduct, contributor guidelines, and a pull request template. I began research on user statistics and found some already created. I wrote one of my own, but need to learn more about Google BigQuery to advance further.

Paving the contributor pathway 🔗

Earlier, I identified weaknesses for the ListenBrainz contributor pathway and found ways we could improve the pathway. This started with the development environment documentation. Now, I helped draft first revisions of our contributor guidelines, Code of Conduct reference, and pull request templates. Together, these three documents have two goals.

1. Make it easier to contribute to ListenBrainz
2. Have a better experience and have fun contributing!

Adding these documents addresses these goals. Additionally, the GitHub community profile also highlights these deliverables as ways to meet these goals. After getting feedback and seeing what others think, we make more revisions later (with some trial runs).

Back to SELinux context flags 🔗

Recently, I set my desktop back up and installed Docker for the first time on this machine; however, the development environment still failed to start. When I ran the script, it would eventually error out because of a permission denial. The web server image for ListenBrainz was failing.

After debugging, I noticed that I missed the SELinux volume tags for the ListenBrainz web server images in my original pull request, #257. When I created the pull request, I might have had cached data that let my laptop run the development environment without a problem. In either case, it was an easy fix and I knew what the issue was when it happened. Therefore, I submitted a new fix in #290.

Writing new user statistics 🔗

The most interesting part of my independent study is working with the music data to build and generate interesting statistics. I finally began exploring the existing statistics in ListenBrainz. The statistic queries use BigQuery standard SQL. BigQuery helps rapidly scan and scale data queries to help with performance (I have a lot to learn about BigQuery).

Two types of statistics 🔗

Additionally, ListenBrainz generates two types of statistics:

1. Site-wide statistics
2. User statistics

Site-wide statistics are metrics non-specific to a single user. There is only one site-wide query now. It counts how many artists were ever submitted to this ListenBrainz instance and returns an integer. There’s room for expansion in site-wide statistics.

On the other hand, user statistics are metrics specific to a single user. There’s a fair number already, like the top artists and songs in a time period and the number of artists you’ve listened to. These are a little more complete and offer more expansion for doing cool front-end work with something like D3.js.

Writing user statistics 🔗

Of course, I had to try writing my own. One helpful query I thought of was getting a count of the songs you listened to over a time period (e.g. “you listened to 500 songs this week!”). I haven’t tested it yet, but I have this in a local branch and hope to test it with real data soon.

def get_play_count(musicbrainz_id, time_interval=None): 
 
 filter_clause = "" 
 if time_interval: 
     filter_clause = "AND listened_at >=
     TIMESTAMP_SUB(CURRENT_TIME(), 
     INTERVAL {})".format(time_interval) 
 
 query = """SELECT COUNT(release_msid) as listen_count 
            FROM {dataset_id}.{table_id} 
            WHERE user_name = @musicbrainz_id 
            {time_filter_clause} 
            LIMIT {limit} 
         """.format( 
                 dataset_id=config.BIGQUERY_DATASET_ID, 
                 table_id=config.BIGQUERY_TABLE_ID, 
                 time_filter_clause=filter_clause, 
                 limit=config.STATS_ENTITY_LIMIT, 
            ) 
 
 parameters = [ 
     { 
         'type': 'STRING', 
         'name': 'musicbrainz_id', 
         'value': musicbrainz_id 
     } 
 ] 
 
 return stats.run_query(query, parameters)

Researching Google BigQuery 🔗

My next steps for the independent study are researching Google BigQuery. After going through the existing statistics and understanding how ListenBrainz generates them, an understanding of Google BigQuery is essential to writing effective queries. When I become more comfortable with the tooling and how it works, I want to map out a plan of statistics to generate and measure.

Until then, the hacking continues! As always, keep the FOSS flag high…

Yet, he stands and watches for perhaps five or ten minutes, before taking his leave. During his observation, he was never interrupted by a digital device. Only the ever-present world filled that moment for him. The moment, like many others, is preserved into the mind as a scientist meticulously stores his laboratory materials.

Smart phone world 🔗

The world of digital devices alters modern experience of reality. Time no longer asserts priority or influence over a moment. In a moment, a smart phone takes a picture of something nice, and preserves it in electrons. At any moment in the future, you spend that moment reflecting back on the captured moment. It will never leave you, as you preserved a digital replica.

But the missed point is the relationship between analog and digital. Analog is the pure format – there is no conversion. All digitized items suffer from quality loss when converted from analog to digital, and back to analog. Sound, colors, brightness, warmth… all factors that lack in a digital form.

Humans may invent experiences for ourselves to simulate and re-live a moment or some time, but it will only ever be a simulation. Without the ability to access time as a dimension, there is no way anything will ever be but a simulation created or influenced by modern-day humans.

Lossy compression of memory 🔗

So the smart phone age of the information era deteriorates time’s hold on capturing your attention. Just like a digital song starts analog, goes digital, and comes out analog again, we down-scale our memories on the conversion scale. It’s a lossy compression. We hold a moment in our hands, measured by pixels, over a connection and passion that comes from remembering the full power of a moment.

But the solution isn’t to abandon the digital world and cast the device aside. The solution is to promote and encourage better balance between the digital and analog worlds. Compact lenses capture a moment, but the act of capturing doesn’t have to end the moment. If your digital world is ever gnawing at your back, find time to pull out into the analog world a bit.

Featured image by Justin Wheeler. Uses content by Iris Li from the Noun Project.

Recently, I discovered brightlight, a tool that changes backlight brightness. I decided to try it, and it worked with root privileges. However, I found there was no RPM package in Fedora for brightlight. I decided this was the right time to try creating a package in Fedora and learn how to create an RPM.

In this article, I’ll cover and share how I…

• Created the RPM SPEC file
• Built the package in Koji and Copr
• Worked through an issue with debug package
• Submitted the package to Fedora package collection

Pre-requisites 🔗

On Fedora, I installed these packages for all steps of the package building process.

sudo dnf install fedora-packager fedpkg fedrepo_req copr-cli

Creating the RPM SPEC file 🔗

The first step to create a RPM is to create the SPEC file. These are the specifications, or instructions, that tell RPM how to build the package. This is how you tell RPM to create a binary file from the package’s source code. Creating the SPEC file is likely the hardest part of the packaging process and its difficulty depends on the project.

Fortunately for me, brightlight is a simple application written in C. The maintainer made it easy to create a binary application with a Makefile. Building it was a matter of simply running make in the repo. So now I had a simple project to learn RPM packaging.

Finding documentation 🔗

Googling “how to create an RPM package” yields many results. I started with IBM’s documentation. However, I found it confusing and difficult to understand (although quite detailed; it might be more useful for a complicated app). I also found the package creation instructions on the Fedora wiki. The documentation here was good at explaining the composition and process, but I was still confused on how to begin.

Finally, I found the RPM Packaging Guidelines, written by the amazing Adam Miller. These instructions were helpful and included three excellent examples for Bash, C, and Python applications. This guide helped me better understand how to compose a RPM SPEC, and more importantly, how all the pieces fit together.

After this, I was able to write my first SPEC file for brightlight. Since it is so simple, the SPEC file is short and easy to understand. Once I had my SPEC file, I linted the file for errors. After cleaning a few mistakes, I created the source RPM (SRPM) and the binary RPM, then linted each for errors.

rpmlint SPECS/brightlight.spec
rpmbuild -bs SPECS/brightlight.spec
rpmlint SRPMS/brightlight-5-1.fc26.src.rpm
rpmbuild -bb SRPMS/brightlight-5-1.fc26.src.rpm
rpmlint RPMS/x86_64/brightlight-5-1.fc26.x86_64.rpm

Now, I had a valid RPM to send to the Fedora repositories.

Building in Copr and Koji 🔗

Next, I read the guidelines to becoming a Fedora packager. Before submitting anything, they encouraged packagers to test their packages by hosting the project in a Copr repo and building in Koji.

Using Copr 🔗

First, I created a Copr repository for brightlight. Copr is a service in Fedora’s infrastructure that builds your package and sets up a custom repo for whatever version of Fedora or EPEL that you choose. It’s handy to get your RPM hosted quickly and to share it with others for testing. You don’t need special approval to host a Copr.

I created my Copr project from the web interface, but you can also use the copr-cli tool. There is an excellent guide in the Fedora Developer portal. After I created my repo on the website, I built my package with this command.

copr-cli build brightlight SRPMS/brightlight.5-1.fc26.src.rpm

My packages successfully built for Copr and I was able to install it on my Fedora system easily.

Using Koji 🔗

Anyone can use Koji to test their package on multiple architectures and versions of Fedora or CentOS / RHEL. To test on Koji, you must have a source RPM. I wanted to package brightlight on all supported versions of Fedora, so I ran these commands.

koji build --scratch f25 SRPMS/brightlight-5-1.fc26.src.rpm
koji build --scratch f26 SRPMS/brightlight-5-1.fc26.src.rpm
koji build --scratch f27 SRPMS/brightlight-5-1.fc26.src.rpm

It took some time, but Koji built all the packages. Everything was fine for Fedora 25 and 26, but Fedora 27 failed. Koji scratch builds keep me on the right track and make sure my packages build successfully.

Problem: Fedora 27 builds failing! 🔗

Now I know that my Fedora 27 package was failing to build on Koji. But why? I discovered two relevant changes for Fedora 27.

• Subpackage and Source Debuginfo
• RPM 4.14 (specifically, the debuginfo package rewrite)

These changes mean that RPM packages must build with a debuginfo package. This is helpful for troubleshooting or debugging an application. In my case, this wasn’t critical or too necessary, but I needed to build one.

Thanks to Igor Gnatenko, he helped me understand what I needed to add to my package SPEC for it to build on Fedora 27. Before the %make_build macro, I added these lines.

export CFLAGS="%{optflags}"
export LDFLAGS="%{__global_ldflags}"

I built a new SRPM and submitted it to Koji to build on Fedora 27. And success! It built successfully.

Submitting the package 🔗

Now that I verified my package successfully built on Fedora 25 to 27, it’s time to begin the packaging process for Fedora. The first step to submitting a package is to create a new bug in the Red Hat Bugzilla to ask for a package review. I created a ticket for brightlight. Since this was my first package, I made an explicit note that this was my first package and I was seeking a sponsor. In the ticket, I linked to the SPEC and SRPM files in my git repository.

Getting into dist-git 🔗

Edit, 2022 Feb. 14th: It was pointed out on Twitter that the fedrepo-req tool is no longer used. See the documentation linked throughout this blog post for more guidance on best practices for today.

Igor Gnatenko sponsored me into the Fedora Packagers group and left feedback on my package. I learned of some other things specific for packaging C applications. After he sponsored me, I was able to ask for a repo in dist-git, Fedora’s collection of RPM package repositories that host SPEC files for all of Fedora.

A handy Python tool helps make this part easy. fedrepo-req is a tool that creates a request for a new dist-git repository. I submitted my request with this command.

fedrepo-req brightlight \
    --ticket 1505026 \
    --description "CLI tool to change screen back light brightness" \
    --upstreamurl https://github.com/multiplexd/brightlight

This created a new ticket for me in the fedora-scm-requests repo. The next day, an admin created the repository for me. Now, I was in business!

Working with dist-git 🔗

Next, fedpkg is the tool used for interacting with dist-git repositories. I changed directories into my git working directory and ran this command.

fedpkg clone brightlight

fedpkg then clones my package’s repo from dist-git. For the first branch only, you need to import the SRPM.

fedpkg import SRPMS/brightlight-5-1.fc26.src.rpm

fedpkg imports your package’s SRPM into the repo and sets up the sources for you. It’s important to use fedpkg for this because it helps provision the repo in a Fedora-friendly way (as compared to adding the files manually yourself). Once you import the SRPM, push the changes to the dist-git repo.

git commit -m "Initial import (#1505026)."
git push

Building the package 🔗

Once you push the first import to your dist-git repo, you’re ready to do a real Koji build of your project. To build your project, run this command.

fedpkg build

This builds your package in Koji for Rawhide, the unversioned branch of Fedora. You must build successfully for Rawhide before you can build for other branches. IF everything builds successfully, you can now ask for other branches for your project.

fedrepo-req brightlight f27 -t 1505026
fedrepo-req brightlight f26 -t 1505026
fedrepo-req brightlight f25 -t 1505026

Note about building other branches 🔗

Once you import the SRPM initially, remember to merge your master branch to other branches, if you choose to create them. For example, if you later request a branch for Fedora 27, you would want to use these commands.

fedpkg switch-branch f27
git merge master
git push
fedpkg build

Submitting update to Bodhi 🔗

The last step of the process is to submit your new package as an update to Bodhi. When you first submit your package as an update, it goes to the testing repositories. Anyone can test your package and add karma to the update. If your update receives +3 votes (or as Bodhi calls it, karma), your package automatically pushes to the stable repositories. Otherwise, it pushes after a week in the testing repositories.

To submit your update to Bodhi, you only need one command.

fedpkg update

This opens a Vim window with different configuration options for your package. Usually, you only need to specify the type (e.g. newpackage) and the ticket ID number for your package review. For a more in-depth explanation, there is an update guide on the Fedora wiki.

After saving and exiting the file, fedpkg submits your package as an update to Bodhi and eventually synchronizes to the Fedora testing repositories. I was able to install my package with this command.

sudo dnf install brightlight -y --enablerepo=updates-testing --refresh

We’re stable! 🔗

My package was recently submitted to Fedora 26 stable repositories and will soon enter Fedora 25 and Fedora 27 stable repositories. Thanks for everyone who helped me with my first package. I look forward to more opportunities to add more packages to the distribution.

Last week moved quickly for me in ListenBrainz. I submitted multiple pull requests and participated in the weekly developer’s meeting on Monday. I was also invited to take part as a mentor for ListenBrainz for the upcoming round of Google Code-In! In addition to my changes and new role as a mentor, I’m researching libraries like D3.js to help build visualizations for music data.  Suddenly, everything started moving fast!

Last week: Recap 🔗

The ListenBrainz team accepted my development environment improvements and documentation. This gave me an opportunity to better explore project documentation tools. I experimented with Sphinx and Read the Docs. Sphinx introduced me to reStructuredText for documentation formats. I’ve avoided it in favor of Markdown for a long time, but I see where reStructuredText is stronger for advanced documentation.

Since ListenBrainz is a new project, I plan to contribute documentation for any of my work and improve documentation for pre-existing work. One of the goals for this independent study is to make ListenBrainz a viable candidate for a future data analysis course. To make it easy to use and understand, ListenBrainz needs excellent documentation. Since one of my strengths is technical writing, I plan to contribute more documentation this semester.

You can see some of the new documentation already!

Google Code-In mentor 🔗

The MetaBrainz community manager, Freso Olesen, approached me to mentor for Google Code-In. Google Code-In is an opportunity for teenagers to meaningfully contribute to open source projects. Google describes Google Code-In as…

Pre-university students ages 13 to 17 are invited to take part in Google Code-in: Our global, online contest introducing teenagers to the world of open source development. With a wide variety of bite-sized tasks, it’s easy for beginners to jump in and get started no matter what skills they have.

Mentors from our participating organizations lend a helping hand as participants learn what it’s like to work on an open source project. Participants get to work on real software and win prizes from t-shirts to a trip to Google HQ!

MetaBrainz is a participating organization of Google Code-In this cycle. Because of my work with ListenBrainz, I will contribute a few hours a week to help mentor participating students with ListenBrainz. Beginner problems should be easy to help with since I’m still beginning too, and as I spend more time with ListenBrainz, I can help with harder problems.

I’m excited to give back to one of my favorite open source projects in this way! I’m grateful to have this chance to help out during Google Code-In.

Choosing easyfix bugs 🔗

After I figured out the development environment issues, I went through open tickets filed against ListenBrainz to find some to work on. I made a preliminary pass through all open tickets and left some comments for more information, when needed. The tickets I highlighted to look into next were

• LB-85: Username in the profile URL should be case insensitive
• LB-124: Install messybrainz as a a python library from requirements
• LB-176: Add stats module and begin calculating some user stats from BigQuery
• LB-206: “playing_now” submissions not showing on profile
• LB-212: Show the MetaBrainz logo on the listenbrainz footer.

Of these five, LB-124 and LB-212 are already closed. While drafting this article, I completed LB-124 in PR #266. This was part of a test to get the documentation building again because of odd import errors. Later, a new student also learning the project for the first time asked to work on LB-212. Since it was a good first task to explore the project code, I passed the ticket to him.

I want to do one more “easyfix” bug before going into the main part of my independent study timeline. I don’t yet feel comfortable with the code and one more bug solved will help. After this, I plan to pursue the heavier lifting of the independent study to explore data operations and queries to make.

Researching D3.js 🔗

Prof. Roberts introduced D3.js as a library to build interactive, dynamic charts and visual representations of data. I haven’t yet looked into much front-end work, but this was a cool project that I wanted to highlight in my weekly report. This feels like it could be a powerful match for ListenBrainz, especially since the data has high detail.

Upcoming activity 🔗

This next week, I won’t have as much time to contribute to ListenBrainz. On October 21, I’m traveling to Raleigh, NC for All Things Open. On October 24, I present my talk, “What open source and J.K. Rowling have in common”. Since I’ll be out of Rochester and missing other classwork, I expect less time on my ListenBrainz work.

This next week will be slower than the last two weeks. Hopefully I’ll learn something at the conference too to bring back for ListenBrainz.

Until then… keep the FOSS flag high.

After deep consideration, I am resigning from the Fedora Council effective at the end of the Fedora 26 release cycle.

Why I’m stepping back 🔗

When I decided to run for Fedora Council in July, I had not yet moved back to Rochester, New York. From my past experiences, I didn’t predict an issue to fulfill my commitments to the Fedora community. However, since moving back to Rochester, it is difficult to fulfill my expectations, Council and otherwise, to Fedora.

I’m entering the last years of my degree and the rigor of my coursework demands more time and focus. Additionally, I’m working more hours this year than I have in the past, which takes away more time Fedora. Because student loans are too real.

If I expected these changes, I would not have run for the Council. However, from my short time on the Council, I understand the energy and dedication needed to represent the community effectively. During my campaign and term, this was my driving motivation – to do my best to represent an international community of thousands in the highest body of leadership in Fedora. Now, I do not feel I am meeting my standard of participation and engagement. Already, I’ve stepped back from the Fedora Magazine and Marketing teams to focus more time in other areas of Fedora. Now, it is right to do the same for the Council.

I will spend the most time in the CommOps and Diversity teams, since I believe that is where I can make the largest impact as a contributor.

Fedora 27 Council elections 🔗

I privately shared my resignation with the Fedora Council before writing this post. After discussing with other Council members, the plan is

1. Elect a new, full-term Council member for Fedora 27 and 28
2. Elect a new, half-term Council member for only Fedora 27

In past elections with half-term seats, the candidate with the most votes receives the full-term seat and the runner-up receives the half-term seat. I expect this to happen again, although final details will come once the election phase begins.

Thank you for your trust 🔗

This is one of the most difficult decisions I’ve made in Fedora. Serving on the Fedora Council is the greatest privilege. My election to the Council by hundreds of people was humbling and inspired me to not only lead by example, but represent the perspective of the greater Fedora community to the Council. This was the greatest honor for me and it disappoints me to finish my term early.

However, based on current circumstances, I believe this is the best path forward to make sure the community is well-represented in Fedora leadership. Thank you for your trust and I hope I can return to serve the community in this capacity someday in the future.

One of the first rites of passage when working on a new project is creating your development environment. It always seems simple, but sometimes there are bumps along the way. The first activity I did to begin contributing to ListenBrainz was create my development environment. I wasn’t successful with the documentation in the README, so I had to play around and work with the project before I was even running it.

The first part of this post details how to set up your own development environment. Then, the second half talks about the solution I came up with and my first contribution back to the project.

Install dependencies: Docker 🔗

This tutorial assumes you are using a Linux distribution. If you’re using a different operating system, install the necessary dependencies or packages with your preferred method.

ListenBrainz ships in Docker containers, which helps create your development environment and later deploy the application. Therefore, to work on the project, you need to install Docker and use containers for building the project. Containers save you from installing all of this on your own workstation! Since I’m using Fedora, I run this command.

sudo dnf install docker docker-compose

Register a MusicBrainz application 🔗

Next, you need to register your application and get a OAuth token from MusicBrainz. Using the OAuth token lets you sign into your development environment with your MusicBrainz account. Then, you can import your plays from somewhere else.

To register, visit the MusicBrainz applications page. There, look for the option to register your application. Fill out the form with these three options.

• Name: (any name you want and will recognize, I used listenbrainz-server-devel)
• Type: Web Application
• Callback URL: http://localhost/login/musicbrainz/post

After entering this information, you’ll have a OAuth client ID and OAuth client secret. You’ll use these for configuring ListenBrainz.

Update config.py 🔗

With your new client ID and secret, update the ListenBrainz configuration file. If this is your first time configuring ListenBrainz, copy the sample to a live configuration.

cp listenbrainz/config.py.sample listenbrainz/config.py

Next, open the file with your favorite text editor and look for this section.

# MusicBrainz OAuth
MUSICBRAINZ_CLIENT_ID = "CLIENT_ID"
MUSICBRAINZ_CLIENT_SECRET = "CLIENT_SECRET"

Update the strings with your client ID and secret. After doing this, your ListenBrainz development environment is able to authenticate and log in from your MusicBrainz login.

Initialize ListenBrainz databases 🔗

Your development environment needs some databases present to work. Before proceeding, run these three commands to initialize the databases.

docker-compose -f docker/docker-compose.yml -p listenbrainz run --rm web python3 manage.py init_db --create-db
docker-compose -f docker/docker-compose.yml -p listenbrainz run --rm web python3 manage.py init_msb_db --create-db
docker-compose -f docker/docker-compose.yml -p listenbrainz run --rm web python3 manage.py init_influx

Your development environment is now ready. Now, let’s actually see ListenBrainz load locally!

Run the magic script 🔗

Once you have done this, run the develop.sh script in the root of the repository. Using docker-compose, the script creates multiple Docker containers for the different services and parts of the ListenBrainz server. Running this script will start Redis, PostgreSQL, InfluxDB, and web server containers, to name a few. But this also makes it easy to stop them all later.

./develop.sh

You will see the containers build and eventually run. Leave the script running to see your development environment. Later, you can shut it down by pressing CTRL^C. Once everything is running, visit your new site from your browser!

http://localhost/

Now, you are all set to begin making changes and testing them in your development environment!

Making my first pull request 🔗

As mentioned earlier, my first attempt at a development environment was unsuccessful. My system kept denying permission to the processes in the containers. After looking at system audit logs and running a temporary setenforce 0, I tried the script one more time. Everything suddenly worked! So the issue was mostly with SELinux.

With my goal to get my environment set up, I figured out a few issues with the configuration offered by the project developers. I eventually made PR #257 against listenbrainz-server with my improvements.

Labeling SELinux volume mounts 🔗

To diagnose the issue, I started with a quick search and found a StackOverflow question with my same problem. There, the question was about Docker containers and denied permissions in the container. The answers explained it was an SELinux error and the context for the containers was not set. However, temporarily changing context for a directory didn’t seem too effective and doesn’t persist across reboots.

Continuing the search, I found an issue filed against docker-compose about the :z and :Z flags for volume mounts. These flags set SELinux context for containers, with the best explanation I found coming from this StackOverflow answer.

Two suffixes :z or :Z can be added to the volume mount. These suffixes tell Docker to relabel file objects on the shared volumes. The ‘z’ option tells Docker that the volume content will be shared between containers. Docker will label the content with a shared content label. Shared volumes labels allow all containers to read/write content. The ‘Z’ option tells Docker to label the content with a private unshared label.

Therefore, I added the :z flag to all the volume mounts in the docker-compose.yml file. I submitted a fix upstream for this in listenbrainz-server#257!

Correct the startup port 🔗

In the README, it says the server will start on port 8000, but the docker-compose.yml file actually started the server on port 80. I included a fix for this in my pull request as well.

git push! 🔗

This post makes a debugging experience that actually took hours look like it happened in minutes. But after getting over this hurdle, it was awesome to finally see ListenBrainz running locally on my workstation. It was an even better feeling when I could take my improvements and send them back in a pull request to ListenBrainz. Hopefully this will make it easier for others to create their own development environments and start hacking!

Many students take part in independent studies where they work on their own projects. However, in the spirit of open source collaboration, I wanted to contribute to a project that already existed. That way, my work would be helpful to a real-world project where it would have a value even after the end of the semester. Additionally, I wanted  a project to help me sharpen my Python skill. And ListenBrainz was a fun, exciting candidate for this.

Objectives 🔗

The independent study proposal included three primary goals I hoped to meet during this independent study:

1. Add basic reports to ListenBrainz from listening history data for top songs / artists / albums of week, month, year, etc.
2. Create documentation to improve ease to use and develop for the ListenBrainz project
3. Offer as a use case for the data visualization course in fall 2018 with instructions on how to use the data

Add basic reports 🔗

Methods for generating basic reports, charts, and statistics about listening history are important. They help make ListenBrainz a more interesting platform for a casual music listener, not just a developer. Therefore, my goal was to add a way to add basic reports or specific metrics for presenting to the user in the front-end.

As a stretch goal, if I have extra time, I would work on generating content (e.g. charts / graphs / statistics) to show the user in the front-end.

Documentation 🔗

Documentation is something near and dear to me. I enjoy making it easier for other people to use a project or get started with contributing. Therefore, I will contribute some time as a technical writer and help improve documentation on the project. This includes improving existing documentation, like how to set up a development environment, or creating new content.

As an end deliverable, it would be nice to have someone who has never worked with the project run get a development environment set up, import some data, and see something presented to them. Good documentation is key to making something like this possible.

Use case for data course 🔗

RIT will offer a data visualization course in future semesters and it would be helpful if ListenBrainz could be a use case or even tool for the course. Then, students could work with ListenBrainz for creating different visualizations for the music data. And maybe contribute some of their visualizations back upstream! For this to happen, we need comprehensive documentation and complete features.

A focus includes making ListenBrainz a good fit for this course.

Learn more about ListenBrainz 🔗

For the next few months, until December, I will blog regularly about contributing to the ListenBrainz project and my progress. Additionally, more posts about MusicBrainz, other MetaBrainz projects, or music data may follow. I’m hoping to either create new or improve old documentation as well, so I plan to write often anyways!

For now, you can learn a bit more about ListenBrainz and other projects in the MetaBrainz family, like MusicBrainz.

• ListenBrainz
• GitHub: metabrainz/listenbrainz-server
• About MusicBrainz
• About MetaBrainz

Open source software has come a long way since the turn of the century. Each year, more and more people are embracing open source technology and development models. Not just people, though ­– corporations and governments are exploring open source solutions too. From the White House to the Italian army, open source is appearing more frequently in the public sector. But perhaps the newest addition to the list is the municipality of Tirana, Albania.

On June 11th, the local government in the municipality of Tirana migrated their private cloud to Nextcloud, an open source cloud and office productivity suite. The decision to move to an integrated cloud / office suite came after internal discussion about security and performance. Because Nextcloud is entirely open source, it stood out as a powerful option for the municipality to consider.

Why switch to Nextcloud? 🔗

The municipality was looking for ways to optimize on costs without sacrificing security. Many people deeply familiar with open source are already aware of the security benefits of using open source software. Instead of relying on a private firm to assure the code is secure, open source software benefits from letting anyone (or paying someone else) to audit the code, find flaws, and submit bugs or patches to get them fixed. This was something Ermir Puka and other members of the IT team in Tirana considered when choosing a cloud solution for the 600 employees of the municipality.

“The IT directory at the municipality of Tirana thought the movement to Nextcloud, which is an open source platform, gives us flexibility since we won’t be dependent from providers who offer proprietary solutions. We can also develop it ourself, according to our needs, if we have the staff with the necessary qualifications to do such a thing,” Puka said.

Nextcloud also stood out not only for its use as a file sharing tool, but also the other features that make it helpful as an office productivity suite. With Nextcloud, you can edit documents simultaneously with Collabora Online, share calendars with co-workers, use an intranet messaging system, and use it on your phone too. A large selection of open source apps are available to add to an Nextcloud installation.

According to European Commission Joinup, Tirana is one of the first municipalities in southeastern Europe implementing open source technology in the public sector. This continues the municipality’s growing interest in open source, following the recent announcement of their open data portal (see it at opendata.tirana.al) and decision to collaborate with the local open source community by contributing GIS data to OpenStreetMaps. “We also hope to give a good example in the region and maybe other municipalities can follow our example,” Puka added. This further shows the municipality’s dedication to saving money on software licenses, protecting user privacy, and innovating by using open source technology.

About Tirana 🔗

Tirana is located in Albania, in southeastern Europe, on the Mediterranean Sea just above Greece. The open source community in Tirana is growing each year. This is in part to the Open Labs Albania community in the city. Open Labs Albania is a not-for-profit hackerspace that promotes free and open source technologies, open data, open technological standards, and online privacy. You can read more about them in their manifesto.

This continues a trend of exciting news for open source in the region. Earlier this year, the first-ever overnight hackathon for the UN Sustainable Development Goals happened in March, with an emphasis on sustainable projects with open source licenses. They also host Linux Weekend, an annual mini-conference to help on-board students and interested technologists to Linux and open source. However, their most well-known event is Open Source Conference Albania (OSCAL), an annual conference gathering open source developers and community members from across the world. Together with the municipality, Open Labs has helped provide advice and support for some of the municipality’s research into using open source software.

Get in touch 🔗

If you’re interested in learning more or sharing your thoughts, you can view the public announcement on the European Commission website or visit the thread on the Open Labs forums.

The needs and demands of infrastructure environments changes every year. With time, systems become more complex and involved. But when infrastructure grows and becomes more complex, it’s meaningless if we don’t understand it and what’s happening in our environment. This is why monitoring tools and software are often used in these environments, so operators and administrators see problems and fix them in real-time. But what if we want to predict problems before they happen? Collecting metrics and data about our environment give us a window into how our infrastructure is performing and lets us make predictions based on data. When we know and understand what’s happening, we can prevent problems before they happen.

But how do we collect and store this data? For example, if we want to collect data on the CPU usage of 100 machines every ten seconds, we’re generating a lot of data. On top of that, what if each machine is running fifteen containers? What if you want to generate data about each of those individual containers too? What about by the process? This is where time-series data becomes helpful. Time-series databases store time-series data. But what does that mean? We’ll explain all of this and more and introduce you to InfluxDB, an open source time-series database. By the end of this article, you will understand…

• What time-series data / databases are
• Quick introduction to InfluxDB and the TICK stack
• How to install InfluxDB and other tools

Introducing time-series concepts 🔗

If you’re familiar with relational database management software (RDBMS), like MySQL, tables, columns, and primary keys are familiar terms. Everything is like a spreadsheet, with columns and rows. Some data might be unique, other parts might be the same as other rows. RBDMS’s like MySQL are widely used and are great for reliable transactions that follow ACID (Atomicity, Consistency, Isolation, Durability) compliance.

With relational database software, you’re usually working with data that is something you could model in a table. You might update certain data by overwriting and replacing it. But what if you’re collecting on data on something that generates a lot of data and you want to watch change over time? Take a self-driving car. The car is constantly collecting information about its environment. It takes this data and it analyzes changes over time to behave correctly. The amount of data might be tens of gigabytes an hour. While you could use a relational database to collect this data, they’re not built for this. When it comes to scaling and usability of the data you’re collecting, an RBDMS isn’t the best tool for the job.

Why time-series is a good fit 🔗

And this is where time-series data makes sense. Let’s say you’re collecting data about a city traffic, temperature from farming equipment, or the production rate of an assembly line. Instead of going into a table with rows and columns, imagine pushing multiple rows of data that are uniquely sorted by a timestamp. This visual might help make more sense of this.

Having the data in this format makes it easier to track and watch change over time. When data accumulates, you can see how something behaved in the past, how it’s behaving now, and how it might behave in the future. Your options to make smarter data decisions expands!

Curious how the data is stored and formatted? It depends on the time-series database (TSDB) you use. InfluxDB stores the data in the Line Protocol format. Queries return the data in JSON.

If you’re still confused or trying to understand time-series data or why you would want to use it over another solution, you can read an excellent, in-depth explanation from Timescale’s blog or InfluxData’s blog.

InfluxDB: A time-series database 🔗

InfluxDB is an open source time-series database software developed by InfluxData. It’s written in Go (a compiled language), which means you can start using it without installing any dependencies. It supports multiple data ingestion protocols, such as Telegraf (also from InfluxData), Graphite, collectd, and OpenTSDB. This leaves you with flexible options for how you want to collect data and where you’re pulling it from. It’s also one of the fastest-growing time-series database software available. You can find the source code for InfluxDB on GitHub.

This article will focus on three tools in InfluxData’s TICK stack for how you can build a time-series database and begin collecting and processing data.

TICK stack 🔗

InfluxData creates a platform based on four open source projects that work and play well with each other for time-series data. When used together, you can collect, store, process, and view the data easily. The four pieces of the platform are known as the TICK stack. This stands for…

• _T_elegraf: Plugin-driven server agent for collecting / reporting metrics
• _I_nfluxDB: Scalable data store for metrics, events, and real-time analytics
• _C_hronograf: Monitoring / visualization UI for TICK stack (not covered in this article)
• _K_apacitor: Framework for processing, monitoring, and alerting on time-series data

These tools work and integrate well with the other pieces by design. However, it’s also easy to substitute one piece out for another tool of your choice. For this article, we’ll explore three parts of the TICK stack: InfluxDB, Telegraf, and Kapacitor.

InfluxDB 🔗

As mentioned before, InfluxDB is the time-series database (TSDB) of the TICK stack. Data collected from your environment is stored into InfluxDB. There are a few things that stand out about InfluxDB from other time-series databases.

Emphasis on performance 🔗

InfluxDB is designed with performance as one of the top priorities. This allows you to use data quickly and easily, even under heavy loads. To do this, InfluxDB focuses on quickly ingesting the data and using compression to keep it manageable. To query and write data, it uses an HTTP(S) API.

The performance notes are noteworthy standing up the amount of data InfluxDB is capable of handling. It can handle up to a million points of data per second, at a precise level even to the nanosecond.

SQL-like queries 🔗

If you’re familiar with SQL-like syntax, querying data from InfluxDB will feel familiar. It uses its own SQL-like syntax, InfluxQL, for queries. As an example, imagine you’re collecting data on used disk space on a machine. If you wanted to see that data, you could write a query that might look like this.

SELECT mean(diskspace_used) as mean_disk_used
FROM disk_stats
WHERE time() >= 3m
GROUP BY time(10d)

If you’re familiar with SQL syntax, this won’t feel too different. The above statement will pull the mean values of used disk space from a three-month period and group them by every ten days.

Downsampling / data retention 🔗

When working with large amounts of data, storing it becomes a concern. Over time, it can accumulate to huge sizes. With InfluxDB, you can downsample into less precise, but smaller metrics that you can store for longer periods of time. Data retention policies for your data enable you to do this.

For example, pretend you have sensors collecting data on the amount of RAM in a number of machines. You might collect metrics on the amount of memory in use by multiple users, the system, cached memory, and more. While it might make sense to hang on to that data for thirty days to watch what’s happening, after thirty days, you might not need it that precise. Instead, you might only want the ratio of total memory to memory in use. Using data retention policies, you can tell InfluxDB to hang on to the precise data for all the different usages for thirty days. After thirty days, you can average data to be less precise, and you can hold on to that data for six months, forever, or however long you like. This compromise meets in the middle between keeping historical data and reducing disk usage.

Telegraf 🔗

If InfluxDB is where all of your data is going, you need a way to collect and gather the data first. Telegraf is a metric collection daemon that gathers various metrics from system components, IoT sensors, and more. It’s open source and written completely in Go. Like InfluxDB, Telegraf is also written by the InfluxData team and is built to work with InfluxDB. It also includes support for different databases, such as MySQL / MariaDB, MongoDB, Redis, and more. You can read more about it on InfluxData’s website.

Telegraf is modular and heavily based on plugins. This means that Telegraf is either lean and minimal or as full and complex as you need it. Out of the box, it supports over a hundred plugins for various input sources. This includes Apache, Ceph, Docker, IPTables, Kubernetes, NGINX, and Varnish, just to name a few. You can see all the plugins, including processing and output plugins in their README.

Even if you’re not using InfluxDB as a data store, you may find Telegraf useful as a way to collect this data and information about your systems or sensors.

Kapacitor 🔗

Now we have a way to collect and store our data. But what about doing things with it? Kapacitor is the piece of the stack that lets you process and work with the data in a few different ways. It supports both stream and batch data. Stream data means you can actively work and shape the data in real-time, even before it makes it to your data store. Batch data means you retroactively perform actions on samples, or batches, of the data.

One of the biggest pluses for Kapacitor is that it enables you to have real-time alerts for events happening in your environment. CPU usage overloading or temperatures too high? You can set up several different alert systems, including but not limited to email, triggering a command, Slack, HipChat, OpsGenie, and many more. You can see the full list in the documentation.

Like the previous tools, Kapacitor is also open source and you can read more about the project in their README.

Installing the TICK stack 🔗

Packages are available for nearly every distribution. You can install these packages from the command line. Use the instructions for your distribution.

Fedora 🔗

sudo dnf install https://dl.influxdata.com/influxdb/releases/influxdb-1.3.1.x86_64.rpm \
https://dl.influxdata.com/telegraf/releases/telegraf-1.3.4-1.x86_64.rpm \
https://dl.influxdata.com/kapacitor/releases/kapacitor-1.3.1.x86_64.rpm

CentOS 7 / RHEL 7 🔗

sudo yum install https://dl.influxdata.com/influxdb/releases/influxdb-1.3.1.x86_64.rpm \
https://dl.influxdata.com/telegraf/releases/telegraf-1.3.4-1.x86_64.rpm \
https://dl.influxdata.com/kapacitor/releases/kapacitor-1.3.1.x86_64.rpm

Ubuntu / Debian 🔗

wget https://dl.influxdata.com/influxdb/releases/influxdb_1.3.1_amd64.deb \
https://dl.influxdata.com/telegraf/releases/telegraf_1.3.4-1_amd64.deb \
https://dl.influxdata.com/kapacitor/releases/kapacitor_1.3.1_amd64.deb
sudo dpkg -i influxdb_1.3.1_amd64.deb telegraf_1.3.4-1_amd64.deb kapacitor_1.3.1_amd64.deb

Other distributions 🔗

For help with other distributions, see the Downloads page.

See the data, be the data 🔗

Now that you have the tools installed, you can experiment with some of these tools. There’s plenty of upstream documentation on all three projects. You can the docs here:

• InfluxDB documentation
• Telegraf documentation
• Kapacitor documentation

Additionally, for more help, you can visit the InfluxData community forums. Happy hacking!

Internet Relay Chat, or IRC, is one of the oldest chat protocols around and still popular in many open source communities. IRC’s best strengths are as a decentralized and open communication method, making it easy for anyone to participate by running a network of their own. There’s also a variety of clients and bots available for IRC. But on the reverse side, usability is a concern. Most common user interfaces for IRC clients or platforms aren’t always intuitive. People from parts of the world with unstable Internet connections are challenged with remaining connected to participate in conversation. Many people have tried addressing this problem before, but none have come as far as Riot.

What is Riot? 🔗

Riot is a free, open source, and multi-platform client based on the Matrix protocol. To understand better, think of Matrix as the protocol and Riot as the client. Matrix is a decentralized, secure, messaging protocol. It has the benefit of using HTTP / JSON APIs, is capable of sending and receiving messages with full end-to-end encryption, WebRTC VoIP / video calling, and maybe most importantly, integration capabilities. Matrix was built to integrate with IRC servers and other communication protocols, meaning you can use the Riot client as an IRC bouncer. You can read more of the details on what separates Matrix from Riot on their FAQ.

As a result, Riot becomes most useful in its implementation as the default Matrix client. It’s convenient and decentralized, as anyone is able to launch their own Matrix “homeserver” and connect it with Riot. However, Matrix by default has servers bridged with Freenode, Mozilla IRC, and more. This lets you use Riot as a persistent client that keeps you connected to IRC even when you’re not there.

Outside of the web application, you can also find it as a desktop application for Mac, Windows, and Linux, or a mobile application for iOS and Android. In this guide, you’ll learn how to get started using Riot as a full-time messaging client with the default Matrix / IRC integration servers.

Register and get a client 🔗

First, you’ll need to grab an account from Riot’s website. Registration is straightforward and shouldn’t take you much time. You can find the registration form here. Once you’re registered and have confirmed your email, you’ll need to get the Riot applications on your devices of choice.

Desktop clients 🔗

There are desktop clients available for Windows, macOS, and Linux. If you’re running Windows or macOS, you can download the right version for your desktop on the Riot downloads page. If you’re using Debian, Ubuntu, or a related operating system, you can add a repository to your system to install the Riot desktop client. You can read this guide on how to add the repository and install Riot to your system.

Fedora 🔗

Riot is not yet officially packaged in Fedora’s repositories. However, there is a third-party Copr repository where the desktop application is packaged. Until it makes it into Fedora’s repositories, you can use this version to get started with Riot. You can find the Copr project and install instructions here.

Mobile clients 🔗

Want to have Riot integrated on your phone or prefer a mobile client? You can also find official versions of Riot on iOS, Google Play Store, and F-Droid. Using any of the mobile clients will integrate fully with a desktop client, if you choose to use both. This guide will focus more on the desktop clients.

Setting up Freenode in Riot 🔗

Riot currently supports eight IRC networks: Freenode, Moznet, Snoonet, OFTC, GIMPNet, Foonetic, Rizon, and EsperNet. Although you can use any network you like and the instructions will mostly be the same, this guide focuses on using Freenode.

Joining your first channel 🔗

One of the first things you’ll see after signing into Riot is the directory. In the directory, you can search through chat rooms on Matrix itself or any of the other IRC servers that are integrated. To join your first channel, you can select the IRC channel of choice in the dropdown menu and search for a channel.

For example, if we want to find #opensource.com on Freenode, you can select the Freenode option and search for #opensource.com. Once it’s there, you can join and say hello to the rest of the Opensource.com community hanging out in IRC.

Alternatively, if you would prefer directly joining a room, you can type the following as a command from any chat window in Riot.

/join #freenode_#channelname:matrix.org

Setting your IRC nick 🔗

By default, your IRC nick, or username, will be similar to your display name in Riot. Sometimes it will have a [m] appended to the end. However, after you connect to a channel, you can change your nick on the IRC side as well. You’ll need to start a new conversation with the IRC integration bot between Riot and Freenode.

In the bottom left corner of your Riot client, you can start a new personal chat with any user. To message the IRC integration bot, start a new chat with @appservice-irc:matrix.org. This will put you and the bot together in a private chat. To change your nick, send the following command to the bot:

!nick irc.freenode.net <IRC nick>

You should receive a confirmation message, similar to: “Nick changed from ‘OldNick’ to ‘NewNick.’” For more help, you can read the official documentation on changing your nick.

Authenticating with NickServ 🔗

One of the other vital functions you might need to do is authenticate with NickServ. This is especially important if you want to use your registered IRC nick or are a member of invite-only channels. However, it’s possible to do this too.

You’ll need to start another direct chat again. This time, you can search for the user @freenode_NickServ:matrix.org. This will put you into a private message with NickServ on Freenode’s servers. To authenticate, you can send a message just like you normally would.

IDENTIFY <username> <password>

After doing this, you should receive the normal confirmation that you are now logged in as your account. Remember to use caution when opening this chat in a public place, as your password will be displayed in plaintext whenever you open that direct message with NickServ.

Say hello! 🔗

Once you’ve joined a channel, claimed your nick, and authenticated with NickServ, you will be all set to begin using Riot. In any channel bridged in IRC with Matrix, all of your messages from Riot will show up in the IRC channel. Riot can also act like an IRC bouncer that keeps you persistently connected. Whenever you open Riot, you will be able to see a log of past discussions even if you weren’t connected to the Internet.

Both Matrix and Riot are open source projects. You can find Matrix’s code and Riot’s code on GitHub. If you want to better understand how the integration bridge works, you can read this blog post by one of the developers.

Have any comments or stories to share about using Riot? Are you already using it for IRC? Share your comments with us down below!

Welcome back to the Kubernetes and Fedora series. Each week, we build on the previous articles in the series to help introduce you to using Kubernetes. This article picks up from where we left off last when you installed Tectonic to Amazon Web Services (AWS). By the end of this article, you will…

• Start up Redis master and slave pods
• Start a front-end pod that interacts with the Redis pods
• Deploy a simple web app for all of your friends to leave you messages

Compared to previous articles, this article will be a little more hands-on. Also like before, this is based off an excellent tutorial in the upstream Kubernetes documentation. Let’s get started!

Pre-requisites 🔗

This tutorial assumes you followed the Minikube how-to earlier in this series and that you already have a Tectonic installation running (doesn’t have to be on AWS). In case you’re jumping in now, make sure you have the Kubernetes client tools installed on your Fedora system, like kubectl. If not, you can install them now.

$ sudo dnf install kubernetes-client

Configure kubectl for Tectonic 🔗

To use kubectl with your Tectonic installation, you need to have a valid configuration in ~/.kube/config for your cluster. This is how kubectl knows where and how to talk to Tectonic. To get these values, first log into the Tectonic Console you installed.

1. Click username (usually admin) > My Account on the bottom left.
2. Click Download Configuration.
3. When the Set Up kubectl window opens, click Verify Identity.
4. Enter your username and password, and click Login.
5. From the Login Successful screen, copy the provided code.
6. Switch back to Tectonic and enter the code in the field.

Now you will be able to download kubectl-config from Tectonic. There’s two ways to proceed from here.

Add a new configuration 🔗

If this is your first time using kubectl, your configuration is likely empty. If it’s empty or you don’t care about overwriting an old configuration, you can run the following commands to add the configuration.

$ mkdir ~/.kube/
$ mv ~/Downloads/minikube-config ~/.kube/config
$ chmod 600 ~/.kube/config

Append to an existing configuration 🔗

If you already have a configuration, like from Minikube, you might not want to wipe it all out. In this case, you can merge the files manually together. You’ll need to copy the clusters, users, and contexts from the Tectonic configuration into your existing one. The benefit of doing this is that you’ll be able to change contexts to switch from one cluster to another.

Test your configuration 🔗

Once you finished your configuration, test to see if it works.

$ kubectl config use-context tectonic       # if you have multiple contexts in config
$ kubectl get nodes
NAME                                        STATUS    AGE
ip-10-0-0-59.us-east-2.compute.internal     Ready     1d
ip-10-0-23-239.us-east-2.compute.internal   Ready     1d
ip-10-0-44-211.us-east-2.compute.internal   Ready     1d
ip-10-0-61-218.us-east-2.compute.internal   Ready     1d
ip-10-0-67-239.us-east-2.compute.internal   Ready     1d
ip-10-0-95-51.us-east-2.compute.internal    Ready     1d

Huzzah! Now we’re ready to get to work.

Getting the deployment and service files 🔗

All of the example files come from the official Kubernetes GitHub repo. You can find them in the Guestbook example. To get started, create a new directory and download all of the files.

$ wget https://raw.githubusercontent.com/kubernetes/kubernetes/master/examples/guestbook/redis-{master,slave}-{deployment,service}.yaml \
       https://raw.githubusercontent.com/kubernetes/kubernetes/master/examples/guestbook/frontend-{deployment,service}.yaml

We’ll explain what all of these do in next steps. All of these next steps will start with the command to run, followed by a short explanation of what’s actually happening.

Start the Redis master 🔗

$ kubectl create -f redis-master-service.yaml
service "redis-master" created
$ kubectl create -f redis-master-deployment.yaml
deployment "redis-master" created

Define the deployment 🔗

The redis-master-deployment.yaml file downloaded earlier defines the deployment and its characteristics. In this case, we have one pod that runs the Redis master in a container. Since we’re using a deployment, that means if our pod goes down, Kubernetes will spin up a new pod to replace it. Worth noting in this example, if the pod did go down, there would be a potential for data loss until the new one replaces the old one (since the Redis master is not highly available, i.e. there are multiple).

Define the service 🔗

Our service in this example is a named load balancer that proxies traffic across one or many containers. Even though we only have one Redis master pod, we still want to use a service. This is a deterministic way of making the route to the master with a dynamic (or elastic) IP address.

Labeling the pods is important in this case, as Kubernetes will use the pods’ labels to determine which pods receive the traffic sent to the service, and load balance it accordingly.

Create the service 🔗

The next important step is to create the service. Note that we’re doing this before we create the deployment. It’s best practice to create the service first. This allows the scheduler to later spread the service across the deployments you create to support your application.

After creating the service, you can check its status by running this command. You should see similar output.

$ kubectl get services
NAME              CLUSTER-IP       EXTERNAL-IP       PORT(S)       AGE
redis-master      10.0.76.248      <none>            6379/TCP      1s

Now your Redis master serivce is up and running! The next step will be to create the Redis master deployment.

If you look at the service configuration file, you’ll notice port and targetPort are two defined variables. Once everything is up and running, these will be important for determining how the traffic from the slaves to the masters is routed.

1. Redis slave connects to port on Redis master service
2. Traffic forwarded from service’s port to targetPort on pod the service listens to

Create the deployment 🔗

Next, we created the Redis master pod in the cluster. To see our deployment and pods, we can run the following commands to see what was created.

$ kubectl get deployments
NAME           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
redis-master   1         1         1            1           27s

$ kubectl get pods
NAME                            READY     STATUS    RESTARTS   AGE
redis-master-2353460263-1ecey   1/1       Running   0          1m
...

You should see all of the pods in your cluster so far. For now, that’s just the Redis master. Let’s give it some friends!

Start the Redis slaves 🔗

$ kubectl create -f redis-slave-service.yaml
service "redis-slave" created
$ kubectl create -f redis-slave-deployment.yaml
deployment "redis-slave" created

Defining the deployment 🔗

In the configuration file, we defined two replicas, unlike the master. By doing this, it tells Kubernetes that the minimum number of pods that should always be running is two. If one of your pods goes down, Kubernetes automatically creates a new one to support the application. If you want, you can try killing the Docker process for one of your pods to see it happen in real time.

Start the guestbook front-end 🔗

$ kubectl create -f frontend-service.yaml
service "frontend" created
$ kubectl create -f frontend-deployment.yaml
deployment "frontend" created

The front-end is a PHP application with an AJAX interface and Angular-based UI. When using the form on the front-end application, it talks to the Redis master or slave, depending on if it’s reading or writing to Redis. Again, we’re deploying the front-end with multiple replicas. In this case, there will be three pods to support the front-end.

Say hello! 🔗

Once you’ve finished deploying everything, your web app should now be accessible! To get the full domain from AWS, run this command to figure out where to look.

$ kubectl get deploy/frontend svc/frontend -o wide
NAME           CLUSTER-IP   EXTERNAL-IP                                                             PORT(S)        AGE       SELECTOR
svc/frontend   10.3.0.175   aaebd8247ef2311e6a045021d1620193-54019671.us-east-2.elb.amazonaws.com   80:31020/TCP   1m        k8s-app=guestbook,tier=frontend

NAME              DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deploy/frontend   3         3         3            3           1m

Congratulations, we’re all finished!

Cleaning up 🔗

Once you’re finished or when you want to stop running the guestbook, it’s easy to get rid of the deployments and services we created. Using labels, all the deployments and services can be deleted with one command.

$ kubectl delete deployments,services -l "app in (redis, guestbook)"

And now your guestbook application is offline. (It was nice while it lasted!)

Learn more about Kubernetes and Tectonic 🔗

If you want to explore more about Kubernetes, you can read some of the earlier articles in this series. You can also read the original tutorial published by Kubernetes on GitHub. Additionally, the upstream documentation for Kubernetes and Tectonic is thorough and can help answer more advanced questions.

Questions, Tectonic stories, or tips for beginners? Add your comments below.

Past term 🔗

In this past election, the Council encouraged the new FAmSCo to retool themselves. They should support the Ambassadors in a new age of Linux outreach and events. And they have done exactly that. Clarifications and improvements to the mentorship policies are taking place, the Fedora Ambassadors Membership Administration (FAMA) was reformed, and a Fedora Activity Day (FAD) for the LATAM region was successfully planned and executed. As a voting Ambassador, I am proud of all FAmSCo members and happy to see the progress they have made this term.

One concern 🔗

However, one thing stood out to me the past election. All of the representatives on FAmSCo were only from the EMEA and LATAM regions. Part of the fault is that there were no NA candidates and only one candidate from APAC. Therefore, the benefit of this was that EMEA and LATAM communities were more in touch with FAmSCo, since members in their meeting included elected representatives. In NA and APAC, this was not the case.

For Ambassadors in these regions, we did not have an attendee in our meetings to share news with FAmSCo. If we wanted to keep up, we would have to dig deeper. In March, I filed two tickets to suggest opening the mailing list to public participation and establishing an IRC channel presence. Consequently, FAmSCo has improved on being more accessible and transparent for all Ambassadors.

However, there is still a disconnection when your region doesn’t have an elected official to help represent the unique needs and perspectives of your region. In NA, I thought it would help to have a representative. This past June, I traveled to India and met with some Ambassadors in Pune, India. My discussions with them led me to believe that APAC needs representation in FAmSCo too.

Looking ahead to the next FAmSCo 🔗

Three seats are open for this coming election in August, leaving four (fantastic and well-qualified) FAmSCo members from EMEA to serve another term. Therefore, this leaves one region of the world well-represented by the Fedora Ambassador leadership body. Seeing as there are three seats up for elections and three regions that could be represented, I encourage voters in the next FAmSCo election to remember how big the Fedora community is.

The planet is big, and it’s hard to know what’s happening in different countries, regions, and continents. While we are all united as Fedora Ambassadors, there are unique challenges that our Fedora friends from one region may face that others may not. There are cultural, language, and currency differences. Some communities have a better foundation while others need guidance and encouragement to grow. I encourage all participating voters in this next election to remember our friends around the world and to help keep everyone included and involved in the conversations that drive the project forward.

Welcome back to the Kubernetes and Fedora series. Each week, we build on the previous articles in the series to help introduce you to using Kubernetes. This article takes off from running Kubernetes on your own hardware and moves us one step closer to the cloud. By the end of this article, you will…

• Understand what CoreOS Tectonic is
• Set up Amazon Web Services (AWS) for Tectonic
• Deploy Tectonic to AWS

This article is also based off of the excellent tutorial provided in the CoreOS documentation. Let’s get started!

What is Tectonic? 🔗

In the first article, some of the key concepts of Kubernetes and why it’s useful were explained. Kubernetes automates the deployment and setting up of your infrastructure across the three layers (users, masters, nodes). If you’re working on your own at a small scale, Kubernetes itself can be plenty to meet your needs. However, there is still a decent amount of human involvement in managing the different pieces of Kubernetes. If you’re working with multiple people in a team and across different environments, vanilla Kubernetes can be a lot to manage. For an enterprise environment, there’s still some unmet needs. This is where Tectonic steps in.

Tectonic is a commercial product offered by CoreOS, the providers of Container Linux and the original developers of etcd, now one of the core components of Kubernetes. Tectonic takes all of the open source components and pre-packages them. The self-proclaimed goal of doing this is to let anyone build a Google-style infrastructure into a cloud or on-premise environment. The outcome for the user is that it’s easy to install a Kubernetes infrastructure across many different environments. In addition to simplifying the installation of the various components of a Kubernetes stack, Tectonic also provides a management console, a container registry for building and sharing containers, additional tools for deployment, and a few other nice features.

If we think about Kubernetes as a cake like we did before with three layers, Tectonic is like the box you set it in. Now, you can take your cake anywhere, move it around, and stack it with other cakes-in-a-box. All of your cakes are in their own boxes and you don’t have to worry about them accidentally being damaged. If you’re still a little confused, this diagram might help make more sense of it.

Fortunately, Tectonic has a free license that lets you use it for ten nodes. In this example, we’ll register, get a free license, and deploy it into AWS.

(Note: If you want to revert anything we do in this example, there’s an easy way to dismantle it across AWS and bring your bill to $0.00.)

Pre-requisites 🔗

In order to successfully run this guide, there’s a few things you’ll need first.

• Amazon Web Services (AWS) account (free)
  • Register here
• CoreOS Tectonic account and license (free)
  • Register here
• A root-level or sub-domain (e.g. example.com or k8s.example.com)
  • If you look around, you can probably find some for less than USD$1 a year if you need one
• Curiosity!

Setting up DNS with Route 53 🔗

The first things we’ll do is set up our domain with Route 53 in AWS. Route 53 can do a lot of things, like DNS management, traffic management, availability monitoring, domain registration, and more. However, we’re only going to be using it for DNS management. Tectonic will use this to automatically provision DNS records for internal and external use.

Add your domain 🔗

To add your domain to Route 53, follow these steps from AWS.

1. From Services, select Networking & Content Delivery > Route 53.
2. Select Hosted zones from the left pane and click Create Hosted Zone.
3. Enter your domain or sub-domain, add a comment if you want, and choose a Public Zone for the type.

Once you’ve done this, you can go ahead and click “Create”.

Change the nameservers 🔗

After adding the hosted zone to Route 53, you’ll need to change the nameservers for your domain via the domain registrar (whoever you bought the domain from). Usually it should be easy to find this, but it varies among registrars. If you’re having a hard figuring out how to do this, try searching for a how-to or contacting your registrar’s support.

After you added the hosted zone, you should see the nameservers in Route 53. There will be four nameservers provided there. You can copy and paste them from Route 53 to your domain registrar. Also note that if you’re using a subdomain, the instructions might be a little different. You can read how to do this in the Route 53 documentation.

The nameservers could take minutes or hours to update, depending on how lucky you are. If you’re impatient and want to check, open up a terminal and run this command. If you see the AWS nameservers in the output, then your domain has propagated and is now usable by Route 53.

dig -t ns <example.com>

Configuring EC2 with SSH key pair 🔗

This guide assumes you already have an SSH key pair created on your system. If you don’t have one generated, you can read how to generate one here.

The next step for us is to add an SSH key pair to EC2, one of the compute engine products offered by AWS. We’ll import an existing key on your system into EC2.

1. From AWS, go to Services > Compute > EC2.
2. Confirm that you are in the correct EC2 region by checking the location next to your name in the menu bar.
3. Under Network & Security, click Key Pairs.
4. Click Import Key Pair.
5. Either upload your public key file (~/.ssh/id_rsa.pub) or paste it into the text field. Don’t forget to give it a name.

And that’s all you need to do!

Assigning AWS user privileges 🔗

Tectonic does the magic of setting up AWS for you, so you don’t have to manually add and create the services from the web interface. In order to do this, you need to add a user account that Tectonic can use to do all of the provisioning it needs. To do this, you’ll need to create a new Access ID and Secret key pair from AWS.

1. Select Services > Security, Identity & Compliance > IAM.
2. From the left hand pane, click Users, then click Add user.
3. Set the user details:
   1. User name can be anything you like (I used tectonic-mydomain.com)
   2. Access type only needs to be Programmatic access
4. For permissions, click Add user to group and create a new group for your user.
5. When creating a new group, attach only the policies needed by Tectonic to operate correctly:
   1. AmazonEC2FullAccess
   2. IAMFullAccess
   3. AmazonS3FullAccess
   4. AmazonVPCFullAccess
   5. AmazonRoute53FullAccess
6. Finish creating the user. You’ll then see the Access key ID and Secret access key. Hold onto these, you’ll need them later. You won’t get to see the secret key again!

Now we’re ready to install Tectonic! Let’s grab your credentials next.

Download Tectonic credentials 🔗

Jump back over to the CoreOS accounts page. When you’re logged in, you’ll see the Account Assets area. Download the CoreOS license file and pull secret. Later on in the installer, you’ll need to insert these to finish the installation.

Running the installer 🔗

Now things get interesting! We finally get to install and deploy Tectonic into AWS. The installer takes the form of a graphical installer in your web browser. To use the installer, you need to download the binary and run it. If you’re curious, you can find the installer source code on GitHub.

Download and run installer 🔗

First, open up a new terminal window and navigate to a directory you want to download the installer to. Even though you likely won’t need to run the installer again, you will want to hang on to this if you ever want to easily dismantle everything in AWS later.

curl -O https://releases.tectonic.com/tectonic-1.6.4-tectonic.1.tar.gz

Next, extract the tarball and navigate into the directory.

tar -xzvf tectonic-1.6.4-tectonic.1.tar.gz
cd tectonic/tectonic-installer

Now execute the installer binary. After running this, a new browser window will open that features the graphical installer.

./linux/installer

Running the installer 🔗

The installer is thorough and assumes safe defaults for most of the steps. Be sure to have your AWS Access and Secret ID keys on hand. You should be able to run through the installer without issue. If you’re confused about what any of the values mean or want to make custom changes, you can read more in the upstream documentation.

Once you’re finished, congrats! You’ve successfully installed Tectonic!

Check out your Tectonic install 🔗

Once you finish the installation successfully, your Tectonic installation will be accessible within AWS. You can navigate to the domain you specified during the install to find it. Unless you added a CA authority and certificates, your browser will probably complain about invalid SSL certificates, but you can ignore the warning safely. It might also take a few minutes before the URL is accessible, so if you were looking for a coffee or tea break, now would be a good time!

Once you’re logged in, you should see something like this.

Blow it all away! 🔗

If you’re like me, you might be frustrated by guides that tell you how to install things but not how to take it all apart. Fortunately, this guide not only tells you how to do that, but the Tectonic installer also makes it super easy to do. If you’re sure that you’re done with Tectonic and don’t want any leftovers to remain in AWS, this is the best way to do it, instead of deleting everything manually from the AWS Console.

Every installation has a time-stamped folder in the tectonic directory we used earlier. First, you need to navigate into the specific folder for the cluster you installed. It’s important to be inside of this directory first.

cd tectonic/tectonic-installer/linux/clusters/<CLUSTERNAME>

<CLUSTERNAME> will be the time-stamped directory. Once you’re in the folder, run this command to trigger the uninstaller. After running this, you’ll see the installer slowly dismantle everything and delete any leftovers in AWS.

../../terraform destroy

Once it finishes, you should see an output message confirming how many AWS resources were destroyed. And now you’re back to where you started.

Learn more about Tectonic 🔗

If you thought this was exciting and want to learn more, there is no shortage of resources for you to read. You can learn more about Tectonic from the CoreOS website or the original release announcement. You can also dig into the installer’s source code on GitHub. If you’re still trying to wrap your head around Tectonic, there’s a good write-up on virtualizationreview.com.

Next week, we’ll install a simple guestbook application to our Tectonic installation to see how it all works and what you can do with it. Stay tuned!

Questions, Tectonic stories, or tips for beginners? Add your comments below.

The team consists of four people: Elio Qoshi, Redon Skikuli, Giannis Konstantinidis, and Anxhelo Lushka. Ura Design started from an idea. The team believed that many open source projects are full of capabilities and features, but their design can make it difficult for users to effectively use the software. This could be through user experience, branding, or accessibility. And the goal? To help bring these better design principles to open source projects at little to no cost. “In open source, there are amazing projects that are poorly communicated with the outside world. By communication, we mean visual communications, branding, even marketing. That is nonexistent for many reasons. There is a connection between communicating your project well and also getting contributors or users on board,” says Skikuli.

The Ura Design team helps open source projects improve their design so they can focus on great code.

How it works 🔗

Together, the four of them work with open source project owners to help them bring better design elements to their projects. The principles of ethical design are part of the goals and values of the project.

Some of their past projects include Mozilla, the Tor Project, Free Software Foundation Europe, Glucosio, and more. The team takes contract work with companies or communities with a budget, but for projects with less financial support, they’ll even do the work free. This is in part supported by their Patreon page, where anyone can subscribe or see updates from Ura Design.

Their Patreon page is part of the reason Ura Design is able to take on some projects at no cost. “Since there are working hours involved, we are asking for people to make small contributions to help us pay living costs, so we work for small projects who apply for free or minimal design support from us. This is our way of supporting some open source initiatives that we think are worth it,” says Skikuli. Right now, they have 22 backers to the project, which lets them cover most infrastructure costs. Some of the goals for the team now is to expand into photography to release work into the public domain.

Past projects 🔗

Ura Design has worked with many open source projects already. Some of their work covers projects at Mozilla, the Tor Project, Glucosio, GalliumOS, Open Labs Hackerspace, and more. You can see the full list of past works on their website.

Mozilla 🔗

For Mozilla, Qoshi had an existing relationship with Mozilla as a contributor. He was asked to help design and capture this connection inside of the localization community for Mozilla. The final design focused on two lions, one big and one small, looking at each other. “It was nice effort for contributors who have been mentoring others to get recognized for their contributions. Good design breaks off a conversation even for a project like this,” Qoshi said.

The Tor Project 🔗

Working with the Tor Project was a unique experience for Ura Design. The Tor Project was looking at rebranding the entire project. The end goal was to try to improve the accessibility of the project by incorporating good design elements.

Together with the Tor Project leadership, Ura Design helped lead the rebranding of the project. This included graphical assets, logos, and corporate identity. Today, you can see the new branding featured across Tor’s web presence online. There are still plans to continue to roll these changes out over the coming year.

Logobridge 🔗

The newest project from the team is Logobridge. From unused work or small samples, Ura Design releases several new logos into the public domain each month. People are encouraged to use them in their projects, for icons, for placeholders, or anything they want. There’s no restrictions on how the logos can be used. Anyone can download the source SVG files to use in vector imaging software, like Adobe Illustrator or Inkscape.

Most of the logos designed through Logobridge are supported by monthly subscribers to Ura Design. It was from this that they decided to start Logobridge. You can see all of the logos they have on their website.

Got projects? 🔗

Ura Design is still relatively new, but they hope to continue impacting open source projects through their work. To learn more about Ura Design, you can visit their website or read their blog. Additionally, you can follow them on Facebook or Twitter for other news and updates from the team. If you want to support their work, you can visit their Patreon page. And if you’re an open source project? The Ura Design team encourages you to get in touch!

This is a short series to introduce Kubernetes, what it does, and how to experiment with it on Fedora. This is a beginner-oriented series to help introduce some higher level concepts and give examples of using it on Fedora. In the first post, we covered key concepts in Kubernetes. This second post shows you how to build a single-node Kubernetes deployment on your own computer.

Once you have a better understanding of what the key concepts and terminology in Kubernetes are, getting started is easier. Like many programming tutorials, this tutorial shows you how to build a “Hello World” application and deploy it locally on your computer using Kubernetes. This is a simple tutorial because there aren’t multiple nodes to work with. Instead, the only device we’re using is a single node (a.k.a. your computer). By the end, you’ll see how to deploy a Node.js application into a Kubernetes pod and manage it with a deployment on Fedora.

This tutorial isn’t made from scratch. You can find the original tutorial in the official Kubernetes documentation. This article adds some changes that will let you do the same thing on your own Fedora computer.

Introducing Minikube 🔗

Minikube is an official tool developed by the Kubernetes team to help make testing it out easier. It lets you run a single-node Kubernetes cluster through a virtual machine on your own hardware. Beyond using it to play around with or experiment for the first time, it’s also useful as a testing tool if you’re working with Kubernetes daily. It does support many of the features you’d want in a production Kubernetes environment, like DNS, NodePorts, and container run-times.

Installation 🔗

This tutorial requires virtual machine and container software. There are many options you can use. Minikube supports virtualbox, vmwarefusion, kvm, and xhyve drivers for virtualization. However, this guide will use KVM since it’s already packaged and available in Fedora. We’ll also use Node.js for building the application and Docker for putting it in a container.

Pre-requirements 🔗

You can install the prerequisites with this command.

$ sudo dnf install kubernetes libvirt-daemon-kvm kvm nodejs docker

After installing these packages, you’ll need to add your user to the right group to let you use KVM. The following commands will add your user to the group and then update your current session for the group change to take effect.

$ sudo usermod -a -G libvirt $(whoami)
$ newgrp libvirt

Docker KVM drivers 🔗

If using KVM, you will also need to install the KVM drivers to work with Docker. You need to add Docker Machine and the Docker Machine KVM Driver to your local path. You can check their pages on GitHub for the latest versions, or you can run the following commands for specific versions. These were tested on a Fedora 25 installation.

Docker Machine 🔗

$ curl -L https://github.com/docker/machine/releases/download/v0.12.0/docker-machine-`uname -s`-`uname -m` >/tmp/docker-machine
$ chmod +x /tmp/docker-machine
$ sudo cp /tmp/docker-machine /usr/local/bin/docker-machine

Docker Machine KVM Driver 🔗

This installs the CentOS 7 driver, but it also works with Fedora.

$ curl -L https://github.com/dhiltgen/docker-machine-kvm/releases/download/v0.10.0/docker-machine-driver-kvm-centos7 >/tmp/docker-machine-driver-kvm
$ chmod +x /tmp/docker-machine-driver-kvm
$ sudo cp /tmp/docker-machine-driver-kvm /usr/local/bin/docker-machine-driver-kvm

Installing Minikube 🔗

The final step for installation is getting Minikube itself. Currently, there is no package in Fedora available, and official documentation recommends grabbing the binary and moving it your local path. To download the binary, make it executable, and move it to your path, run the following.

$ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
$ chmod +x minikube
$ sudo mv minikube /usr/local/bin/

Now you’re ready to build your cluster.

Create the Minikube cluster 🔗

Now that you have everything installed and in the right place, you can create your Minikube cluster and get started. To start Minikube, run this command.

$ minikube start --vm-driver=kvm

Next, you’ll need to set the context. Context is how kubectl (the command-line interface for Kubernetes) knows what it’s dealing with. To set the context for Minikube, run this command.

$ kubectl config use-context minikube

As a check, make sure that kubectl can communicate with your cluster by running this command.

$ kubectl cluster-info
Kubernetes master is running at https://192.168.99.100:8443
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

Build your application 🔗

Now that Kubernetes is ready, we need to have an application to deploy in it. This article uses the same Node.js application as the official tutorial in the Kubernetes documentation. Create a folder called hellonode and create a new file called server.js with your favorite text editor.

var http = require('http');

var handleRequest = function(request, response) {
 console.log('Received request for URL: ' + request.url);
 response.writeHead(200);
 response.end('Hello world!');
};
var www = http.createServer(handleRequest);
www.listen(8080);

Now try running your application and running it.

$ node server.js

While it’s running, you should be able to access it on localhost:8080. Once you verify it’s working, hit Ctrl+C to kill the process.

Create Docker container 🔗

Now you have an application to deploy! The next step is to get it packaged into a Docker container (that you’ll pass to Kubernetes later). You’ll need to create a Dockerfile in the same folder as your server.js file. This guide uses an existing Node.js Docker image. It exposes your application on port 8080, copies server.js to the image, and runs it as a server. Your Dockerfile should look like this.

FROM node:6.9.2
EXPOSE 8080
COPY server.js .
CMD node server.js

If you’re familiar with Docker, you’re likely used to pushing your image to a registry. In this case, since we’re deploying it to Minikube, you can build it using the same Docker host as the Minikube virtual machine. For this to happen, you’ll need to use the Minikube Docker daemon.

$ eval $(minikube docker-env)

Now you can build your Docker image with the Minikube Docker daemon.

$ docker build -t hello-node:v1 .

Huzzah! Now you have an image Minikube can run.

Create Minikube deployment 🔗

If you remember from the first part of this series, deployments watch your application’s health and reschedule it if it dies. Deployments are the supported way of creating and scaling pods. kubectl run creates a deployment to manage a pod. We’ll create one that uses the hello-node Docker image we just built.

$ kubectl run hello-node --image=hello-node:v1 --port=8080

Next, check that the deployment was created successfully.

$ kubectl get deployments
NAME         DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
hello-node   1         1         1            1           30s

Creating the deployment also creates the pod where the application is running. You can view the pod with this command.

$ kubectl get pods
NAME                          READY     STATUS    RESTARTS   AGE
hello-node-1644695913-k2314   1/1       Running   0          3

Finally, let’s look at what the configuration looks like. If you’re familiar with Ansible, the configuration files for Kubernetes also use easy-to-read YAML. You can see the full configuration with this command.

$ kubectl config view

kubectl does many things. To read more about what you can do with it, you can read the documentation.

Create service 🔗

Right now, the pod is only accessible inside of the Kubernetes pod with its internal IP address. To see it in a web browser, you’ll need to expose it as a service. To expose it as a service, run this command.

$ kubectl expose deployment hello-node --type=LoadBalancer

The type was specified as a LoadBalancer because Kubernetes will expose the IP outside of the cluster. If you were running a load balancer in a cloud environment, this how you’d provision an external IP address. However, in this case, it exposes your application as a service in Minikube. And now, finally, you get to see your application. Running this command will open a new browser window with your application.

$ minikube service hello-node

Congratulations, you deployed your first containerized application via Kubernetes! But now, what if you need to our small Hello World application?

How do we push changes? 🔗

The time has come when you’re ready to make an update and push it. Edit your server.js file and change “Hello world!” to “Hello again, world!”

response.end('Hello again, world!');

And we’ll build another Docker image. Note the version bump.

$ docker build -t hello-node:v2 .

Next, you need to give Kubernetes the new image to deploy.

$ kubectl set image deployment/hello-node hello-node=hello-node:v2

And now, your update is pushed! Like before, run this command to have it open in a new browser window.

$ minikube service hello-node

If your application doesn’t come up any different, double-check that you updated the right image. You can troubleshoot by getting a shell into your pod by running the following command. You can get the pod name from the command run earlier (kubectl get pods). Once you’re in the shell, check if the server.js file shows your changes.

$ kubectl exec -it <pod-name> bash

Cleaning up 🔗

Now that we’re done, we can clean up the environment. To clear up the resources in your cluster, run these two commands.

$ kubectl delete service hello-node
$ kubectl delete deployment hello-node

If you’re done playing with Minikube, you can also stop it.

$ minikube stop

If you’re done using Minikube for a while, you can unset Minikube Docker daemon that we set earlier in this guide.

$ eval $(minikube docker-env -u)

Learn more about Kubernetes 🔗

You can find the original tutorial in the Kubernetes documentation. If you want to read more, there’s plenty of great information online. The documentation provided by Kubernetes is thorough and comprehensive.

Questions, Minikube stories, or tips for beginners? Add your comments below.

This article is part of a short series that introduces Kubernetes. This beginner-oriented series covers some higher level concepts and gives examples of using Kubernetes on Fedora.

The information technology world changes daily, and the demands of building scalable infrastructure become more important. Containers aren’t anything new these days, and have various uses and implementations. But what about building scalable, containerized applications? By itself, Docker and other tools don’t quite cut it, as far as building the infrastructure to support containers. How do you deploy, scale, and manage containerized applications in your infrastructure? This is where tools such as Kubernetes comes in. Kubernetes is an open source system that automates deployment, scaling, and management of containerized applications. Kubernetes was originally developed by Google before being donated to the Cloud Native Computing Foundation, a project of the Linux Foundation. This article gives a quick precursor to what Kubernetes is and what some of the buzzwords really mean.

What is Kubernetes? 🔗

Kubernetes simplifies and automates the process of deploying containerized applications at scale. Just like Ansible orchestrates software, Kubernetes orchestrates deploying infrastructure that supports the software. There are various “layers of the cake” that make Kubernetes a strong solution for building resilient infrastructure. It also assists with making systems that can grow at scale. If your application has increasing demands such as higher traffic, Kubernetes helps grow your environment to support increasing demands. This is one reason why Kubernetes is helpful for building long-term solutions for complex problems (even if it’s not complex… yet).

At a high level overview, imagine three different layers.

• Users: People who deploy or create containerized applications to run in your infrastructure
• Master(s): Manages and schedules your software across various other machines, for example in a clustered computing environment
• Nodes: Various machines to support the application, called kubelets

These three layers are orchestrated and automated by Kubernetes. One of the key pieces of the master (not included in the visual) is etcd. etcd is a lightweight and distributed key/value store that holds configuration data. Each node, or kubelet, can access this data in etcd through a HTTP/JSON API interface. The components of communication between master and node such as etcd are explained in the official documentation.

Another important detail not shown in the diagram is that you might have many masters. In a high-availability (HA) set-up, you can keep your infrastructure resilient by having multiple masters in case one happens to go down.

Terminology 🔗

It’s important to understand the concepts of Kubernetes before you start to play around with it. There are many core concepts in Kubernetes, such as services, volumes, secrets, daemon sets, and jobs. However, this article explains four that are helpful for the next exercise of building a mini Kubernetes cluster. The three concepts are pods, labels, replica sets, and deployments.

Pods 🔗

If you imagine Kubernetes as a Lego® castle, pods are the smallest block you can pick out. By themselves, they are the smallest unit you can deploy. The containers of an application fit into a pod. The pod can be one container, but it can also be as many as needed. Containers in a pod are unique since they share the Linux namespace and aren’t isolated from each other. In a world before containers, this would be similar to running an application on the same host machine.

When the pods share the same namespace, all the containers in a pod:

• Share an IP address
• Share port space
• Find each other over localhost
• Communicate over IPC namespace
• Have access to shared volumes

But what’s the point of having pods? The main purpose of pods is to have groups of “helping” containers on the same namespace (co-located) and integrated together (co-managed) along with the main application container. Some examples might be logging or monitoring tools that check the health of your application, or backup tools that act when certain data changes.

In the big picture, containers in a single pod are always scheduled together too. However, Kubernetes doesn’t automatically reschedule them to a new node if the node dies (more on this later).

Labels 🔗

Labels are a simple but important concept in Kubernetes. Labels are key/value pairs attached to objects in Kubernetes, like pods. They let you specify unique attributes of objects that actually mean something to humans. You can attach them when you create an object, and modify or add them later. Labels help you organize and select different sets of objects to interact with when performing actions inside of Kubernetes. For example, you can identify:

• Software releases: Alpha, beta, stable
• Environments: Development, production
• Tiers: Front-end, back-end

Labels are as flexible as you need them to be, and this list isn’t comprehensive. Be creative when thinking of how to apply them.

Replica sets 🔗

Replica sets are where some of the magic begins to happen with automatic scheduling or rescheduling. Replica sets ensure that a number of pod instances (called replicas) are running at any moment. If your web application needs to constantly have four pods in the front-end and two in the back-end, the replica sets are your insurance that number is always maintained. This also makes Kubernetes great for scaling. If you need to scale up or down, change the number of replicas.

When reading about replica sets, you might also see replication controllers. They are somewhat interchangeable, but replication controllers are older, semi-deprecated, and less powerful than replica sets. The main difference is that sets work with more advanced set-based selectors – which goes back to labels. Ideally, you won’t have to worry about this much today.

Even though replica sets are where the scheduling magic happens to help make your infrastructure resilient, you won’t actually interact with them much. Replica sets are managed by deployments, so it’s unusual to directly create or manipulate replica sets. And guess what’s next?

Deployments 🔗

Deployments are another important concept inside of Kubernetes. Deployments are a declarative way to deploy and manage software. If you’re familiar with Ansible, you can compare deployments to the playbooks of Ansible. If you’re building your infrastructure out, you want to make sure it is easily reproducible without much manual work. Deployments are the way to do this.

Deployments offer functionality such as revision history, so it’s always easy to rollback changes if something doesn’t work out. They also manage any updates you push out to your application, and if something isn’t working, it will stop rolling out your update and revert back to the last working state. Deployments follow the mathematical property of idempotence, which means you define your specs once and use them many times to get the same result.

Deployments also get into imperative and declarative ways to build infrastructure, but this explanation is a quick, fly-by overview. You can read more detailed information in the official documentation.

Installing on Fedora 🔗

If you want to start playing with Kubernetes, install it and some useful tools from the Fedora repositories.

sudo dnf install kubernetes

This command provides the bare minimum needed to get started. You can also install other cool tools like cockpit-kubernetes (integration with Cockpit) and kubernetes-ansible (provisioning Kubernetes with Ansible playbooks and roles).

Learn more about Kubernetes 🔗

If you want to read more about Kubernetes or want to explore the concepts more, there’s plenty of great information online. The documentation provided by Kubernetes is fantastic, but there are also other helpful guides from DigitalOcean and Giant Swarm. The next article in the series will explore building a mini Kubernetes cluster on your own computer to see how it really works.

Questions, Kubernetes stories, or tips for beginners? Add your comments below.

If you’re outside of the Mediterranean region, the Open Labs Hackerspace might be one of the hidden secrets of the region that you never knew existed. Free software and open principles build the community’s foundation. In their hackerspace, they support various open source projects with time, energy, and activism. Members work on various open source projects, ranging from Fedora, Mozilla, Nextcloud, Wikipedia, OpenStreetMap, and more. But the open source way goes beyond the software. The hierarchy of this Albanian non-profit organization is flat and open too. The hackerspace places a strong emphasis on empowering others to have a voice and to take part in the governance. No question is ever dumb, and anyone who wants to learn is able to find someone who will help guide them in the right direction. The combined effect of open software and open culture has helped Open Labs grow over the past five years.

Why Open Labs? 🔗

There are many hackerspaces in the world, but why does Open Labs mean so much to me? They love free and open source software and believe in the open source way… sure. That’s definitely part of it. But beyond the mission, beyond the activities, Open Labs fosters an inclusive and empowering culture. This culture has the effective of motivating others to understand that their voice matters and that they can have an impact on something far bigger than themselves. The hackerspace helps give young people in Tirana a platform to stand up and share their ideas. But beyond that, it provides them with the resources and community to help turn the ideas into reality.

So, what is the secret? Simply… the people.

Everything that the community here does, they take their unique passion and energy into those tasks. They invest their own personal resources into building solutions to answer complicated problems, inside and outside of Albania. Some of their work is best demonstrated in events that happened earlier this year. In March, Open Labs helped coordinate the first-ever 48 hour hackathon for United Nations Sustainable Development Goals. Later in March, they organized Linux Weekend, an introductory event to help introduce Linux to students. This was done by demonstrating what can be done with Linux and open source and then connecting students to professionals from Tirana and abroad. The organic energy that came from these events is almost immeasurable. Even an event report is hard to convey how inspiring that energy was.

This past weekend, from May 13-14, 2017, the community organized the fourth edition of the annual Open Source Conference Albania (OSCAL) in Tirana. This is the largest open source event in Albania and one of the most notable in southeast Europe. No event report for this yet, but you can expect one soon.

Why part of my heart is at Open Labs 🔗

Whenever I visit Albania and visit Open Labs, I learn something new. There’s many different types of things I learn. Sometimes it’s something about an open source project or community. Other times, I learn about events and opportunities happening in the local Tirana area for open source. And then other times, I gain unique insight towards some of the unique challenges and problems that citizens face here. Every time I visit, my perspective is always broadened in a way that I wouldn’t be able to normally find. It’s exhilarating.

I am privileged and honored to be an official member of this community. However, I am mostly an observer in my role. The passion and interest are at the heart of the hackerspace. The members from Tirana have invested so much of themselves into this community, its mission, and its values. From reading, visiting, and talking with the people involved with Open Labs, you see many of their hearts dedicated to what they’re doing. And when you see someone else who invests their heart into something, it’s challenging to not lend some of your own too.

And in today’s world, where the hearts of many people close with borders and the world shifts towards coldness, the warmth that radiates from Open Labs is refreshing, inspiring, and powerful.

Discover Open Labs 🔗

You can learn more about the Open Labs Hackerspace on their website. Additionally, you can also follow them along on Facebook and Twitter to see what they’re up to. You can also see their Discourse forums to say hello and take part in any discussion too.

Many times, I’ve sat down to write this. The same number of times, I never finish and delete it all. Many times, I’ve wondered how to say the things I want to say. I’ve been doing this for years. However, the motivation this time is different.

Two important events made me realize that writing this is important. A conversation with one of my friends about what was happening in my life reminded me of the critical, psychological benefit of communicating and being honest and open about myself. The second thing was an insight from an article I saw on Twitter, about Sheryl Sandberg and dealing with grief. The profound insight in the article to me was the intersection between effective leadership and expressing emotion. “Expressing emotion when you’ve gone through extreme pain is not weakness. It is humanity.”

This post isn’t like anything I’ve written before, but it is a necessary next step for me to move forward.

I live with depression.

It’s a battle that has various turns and twists, and different highs and lows. There are days, weeks, even months where I don’t feel its weight. But there are also long periods of time where it envelops me and becomes my world.

There are some insights I’ve learned over time, though. In the spirit of being more open and true to myself, I want to share some of my experiences and also some advice from those experiences.

In my own world 🔗

Others who have experiences of their own can recount similar details to the looming feelings that overtake them. Sometimes it comes at the most unexpected moments, even if everything around you is going right. Yet, there it is.

The looming feeling deep in your stomach.

The heavy weight that presses down on your consciousness.

Sleeping early and waking up late, or not sleeping at all.

The sucking of your productive energy towards meaningless tasks, like spending more of your time reading about the lives of other people instead of living your own. The feelings have a wide range. Regardless of the specifics, anyone who has walked this quiet path can take these general points and recount them into their own story.

The most difficult part is the creeping feeling when the depression begins to take hold, but it feels like there’s nothing that can stop it.

Now that I’ve had more years to reflect on my depression, I’m better able to pick out some of its origins and characteristics. Even knowing these things, there isn’t one form of depression or one way it looks like. What form it takes on depends on contextual evidence and what’s happening around me.

Depression is… 🔗

Sometimes, depression wears the mask of incompetence. It’s not uncommon for me to set too high of a bar for myself to reach. When I don’t meet those expectations or if I fall behind, my self-esteem slowly erodes. One missed assignment or deadline turns into two, then four. What was a small problem is exacerbated into a chain reaction of many problems. This builds the feeling of incompetence. Navigating the web of problems after it is spun becomes difficult and drains all energy. Personal motivation decreases leaving me wondering why I bother at all.

Sometimes, depression causes you to cast poor comparisons. It’s looking at the highlight reel of other peoples’ lives while you’re going through the cut-out reel. I wrap myself up in the achievements and successes of others. It’s an echo chamber of negative thought, where the lives of friends, family, or acquaintances remind me of my self-perceived incompetence. Everyone seems smarter and brighter. It looks like everyone else has it together when I’m struggling to meet deadlines and remembering to eat. Social media aggravates this. The entire premise of social media is to share the “highlight reel”, to show off when everything in your life is going right—which is why social media is the worst thing to look at when you’re in the trenches.

John Green shared a video recently about how we frame our lives that describes this well.

In which John discusses the ways we frame reality, the distance between the selves we put online and the selves we inhabit, and the challenge of understanding public lives as self-portraiture rather than reality.

There are other forms that it takes too. But underneath its form, the emotions are usually the same (at varying intensities). It’s a spectrum of feelings and activities, ranging from loss of interest, difficulty finding motivation, worthlessness, unusual sleep patterns, nail-biting, and at its worst, wanting a permanent way to escape. This goes without saying, over the years, I have become more adept at pushing out the harsher thoughts by recognizing them and reaching out to a close friend when I feel that way. But the spectrum varies depending on the surrounding events.

Invisible 🔗

My biggest challenge was how I kept it all hidden. Only a handful of people knew about some of my difficulties and what was going on behind the scenes. There were two critical fears that always prevented me from stepping out of the dark.

If I were to be honest about what I was going through, I didn’t want to be treated differently by others, personally or professionally. I’ve always felt that if I presented an idea or had a conversation with someone, agreements or disagreements were because of the ideas being conveyed, not because someone cast judgment on what they think I can handle. This was and is valuable to me.

But why was this a fear of mine? We have a problem of “talking about it”. The stigma is that it’s wrong to “feel bad”. It’s not comfortable to talk about. It’s difficult for others to sometimes relate. The tone that people speak to you changes. This stigma created the fear that every conversation would become heavy-handed with special treatment. What I realized is that this fear isn’t justification to keep the lights off.

By becoming transparent about it, my hope is that this won’t be the case. I don’t want to be treated differently than how anyone has already treated me. If you’re wondering about how you can help, this is one of the best ways: to treat me the same way. (Although more hugs are never something I complain about!)

However, there was one more fear that kept me in the dark.

To become more comfortable with sharing these emotions, it means being honest when someone asks how you are and reaching out for help when you need it. But it can be a lot to ask someone to help untangle the thick cobwebs when you’re having a hard time seeing through. From being on the receiving end before, I knew how it can be draining (even if it’s worthwhile and makes a difference in the end). My fear was putting too much burden on others and draining their energy on problems that don’t concern them. Everyone has their own stress and problems too. As a result, I rarely shared my pain and difficulty with others to avoid placing more stress on others.

When you’re afraid of adding more stress onto others, it impacts the type of actions you make. It might look typing out a long message when someone asks if everything is okay, then deleting it to say, “Everything is fine!” Other times, it’s the confusion over how to answer a simple question like, “How are you?” Sometimes it’s simply feeling alone.

But even though this is a fear, there is also a balance and a way to prevent adding so much stress to a close one’s life. Real relationships don’t flow like a river, in a single direction. It’s like a two-way road where traffic passes in both directions. It’s unsustainable for one person to only lean on one person. It goes both ways and the communication has to be two-way to be successful. However, letting everything out at once after it’s built up for so long isn’t the answer either. This is that overloading stress that creates this fear of sharing in the first place. Communication needs to be early and often. You have to share and you have to be honest.

I realized these fears shouldn’t keep me from sharing my story. The benefits of being open and sincere outweigh the perceived negatives from these fears. It takes a lot to throw yourself out in the open, but once it’s out, some of the extra weight falls off.

Opening the blinds, turning on the lights 🔗

But my purpose with this post wasn’t to only reflect on my personal experiences either. I hate raising problems without offering means to solving them. There are plenty of ways to learn about how to deal with depression. You can talk to a therapist and seek medicine too. But I wanted to share some of the things that have helped me get out of the hole and fight back.

However, none of this advice should be taken over professional medical advice. I am not a doctor and I won’t act like one. If you are experiencing severe depression, please take the first step and talk to a doctor.

Seriously… talk about it 🔗

Maybe this seems like common sense. Maybe you are afraid of what others might think of you if you tell them “the truth”. What talking about it looks like is up to you. Whether it’s a trusted friend, a family member, or a trusted individual, psychotherapy (or talk therapy) has significant benefits for helping you put your best foot forward. Whether it’s formal or informal, professional or friend-to-friend, getting it out there helps. It lets you have a chance to decompress from the build-up of stress. It also gives someone else a chance to remind you of the positive counterpoints to the negative thoughts.

Sometimes the best responses I’ve received is just an affirmation of love. Telling someone that you value them and that you love and care for them goes a long way.

Find your detox 🔗

Your “detox” activity depends on you. Everyone has a different form of what helps remove them from the negative emotion and feelings. The purpose of detoxing is to give yourself a chance to separate from what’s providing the stress and to step away, even if for a short while. Usually, one of the best first steps is unplugging from the laptop, the phone, or other digital ties. Some time off from the grind will help you to refocus and bring your mind to a better place.

For example, some of my detox activities are listening to the right music and taking a walk. My music might be my best therapy. Sometimes it’s having a conversation with a close friend about something completely random. Other times, it’s writing a few lines into a notebook. What the activity is depends on you. But it’s important to find those positive, uplifting experiences and remember them when your vision becomes cloudy.

Look up, even if it feels wrong 🔗

One of the things that I’ve started to practice is persuading my mind how to think. Even when everything looks or feels completely awful, I make myself look up. I tell myself that I’m feeling good, and I make myself genuinely believe it. I put my entire faith into that positive energy, of what I know things should be. It’s a challenge. It’s not easy. I can’t always do it. But it’s an art of persuasion. And with any art, it takes practice.

The challenge is to sincerely look for the positivity and happy emotions that are around you. You have to tune yourself to the same emotional frequency as the positive energy. Like a radio signal, you have to turn your channel to receive that positive energy and emotion. And if you’re ready to receive, it will present itself.

In the more difficult times, this is the hardest advice to follow. The negative thoughts creep back into your mind. But recognition is key. To see and identify those thoughts and consciously acknowledge them for what they are is the first step. After identifying the negative energy, you have to turn your own channel. Instead of thinking, “I don’t want to feel that way,” think of the way you do want to feel. Think of the positive energy, emotions, experiences, or memories. Tell yourself, “I want to feel this way,” or “I want to feel good.” Even if it seems trivial and impossible, invest your energy and focus into attracting that positive energy. If you convince yourself that it’s there and you are going to find it, circumstances change. They have a strange way of working themselves out. But you have to know what you want.

Even when it feels like you’re in an emotional headlock straight to the ground, twist a little more to look up. At the sun, the light. The positive emotions and energy in life. And keep looking up.

Remember what’s good 🔗

Depression isn’t a one-time illness. You don’t have a revelation one magical day and are suddenly “cured” of depression. It’s a cycle, with ups and downs. It requires balance and powerful support systems to stave off its hardest moments. The first step is recognizing the tug-of-war and identifying when things start to feel wrong. Make the steps to pull back from the things that bring the negative thoughts and energy. Remember what you do want and how you want to feel. Remember what’s good.

It took me a long time to write this. For six or seven years, I’ve tried to find the right words. But what I realized is that if I wait for the right words, I’ll wait forever. Even with the advice I gave, I’m not perfect and I’m not always able to fight it every time. This is something I actively live with. I have good days and I have bad days. The bad days are what brought me to write this in the first place. But the sun always comes up, one way or another. That’s what I always have to remind myself.

There are many stories out there. But this one is mine. Thank you.

The Fedora Diversity FAD (a.k.a. Fedora Activity Day, or a sprint) took place during the weekend of DevConf, 27-29 January. The original planning for this FAD started in August 2016, after the Flock 2016 conference. At Flock, the Diversity Team held a panel with open discussion about diversity and inclusion efforts in Fedora. Based on the feedback received during and after the panel, it was a priority for us to continue working on the objectives we had established before Flock. For the FAD, a majority of the Fedora Diversity Team was present along with a few others.

• Amita Sharma (amsharma)
• Bhagyashree “Bee” Padalkar (bee2502)
• Brian Exelbierd (bex)
• Jona Azizaj (jonatoni)
• Justin Wheeler (jflory7)
• Maria “tatica” Leandro (tatica)
• Marina Zhurakhinskaya (marinaz)
• Radka Janek (rhea)

We made significant progress in accomplishing our larger objectives and to contribute to the Fedora Project mission and goals. The primary objectives we established for our FAD were completing plans for the demographic survey, building a campaign based on those results, and analyzing our Code of Conduct to find ways to better impact the community. This report covers each of these objectives, what we accomplished, and what we plan to do next.

Demographic survey / marketing campaign 🔗

The majority of our discussions and planning on Friday and Saturday were focused on establishing strategic goals for the demographic survey and crafting the questions. The wish for having a survey like this predates the Diversity Team back to some of the earliest tickets in the Fedora Council ticket tracker (see #1 and #16). The need for a demographic survey was established by the Diversity Team as well shortly after Flock. At Flock, there was expressed concern about little understanding for the diversity of our community. Fedora is a global community spanning all four corners of the world. It’s hard to understand the unique needs and wishes of our community if we don’t know they are there or what they think we could do better. The survey is the means to this end and how we best understand how our community is composed to make Fedora a more welcoming and inviting place for our global community of contributors.

The FAD enabled us to make significant progress on establishing the groundwork for the survey and move towards deploying a live version of the survey. One of the early outcomes of our discussion was postponing ideas about a marketing campaign until we had actual data and results to work with. This would make sure our efforts and focus on that would not be wasted. While the marketing campaign is a primary goal for our team, we decided it was best to double our efforts on the survey. As it turned out, this was a good decision with the amount of time we had, as the survey discussion and planning took the longest part of our time together.

Building the questions 🔗

Before the FAD, Maria, Bee, and Marina had compiled a list of questions starting in a mailing list thread. Many of the questions at the beginning were based on survey questions used in the FLOSS 2013 and Apache Software Foundation Committer Diversity surveys. We started our discussion about the objectives and problems we wanted to solve with this survey. We established these two points as our primary goals.

1. Gather baseline demographics about the contributor community
2. Determine contributor knowledge about project components that ease contribution

With these points in mind, we revisited the draft of questions prepared by Marina. We took an initial pass discussing the questions and weighing if this was something we needed to know and whether we saw a use for the answers based on our goals. The first pass took the longest amount of time, but it narrowed the questions significantly. After getting to a smaller number of questions with varied opinions, the questions were organized them into a spreadsheet where we weighted them by point values and narrowed it down to our final set. Our final draft of questions can be found in the Pagure ticket tracking this task. We are awaiting feedback from Fedora Legal before moving forward. Once we receive additional feedback, we plan to revisit the implementation questions about how and where to deploy the survey.

Noting the working process 🔗

One thing worth mentioning and explaining is how we narrowed the questions. We originally had a wide set of questions and were struggling with how to narrow them down. The methods we ended up using, suggested by Brian, were successful in us focusing on the purpose and goals we originally identified. The concern was on survey engagement and trying to guarantee survey completion. Too many questions or making it too long could result in people not finishing the survey. It is more valuable for us to have the most important data (even if it’s less) rather than have more questions but fewer responses.

In the beginning, we started with the set of questions curated by Maria, Bee, and Marina. It was over 50 questions with different motivations or objectives. Our first approach was going from top to bottom of all the questions. We discussed each one and tried to justify if it was worthwhile to include. Some questions were easy to remove, but others were more challenging. All of this initial discussion gave background to the questions in the later steps. This took up a significant amount of time and was possibly one of the more difficult parts of this process.

After the initial pass, Brian organized all of the questions into a spreadsheet and established a scale from 1 to 7. Of the remaining questions, we ranked them in this order:

• Category 1: Five questions
• Category 2: Five questions
• Category 3: Five questions
• Category 4: Five questions
• Category 5: Five questions
• Category 6: Five questions
• Category 7: Four questions

After all of the team members ranked the questions by order of preference, we tallied up the points for all of the questions. We ended up taking the top twenty-two questions, which can currently be found in the ticket. This method of going through the options we had forced us into making tough calls and choices on the things we felt were most important. It was powerfully effective for us to go through our options in this way, and it’s a method that could definitely be recycled for other purposes or even by other teams in Fedora.

Code of conduct 🔗

A code of conduct is a valuable part of an open source community. Its purpose is to set clear expectations about how the community interacts and behaves with each other. An effective code of conduct empowers contributors to be excellent to each other. This creates a welcoming and inclusive space.

Background 🔗

Before we all gathered in Brno, we planned to analyze the Fedora code of conduct to understand its strengths and weaknesses. We also wanted to focus on its visibility and ensure that it is well-communicated. This includes new contributors when they first join the community and also current contributors. We published a post about the Fedora Code of Conduct to help raise awareness, but planned to cover this more during our FAD.

A comprehensive code of conduct is important to set the tone for interactions among contributors. This helps promote a global perspective and create a welcoming community. The code of conduct drives the belief that contributors should always be excellent to each other. This builds the community as a united, global team. It was valuable for us to deliver on our proposed impact for the Fedora community through our discussions and planning.

Seeking positive engagement 🔗

After we arrived in Brno, we started to have discussions about this and what some our actions would be. The tone of our conversation switched from looking at it from a disciplinary point of view to an enabling point of view. A code of conduct isn’t the only part of how to empower contributors to be excellent. To this end, we asked ourselves these questions.

1. What kind of behaviors does the Fedora code of conduct encourage?
2. How are we able to reward positive interactions that show this behavior?

While we spent time looking at the code of conduct, the main focus was how to promote the behavior the code of conduct encourages. The biggest idea that came from this discussion was Fedora Appreciation Week. It is a subtle yet positive way for people to be excellent to each other by saying “thanks!” and raising awareness for the work that people put into Fedora.

Fedora Appreciation Week 🔗

This discussion mostly occurred on parts of Saturday and the Sunday of DevConf. This idea was originally suggested on the CommOps Pagure. It was not an original part of our pre-planning, but it became a pivotal point in the context of how to encourage the positive behavior the code of conduct suggests. One of the first changes to the original suggestion was making it into an entire week instead of a day, so we have the most flexibility for planning the event and giving ample time for contributors to participate.

Afterwards, we started to look at systems used in other places to use as case studies. We examined the Red Hat appreciation system and the Happiness Packets project. These examples helped to understand the benefit of co-workers or other community members encouraging each other. The Happiness Packets website puts it simply: “The feeling that you made a difference, that your work matters and has value, and that the people you work with are happy to work with you, is an awesome feeling.” Taking the time to understand the background and motivations behind these systems helped us determine the background and motivations for Fedora Appreciation Week. We divided our plans into short-term and long-term criteria.

Long-term 🔗

The long-term discussion mostly focused on how we could make it easier for people to thank each other with Fedora web services. We started our focus with the existing platform of Fedora Badges. One idea was giving all Fedora contributors the ability to award a special type of badge to other contributors a fixed number of times in a release cycle. Each special badge would fit into one of the Four Foundations of Fedora (Freedom, Friends, Features, First). Each one would have guided criteria to consider when awarding the badge to someone else. The effect of doing is to strengthen our commitment to our Four Foundations and to thank contributors who are committed to any of the four areas.

As one example, imagine someone working on a new feature or exciting change for an upcoming Fedora release. They have invested a lot of time and energy into developing this change. Another contributor who noticed this could give them a “Features” badge to thank them for their commitment to driving Fedora forward. Another example might be when one contributor sends thoughtful words to another, thanking them for their time or for everything they do. That person might give the first person a “Friends” badge for being kind and considerate to them.

We also discussed the idea of tying the accumulation of these badges into a physical reward, such as a special t-shirt or sticker sent via the mail. We ran out of time to discuss this idea further.

Short-term 🔗

We started by trying to establish the general timeline for planning Fedora Appreciation Week. Initially, we want start defining guidelines and creating promotional materials to use and spread leading up to the week. This would include things like giving examples of the different ways contributors can give thanks and also to work on articles or posts.

The month before the appreciation week would focus on general awareness. This would include a Community Blog article and a post to the Fedora announce list. The week before the first day would include a Fedora Magazine article explaining what’s happening and also to provide a way for users or people outside of the contributor community to participate.

Methods to give thanks included thanking in IRC (either thoughtful messages or with karma cookies), writing messages on a public wall or forum, and sending personal notes to individual contributors. Methods we could use to measure this impact included but was not limited to were karma cookies, mailing list traffic, or wiki page edits.

For the short-term focus, more discussion is needed to develop the ideas for running Fedora Appreciation Week in 2017.

Tying it together 🔗

The first-ever Diversity FAD was a great opportunity to spend significant amounts of time looking at how we can build more inclusive environments for Fedora contributors and how to tackle other issues like understanding who makes up the Fedora community. Our team was able to use this valuable time to work on these issues more personally and intently than IRC or mailing lists can provide.

Special thanks and our gratitude go to the Fedora Council for supporting our work with the Fedora Project budget and enabling us to be gather and work on these tasks. To all of us, this also showed that Fedora leadership is committed to supporting these initiatives and helping make diversity and inclusion an important part of the Fedora community. Additionally, we’d also like to thank Brian Exelbierd for participating in the FAD even though his attendance wasn’t originally planned—we were lucky to have him with us and to steal his time from other DevConf activities happening during the weekend!

We’re looking forward to next plan talks and/or workshops at Flock 2017 this year.

Come say hello! 🔗

The Fedora Diversity Team mostly consists of a few active, core members. But we are always looking for more people to get involved and participate! Every contribution is significant and it helps to have numerous people from different backgrounds following along with our discussions, so they can speak up and add their voice when they feel it’s important.

There are multiple ways you can get in touch with the Diversity Team. We have a mailing list you can subscribe to and you can follow our discussions. We have an IRC channel on freenode (#fedora-diversity). You . We meet once every other week on Wednesdays at 12:00 UTC in #fedora-meeting on free

• Mailing list: Subscribe to follow our discussions
• IRC channel: Say hello in #fedora-diversity on freenode (you can join with a web client if you don’t have an IRC client)
• Weekly meeting: Meet every other week on Wednesdays (12:00 UTC) in #fedora-meeting on freenode
• Pagure tickets: See some of the current tasks we’re working on and what needs doing

Come say hello and introduce yourself—we’d love to hear what you have to say!

Heterogeneous group icon by Magicon from the Noun Project

What exactly are Happiness Packets? 🔗

Fortunately, I don’t have to do a lot of work to explain this, because it’s all on the front page of the Happiness Packets website. Repeated below for your convenience:

People are generally much more loved than they think they are. Especially when things don’t go according to plan, other people almost never think as harshly of you as you might think of yourself. It’s easy for us to complain when bad things happen, and yet we’re often fairly silent when things are good. Open-source communities are no different, especially when our main communication channels are textual and virtual.

The feeling that you made a difference, that your work matters and has value, and that the people you work with are happy to work with you, is an awesome feeling. With Open-Source Happiness Packets, we’re trying to spread that feeling.

How does it work? 🔗

Openly expressing appreciation, gratitude, or happiness to other people can be difficult. This is especially true when you don’t know them very well. Many of us come from cultures in which people are not open by default about such feelings, and naturally feel uncomfortable or even creepy to share them.

Open-Source Happiness Packets is a very simple platform to anonymously reach out to the people that you appreciate or to whom you are thankful in your open-source community. Your message can be sent anonymously if you feel uncomfortable to share your name with the recipient. Of course, we encourage you to share your name, but it’s completely optional!

Take the challenge 🔗

So, what is the #HappinessPacketChallenge? I challenge you to do the following: write at least one Happiness Packet (or more!) every day for one week. At a minimum, this is only seven times where you say “thank you” to someone else in open source. Of course, you can send more if you want to.

If you open your social media feed or turn on the news channel, you probably see a lot of negativity. Whether it’s world events, politics, or other sad news, the negativity gets at you. For one week, this is your opportunity to have the opposite effect. For all of the good things and people you see, you can spend a few minutes of each day this week to make someone’s day. It seems simple—and it is! But the power you have to spread the positivity is a big power. So this is the challenge you have: to commit yourself to spreading that message every day for one week.

“I don’t know what to say.” 🔗

Having a hard time coming up with words or not sure who to thank? No problem. Your message can be as short or as long as you like. If you’re not sure who to thank, look at some of the software you’re using now. If you’re using a Linux distribution, start there! Look for the names and emails of maintainers of software you enjoy using. If you’re already contributing to open source, consider some of the people in your community! You can thank someone who had a special role in helping you get started or impacted why you decided to work on a project.

Maybe you have other ideas or reasons to thank others. Whatever the reason is, don’t make an excuse to say thanks! The options are limitless. If you have a lot to say, say it! If not, even a simple “thanks for all the work you do!” can go a long way to make someone’s day.

Share your happiness 🔗

The magical part of Happiness Packets is sharing happy moments with others. If you receive one, don’t be afraid to tell the world! You can tweet at @happinesspacket on Twitter. Use the #HappinessPacketChallenge hashtag. Encourage other people to send their own thanks. If you can get one other person to take the challenge, then you’re already making the days of seven more people! Imagine what would happen if all of those seven people decided to take the challenge too.

So, what are you waiting for? Get started! Go send a Happiness Packet now! And if you’re feeling bold, try challenging someone directly.

Love Letter by Vectors Market from the Noun Project

During the hiring process, I was happy to ensure that contributing to open source software would still be possible during my time of employment. I saw during my on-site interview that Jump Trading employs open source software throughout the company but also contributes back to open source, either with hours or donations. However, while I am still able to contribute to Fedora, I do not anticipate being able to maintain the level of activity that I contribute at now during my internship.

Stepping out from May to August 🔗

Due to exams and personal travel plans in May followed by an almost immediate departure to Chicago in early June, I will be stepping out of Fedora beginning in early May. I hope to spend time with friends and family before departing for Chicago, so my estimate is a little generous to the benefit of being realistic. My internship will finish around August 20th, 2017, so I hope to begin my normal levels of contribution around this time.

It will be challenging for me to step back for this long amount of time, after my involvement with Fedora has become such a huge part of my life. However, it is only a temporary change, and the time off ends near Flock 2017. So I will have a lot to get caught up on before the conference begins!

The only area I hope to stay partially active with is the Fedora Magazine to continue my post as the editor-in-chief. While I still don’t anticipate being fully involved, I hope to help with editing and to write a few articles during the summer as well.

I’m looking forward to seeing familiar faces again in August!

Open source projects are built online and a lot of their community members are placed all over the world. Even though projects have people from around the world, this doesn’t stop ambitious community members to organize open source conferences or events in their own cities. Whether they’re focused generally to open source or for a specific project, you can find a variety of conferences, hackathons, workshops, or meet-ups all over the world. Fedora benefits from having Ambassadors to attend these events to introduce Fedora and spread the word about the community. It’s not uncommon to see Fedora participating in these events, and Linux Weekend 2017 in Tirana, Albania was not an exception.

From March 25-26, 2017 in Tirana, Albania, nearly 130 people attended the first-ever Linux Weekend 2017. Linux Weekend was organized by Open Labs Hackerspace at the Universiteti Politeknik i Tiranës as an introduction to Linux for beginners. Throughout Tirana, universities have a strong focus on Windows or macOS operating systems and little focus is given to Linux. Open Labs community members wanted to organize an event that would promote Linux as an open source alternative and demonstrate some of its benefits over proprietary environments. The event collected representatives from various communities, including Fedora, Ubuntu, OpenSUSE, NextCloud, MusicBrainz, and more.

Organizing Linux Weekend 🔗

The Open Labs community is not unfamiliar to organizing open source events in Tirana. Their portfolio includes Fedora release parties, OpenStreetMap map-a-thons, Wikipedia edit-a-thons, and Fedora community meet-ups. However, these events have been targeted towards people who already had prior interest or knowledge about open source communities. The organization and planning for Linux Weekend began in the middle of January as an idea to introduce Linux to complete beginners.

Planning and organizing Linux Weekend was a community effort. Jona Azizaj is a board member of Open Labs and a Fedora contributor, and was involved as an organizer for the event. “This was the first edition of Linux Weekend, so the main focus is to raise awareness about Linux and open source. We wanted to educate beginners and spread the word about the choices that are available,” Azizaj explained. The two tracks for the event were full of talks and workshops to introduce attendees not only to Linux, but also various software and applications of what someone can do with Linux.

Many of the attendees were students who had either heard of Linux in their classes or from their peers. Other attendees included industry professionals or other open source community members. Several representatives of Fedora from different parts of the community were in attendance as well. Ambassadors, designers, and translators were available to answer questions and teach newcomers about Fedora.

Albanian students learn Linux 🔗

Since the focus of the event was to teach newcomers about Linux and how it can be used, Linux Weekend was organized to be an introduction to various parts of the Linux ecosystem. Representatives from Fedora, Ubuntu, Arch Linux, OpenSUSE, Linux Mint, and elementaryOS gave introductions to the operating systems and their communities. In addition to distributions, there were also sessions on open source licenses, NextCloud, text editors, MusicBrainz, and more. The benefit of these sessions were demonstrating the different ways Linux can be used to accomplish various tasks.

In addition to the various sessions during the weekend, there were three community booths for Fedora, OpenSUSE, and Mozilla. Attendees had a chance to get swag from each project and also talk with representatives about their own experiences or how to get started using their project.

Sidorela Uku was both an attendee and a speaker at Linux Weekend. Her talk, “Programming in Linux, editors, and tools”, introduced various text editors and other tools to help customize any Linux distribution to someone’s needs or personal preferences. In addition to sharing her own knowledge, she was also excited to discover new things. “I wanted to attend the talks and workshops to learn as much as possible. I also wanted to figure out the next steps to find a project and get involved as a contributor,” Uku explained. “I also wanted to share the things I know with others to help them get started with Linux.” This was Uku’s first time speaking at an event and she looks forward to more open source events in Tirana in the future.

Fedora contributors introduce community 🔗

Various members of the Fedora community were also in attendance. Some of the Fedora presentations over the weekend introduced the project to newcomers, detailed the translation efforts to bring Fedora to Albanian, and also guided attendees on how to make their first steps as contributors. The Fedora presence aimed to help give newcomers a taste of the operating system but also to show the impact someone can have if they decide to contribute.

Mariana Balla was one of the first speakers on Saturday morning with her talk titled, “Introduction to Fedora Project and how to be a part of the community”. She started with localizing Fedora into Albanian in early 2016 and more recently started to become an advocate as well. “Fedora is one of the most used distributions, and it was great to have Fedora here to spread the word and show what our community is all about,” Balla said. “One thing I hoped to show in my talk was that technical skills aren’t required to contribute to Fedora. There’s so many things that aren’t code that people can help with!” One of the highlights of Balla’s presentation was breaking down the different sub-projects in the community and how they contribute to making Fedora what it is. One site that was mentioned was whatcanidoforfedora.org, a site anyone can click their way through to find an area that interests them.

One key contribution area that was important for the local community was localization. Many attendees and speakers alike thought it was important to have software translated into their native language. Anxhela Hyseni is a Fedora Ambassador and led the workshop on “Translation of Fedora”. “It’s important for Albanians to have software in Albanian because we are Albanians!” Hyseni laughs. “People are better able to understand Fedora and it makes it more accessible for us to have it in our local language.” She hopes that attendees left Linux Weekend with plenty of new contacts in the open source community and a better idea of what Linux is all about. She and others also helped Linux newcomers install Fedora 25 as a dual-boot or for virtual machines in the installfest on Saturday morning.

Wrapping up 🔗

After two days of talks, workshops, and hallway discussions, the final talk finished around 4:00pm on Sunday. Azizaj closed out with some final words of encouragement and thanks for attendee participation.

The presence of Fedora, open source software, and its philosophy was present during the entire weekend. Between stickers, install media, and brochures from community tables and the various presentations during the weekend, participants and organizers felt the event was worthwhile. “We had limited time to plan, but it was important to bring Linux to people to introduce the philosophy, show them how to use it, and also how they can give back,” Anxhelo Lushka, an event organizer and Fedora contributor, explained. “We hope attendees had new experiences and learned something new and useful for the real world, for jobs or studying. We also hope we convinced them to contribute and give back, even if in a small way.”

Now that Linux Weekend 2017 is finished, the organizing team is switching their focus to Open Source Conference Albania (OSCAL), the largest open source conference in the region.

Find Fedora near you 🔗

Open source events are happening all around the world, and Fedora might be closer to you than you think! Check for local user or meet-up groups near you to get involved in some of these events. Meetup.com is a great way to find local events happening in your community. You can also keep an eye on what Fedora is up to by following us on Facebook, Twitter, Google+, or Instagram.

We hope to see you at an event in the coming future!