| title |
|---|
Being a Good OSS Citizen |
Let's take a look at the day in the life of an open source citizen, me. I was given an issue that would allow suers to refine what kinds of sale artworks they were looking at, and it included this awesome slider so they could set min/max price ranges.
Nice.
But iOS doesn't have a slider like that built in, so I headed to CocoaPods.org to find something that would work for me. Searching for "range slider" yielded a bunch of results, and I looked through a three or four of them.
I picked this one because it did almost exactly what I needed, provided a reasonable level of customization, and had a history of development leading to a recent v1.0.
But I said it did "almost" exactly what I needed, which meant I'd have to modify it. At this point, a lot of developers either look for another solution or abandon the idea of using an existing library and invent one themselves. That's a shame, because it's almost always faster and easier to improve an existing library than it is to build your own.
So let's step through what I did to modify this library. First, I checked to see if there was an issue for my feature already opened on the repository; maybe someone else had tried this, and I could benefit from their experience. That wasn't the case, so I forked the library to my personal account and cloned my fork locally. Now I can modify the library's code. Next I add the library to my Podfile, but I'm clever about it.
pod 'MARKRangeSlider', :path => '../MARKRangeSlider'This tells CocoaPods that I'm working on the pod, and it's stored in a directory (where I cloned my fork). This makes it a "development pod", so the files in Xcode are actually the ones I've cloned locally. Any changes I make to the library while working on my app can be easily committed and pushed up to my fork.
That's exactly what I did. I made my changes and pushed them to my fork, then pointed the Podfile to my version of the pod.
pod 'MARKRangeSlider', :git => 'https://github.com/ashfurrow/MARKRangeSlider.git'Nice. At this point, I continued on as a developer, running a pod install to install the forked library with my commits. I finished building the feature and PR'd it using my fork.
I could've stopped here, but that'd be a shame. Someone else might want the same changes I made, and I should submit them back. I opened a PR on the library to contribute my changes back, and I made sure to explain why my changes were necessary. Because our app is open source, I was even able to link to our PR to show the library author how their work was being used.
I woke up to find the PR merged, and after the author pushed an updated version of the library (including my changes), I updated the Podfile once more.
pod 'MARKRangeSlider'Then ran pod update MARKRangeSlider so it would update just that pod, and point to the new release. I re-ran the unit tests to make sure I hadn't broken anything, and PR'd the change.
This sounds like a lot, and having written it all out, it is. But it's a series of small steps, not big ones, and I've worked like this long enough so it's second-nature to me now.
I believe that using existing open source libraries is almost always better than writing your own, and I believe that improvements I make to open source ought to be shared. Those beliefs shape my behaviour as a developer, and as a person.
Making your first contribution to a project may seem scary, but we all start somewhere. It gets easier, and in time, you can become a paragon of open source citizenry.
yep