Choosing Open Source: A career perspective

Through the late 90s and through the early to mid-2000s there was a great rivalry, Open Source versus closed, proprietary software. At times it got ugly - any of us working at that time will remember the “Linux versus Windows” flamewars and the Microsoft-as-the-Borg memes (before “memes” were a thing). But all the ire directed at MS could arguably be justified - recall the so-called “Halloween Documents” or Steve Balmer declaring that “Linux is cancer”.

How different did things look to a programmer at the end of the second decade of the 21st century? To some extent, the “war” is over. Open Source Software is ubiquitous across the entire stack, from server infrastructure to front end frameworks.

My guess is that you’d be hard pressed to find a modern software project that doesn’t involve Open Source in some way.

If I were to attempt to answer the question “how can you use open source to your advantage” twenty years ago, the overall thrust of my suggestions would look a lot different than they do today (and possibly a lot angrier). I don’t have to convince you or the utility of Open Source. History has already done that for me.

If you’d like a rundown of the reasons that people ordinarily use to justify why you should investigate/use Open Source, you’d be hard pressed to find a better summary than Michael Tiemann’s whitepaper “How open source can save the ICT industry $1 Trillion per year”.

I’d like to suggest a few, more personal, reasons how you might use Open Source to your advantage. Think of them as expanding circles of concern, first for yourself, then your immediate community, and then for the world as a whole.

What others give to us

I’m not suggesting that you can use Open Source software to beef up your resume, which I’ve seen argued again and again. Rather, I’m speaking to those programmers who genuinely care about becoming better at what they do.

There’s a deep satisfaction in progressing at your craft - whether that be writing poetry, painting, or coding - and there are at least two parts to this. The first is actually producing, writing new poetry or code. That’s vitally important. But there’s a second, arguably more important, and often forgotten part.

That is, developing your taste.
Your eye.
Your sensibilities.

Ira Glass, in his much-shared piece, speaks about “the gap” that exists in any artist between their taste and what they can produce at any time.

The suggestion is that becoming a better artist is about producing a lot of work so that what you’re making begins to line up with what you consider great. Your taste guides your practice.

With visual arts or prose, developing your taste seems to be simpler. Those writers can read a lot of poetry. Those artists can visit galleries and view hundreds of the best works that history has to offer. Further, there’s a long tradition of critical literature that reaches at least as far back as Aristotle that can help inform us, help further develop our taste.

While the field of critical code studies is relatively new and we don’t yet have quite the mass of critical literature as poetry or visual arts (it does exist, though -- this is a wonderful example), the fact that there are just so many examples of truly great code that we’re able to read and learn from means that the problem of developing taste, and thus knowing what great code is in your bones, is made far simpler.

Fabian Sanglard, for instance, suggests that anyone wanting to become a great C programmer should read the source of the games Doom and Quake. Closer to my own concerns, being a web developer, I might suggest to a junior on our team to read something like Elloquent’s Collection class for an example of an elegantly structured set of abstractions, or the code for the Slim Framework to get a clear idea of how precisely middleware works.

What we can give to others

This might be the most personal (for me) of the three ways you can leverage Open Source software, and I doubt it will resonate with everyone - but it might, so it’s worth mentioning.

The first time you ask a question can be terrifying.
The first time you submit a bit of code to a project can be terrifying.
Making a mistake in either of these can be mortifying.

And yet, learning to be brave enough to ask questions, to make suggestions, to submit PRs - is a vital step to becoming a better developer.

For some, these steps are taken in their first jobs, within the context of a team, sometimes with a mentor. For most, I’d bet, this is not the case.

Open Source projects are the perfect place to get this kind of feedback, to experience what it’s like working with other programmers, asking questions etc.

This is not simply about developing your taste, or reading code, but learning about the collaborative nature of programming.

Open Source projects are a fantastic space in which to get this kind of experience for new programmers. But we need to be mindful.

There is a certain style of communication in “tech” that’s needlessly aggressive. When there is a community that, or individual who has adopted this kind of communication style, it can be chilling for those who are just getting started. I’m not sure what causes some people to use their knowledge and experience as a weapon, but the mere presence of someone adopting that kind of style can be crippling.

I’m not suggesting there shouldn’t be standards or that anything should go in terms of code. It’s good and right to worry about quality and correctness. But this style of communication can drive people away who might otherwise make great contributions, who may eventually be great programmers. It can drive them away faster and more successfully than any kind of intrinsic difficulty there is in programming.

And so, my second suggestion about leveraging Open Source has two parts.

First, Open Source may be an important place for beginners to take their first steps collaborating and learning “in the open”, sure. But here I’m not really interested in the in beginners.

The second and more important aspect is for more experienced programmers. Working in Open Source gives us the opportunity to be kind to those taking their first steps, those just learning to be brave. We can listen, we can answer with patience, we can learn how to guide people without hardening ourselves towards them and their feelings. We can learn to put aside our frustrations, and when we can’t, learn how to express them humanely, in ways that don’t belittle and crush.

Furthermore, when we successfully demonstrate this kind of behaviour towards others, we’re acting as a positive example for the next generation of programmers.

What we can change

I mentioned at the beginning that Open Source has won, at least in terms of global adoption and acceptance by businesses. But this is only a partial victory.

Open Source, and free software more generally, has never simply been about business value. It has to a large degree been underwritten by the notion that we can change the world.

What I’m suggesting is that we should remain alert to this revolutionary undercurrent in Open Source, to not forget it.

It seems to me that in Open Source software we have a strange win-win situation - we have the opportunity to deliver business value while at the same time making the world a better place. This is what has always drawn me to work with and in Open Source Software. Installing Linux used to feel like a small act of resistance.

And even now, the code you contribute to a project like Drupal or Laravel doesn’t simply make, say, a form easier to place on a page, but it can help, in some small way, say, a startup in Zimbabwe with no access to capital to build a viable business.

It can help charities and governments save many millions of dollars on software licenses, money that is far better spent elsewhere.

In a very real way, Open Source Software has already changed the world. We should never forget that.

My third suggestion for leveraging Open Source is to use it both as an example of how to change the world and as a vehicle to do just that again and again.

Resources: