How I got 1,000 stars on my GitHub Project, and the lessons learned along the way
I’ve been an iOS developer since 2012. I started writing open source code, to stop re-inventing the wheel and carry over my best code across projects.
While some of my early projects had gathered some interest from the community, none of them took off like SwiftyStoreKit did.
Before I share the secret sauce that made this possible, let me say one thing:
I want my code to have an impact in the world.
I want my code to empower developers, so that they can focus on creating great apps.
If I succeed, all the bug fixes, answered questions and unpaid time I put in will be worth it.
Open source software has leverage. My code reaches end-users via multiple apps, and enables fellow developers to be more productive.
How much leverage?
According to the Cocoapods Metrics API, SwiftyStoreKit has been downloaded 42302 times and installed into 1194 apps as of October 20th, 2016.
For context, AFNetworking (one of the top iOS projects) has been downloaded 21,659,973 times and installed into 413,742 apps.
But enough bragging now. 😇
My point is that you can do this too.
- Stay on top of your game.
- Write your own code and open source it, or contribute to existing projects.
- You will grow as a developer and you can really help and benefit others.
- Doing this is great for your CV. It will make you stand out and land better jobs and clients.
So, how did I get all the ⭐️⭐️⭐️⭐️⭐️?
My recipe
- Choose the right project
- Make it easy to use
- Write the best README you can
- Share in the right places
- GitHub Trending
- Google Search
- Keep growing
Let’s look at these points in detail.
1. Choose the right project
How do you choose? A good way to start is to solve a problem you have. In my case, I needed an in-app purchase (IAP) framework for one of my apps.
IAPs are a very popular way of monetising your apps in the App Store.
Unfortunately, Apple’s StoreKit framework is not exactly the easiest thing to work with:
- Many native APIs to learn, mostly designed in the era of Objective-C.
- Various types of in app purchases.
- Security considerations are very important.
- Testing that your purchase flows are correct is hard.
A lightweight IAP framework to make things easier was sorely needed, so SwiftyStoreKit was the right project.
2. Make it easy to use
While I have tried some other 3rd party IAP libraries before, not a single one was as simple as I had hoped for.
I started building SwiftyStoreKit when Apple released Swift 2. I did leverage closures, enumerations and the new error handling features of the language to write a clean and easy to use API.
With SwiftyStoreKit, you no longer need to explicitly register an observer to the payment operation queue. You just call an asynchronous method for your IAP, and update your application state and UI on completion.
I borrowed ideas and code patterns from other popular open source projects. And I was happy with the results.
3. Write the best README you can
Your README is the landing page of your project. You should spend a lot of time on it.
It should look good! If you’re building a UI control, include an animated gif, screenshots, or even a link to a prototype. Swift Messages does this very well.
It should include badges so you can quickly glance at the status of the project. A lot of projects use shields.io. So should you.
The README should highlight:
- What is the feature set and how to use the project by clearly documenting the API.
- How to install it. Note: Do support as many dependency management tools as possible, not just Cocoapods.
- Supported platforms. You guessed it, as many as you can.
- Supported languages, with links to appropriate branches or tags for different language versions.
- List of known issues (optional). This can serve as a summary of the current issues in the project.
Additionally, you can add a FAQ section, references to related projects and resources, a list of credits, and the license.
Very important: if your users open lots of issues asking for clarifications, your README is not good enough. Answer the questions and improve it accordingly.
Include a sample demo. This helps others using your project. It serves as a reference implementation, and shows how to integrate your code inside a real app.
4. Share in the right places
Some GitHub users maintain lists of popular open source projects by platform or language. I have submitted Pull Requests to include SwiftyStoreKit on Awesome iOS and Awesome Swift.
Don’t limit yourself to GitHub:
- Find websites that aggregate open source projects and submit yours to them.
- Have your project featured in popular newsletters for your language or platform.
- Share on social media with relevant developers and accounts. Some good outlets are Product Hunt, Hacker News, Twitter, Reddit.
5. GitHub Trending = Lots of ⭐️⭐️⭐️⭐️⭐️
If you make it to the GitHub Trending list, your project can take off big time!
For me, it was a surprise. A colleague at work told me SwiftyStoreKit was on the Swift weekly trending list on GitHub. From there, I started receiving up to 50 stars a day!
How to make it into the GitHub Trending list? Read this.
Note: Right project + great visibility = a lot of interest. Be prepared to keep up.
6. Google Search
Google Search has been a big source of organic traffic:
In fact, searching for “Swift StoreKit” and “Swift In App Purchase” shows SwiftyStoreKit as the second and fourth result respectively:
I have not done any keyword research to improve the SEO ranking of my project. It simply made to the top once it became popular.
Still, if you plan a good SEO strategy the results can be great!
7. Keep growing
Once your project is popular, people will ask a lot of questions and open pull requests.
At some point a single contributor ported SwiftyStoreKit to macOS and added receipt verification support. I had no experience in either area, and it felt great that someone was helping to make the project better!
Other valuable contributions followed after that, and I found myself wearing two hats: main developer and maintainer.
Being a good maintainer requires good judgement:
- Carefully evaluate feature requests. Aim to keep your API clean and avoid code bloat. This is especially true for SwiftyStoreKit as it is a lightweight framework.
- For any pull requests that add useful functionality, don’t be afraid to request changes to keep the code clean and consistent.
- You can decline pull requests that are out of scope or if the existing code already covers them.
- Always be courteous to the contributors. If you reject their changes, politely explain why. Don’t be like Linus Torvalds. 😆
Things I have learned
SwiftyStoreKit has been a great project, and pushed me into the maintainer role for the first time.
It forced me to increase my knowledge about in-app purchases, especially as other people made contributions.
This quote about stewardship feels appropriate here:
In reality, the biggest challenge to a business open sourcing a project is the obligation of stewardship. This responsibility is mostly a matter of working with people and needs to be managed correctly — especially if a project gains enough popularity. Most projects don’t get large enough for their stewardship to become burdensome. — Artsy Blog
I have not always been able to answer questions on time. I hope to do better in the future, and improve my process in various ways:
- Add a CONTRIBUTING file outlining the recommended way of opening issues and pull requests, as popular open source projects do.
- Add a Code of Conduct.
- Add code linting.
- Add unit test coverage, as I need confidence in making changes. Really, I should have done this a long time ago.
I’m right at the point where SwiftyStoreKit isn’t large enough to become burdensome to manage. I want this project to flourish, and welcome contributions from the community.
Credits
Disclosure: A while ago I discovered this great story by Richard Kim on Medium:
This opened my eyes about what makes an open source project stand out. I have been following his advice since then. It really has paid off and I would like to thank him for the insight.
Conclusion
Open sourcing can be a very rewarding experience, making you grow along with your projects.
I have helped teams in various companies for over 10 years, using a lot of open source software along the way.
Writing open source code is a great way of giving back to our great community, and I deeply enjoy the process.
Here’s to making the world better, one line of code at a time!
Update 2017–02–25: Read my follow up to this article about Maintaining a Growing Open Source Project.
About me: I’m a freelance iOS developer, juggling between contract work, open source, side projects and blogging.
I’m @biz84 on Twitter. You can also see my GitHub page. Feedback, tweets, funny gifs, all welcome! My favourite? Lots of 👏👏👏. Oh, and banana bread.
