How to become famous on GitHub
GitHub holds perhaps the largest collection of open source software on the planet. It’s an ecosystem of collaboration, learning, and integration for developers and organizations alike. You can write software, contribute to other software, or use free and open software in other projects and products. It’s an incredible tool that powers the world of programming, and promotes access and collaboration to produce open source software for everyone.
Using GitHub as a developer, to either further your career or increase your influence in a genre of open source is a bit different. Getting well known on GitHub isn’t straight forward, and requires a intricate understanding of what drives the use of open source packages, and what sets the most popular packages apart from the rest. I will discuss the best and worst ways to use GitHub as a developer, and how you might just create the next trending library or package on the site. No guarantees, but hopefully you will be inspired and guided in the right direction.
An Ecosystem
GitHub is quite an open and unrestricted platform. You can create repositories and pretty much use them for whatever you want. There’s even a lot of people using GitHub for computer science lesson plans. There’s also applications that integrate with repositories on GitHub, like Git Books. GitHub functions as an ecosystem of code encapsulated in repositories, in a similar way that social media sites function as an ecosystem of text, pictures, and interactions.
Any person or group of people using GitHub can usually be divided into two categories: consumers and producers. Consumers mainly use GitHub to use and integrate software on the site into their own applications. Producers write code for the intent of others consuming the code in repos that they publish on the site. While some people can certainly embody both categories, they usually lean toward one that’s a more common use pattern for them.
Understanding what kind of libraries and packages become highly used is tricky. The site contains types of packages that will more easily gain popularity, and types that likely won’t ever be used. The difference though, is not what you might think. Packages with rare use cases, but production quality code and interfacing, can readily become more popular than a package with a common use case, yet poor quality code. That will be discussed more later.
Another vital part of packages on GitHub is a packaging system. Most programming languages, come with some build or installation system for managing open source or third party packages. Any popular package, regardless of how intuitive or useful it may be, must be easily integrated into other projects. If there’s a large learning curve or barrier just to get to the point you can use a package, it’s likely not going to get very far at all.
Packaging is not the only component that can make a package easy to integrate though. Some packages, instead focus on tools rather than bundles of code. A great example of such a package is ripgrep. Ripgrep is a CLI tool that allows you to search files and directories for a regular expression pattern. Except, it aims to do so at an extremely fast speed, much faster then the typical grep that you probably already use. Ripgrep is written in rust, a cross-platform, natively compiled programming language. Normally, it’s a little difficult to ship cross platform binaries, as you either need to download a compiler to compile it from source, or ship a binary for each platform. With rust , that’s a little easier with crates system, that manages installing binaries as CLI tools on it’s own. You can in theory install ripgrep with just two terminal commands.
The Demand
Demand functions as a critical component of gaining notoriety on GitHub. A project or package can generally gain an initial amount of popularity for just being unique, interesting, or “cool”. This encompasses both completely esoteric projects, as well as projects that are functional but largely for leisure purposes. One example is on of my own endeavors , a language that compiles to an SVG graphic. My primary inspiration for this was my love of both art and programming. It initially gained some traction and popularity. Yet, the language was only written to make lines and filled line shapes. This may be fun for someone learning to code, but lacks the more sophisticated features of the SVG spec for stuff like transformations and animations. Thus, it never gained over a few hundred stars on the site.
Projects that gain in the thousands or tens of thousands of stars and users need a production applicable purpose, or a large developer community. The former category contains projects are more full featured software that often run on their own, such as databases like Redis , or search engines like Elastic. Such projects generally function as an independent component of a technology stack a company or organization uses, and does not require other packages to run. The ladder category contains projects that cannot directly be used in a production setting, but allow creation of full featured software that could be. Programming languages, machine learning or data science libraries, quality assurance and testing packages, all have large developer communities using their projects every single day. Many programming languages even hold yearly conferences where developers come and present their use cases for their work they have done with the language.
In order for you or your project to become famous on GitHub, you need to think what solves a problem or provides a solution that many people could use.
Be Realistic
You also have to be realistic in your project ideas, in terms of how long they will take to finish and if you even have the time to finish them. This is the main problem with “side” projects. People generally starts projects they can never finish. It’s unlikely you will have the time or patience to make your own operating system. If you choose to make your own project on GitHub, start small like with a library that simplifies some task, and move up and broader after you finish that.
Contribution vs Creation
One thing to consider in your time coding and developing on GitHub is whether or not you should contribute to existing projects, or create your own. It’s very likely regardless of which one you decide, you will end up doing some of both. It’s important to keep in mind a few tips here though, because you ultimately want to use your time wisely in a way that benefits you in the future:
- Don’t contribute to very small projects, unless you believe they have high potential to garner a large community. Early contributions to projects may be entirely rewritten or taken out later on due to project maturity or design changes.
- Don’t make line spacing or formatting improvements unless a project specifically calls for it. Such contributions may be rejected in larger projects as an attempt to get your name added to the contributor list while not contributing anything functionally to the project.
- Do make contributions that relate to code quality or code safety. These types of changes help improve the product functionally or make it more adverse to serious bugs like crashes or memory leaks.
- For large contributions to mature projects, try to get a sense of whether or not your contribution would be accepted or not. Significantly altering the design of an older project is unlikely to be approved or accepted. This is why smaller changes and improvements are generally preferred.
Beyond that, think carefully about your contributions, spend your time wisely, and you probably have a good chance at gaining some fame on GitHub.
Gain Access to Expert View — Subscribe to DDI Intel
