The concept of open source has been around for decades, but platforms like GitHub have accelerated the growth of open source initiatives. Most of us can't imagine a world without open source software.
Open source software can be a powerful instrument to promote yourself as a developer. Many respected developers in the Cocoa and Swift communities have gained name and fame through their open source projects, think Eloy Durán, Mattt Thompson, and Ole Begemann.
Start Small
If you're new to open source, then I don't recommend diving in head first. Start small. I'm sure there are several open source projects you make use of in your own projects. A good place to start is to explore the documentation of these projects. That's right. The documentation.
You'd be surprised by the number of open source projects that have outdated documentation. This isn't surprising since it requires a lot of work to maintain an open source project. Because you're already familiar with the project, you can browse the documentation and fix any issues you find on your path, including typos and grammatical issues. While this may seem nitpicky, the author of the project will thank you for it.
Clone the project, make the changes, and submit a pull request. Make sure you read the guidelines for contributing to the project first. Many projects have a code of conduct to make contributions easier and reduce friction.
Taking the Plunge
You may already have a library or project you want to share with the community. Sharing something with the world can be scary, though. Make sure you've cleaned up the project and don't share any personal or confidential information. When you share a repository with the world, you give everyone access to its history.
For example, if you committed a private key or token at some point and removed it later, then anyone with access to the repository can retrace your steps and access that information. Remove the project history if you want to play it safe. Once the information is public, there's no way back.
Documentation
Most of us don't spend much time documenting personal or internal projects. That's a decision everyone needs to make for themselves. An open source project without documentation, however, won't get much traction. Not only is it difficult for anyone interested in your project to get up to speed, it's not a healthy sign.
Every time I look for a third party library to include in a project, I immediately discard repositories without a proper README. It only takes a few minutes to create a README and an additional hour to create an installation and getting started guide. Not only does your project look more appealing, you help anyone interested in your project.
You can take it one step further and add a sample application that shows developers how to use your library. Anyone new to your library can play with the bundled application and see for themselves how to use your library and integrate it into a project.
Taking It Seriously
The commitment of some developers is admirable. They cover their project with unit tests, set up continuous integration, and write pages and pages of documentation. This is usually a community effort and that's what's wonderful about open source software. Once your project gains traction, developers automatically start giving back with small, or large, contributions.
These contributions are very welcome, especially if you have limited time to spend on your open source project. If you're a freelancer or an independent developer, then it can be a breath of fresh air to collaborate with other developers on a project. That's a bonus you get for free.
Giving Up Control
For some developers, the hardest part of open sourcing a project is giving up some of the control they have over the project. You can decide to manage everything yourself, but that isn't feasible if your project becomes popular. It also goes against the spirit of open source software.
To avoid that your project becomes messy and an odd collection of coding styles, you should adopt and enforce a style guide. This isn't difficult to implement. When I submitted my first pull request to the CocoaPods project, I immediately received automated feedback about the coding style I was using. I took a look at the project's style guide, made a few changes, and submitted an update. Having a style guide that's automatically enforced helps to keep your project consistent and it keeps the maintainer(s) sane.
Taking Responsibility
One of the most challenging aspects of an open source project is keeping it up to date. It takes time and effort to keep your projects up to date. Automation can make this much easier. Know that several hosted continuous integration solutions offer a free tier for open source projects. If you're serious about your project, then that may be worth looking at.
And remember that you don't need to do everything yourself. For Cocoacasts, I create many, many projects for the tutorials I write and record. It's challenging to keep them up to date. If a reader notifies me that a project hasn't been updated for the latest version of Swift or Xcode, then I suggest that they submit a pull request. That's not unreasonable. Is it?
Open source is a community effort and everyone involved in a project should take responsibility.
