As you all know, Swift just went OpenSource earlier this week. Thatâs huge news for the community, and there have been plenty of posts about that already explaining what a game changer that is.
And now for something completely differentâ˘, today Iâll take this opportunity to talk about my own experience with OpenSource and how contributing to OSS can be very enlighting for everybody.
Introduction: The big deal with Swift OSS
So the big news of this week is obviously Swift now being OpenSource. Apple went way further that anyone expected there, releasing the full GIT history of Swift source, but also the source of other tools like lldb and the REPL, revealing they are working on a Swift Package Manager, and making everything to build a better community!
Thatâs a very welcomed move from Apple and even if they announced at the WWDCâ15 that this were coming, Iâm almost certain that nobody expected it to be that huge, and that well done and handled.
But whatâs all this fuzz about OpenSource, why is it so great? Instead of talking about what Swift being OpenSource can bring to all of us â there is already plenty of blog posts on the net about that â let me tell you my story with OpenSource and how it changed my way of thinking. Hopefully youâll get why I love it so much!
Hello GitHub
So, my first experience with OpenSource was just writing some iOS libraries and publishing some code on GitHub, probably like a lot of you already. At first, I didnât really think âIâm doing OpenSourceâ, but just âhey, I have written some nice code, letâs push it on GitHub because thatâs nice and easy to shareâ.
A lot of my first projects on GitHub were actually just tests, like little toy projects I wrote to experiment new concepts or new libraries. Iâm super curious and love to experiment new frameworks or design patterns or ideas, so I was only playing around.
Then came my first real libraries that I put on GitHub to really share with others. I think my first pods were OHAlertView and OHActionSheet. But then came OHHTTPStubs.
Share some love
So here is how it all started for me: after reading a blog post about NSURLProtocol I wanted once again to toy around and see how we could generalize the idea by making it customizable. By the time I wrote the first lines of that GitHub project, that was still a Proof of Concept. But then I improved it, transforming it into a stand-alone component⌠and people began to star the GitHub repository đ
I really didnât see the success of OHHTTPStubs coming, and that brought me a nice feeling and some confidence. Seeing that repository becoming more and more popular was heartwarming, realizing that this code helped people and that they actually use it in their projects made me very happy. That was not just a toy project anymore, I was helping the community.
By doing OpenSource projects and releasing your libs to the community, youâre receiving love in return â¤ď¸. And thatâs what matters the most.
The thing to remember here is: donât do OpenSource projects just to be the popular kid. Do OpenSource projects because itâs nice and rewarding to share with others. With OHHTTPStubs being OpenSource and becoming popular, I gain the joy of knowing my work was used by others, but also contributions from other people that helped a lot improving the library code and its feature. Teamwork is really great!
Donât be afraid to contribute
After a while, I wanted to give back to the community. As I used CocoaPods a lot in my development projects, I wanted to help on that front.
I canât find back the first Pull Request I did on CocoaPods, but I remember quite well that at that time I was not really confident because:
- CocoaPods seems like a huge project and I was kinda lost in it, and didnât know where to start
- I didnât know how to do Ruby at all. I was thinking that my code would probably look ridiculous compared to the Grand Masters working on CocoaPods
So what I did is I started small, with Pull Requests about documentation typos, and helping improve the Guides using my experience as a CocoaPods user, to give feedback and avoid other people to have the same issues that I had when I first started using CocoaPods. It didnât seem much, but at least I was helping.
Every little helps. And even sometimes helps a lot. Even Pull Requests on documentation and guides are important. đ
As Chris Lattner says himself:
My first steps in a foreign code and language
Back after I first contributed to CocoaPods, it was time for me to try and fix some small bugs that affected me in the CocoaPods code base. Even not knowing how to code in Ruby, I started making small fixes in the CocoaPods source code. Ruby is very easy to understand and read (as easy as Swift) so changing bits in existing code was simple enough, even if I was scared of breaking everything.
Those first contributions were very welcomed by the team. Seriously. The CocoaPods Team is really awesome and made me feel welcome even if I wasnât totally confident at first about the modifications I did in their code.
But instead of telling me my code was not good, they told me how to improve my Ruby skills and how I could improve my code in better ways. They even helped me setting up my Ruby environment (as I had problems running the Unit Tests and understanding how this was organized at first)! It was very heartening and encouraging and made me want to do more.
When working on an OpenSource project, the community is very important. A welcoming community â that follows a nice code of conduct and helps newcomers â changes everything. Understanding that not everybody has the same skills as you but wants to improve is way better.
As a matter of fact, I literally learned to do Ruby by contributing to CocoaPods, learning along by doing Pull Requests.
All about people
One thing that can seem quite unsignificant but which is in fact quite important is also attribution. The simple fact that once I did my first Pull Requests on CocoaPods, I had my name added in the projectâs CHANGELOG was really nice.
It probably would have been nothing for any long time contributor on the project, but at that time as I was new as a CocoaPods contributor, having my name there was quite something, even if for a very little feature, it kinda made me proud.
Donât be afraid to ask questions and ask some help to long-time contributors. Sure theyâll take some time to help you and even if that takes time, this is not wasted time as it will make you improve, and contribute more. The more the merrier!
Time went by and I contributed more and more to CocoaPods, and at some point I was invited to join the Core Team, having even my name in CocoaPodsâs about page. That was quite another step for me!
Working on CocoaPods was also the occasion to meet awesome people and learning a lot from them, both in the virtual world via GitHub, Slack and all, but also IRL in conferences. Thatâs one really great way to talk with other developers from all around the world.
Being nice is nice
I think that being welcomed that way in the CocoaPods community helped me a lot doing much more OpenSource. The things I loved by working on CocoaPods is that they donât judge your skills and try to help instead of throwing you under the bus if you did something wrong, and they help you improve.
But participating in a community is sometimes hard. In GitHub everybody can create a new issue and make a Pull Request, but some people just open issues with harsh language like âthis doesnât work, your project sucksâ and this is not helping. I can understand that it can be frustrating when something doesnât work, but contributors have to keep in mind that:
- The OpenSource project is brought to you free of charge
- Itâs maintained by people taking on their own free time to write the code and improve it
- Time is not infinite and people working on OSS canât test every configuration out there, even if we try to cover as much as possible
- Being harsh doesnât help. Providing a way to reproduce the issue and explaining what you tried helps.
Orta would say, Being Nice is Nice. And thatâs also why Code of Conducts are important, to let people know how to be nice with people but more importantly that you are welcoming to everyone â as long as they are nice to each other.
And you know what? Thatâs also a way to participate in OpenSource and share some more â¤ď¸.
Opening descriptive issues on GitHub with ways to reproduce the problem is as important as writing Pull Requests in Open Source. Filing bugs or suggestions is also contributing, as long as itâs constructive.
Welcoming others
Once I was familiar with the CocoaPods project, I did also help newcomers to CocoaPods and tried to be as helpful as people were to me when I started.
But then I started having new projects of my own gaining popularity, like SwiftGen and Dip, and that now takes me quite some time (thatâs probably why I started spending less time on CocoaPods lately).
Thatâs also when I saw the other good side of OpenSource. To my surprise, Newsletters and Tweets started to talk about those projects quite quickly, and those projects also gained popularity quite fast, generating a lot of demand and issues submitting ideas to improve those. I wasnât able to keep up alone.
Thatâs when Ilya started to contribute a lot to Dip, adding a lot of Pull Requests that fixed bugs or add a lot of nice features, and I decided to give him Push Access to my repository.
That was the first time I gave someone I didnât know the push access to one of my public repositories. That might be frightening at first, because you never know if other people have the same idea as you about the project, if they wonât mess it up, or if they have other coding habits and a way of writing code that donât match yours, and more importantly you donât want them to break everything.
But I donât regret that decision at all, and given my background in OpenSource I actually didnât even hesitate much to give them push access. It felt really great to trust someone, and in the end Ilya is doing an amazing job and brings way more features in Dip that I ever wouldâve. And itâs always interesting to have a fresh perspective on your code and what youâre building!
Trusting people on your project is also important and very heartwarming. Youâll rarely be disappointed by trusting people in OSS as itâs all about sharing and helping each other.
Conclusion
- Open Source is wonderful
- Gives you opportunity to meet wonderful people
- Sharing is very gratifying
- Donât be ashamed by your skills or shy to participate on an OpenSource project
- Every little PR or issue counts, Documentations PRs and well documented issues with ways to reproduce are as important as code contributions.
- Nice things happen when being nice
- You should all do Open Source by Default
Well, now that Iâve talked about my experience in entering the OpenSource world, I hope I made you want to do more OpenSource and participate!
Of course Iâd welcome your contribution on one of my own OpenSource project, especially on SwiftGen where there is tons of great ideas to implement to improve the tool đ