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.)

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.

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.

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

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

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

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

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

On the origins of Software Freedom 🔗

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

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

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

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

Freedom in 2020 🔗

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

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

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

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

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

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

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

Reconciliation and intersections 🔗

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

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

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

The name of this intersection is digital intersectionality.

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

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

What now? 🔗

Chadwick Boseman is gone. But we are not.

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

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

Special thanks to my early editors!

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

Overview 🔗

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

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

If you are hooked, read on.

The Sticky Idea 🔗

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

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

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

Open Source Accountability Goals 🔗

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

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

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

Facilitation of Authentic Participation discussion 🔗

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

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

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

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

Facilitation, Roosevelt-style 🔗

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

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

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

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

How did facilitation start? 🔗

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

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

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

Is there a next chapter to this story? 🔗

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

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

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

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

Closing thoughts 🔗

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

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

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

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.

I never intend to adjust myself to injustice.

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

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

Where Byfield was accurate 🔗

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

Predisposition towards difference 🔗

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

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

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

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

Outreach on ethics, not software 🔗

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

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

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

Intersectional movement building is the future 🔗

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

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

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

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

Where Byfield didn’t go far enough 🔗

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

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

What are today’s challenges? 🔗

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

Inclusion builds power 🔗

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

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

Power and governance 🔗

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

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

Where do we go from here? 🔗

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

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

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

Photo by Walid Berrazeg on Unsplash

Use alt tags for Markdown images 🔗

Often an embedded picture in Markdown looks something like this:

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

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

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

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

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

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

Photo by Roman Kraft on Unsplash

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

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!

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.

Today’s entry to the blog is sourced from a thread that I posted on the SpigotMC Forums. If you wish to join in the discussion about this, feel free to chime in on the thread or leave a comment on my blog. In this post, I covered licensing, licenses, and why your open-source software project should have a license. You can read my original post in this blog entry.

I’d like to share some personal and real-word advice to many of you contributing open-source resources to Spigot, but also to other open-source software projects you may work on even outside of just Minecraft or Spigot.

Licensing 🔗

What is licensing? Why does it matter? Why should you care? There are many reasons that licensing is an important part of a project you are working on. You are taking the time to write code and share it with the world in an open way, such as publishing it on GitHub, Bitbucket, or any number of other code-hosting services. Anyone might stumble across your code and find it useful.

Licensing is the way that you can control exactly how someone who finds your code can use it and in what ways.

Okay, why does it really matter? 🔗

Maybe you’ve been writing code for a really long time and you’ve never bothered with licenses and don’t feel the need to. I’d like to present two hypothetical situations that I see pop up all the time, one in Spigot and one in the greater open-source community.

Your Plugin 🔗

You have spent a lot of time writing an awesome resource and you pushed all of your code on GitHub! Woohoo, project complete! You package it up as a JAR and submit out to the open. Skip ahead a few months, and maybe you no longer have the time to contribute to your project. Or maybe someone has an awesome idea for a totally different plugin that uses similar functionality to what you have written.

A new person finds your code on GitHub and discovers that it has the perfect method or algorithm for his own project. Or maybe they want to continue your project with new, fresh energy! But you have no license for your code. By default, this means default copyright laws will apply to your code. This is an extremely limiting type of copyright enforcement and almost defeats the entire purpose of even open-sourcing your code. A law-abiding programmer might just give up on the project and look elsewhere, or maybe a not-so-law-abiding programmer will secretly copy and paste your code without attributing your work back to you. This helps neither you or the friendly programmer looking at continuing or forking your work.

In many cases, the SpigotMC Staff receive reports about people “copying” other peoples’ code. Having a licensed project makes reviewing these reports 10x easier. People without licenses or with ambiguous sources makes it extremely difficult to review and make decisions about whether projects are copies.

By licensing your code, you are protecting your own work and writing the rules to how people can use your code. If you are open-sourcing your code, usually the point is to have collaboration with others and give back to the community by allowing others to tinker, modify, or play with what you have created. Make it easier for others to contribute, help, or build new awesome things by choosing a license!

Your Project 🔗

For any open-source software project on the Internet, having a license is very, very important. For example, let’s say you write an important library or utility that can be used to make a developer’s life easier for making a user interface more friendly. Your program is well-designed and has usefulness outside of what even you intended to write it for.

Perhaps a large company stumbles across your code and also thinks it’s very useful for their own project. Maybe their project is proprietary or closed-source. Having a license in a situation like this suddenly becomes very important. Some licenses would permit this company to take the plugin or library, modify it to their own needs, and include it in their own product, while only leaving a small mention to you in the “Legal” section of their app. Maybe you’re okay with that! Maybe you’re not.

If you’re not, there are licenses that let you define how the code is used in a case like this. With some licenses, if the company decides to modify and use your code, they will have to open-source their changes that made as well. If they don’t modify anything, they just have to link back to your original source code. In some more extreme licenses, anything that touches your code also by extension has to be open source.

For a Minecraft example of this, let’s say you have a “Super Craft Bros.” plugin open-sourced on your GitHub. Hypixel stumbles across your code and decides they want to use it for their own servers. Let’s say your code is licensed under the Mozilla Public License 2.0. For this license, if they take your code and make no changes, they only have to give credit back to you. If they take your code and change it, they also have to open-source all of the changes they make to your code.

Now, the changes made by the bigger company can benefit many others instead of just the one company!

What licenses are there? 🔗

If you Google “open source licenses”, you may be overwhelmed. There are maybe close to the hundreds of different licenses for you to choose from. How can you pick one to settle on?! Fortunately, there are websites that do a great job of summarizing licenses to exactly what others can or cannot do with your code. A very popular site is tldrlegal.com, which provides bullet-point summaries of different licenses.

tldrlegal.com 🔗

Exploring that site is a great reference for picking a license. However, in this thread, I’m going to do a very quick summary of four of the most popular open-source licenses that exist. However, it is important to preface this with a statement: I am not a lawyer and this does not constitute legal advice. It is important for you to look more into a license that feels right for how you want to share your code and determine what others can do with it.

MIT License 🔗

The MIT License is almost universally regarded as one of the least strict licenses in open source. You can read more about it here.

You can:

• Use the work commercially (think of the big company example said earlier)
• Modify the original code
• Distribute the original code or distribute your modifications
• Sublicense the code (in other words, use it with code that has a different license)
• Use the code for private use

You cannot:

• Hold the original author liable for damages
  • So this can’t happen: “Oh noes! I accidentally exploded my entire server with your code! You must pay me monies to fix this nao!!!”

You must:

• Include a copyright notice in all copies or other uses of the work
• Include an original copy of the license with the original or modified code
  • You will always be credited for your work!

Apache License 2.0 🔗

The Apache License 2.0 is only slightly more restrictive than the MIT License, but it defines a few more rules than the MIT License. This can be useful if you want to make sure your work is given proper credit back to you and you care a little more about how it’s used. You can read more here.

You can and cannot do the same things mentioned above for the MIT License. So we will just highlight the changes!

You can:

• Same as MIT License
• Use patent claims (might be advanced for most of you, but can be useful for bigger projects)
• Place a warranty (lets you have a warranty on your code, if desired)

You cannot:

• Same as MIT License

You must:

• Same as MIT License
• Openly state changes you make from the original project
• Include the NOTICE (if the project has a NOTICE file, you have to keep it in copies / modified works)

Mozilla Public License 2.0 🔗

The next step up from the Apache License 2.0 is the Mozilla Public License 2.0. This license has the same basic rights as the Apache License 2.0, but it goes a little more in-depth about how the code can be re-used. This is my personal favorite license! You can read more here.

Most of the things for what you can and cannot do are the same as the Apache License (and thereby, the MIT License). So again, we’ll just highlight the changes.

You can:

• Same as Apache License 2.0

You cannot:

• Same as Apache License 2.0

You must:

• Same as Apache License 2.0
• Disclose the source (any changes made using MPL’d code must also be made open under the MPL!)
• Include the original (either the source code or instructions to get the original code must be provided)

GNU Public License v3 🔗

The GNU Public License v3, also known as the GPLv3, is one of the most well-known and strict licenses in open-source. It has very specific rules for how the code can be used and shared, and leaves a lot of control over to the author. In a sense, it’s “after” the MPL 2.0, but it also has some key differences. You can read more about it here.

Again, we will highlight the changes from the Mozilla Public License 2.0.

You can:

• Same as Mozilla Public License 2.0 (except sublicensing)

You cannot:

• Same as Mozilla Public License 2.0
• Sublicense the code (this is a big concept worth understanding if you use the GPLv3)

You must:

• Same as Mozilla Public License 2.0
• Include original copyright (must be retained in all copies or modified works)
• Include install instructions (you must document how to install the software)

Go forth and conquer! 🔗

Congratulations! You now know a little bit more about licensing, open-source licenses, and how to use them. Hopefully this will help emphasize why and how licenses are important in open-source software. In many ways, the license you choose to use can even be more important than any lines of code you write. That might sound absurd, but when it comes to deciding how your code can be reused, modified, or distributed, it’s something that can be vitally important to your project.

Those of you without a license, please consider choosing one, or talk to other teammates of your projects about what license you all want to use. If you code in the open, make sure you are protecting yourself and paying attention to how you want other people to use your code.