How to develop a successful IT project on GitHub?

In this article, our experts have prepared recommendations on how to create a successful IT-project on GitHub.

The components of quality Open Source project

1. Documentation

The documentation in GitHub is kind of manual in addition to the code. The more detailed it is written, the clearer third-party developer understands how to apply the solution. Thus, the more chances to get a Star, followers and "contributors. GitHub already has established guidelines on how to prepare the documentation properly.

2. Functionality

The code needs to solve a popular problem and, the important thing, — code should be reusable. For example, while creating our Android-library for Full Screen Image View, we took into account the mobile design trend, in this case — the accent on intuitive gestures. We had noticed that we were often faced with similar tasks in work. At the time there were no ready-made solutions in open source, that could match our request. It turned out — we were not the only one, who needed such solution, and the library became popular.

3. A number of bugs

Flawless code without bugs — a client’s dream and a nightmare of a QC specialist. In real life, 100% perfect code does not exist (at least, we’ve never seen it). If there’s a will, at least one bug will always be found. Still, the less number of bugs in your code, the higher chances to gain your audience. By the way, large companies, that are also on GitHub, will be grateful, if you find a bug in their products. Google, Facebook, Mozilla can even pay you a cash reward.

4. The quality of a code

The quality code can be characterized by the following parameters:

1. The code should be written so, that in the future it can be easy to maintain and extend.
2. The code should match accepted standards within the programming language.
3. The code should be readable, structured. It is advisable to use existing design patterns because they describe solutions to some common situations encountered by the developers. If there are third-party libraries that fully meet your needs, it is better to use them than to reinvent the wheel.
4. The quality code is tested, i.e. it can be trusted. If the functionality of application’s interface can be tested manually, the raw code is usually covered with unit tests (they look like a code, just checking the work of individual program’s pieces). In ideal, of course, to have 100% test coverage — it will protect your code from unexpected bugs during changes, but if the price of 100% code coverage is too high, it would be good to have test coverage at least on the key business logic.
5. Also, when writing code, you should remember the DRY and KISS principles, they will help to make your code better.

A few words in favor of Continuous integration

Most of the code quality checks can be automated. Different programming languages have their own utility formatting standards, code duplication, complexity, forbidden constructions, etc. There are Also libraries for unit tests that simplify tests writing. Quality open source projects are configured with CI (Continuous integration) servers. Their work includes automatic runs all prescribed checks during every pull-request. If a pull request does not pass some verification, the user who sent it, may consider the reason and correct it in order to match the requirements of the repository. One of the most popular CI servers is TravisCI, you can connect it to your public repository for free.

5. Active support

If you post a new solution, be ready to get an active response from others. They might look for bugs, suggest changes or just monitor the project. A good rule is to respond to users activity. Project’s support, prompt critical errors’ correction and, of course, openness to change — keys to success. Developing new versions of the project is also a big plus in your penny bank.

6. License

Open Source — is open software. Speaking very broadly, all programs and materials, available on Github can be used for free, with a small caveat — if the license allows. Depending on the willingness to share and open up to the world, on GitHub you can choose a license type with a particular access, for example:

• The Unlicense — license without conditions, the open source basis, when the code is public domain. Such project will be available for operations, modifications and additions for everyone without exception;
• MIT — users can freely use the code and make suggestions, however, to respect the copyright is obliged. Such license use jQuery, .NET, Core and Rails;
• Apache 2.0 — in addition to the MIT, the license provides an express grant of patent rights. This license is used by Android, Apache and Swift.

There are also projects with a closed license — access to the data, in this case, have only a certain participants. The license for your project, you can pick up here.

Who you should sign up on GitHub, depending on your technology

Android

JakeWharton — an open source king in Android

dmytrodanylyk — GDE from Ukraine, developer of various popular Android libraries

googlesamples — examples of Google API usage

square, facebook — Leading companies who share their experience

Symfony/PHP

fabpot — Symfony's author

rlerdorf — PHP creator

sebastianbergmann — the author of PhpUnit-library

Seldaek — creator of Composer and various other libraries

javiereguiluz — one of active Symfony's contributors

Front end

AngularClass/awesome-angular — a list of Angular4 libraries

vuejs/awesome-vue — a list of libraries for Vue

yyx990803 — creator of Vue.js

addyosmani — Addy Osmani a very cool engeneer from Google

Current ranking of repositories by language (number of stars)

JavaScript

PHP

Java

On the above links you can always find the latest data about the current repositories of technologies, that you are interested in.

Latest company updates you can watch here. Successful projects to you!