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:
How I got 1000 ⭐️ on my GitHub Project
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.
1. GitHub Open Source Guide
This guide contains some great material. In particular, I recommend this section:
Best Practices for Maintainers.
2. Scaling Open Source Communities
Felix Krause talks about the four stages of open source projects in his very detailed Scaling Open Source Communities article. Summary:
- 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 last year, developers started opening issues and pull requests.
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 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 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 code 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.
Today
Some open source projects out there are managed far better than mine, and I know I still have a lot to do.
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.
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 February 25th, 2017, SwiftyStoreKit celebrates the 100K downloads milestone. This is in line with a significant increase in traffic:
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 it it.
- Unit test coverage can be further improved.
- Pull request etiquette should be formalised.
Luckily, I don’t expect new feature development to happen at breakneck speed. Most features in the original scope of the project are already implemented. But I’ll see if this prediction holds true. 😅
Wrapping up
Compared to other open source projects, SwiftyStoreKit has been growing slow and steady. This meant 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. 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 iOS open source libraries that will dominate 2017
Thanks for reading! 🙂
If you liked this post, you can share it with your followers or follow me on Twitter!