Maintaining a Growing Open Source Project
The best part is the journey
In 2015 I open sourced a small Swift framework called SwiftyStoreKit.
The goal: make in-app purchases simple on iOS.
I have written about my experience with it before:
This is a follow up on how my journey is continuing and how this project is pushing me to become a better developer.
First of all, I want to share some great resources that gave me inspiration and many practical tips on how to grow my project.
GitHub Open Source Guide
This guide contains some really great material. In particular, I recommend this section:
Making your life easier as an open source maintainer, from documenting processes to leveraging your community.opensource.guide
Scaling Open Source Communities
- Stage 1: Putting source code on GitHub
- Stage 2: Developers start using your software
- Stage 3: Project is popular and the go-to solution in its field
- Stage 4: Hyper-scale open source projects
I can’t recommend this enough. Go read it.
And this one: Open Source at Artsy.
To the next level
When SwiftyStoreKit became popular sometime last year, developers starting opening issues and pull requests on the project.
Pressure was on
As the only maintainer, I felt some pressure due to a number of problems:
- The issues list was growing. Some of them underlined some flaws in specific areas of the project
- StoreKit is not a trivial framework to use and I didn’t understand some areas very well
- I was worried to introduce regressions when changing things
- I had no metrics on how often IAPs would fail and under which circumstances. Were my users losing sales? 1%, 5%, 10% of them? More?
- I could not effectively test my library in all the possible end-to-end configurations (iOS, macOS, tvOS, sandbox, production, iTunes downtime, account/IAP configuration issues etc)
Keeping things sane
I soon realised I had to do a few things:
- Read more about StoreKit and ensure my implementation was in line with Apple’s guidelines
- Get organised and respond more timely to issues and PRs
- Avoid feature creep and learn when to say no
- Add unit tests
- Standardise and streamline contributions — both mine and from other users
What I did
- Rewritten the purchase flows entirely with full unit test coverage
- Added a Travis CI job to run the build and the tests
- Added an ISSUE_TEMPLATE.md file to encourage reporters to include all relevant details. Big win
- Added a CONTRIBUTING.md file outlining the scope of the project, pull requests process, list of missing features
- Added SwiftLint to the project to standardise project contributions and make them easier to review and accept. Go check it out! 💯
- Adopted gitflow. This introduces a development branch where new feature work can be merged and tested before going to master
- Use feature branches by default for my own contributions. Makes it easier to track features and reference relevant issues
- Periodically spend a few hours reviewing all the issues and closing inactive ones
- Publish milestones to give more visibility on priority and timeframes for for planned future work
These changes were quick to implement, but improved the process considerably.
Still, with my changes I now feel more confident in driving things forward, and I’m enjoying the journey a lot more.
Nothing better than having confidence from unit tests, linting and a good process to grow a healthy project.
I also feel that SwiftyStoreKit is slowing becoming the go-to place for in-app purchases on iOS, which gives me renewed motivation to make it better. As I said before:
I want my code to have an impact in the world.
As of today, SwiftyStoreKit celebrates the 100K downloads milestone, in line with a significant increase in traffic in the most recent period:
As developers increasingly use SwiftyStoreKit in their apps in production, I need to ensure it is safe and reliable, and become even smarter about how to maintain it going forward.
- It is still hard to ensure the framework works correctly in all configurations
- I still have no metrics on how reliable the framework is
- Unit test coverage can still be greatly improved
- Pull request etiquette should be formalised
Luckily, I don’t expect new feature development to happen at breakneck speed as most features in the original scope of the project are already implemented. But I’ll see if this prediction holds true. 😅
Compared to other open source projects that have experienced wide adoption from the start, SwiftyStoreKit has been growing slow and steady. This was a blessing as I could keep things on course and improve my process along the way.
I’m getting better and better at managing software development in the open, and I can apply many of the things I’m learning on this journey to my other projects and client work.
- If you’re just getting started with open source, I hope this will inspire you to build and share some great stuff.
- If you already have a project and maintaining it seems like a chore, some of the tips above may turn it into an enjoyable and rewarding experience.
Who knows, maybe your project will make it to this list next year:
33 best pods for your everyday iOS programming needs in 2017. UI, networking, Core Data, analytics, unit/BDD testing…medium.com
How has your experience been with open source? Let me know in the comments. 🙂
If you liked this, click the 💚 below so other people will see this here on Medium.