Coming from, say, an enterprise-level Microsoft .NET shop and crossing over into the world of open source is like stepping out of an office building into the street during a parade. Clowns and bands and floats roll by as you tighten up your necktie and try to remain distinguished. But you know you really want to join the folks pulling the giant Batman float.
You’ll be entering a world of languages such as Ruby, Python and even something called Go (which is rapidly rising in popularity). There are projects with names that are meaningless, obscure or quite “punny” (e.g. gophercloud, which is — oh boy — “Go” for “Cloud”). There is a NoSQL database (SQL Server DBA: “Huh?”) called CouchDB and a testing tool called Cucumber. Coming from a world of Visual Studio and SQL Server, these names just seem weird.
That’s okay. Open source software attracts a lot of “coding cowboys,” those who prefer to go out and do something on their own, stand out from the crowd and embrace creativity and the occasional Nerf gunfight. They’re not in it for the money, they’re in it to do something.
Open source software (OSS) is defined in Wikipedia as “computer software with its source code made available and licensed with a license in which the copyright holder provides the rights to study, change and distribute the software at no cost to anyone for any purpose.”
Many use the term “open source” in reference to a specific licensing model of OSS, that of free and open source software (FOSS). FOSS allows the user to not only use the software, but also make changes, submit changes to be included and use the software in or for a commercial product.
Let’s take OpenStack, for example.
OpenStack is an open source project that provides APIs to allow a developer to work with cloud computing networks. It is sometimes referred to as a “cloud operating system”.
For .NET developers, the OpenStack SDK for Microsoft .NET allows you to use your C# or VB (or, really, any other .NET language) skills within the Microsoft .NET development stack to control the cloud. Create virtual servers, upload files, create a network to deliver those files … all the cloud goodness we know and love.
But what if that’s not enough for you? What if you want to actually help create or improve the SDK? In that case, welcome to open source development.
Let’s say you are using the OpenStack .NET SDK and you want to improve it. Maybe fix a defect, add a feature, improve performance, what-have-you. How do you do this?
You create a Git account, fork the SDK to your account, clone the forked code to your local machine, make the change, test it, debug it, make sure it works, test again (and again and again…) then submit the code with a pull request.
Let’s break that down.
Git is the standard distributed version control system that is used by practically all open source projects. Visit GitHub and you’ll find nearly eight million (and counting) projects. Microsoft’s Team Foundation Server supports Git. There’s a Git client, including a Bash shell for Windows. If you’re experienced enough (nice way of saying “older”) or are working in a, shall we say “vintage” shop, you might be familiar with Visual SourceSafe. To keep it simple, Git is the open source version; it’s where you store your source code.
(It’s not exactly, of course, but that’s for another blog post)
To keep it very simple, think of a fork as your copy. There’s more to it with forks and branches and merges, but, again, that’s another blog post. When you fork (a verb) the project, you’re getting a copy for yourself. You can do whatever you want. You can customize for your particular situation if you want.
Typically, you’re forking a project because you have something to add to the effort.
This is where the magic happens. This is where you become the coding all-star in your organization.
“My pull request was accepted!”
Keeping it simple, think of a pull request as the action where you submit your code to the project to be included. In other words, think of it this way: you’re asking that your code be pulled into the project and made a part of the project.
Your code will be reviewed — park your ego at the door for this part — and if it passes the criteria (Does it work? Does it meet the style for this project or language? Is it worth doing? Et cetera…), it will be accepted as part of the project.
Congratulations! You’ve just contributed code to an open source project. Your code might be running on millions of machines around the world. That’s pretty cool.
Yes. It can really be that easy to get involved in an open source project.
In fact, if you want to contribute in a big way and don’t have the technical skills, submit something that every project you’ve ever worked on could use more of: documentation. Submit good documentation and you’ll not only immediately contribute an oft-needed part, but you’ll learn as much as possible as quickly as possible.
There’s more, of course, including code reviews and “who decides what gets accepted?” and on and on. Open source is a parade of opportunity into which you can involve yourself at your own liking or pace. But if you like to code or write, and want to improve a project, open source presents a huge window of opportunity.
Find a project. Ask questions. Write some docs, fix a defect, improve a project.
After all, somebody has to pull the Batman float.