By Jason Lowenthal March 14, 2016

Why Contribute To Open Source?

The Open Source Software movement encompasses all kinds of solutions for all kinds of problems, some of which programmers themselves benefit from, others of which serve as hobby projects or creative tools that programmers with non-programming interests contribute to.

The most obvious Open Source software platform anyone could probably think of is the ecosystem for the Linux/UNIX operating system—and for developers we’re all about writing code that Tux would (hopefully) be proud of.

But, there’s so much more out there to contribute to. There’s a better than average chance that you might even use some of the software during your day-to-day routine.

A good chunk of our jobs depends on open ecosystems. Anyone earning a comfortable paycheck writing Java (or other JVM) solutions makes a living creating software with an open source platform, which can run easily in an open source application server (probably running on Linux).

What Is Open Source?

Working in the technology industry, we programmers hear the term “open source” frequently. However, I don’t really think everyone knows the formal definition by heart—I know that I can’t claim to know it. While poking around online for a good concise reference that defines “open source,” I ran across this one and thought it captured the essence quite nicely: The Open Source Definition.

The super short TL;DR version (that I made up):

Anyone can easily get the source code, change it, redistribute it, and not get taken to court for doing so.

Depositphotos_54065895_m-2015

Sounds Awesome! Where’s Teh Codez?

Most developers know about GitHub as the premier hosting platform for open source projects. If you’re willing to pay them for it, they’ll even host closed source—but most of the developers I know have absolutely zero problem showing their work to the world if people are willing to look at it.

A few other platforms do exist for hosting open source code, but GitHub is the one with which I’m most familiar. The two projects I’ve contributed to thus far both host their codebases in GitHub.

I’ve only contributed two small commits thus far, but I feel like it opened the floodgates for me to start contributing more readily towards technology tools that I really use regularly. Several of the tools I’ve used in the past or use currently have open source repositories. So, hopefully soon I can make this list below quite larger:

Project NameMaxScaleSASS
Company NameMariaDBSASS
Project Linkhttps://mariadb.com/products/mariadb-maxscalehttp://sass-lang.com/
My Commit / Pull Requesthttps://github.com/lowenthal-jason/MaxScale/commit/c795032358957d933ff7666dd33d258cb775ff60https://github.com/sass/sass/pull/2002

But, SASS Rejected Your Pull Request!

Yes, they did.

My code didn’t include some edge cases, and it didn’t appropriately provide an automated test to prove that the provided code fixed the related bug that the community reported.

I still learned a considerably valuable lesson in submitting this pull request. Several, in fact—so strap in everyone. Here comes the moral(s) of the story.

You Don’t Have All of the Answers (But You Do Have Some)

If you want to learn how to write good software, learn how to contribute to good software repositories. We all have different definitions for what we think “good” means, but the open source community contains hundreds of projects that cover a variety of fields and problem domains. I can guarantee you that many of these projects maintain rigid standards for test compliance and overall expected quality.

Furthermore, open source software gives people the opportunity to become teachers. Over time, as we contribute more and more to a given platform, we can earn the title of SME (subject matter expert). As an SME, you have the distinct privilege of helping to form the standards that shape a code repository. Imagine the bragging rights (and recruiters) you’d get if you could legitimately post on your resume “Helped shape the coding standard for AngularJS.”

Protect Project Culture at All Costs

Respect Expectations Regarding Licensing

Every project in the open source community uses a slightly different license pattern. All of them expect you to allow your code to freely enter the universe with no strings attached and no alimony payments due. Make sure you willingly live up to that expectation, because open source means open to the world.

Continuous Integration Testing Saves Massive Headaches

The contribution I made to SASS did not appropriately utilize the continuous integration tool suite that the team built to protect the project’s quality. Because of this, one of the projects leads rejected my pull request, and created his own based on my suggestion. I see two ways to react to this:

  1. Throw a hissy fit about not having my code included in the project.
  2. Be flattered that my pull request inspired a code change that goes into the next stable release.

Hopefully, the right approach is easy to see. If it’s not, I’ll give you a hint. It’s an even number. :-)

There’s No Such Thing As Too Small

My first pull request ever submitted to anything fixed a pluralization typo. In the documentation, I changed the word “filter” to the word “filters.”.  I did this because, whenever I tried to run the code with the parameter set as “filter,” it failed to execute properly. As soon as I added the rogue “s” to the end, the code functioned as expected.

Even though all I added was a very trivial documentation change, because it went into a critical section of documentation about how to use the code, I still feel like the contribution will help many others in the future not have to scratch their heads and wonder why their code failed.

Closeup of a man using computer. His shirt and tie in background.

You Get What You Give (and Then Some)

Guess how much money I got paid for contributing to MariaDB? $0. And for my inspiration in contributing to SASS? Infinity times more. Yep, $0.

Open source contributions have no explicit literal, hard earned cash value. However, the implicit value contained in the opportunity to contribute to open source vastly outweighs any literal cash value you might gain by giving your time over to a project. Rather, I got paid in knowledge.

Here are some of the things I’ve already learned I need to learn more about:

  • Forking and merging patterns
  • Continuous integration test executing on pull requests
  • Pre-commit hooks
  • Markdown syntax
  • Writing code in Ruby (so I can be better at contributing to SASS)

And I’m sure I’ve forgotten a few other things that I needed to learn about, when the time required it—but I learned about them.

By watching patterns created by other teams for other projects, you get outside of your “developer’s box” and get to look into someone else’s box for a few minutes / hours / days.

Not only that, but you’ll also develop an interpersonal relationship with the owner of the box. Even though he didn’t accept my commit, the lead developer on SASS and I are now keeping in touch with each-other via Twitter. He also just so happens to be a pretty important fella over at LinkedIn.

Add that one to the list as yet another killer networking moment in my career.

Open Source Doesn’t Require Code Skills

So, maybe you think the open source movement sounds fantastic, but you’re really just a free software junkie and don’t care one lick about learning to write code? Cool—just keep in mind open source depends just as much on users as it does on coders.

If people don’t report bugs and make notes on how to reproduce them, or on ways to reproduce similar behaviors, engineers have no way of knowing how software gets used.

Also, software engineers SUCK at writing good end-user documentation. Heck, we suck at writing good documentation for ourselves and our peers.

Maybe you’re an English expert (unlike the guy writing this post), and you found some grammar or readability issues in the documentation for the software you’re using? That means you can also contribute!

Find a way to suggest an improvement. I promise you, your suggestions will be welcomed as long as you make them politely.

Some Examples of OSS (Open Source Software)

There’s a strong possibility that you use open source software and don’t even realize it. As a very small, incomplete list, here’s a few of my personal favorites:

I promise you, within these projects exist more undiscovered bugs, potential improvements, and documentation flaws. Therefore, even if you don’t want to learn how to write inside of an IDE, you can still find ways to take part in the open source way of life.

popular-open-source-software

Open Source – Open Your World

Contributions to open source really bring amazing things to developers, if for no other reason than pushing the button on a pull request gives a really awesome buzz (one that I doubt anyone can replicate with chemistry experiments).

Whether you find a bug, or find a way to write code to fix a bug, it really helps you to find new approaches to the way you write software—and to meet other people like you.

I, for one, have the open source bug. While my limited time off of parenthood and my engineering job doesn’t afford me too many chances to push the “commit” button, you’d better believe that I’m looking forward to the next time I can.

I’d love to hear more about your experiences with the open source movement in our comments section. So far, everything I’ve dealt with has been positive, but I don’t doubt that at least a few aren’t so friendly—and counterpoint definitely helps round out the conversation about something like this. So give me a comment, and I’ll give you an open (source) mind.

About the author

    Jason Lowenthal

    Jason Lowenthal is an Architectural Software Engineer based in Springfield, MO. A graduate from Drury University, his past work includes stints with Bass Pro Shops, O’Reilly Automotive Inc. and Paperwise. When not contributing his time and talents to his employer, Asynchrony, Jason spends his free time raising his 3 girls, and learning about new technology. You can link up with him on Twitter, too: @lowenthal_jason