Open Source for Fun, Learning, and Kudos
Reflecting on my career, and advice on getting started
My first paid, web-facing work was closed source. My employer was developing applications for the Microsoft Windows web server platform (paid / closed source), using Microsoft Visual C++ (paid / closed source) and the code remained firmly behind closed doors. I would love to be able to see that code today, nearly 20 years later, but it’s sadly lost to history. The only code I have from that era is a Java Applet (!) game that I made for a company promotion.
make” installed, give it a try.Consumers of open source, but contributors to none
As time went on, the company (and more broadly, the rest of the world) moved from closed-source software with restrictive licensing to free, open-source software developed by the community. Open-source wasn’t a philosophical choice for my employer in the 2000s, it was an economic one.
As the company expanded its portfolio of computers, when faced with the choice of paying for operating systems, programming tools and desktop software or getting them for free, they chose the cheaper option. But they gave nothing back. Companies I worked for paid for support contracts occasionally, but the code that they built on these free foundations remained closed source.
The future is open
Today things are different. The tech giants of IBM, Microsoft, Google and the like embrace open source not as a means to shave a few lines from the balance sheet, but as a way of shaping software collaboratively. IBM offers open source products “as-a-service” — Apache CouchDB, Redis, MongoDB, MySQL, Postgres, ElasticSearch, RabbitMQ, Apache Kafka, Apache OpenWhisk, Apache Spark, RethinkDB, ScyllaDB, Hyperledger — but more than that, it employs people who commit work to such projects.
Open source, when used properly, is a way to expand your horizons, learn how stuff works, and join in yourself.
Open source – your first PR
Developing open-source code can be extremely rewarding.
If you want to get started with open source, then there are resources out there to help you contribute to existing projects. Take a look at Your First PR, a site that collects issues for open source projects suitable for first-time committers. Study the project’s contributing guidelines before submitting anything, and don’t be afraid to ask questions. The vast majority of project maintainers will treat you cordially and with respect.
If you have an problem with some open source project, try Stack Overflow, read the documentation, scan the Github issues, and then perhaps raise your own. Decompose your problem to the smallest piece of code you can that demonstrates your problem, or even better submit a pull-request with a new automated test that demonstrates the failure. The project will love you for that!
Remember that open-source projects are often run by maintainers working in their own time, so keep your communications polite, respectful, and constructive. Many projects have a code of conduct which should be read and understood. No one wants comments in GitHub issues to look like those found on YouTube or under newspaper articles.
Open source – your first project
You might then want to open-source a project of your own. It could be an app, a library, or a command-line tool. It could be a fork of an existing project, with additional features that you need, but are not aligned to the direction the original project is going.
If you’ve built something that could potentially save someone else the time it took you to research and write it, then it’s probably worth publishing. Some projects you publish may remain unfound and untouched for years, but occasionally you may hit on something bigger and find that issues are being logged, the number of GitHub “stars” is accumulating, and third-party pull requests are arriving.
Bear in mind the judgements you make of others’ GitHub projects when you see them for the first time:
- Is the documentation good? Does the project say what it is, how to get started and dive into the level of detail I need?
- Is it currently maintained? When was the last commit? Is this a one-person project or a team effort?
- Does it have a set of automated tests?
- Is the license suitable for my needs?
If you want folks to find and use your code, then try and step into the shoes of a first-time user of your project and compose a README for them. It’s not as easy as it sounds.
Open source – health warning
If your open source project really hits the big time, then you may need to prioritise your own health over the that of the project. It is impossible to maintain everything you write forever. Don’t be afraid to deprecate projects which are now irrelevant or are too time-consuming to deal with.
If it’s starting to feel like a chore rather than a privilege, then it may be time re-evaluate your priorities.
GitHub as a CV
Hopefully, you will be able to look back at your GitHub profile as a scrapbook of your software development history, and others can view it as a living, breathing “CV”. There’s even a tool to turn your Github profile into a résumé.
If you’re looking to hire a developer, and the candidate is fortunate enough to work for an employer who encourages open-source contributions, then their GitHub profile can reveal a host of positive signals:
- Is the candidate a regular open-source contributor?
- Does the code they contribute indicate experience in the skills you are looking for?
- Do the written exchanges (issues, pull requests, comments, and documentation) indicate the cooperative, respectful team player you are looking for?
Bear in mind that not all developers are on GitHub! Other source code version control systems are available, and not all code is open source.
When one door closes, open a pull request
The difference between today and when I started my career is stark. Sharing your code and collaborating well on other people’s projects is one of the best ways to stand out professionally. So get involved, and may it lead to bigger and better things for both you and the projects you work on.
