I’ve had five Trending projects so far (on Github Trending page), so I wanted to share some of my experiences and methods.

If you’ve ever open-source code, you know how hard it is to get people interested in your work. It’s weird, isn’t it? We spend at least hundreds of hours on this and give it away for free and no one is interested!! After a few lucky breaks, I slowly figured out how to get other people interested in my open source work. As shown below:

  

Eventually you want to get upvotes and stars from developers who use your Repo (open source project on Github). But first you need to get some plus stars, you are the purpose of this article.

First, LET me introduce myself. I’m primarily an iOS developer right now, and I started releasing my open source game about six months ago. So far, I’ve been on Github’s list of the world’s top iOS developers.



Actually, I’m not as good as Github makes me out to be (thankfully, don’t look down on me). I feel like I have some influence in the open source community because I also do some design work (as you’ll see). Here are some of my popular projects:

All five of these projects have made it to popular Github pages, and I’ve broken it down into six steps.

Six steps (the key tips are steps 4 to 6)

In order to be brief, steps one to three will be briefly discussed, and steps four to six will be explained in detail.

  • The project is the most important thing
  • Reading and Research
  • Open project warehouse
  • Write the Readme
  • Deserve to flush
  • Focus on feedback loops

The project is the most important thing

A Repo is the product you are building as a developer. As a product, it has to solve users’ problems. You’ve probably heard a lot about famous products that were created when the founders had a problem they needed to solve. In the same vein, most open-source code is designed to solve developers’ problems. So, how do you get problems that need to be solved if you don’t always create something new

Twindr (Twitter+Tinder) is a silly business project I do for the simple reason of making my friends and myself laugh. But in the end it brings up RKCardView (500+ plus stars)

So work on business projects, attend hackathons, and spend the weekend fooling around with your coworkers. Find out what code you’re repeating so you can build something modular that others will need too

Reading and Research

Most of the problems have been solved millions of times and will continue to be solved.

Every time you think of something that could be made into an open source Repo, see if someone else has done something similar. If it really exists, a lot of people have been using it, that it is not bad, so pick it up and don’t do it yourself.

If it hasn’t been solved, or if it hasn’t been solved gracefully, start your research. Look at existing plans and find out why you don’t like them. I like to browse Githu Issues of existing projects for inspiration on how to build my own similar solutions. If I had enough time, I would personally use these projects to write down any problems (or problems with documentation) THAT I encountered, although I haven’t done it myself, I’ve just heard about it and think it’s a really good idea.

Finally, start looking at their existing code. For example, I like SVProgressHUB. In particular, I like the fact that it can be invoked with a single line of code without creating and maintaining objects. I ended up implementing RKDropdwonAlert in a similar way.

Open project warehouse

Say it five times quickly: “Simple, straightforward, usable!”

I realized that my latest project was getting some attention and stars faster than my previous projects. Maybe it’s because more people know me (I feel very famous hahaha), but I think it’s because I’m getting lazy. When I first started writing open source projects, I would write lots and lots of code for less obvious optimizations, which I thought were important and interesting. But now I build something elegant and usable, and spend a lot of time cleaning up interfaces/interfaces.



Top left corner of RKNotificationHub burger menu button.

Let’s take the RKNotificationHub (RKNH) as an example.

I first envisioned RKNN when I wanted to add something to the menu button of my project, because I thought it would be nice to entice users to check out the new feature. It worked really well, and I continued to use it in other projects.

Initially, I envisioned the Repo supporting a large back-end, all-purpose notification system. Links to things like set, array, Dictionary, API hit, APN, etc., update it every time the value changes.

But in the end, I was able to implement simple UI logic, leaving the specific business logic to the user to implement and give them more fine-grained control. Why is that? Because I’m getting lazy, but I think it also has its advantages: it’s simple, lightweight and straightforward enough to use.

The bottom line is: if no one knows how to use your code, no one will use it.

Write the Readme

The Readme (Github allows you to create this file and use markdown syntax to display relevant content on your project’s home page) is the most important part of your entire project.

If you could only learn one thing from this article, I think it would be:

Spend as much time writing your README as you spend coding.

I mean it! In fact, I think a big part of my Github success comes from carefully designing my README to make it more aestheticized (and proving that I’m just another programmer).

Here’s how I laid out my README file:



Some key points are:

  • It’s the difference between whether most people stay or leave. Make it better so developers will star it before they leave. The more stars you get, the more people believe in your project.
  • Pictures, pictures, pictures! Use something like LICEcap to create GIFs. If they are animations, store the created images in your Imgur account.
  • Show, not talk. Instead of saying how it solves problems gracefully in words, show it in a GIF. It’s way better than blah blah blah. Show them code examples.
  • You have TO have a how-to section. The user won’t read through your code, so you’ll have to write examples for him.
  • Use images to aid your code examples to better illustrate them
  • If someone makes an issue, resolve it as soon as possible. If someone asks the same question more than once, consider whether to write it to the README.

Deserve to flush

Pictures are better than text.

You really need good code in a Repo. But I bet if I drew some nice pictures and left the code alone I could still get 60% of my current bonus. There’s good technology, and then there’s good design (wherever tech goes, design eventually follow). Consumer hardware, apps, websites, landing pages and more all illustrate this trend. Technology We are targeting Github viewers, not just developers.

Here are some key points to consider when making diagrams. I’ll use the RKNK diagram as an example.

Think about how to communicate the purpose of your Repo.

You want them to understand why the Repo works. RKNK created a simple notification icon, so I decided to use Facebook’s notification center as the center image.

Pay attention to space

 

There’s a specific short link in the title section at the top, and my Twitter at the end. Then cut the middle part in two.

The figure on the left shows how to use RKNH. It’s centered (with a lot of white space), and most people read it from left to right, so the left side carries the more dominant concept.

The image on the right is generally centered and left blank. If the left is about what the product is, the right is about why you need to use it. Animation is fascinating, so I wanted to show it.

End result:



Not only is this diagram a simple and effective way to start a good README, it’s also good to share.

Quick word on current tools. Most of my design work is done with Sketch3 (a very simple graphic design software), GIFs is recorded with LICEcap and edited in GIMP. They’re a little rough, but they’re the best free plan I’ve found so far

Focus on feedback loops

Iteration! Moving! Actionable metrics!

Now we have images and nice documented code. I’m going to show you how to play the whole wash through you. I will first introduce the mechanism of Github Trending Trending page.



This is the page you’re trying to get on.



The data is provided by Github, and the time window is not clear. I think it should be a week. That’s why. More than 90% of the page traffic and redirect comes from Github itself, most likely from the Trending Trending Trending charts page.

Thousands of developers go to Github’s popular page to see what’s trending in the development community. What’s even better is that all of these people have Github accounts and are logged in. If you love getting Github plus stars, these are the best sources.

The algorithm for popular pages is also simple: it looks at the number of times they are starred in a given period of time. This is true for the day and the week.

Feedback loop is the method I use to get more audience involved (reply and iterate on their suggestions as soon as possible). This was inspired by The Lean Startup and how I got my first 30 stars.

The feedback loop looks like this:

  • Post links with images (much more effective than just Github)
  • Get feedback within minutes
  • Respond to feedback in a timely manner
  • Repeat two or three times until the initial transmission is complete

Because of the previous incident, I am not very fond of and wary of promoting my own things in my personal social network. So apart from this post, you rarely see my status on Facebook. For me, Reddit is a great place to get anonymous feedback (because those people also like to learn and accept new things). It really is a good environment to be positive and boost your confidence.

Of course, you don’t have to choose Reddit as your main platform. I just think it suits me. You might prefer Product Hunt, Twitter, Facebook, colleagues, local computer science user groups like hackathons, etc. Make sure to remember these principles:

  • If your work is crap, the feedback probably is too
  • If your document is crap, what good is the feedback
  • If you have to argue with people who take the time to give you their advice, you will almost certainly lose their follow-up

If we look at the screenshot from the source site above, we can see that Reddit brought me 58 people, so I need to get the first 30 plus stars from those 58 people. This is where our previous work (such as project documentation README and illustration) comes in, so work extra hard to get the initial bonus star.

If I have a moment of doubt, I always turn to some of my developer friends. They all help me out, so keep an eye on them.

conclusion

Thanks to those of you who have read so far, I hope you will get what you want soon, but remember that this is not a one-size-fits-all magic. You still need to do your job, which may take hundreds of hours. I’m not exaggerating (when I say there should be a 1:1 ratio between coding and writing documentation), but the more complex and large the project, the more clear and understandable the documentation needs to be.

You may get hundreds of plus stars for the little things you write, but if you really make an impact, you need to make big projects. I personally will continue to spend the next few months maintaining existing open source projects and trying to understand what developers are using my Repo for. Building is fun, but fixing problems is just as important.