I don’t think anybody can understate the value free and open source software has brought to the world at large, value which has largely been freely given with little expectation in return. The ubiquity of free and open source software seems to have fostered a sense of entitlement in the minds of some users. This presumption that free and open source software should do exactly what they expect it to do, and if not, that’s a problem that you the maintainer should address. I find this viewpoint to be not only incorrect, but abusive.

My exact words were “I could have likely filled half a book with thoughts and practices on good security for Jenkins” and were I to write that book, my colleague Daniel would certainly be a guest author of a few chapters, such as one on the limitations of credentials masking. In that linked post Daniel highlights some of the ways in which credentials can be misused in Jenkins. As I mentioned on Twitter, this is not a unique problem to Jenkins, any system which allows user-defined build processes and allows the use of credentials in those build processes will allow exposure of those credentials.

As the number of different ways to configure Jenkins approaches infinity, I have come to appreciate one pattern in particular as generally good. When I first started the draft of this blog post, three years ago (!), I wanted to share that by coupling Jenkins and Docker together I finally had the CI/CD server I had been waiting for. In the past few years, Docker has increasingly become the default environment for Jenkins, and rightfully so. In my previous post I mentioned some of the security pitfalls of using Docker in an untrusted CI/CD context, like that which we have in the Jenkins project. Regardless of trusted or untrusted workloads, I still think Docker is a key piece of our CI/CD story, and here I would like to outline why we need Docker in the first place.

Over the past few years, the topic of architecture and security for CI/CD environments has become among my favorite things to discuss with Jenkins users and administrators. While security is an important consideration to include in the design of any application architecture, with an automation server like Jenkins, security is crucial in a much more fundamental way than a traditional CRUD app. Walking that fine line between enabling arbitrary use-cases from developers and preserving the integrity of the system is a particularly acute problem for CI/CD servers like Jenkins.

This past Saturday, with support from a number of my friends, I passed the first fundraising goal for AIDS/LifeCycle 2019! Cue riotous applause! Prior to my training ride I mentioned on Twitter that I was only six dollars away from my first goal, and by the time the ride was over, a couple hundred dollars had been donated! Hoorah! Each AIDS/LifeCycle (ALC) rider must raise at least $3,000 and thanks to the tremendous support from friends, family, and a quite a few folks on the internet, I am definitely riding from San Francisco to Los Angeles in June.

One of the most significant personal revelations I have had in the past five years has been around the relevance and importance of high-quality engineering management and leadership. From my observations, poor engineering leadership has a negative and cascading effect throughout the product development process, and can substantially improve or degrade the overall performance of the company. As I have previously written, I now appreciate how engineering leadership is a specific skill set which requires practice, growth, and it’s own specialization.

The most recent Jenkins security advisory contains a fix for an issue in the GitHub Authentication plugin. One which I reported many moons ago, during an experiment I named “Code Valet.” Seeing the issue finally resolved brought fond memories back into my mind and I realized that I have never really reflected and shared what it was and more importantly: why it failed. At it’s core, Code Valet was intended to solve two fundamental problems: firstly, I wanted a Jenkins Pipeline as a Service, since I find Jenkins Pipeline to be a very useful tool, which I wanted for all my open source projects. Secondly, the Jenkins project needed to shift its footing towards a continuous feedback and continuous delivery model. Code Valet aimed to solve both of these problems.

Not knowing what I was getting myself into, about eleven years ago I started contributing to what became known as the Jenkins project. What followed has been nothing short of incredible; hundreds of new contributors, tens of thousands of new users, and millions of executed pipelines. Growth is challenging. Growth means new problems which demand new solutions. Two and a half years ago I stood in front of a large group of contributors at the 2017 Jenkins World Contributor Summit and made a pitch for what I called a “Jenkins Software Foundation”, never shy to pilfer ideas from the Python community. With help from my pal Chris Aniszczyk and the Linux Foundation, the concept morphed into something far more comprehensive the Continuous Delivery Foundation (CDF), for which my colleague Tracy Miranda has been leading the charge, helping drive the founding of the CDF.

The first bits I transmitted on the internet were sent through a modem on the end of a old-fashioned copper telephone wire. While I didn’t recognize the complexity at the time, its ingenuity still impresses me. An analog-only medium, the copper wire, could be made to transmit ideas via specially encoded chirps, squeaks, and chimes, to nearly any other destination connected to the web. At their most basic, words are a truly astounding mechanism for encoding and transmitting ideas from one brain to another. Without language, the rest of this wouldn’t be possible. Ideas alone are worthless, ideas in transit are incredibly powerful.

Wrapping up work some afternoon last November, I waltzed into the living room and found myself in the middle of one of those conversations where you weren’t actually necessary for the first half. “It will be great for you to train for ALC too!” She continued to talk excitedly about how we wouldn’t pay for the spin studio anymore, how convenient it will be, and how it would really be a good Christmas present. She showed me the price and I hummed to myself, giving the appearance of stern but deliberate thought “yeah, we’ll see.” Having already started to price out more cycling equipment, I didn’t want to give up the gag just yet.

Jenkins is a large open source project. Well over two thousand repositories, almost two thousand committers, four or five GitHub Organizations, and many thousands of opened, in progress, and closed issues. Part of the reason we’re called Jenkins is because of GitHub and yet many of our repositories do not use GitHub Issues. We eschew GitHub Issues in favor of Jira for a number of reasons, perhaps most importantly is that GitHub Issues are incredibly difficult to scale across repositories and teams. What might be considered a shining example of scaling GitHub Issues would be the Kubernetes ecosystem which has concocted a rather complex workflow using automated bots, labels, and comments on Issues. As such, it’s not impossible, but vanilla out-of-the-box GitHub Issues are tricky to grow with large free and open source projects.

Before moving to San Francisco an older friend had given me the name, which I carried as the title on my first business card: “Angry Young Man.” I had a tendency to practice “anger-driven development” wherein I would stay up late hacking away, determined to make something less shitty. I don’t think I have ever truly been an angry person, so let’s call it “playful cynicism.” I used this energy to develop two characters on Twitter through which I could vent my frustrations and make jokes about day-to-day stupidity in the tech industry. The most popular character and certainly my favorite: sadserver and its relative which I added later on sadoperator, are as of today effectively retired.

What an interesting year it has been in the world of free and open source software! Adoption is through the roof and the age old question of “how should we fund this” has come back to the forefront. This year a number of companies have introduced non-open source licenses, sometimes referred to as “source available” licenses. To date I have not seen a single major open source project change licenses. Funded companies which have built ancillary tools and projects around some major open source projects have switched to these curiously un-open licenses. The big heartburn seems to stem from larger service providers taking open source software, turning it into a product-as-a-service, and making money off of that service. All of which is perfectly valid for the use of open source software. The subject of licenses is not one I wish to discuss in this blog post, but rather something which enables these sorts of license shenanigans: the contributor license agreement.

I learned this morning that a good man by the name of Jacob Sparre Andersen passed away over the weekend. While Jacob (sparre) is not the first person I know of to have died in the open source community, he is the first I interacted with on some frequency. A constant presence in the Ada developer community, most often I would chat with him in #ada on the Freenode network but we would also see each other once a year at FOSDEM.

For the last little while I have been hosting this blog on GitHub Pages, generated using Jekyll. All that is well and good except GitHub Pages doesn’t properly support the jekyll-tagging plugin. Therefore tags on this site have been broken since the migration, until I found ]this blog post](http://longqian.me/2017/02/09/github-jekyll-tag/) by Long Qian.

One of the little applications which I built earlier this year ended up more useful than I originally anticipated. Useful enough to have hit its first performance bottleneck! Performance problems I generally grumble “nice problem to have” which profiling and refactoring, but in this case I know what the performance problem was, but lacked the appropriate solution.

With a clean air and a good bit of weather out in the big blue room, I decided to take advantage of the opportunity and continue some of my AIDS/LifeCycle training outdoors for a change. If you have never been to Sonoma county, you may not be familiar with some of its absolutely fabulous hills, valleys, and vistas. This past weekend I joined the numerous cyclists out there charging about on our beautiful county roads.

In the development of service-oriented applications we often will use the phrase “source of truth” when referring to data and its ownership. The expectation being that there is generally a single source of truth in the system. Take DNS for example, we generally trust that a nameserver somewhere out there is acting as the single source of truth for a single domain, such as brokenco.de. Without this guarantee, much of our experience on the internet would break down. For the software we write, increasingly GitHub has become the source of truth for the source code itself. So much so that systems have been built on top of GitHub which further wed the software ecosystem to a single source of truth, such as Golang’s dependency definition conventions.

We have finally arrived at that most special day on the calendar, one I am sure you have been eagerly waiting for: Tyler Day!. This year’s Tyler Day is not much different than in years past, it has fallen on a Tuesday. It always seems to be a Tuesday. Festivities in the Northern Hemisphere are met, as per usual, with the cold transition from autumn to winter. And to most in the United States, Tyler Day is that last reminder to go to the grocery store to prepare for Thanksgiving.

The impact of HIV/AIDS on the world is difficult to overlook, perhaps more so in the San Francisco bay area where the epidemic decimated the gay community in the 80’s and 90’s. While not directly affected, I have supported AIDS-related organizations and legislation in San Francisco and California at large ever since I moved here over a decade ago. This year I will be trying something of a slightly different color: AIDS/LifeCycle. An event which brings thousands of cyclists, roadies, and supporters together to ride from San Francisco to Los Angeles, raising millions of dollars in the process. This year, rather than donating to friends’ fundraising activities, I will be joining them!.