How I got 1000 ⭐️ on my GitHub Project
and lessons learned along the way
Update 2017–02–25: Read my follow up to this article about Maintaining a Growing Open Source Project.
I’ve been an iOS developer from 2012. Since then I started writing open source code, to stop re-inventing the wheel and to 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 in the same way that 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 save developers’ time, so that they can focus on creating great apps that are useful to others.
If I succeed, all the bug fixes, answered questions and unpaid time I put into this will be worth it.
Writing open source software has leverage. My code can reach the end-users through multiple apps by enabling other developers to be more productive.
How much leverage?
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 and will make you stand out and land better jobs and clients.
So, how did I get all the ⭐️⭐️⭐️⭐️⭐️?
- 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 an essential monetisation tool that is increasing in popularity in the App Store.
Unfortunately, Apple’s Store Kit 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 missing and much needed, so SwiftyStoreKit was the right project.
2. Make it easy to use
While I have tried some other 3rd party IAP libraries in some of my apps, not a single one was as simple as I had hoped for.
I started building SwiftyStoreKit just as Apple released Swift 2, and could leverage closures, enumerations and the 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 when the callback returns.
I borrowed ideas and code designs from other popular open source projects and came up with something that I was happy with.
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 really well.
It should include badges so you can see at a glance the state 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 the appropriate branches or tags for the various 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 reading resources, a list of credits, and the license.
Very important: if multiple issues are opened to ask for usage clarifications, your README is not good enough. Answer the questions and improve accordingly.
Include a sample project
Providing a sample demo app goes a long way in helping other developers using your project.
If your project becomes popular, you will see the issues tab filling up with questions. Having a great README and sample project helps keeping the number of open questions under control.
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 in these lists:
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 really take off big time!
For me, it happened as 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: with great visibility follows a lot of interest in your project, so be prepared to keep up.
6. Bonus: Google Search
Another big source of organic traffic has been Google Search, as shown here:
In fact, searching for “Swift StoreKit” and “Swift In App Purchase” shows SwiftyStoreKit as the second and fourth result respectively:
I admit that 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.
That being said, if you plan a good SEO strategy for your project, the results can be great!
7. Keep growing
Once your project is popular, interesting things will happen:
- People will ask a lot of questions.
- People will open pull requests.
At some point a single contributor ported my whole project to macOS and added receipt verification support. I had no experience in either area, and it felt great to have someone helping making 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 in the interest of keeping your API clean and avoiding code bloat. This is especially true for SwiftyStoreKit as it aims to be a lightweight framework.
- For any pull requests that add useful functionality, don’t be afraid to request changes if they are necessary to keep the code and API clean and consistent.
- You can reject pull requests that are out of scope or if the project already covers their scope.
- Always be courteous to the contributors, and if you reject their changes, politely explain why. Don’t be like Linus Torvalds. 😆
Things I have learned
SwiftyStoreKit has been a great project that has pushed me into the maintainer role for the first time.
It forced me to increase my knowledge of the specific project domain, 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’m aware that at times I have not been able to answer questions about my project on time. I hope to be able 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 unit test coverage, as I need confidence in making changes. Really, I should have done this a long time ago.
- Add code linting.
I’m right at the point where SwiftyStoreKit isn’t large enough to become burdensome to manage. I want this and my other projects to flourish and welcome contributions from the community.
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.
Writing open source software can be a very rewarding experience that makes you grow along with your projects.
I have helped teams in various companies as a developer for over 10 years and used a lot of open source software along the way.
I feel that writing open source code is a great way of giving back to the great community we have and I deeply enjoy the process.
Here’s to making the world better, one line of code at a time!
If you liked this, click the 💚 below so other people will see this here on Medium. It really means a lot to me!