Ramblings on 15 years of Open Source work
For the last couple of days, I wanted to write a little text about my open source experience so far. March 15 marked the 15th anniversary of the day I shared a piece of code with an unlimited audience for the first time. I thought that might be a good time to reflect on things I have done, things I have learned, things I would now do differently, and things I plan to do in the future.
If you know me, you know that I do not usually struggle coming up with comprehensive articles on topics I care about or just things I am passionate about. However, here, I am struggling to find the words to tell the story I wanted to tell, even though I am excited about FOSS, am deeply involved in multiple large open source projects, and care about the FOSS community a lot.
Reflecting a bit more, I realized that my view on open source software, FOSS communities, and driving such projects has changed wildly over the last few years, and I struggle drawing a clear picture of the past or the possible future.
FOSS as a learning experience?
All the way back in 2004, my primary motivation was to get opinions on my coding style, hoping to improve my own skillset based on that feedback. I have seen a lot of discussions with people just getting into software engineering, where they are being told that they should just open a GitHub account, and share all their early coding work there so that random people can have a look and provide feedback. I even suggested that myself a couple of times.
And so, my very first attempt was not a true FOSS project, because I did not include a license back then. Still, I published the source, so it was Open Source software, for sure. I shared it with a couple of strangers on QuakeNet, with a message saying something like “Look at this awesome VBScript I did! Any feedback?”.
In hindsight, I probably got lucky that people did not start laughing at me immediately, which could happen on the internet very quickly, as that would have been quite demotivating. And while I did not get any laughs, I also did not receive any constructive feedback, all I got was a couple of “Oh, that’s cool”s.
Fast-forward to today: I am employed by an open-source company and do a lot of FOSS work in my free time. I try to make my useful work output, as well as side projects, openly accessible if I can. One could say I have gained a lot of “Open Source experience”.
Looking back at the “learning by doing FOSS” aspect, I do not remember ever getting real feedback on any of my work just because I decided to release the source. While I have learned a lot over the last few years, I did so by receiving feedback from specific individuals who I explicitly asked to review my code, I have never received feedback on open source projects from people just stopping by and deciding to comment on my code1.
These days, when people ask me about the best way to get feedback on their code, I no longer reply with “throw it on GitHub”. Instead, I feel like suggesting them to collaborate with people they know personally is much better advise. Working with already familiar people removes the scary parts of sharing your projects, and you can hand-pick the people you trust, and you want to receive feedback from.
Collaborating with others?
People very frequently turn their private projects into FOSS with the hopes that other people will eventually discover them, find the code useful or interesting, and start contributing. The idea is charming: Open Source projects with a healthy contributor base can achieve so much more than any single person ever could do, both in terms of sheer engineering power, but also in coming up with new ideas and directions.
Most of my projects on GitHub have zero stars, zero watchers, and zero followers. I am highlighting this to make the point that if you push your code to the public, probably nobody cares. For most of the projects out there, nobody will ever look at it thinking “oh cool, this code is doing what I want, let’s use it”, or “oh, I wonder how they implemented XYZ, let’s check, maybe I can learn from their work”, or even start contributing. In reality, there are way too many projects out there, and discoverability for a single repository is really low. While there is always the chance of someone discovering your project by accident, it is more than unlikely for your average project.
Collaborating with others is fun, and it is an excellent way to improve your skills. Not only will code reviews (both receiving reviews from others, and reviewing other people’s code) strengthen your coding skills, collaborating will also significantly improve communication and project management-type skills. I think you really should collaborate with others, but you do not need to work on FOSS projects to achieve that goal. Instead, you can ask some friends if they want to work on a project with you together. You may find that much easier, as you already know the people you would be working with.
Sharing knowledge and information?
Another favorite reason for people pushing their code into the public is the thought of sharing knowledge and information with the world.
In my opinion, there are pieces of software that absolutely should be developed in the open, and that their codes should be available for everyone to read, share, and modify. I am thinking about applications like your web browser, which is just a gateway into the open web, allowing you to retrieve all the information you want. Or your social networking application, a very personal topic that deals with a lot of sensitive information. I also believe that software developed by or for public organizations and governments should be released under FOSS licenses because these things are financed by the public, produced for the public, and can have a significant impact on the people.
However, that is probably not what most people are working on. Tons of learning projects are personal websites, small tools people use to enhance their productivity, or a little game. These projects, while being cool and interesting, probably do not serve anyone but their creators, and I personally do not think they benefit from being developed in the open.
”But there is no harm in publishing your code!”
With all that said, one could still argue that these points really do not matter and that one should work in the open anyway because there is no harm in doing so. With that, I have to disagree.
When I pushed my very first project into the wild internet, the feelings of joy got overshadowed by lots of anxiety. Let’s face it, when you are new to programming, you have zero confidence in yourself, you think everyone else is far superior, and you will fear that others might laugh at your code because you made “stupid beginner mistakes”2. It is scary as hell.
Working and learning in the open has many positive points, but there are downsides as well. Collaborating with people you do not know can be hard. It is very easy to misunderstand someone and end up fighting over a misunderstanding. These communication issues happen all the time, even with experienced people, and they always end up eating away a lot of time and energy.
When your work is public, you will, sooner or later, run into a situation where other people start using your project. This can be an enriching experience, but it also comes with a feeling that others rely on your project and your work. No matter how clear you write your project description, and how many notes you add about how it is only your personal project and how you do not intend to work on issues that do not affect you, people will start reporting bugs and requesting features at some point. While most people are friendly, some dudes will get mad at you for not immediately addressing the crucial thing they reported, and those folks can get quite abusive sometimes. There is, unfortunately, no way around this.
Putting your projects out there can be rewarding and fun. It is also possible that nobody will ever discover your work, but there is a good chance that one day, you end up in a situation where people have expectations in you or your projects, and dealing with those expectations can be very, very uncomfortable.
In the end
I feel like I have lost my point half-way through writing this. Probably because I have.
As I mentioned in the beginning, I originally planned on writing a happy and nice summary of the open source adventure I had up until now. Collecting ideas and drafting notes on this post’s contents, I realized that I cannot do that. I have seen too many of the dark sides of Free and Open Source projects for me to just go ahead and ignore those.
This sounds a bit like I am trying to scare people away from FOSS work, but that is absolutely not the case. I will not stop working on free and open source software, and I would never discourage someone who really feels their project should be public from doing so. But once again, it made me realize that especially for people just entering our world of software engineering, working in the open can do a lot of harm, maybe resulting in them leaving and never coming back.
Working in the open can be fun, it can be rewarding, and it can be a great learning experience. But it can also be very frustrating, demanding, and abusive. And that is an excellent statement to end this collection of ramblings with.