Maintaining a Growing Open Source Project

Posted by Andrea Bizzotto on February 25, 2017
Read Time: 5 min

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 really great material. In particular, I recommend the Best Practices for Maintainers section.

2. Scaling Open Source Communities

Felix Krause talks about the four stages of open source projects in this super-detailed 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 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.

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.

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 a pain point 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. 😅

Wrapping up

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 iOS open source libraries that will dominate 2017

How has your experience been with open source? Let me know in the comments. 🙂

If you liked this post, you can share it with your followers or follow me on Twitter!

Want to receive updates and new stories from my blog? Please subscribe to my mailing list.

* indicates required