The State of the Octoverse: new open source projects in 2018

Top open source projects of 2018

This article is part of a series based on our 2018 State of the Octoverse report—trends and insights into GitHub activity, the open source community, and more from the GitHub Data Science Team.

In 2018 alone, we saw more new users than in our first six years combined, and we celebrated hosting over 100 million repositories. All of this growth is thanks to the open source community. Together, you’ve built and collaborated on a broad spectrum of projects, from hobbies to professional tools and across varying developer experience levels. As the year comes to a close, we wanted our final Octoverse report of 2018 to highlight some of your most active new open source projects of the year.

To look back at your projects, we pulled data from December 10, 2017 to December 9, 2018. We pulled the top projects open sourced in 2018 by the number of stars the project received in its first 28 days being public and by the number of unique contributors to the project in the first 28 days being public.

Top projects of 2018

The top projects open sourced in 2018 run the gamut from learning to code to tools for professionals, from side projects for fun to projects for getting work done.

For those new to code, or new to a coding language, you starred projects with coding examples, like trekhleb/javascript-algorithms and leonardomso/33-js-concepts, along with quick tutorials like 30-seconds/30-seconds-of-code.

You also contributed to projects for Hacktoberfest, adding Hello World programs in a variety of languages to Hacktoberfest-2018/Hello-world and Omkar-Ajnadkar/Hello-World, or even more complex algorithm examples to VAR-solutions/Algorithms.

You also had a lot of fun, starring and contributing to gaming projects like wangshub/wechat_jump_game, and had some laughs with projects like kelseyhightower/nocode. felixrieseberg/windows95 and Microsoft/MS-DOS sparked some nostalgia, quickly attracting your stars and contributions.

New open source projects also helped you get work done with tools like denoland/deno for developing in TypeScript, ValveSoftware/Proton for porting games to Linux, and facebookresearch/Detectron to support research in image recognition algorithms.

Based on stars

We pulled the top 10 projects open sourced in 2018 based on the total number of stars they accumulated in their first 28 days on GitHub.

Top contributors based on stars

Based on contributors

We pulled the top 10 projects open sourced in the 365 days prior to December 10, 2018 based on the total number of contributors to the project in their first 28 days on GitHub.

Top projects based on contributors

Top topics for new open source projects

These are the non-language topics that had the biggest increase in number of open source projects created in 2018 compared to 2017. Third on the list, dotnet shows that more open source projects are developing apps for Windows. In our programming languages post, JavaScript was the most popular language for new projects, and we see nodejs, react, and vue in the top topics for 2018—all tools for developing in JavaScript. Machine learning is also gaining momentum on GitHub with new open source projects tagged machine-learning.

  1. nodejs
  2. react
  3. dotnet
  4. docker
  5. android
  6. machine-learning
  7. api
  8. ios
  9. cli
  10. vue

Whether you’re here to do your job or tinker with new technologies, it’s exciting to see an environment where where new developers feel comfortable in code and experienced users have open source communities and projects to innovate. Cheers and congratulations to a year of new ideas emerging, knowledge gained, and continually changing the way we build and think about software development.

Stay tuned for more posts that dive in data on the GitHub Blog—or check out our reports on breaks and holidays and programming languages to see what a community of 31 million developers can accomplish in a year.

Introducing the new GitHub Status Site

Developers and teams expect business-critical services to be reliable. From our perspective, reliability can be defined by three questions: is the product available, how well does the product recover from failure, and how performant is the product as it evolves over time. In order for millions of developers to develop, build, and deploy their software, the underlying platform that powers GitHub must be resilient to a wide range of failure modes. We understand that our products need to satisfy the levels of trust our community expects of us when putting their code and their livelihoods on our platform. Today, we are pleased to announce the new GitHub Status Page.

Behind the Scenes

GitHub is built on a platform of distributed services, spread over multiple data centers across the globe. An incident can occur on any of one these platform tiers, affecting either a standalone service or a cluster of interrelated components. With that in mind, we needed a way to accurately communicate this level of granularity to our users and designed a new status page to provide this functionality.

Our new status site now lists the individual component statuses that make up our wider product. Now GitHub can communicate the statuses of components that matter most to our users, and users can subscribe to them. Git operations, for example, are now split out from API requests, and Pages builds can be tracked independently of Notifications. This makes our messaging during an incident more accurate and reliable.

A component list of all of the services that make up GitHub.

In addition to splitting out the component products on the status site, we’ve also focused on improving and organizing the information we provide to users during an incident. Our goal has been to change our workflow to improve our customer communication during an incident and to reduce friction for incident commanders.

To do this, we started by decoupling the idea of a component status update (e.g. Pages is experiencing degraded performance) from the lifecycle of an incident. The degraded performance of a component could be representative of a wider incident, but updating its status does not allow us to track and share mitigation steps and descriptive updates. In other words, status updates are snapshots in time of a specific component, and incidents are trackable communications between GitHub and customers.

Integrating the new status into your operations

One of the benefits of the new status site is the ability to subscribe to our status changes in multiple ways, such as email, SMS, or webhook delivery. These subscriptions can follow the entire lifecycle of an incident from investigation to remediation. For example, if you’re using Jenkins to run a Continuous Delivery pipeline and our Git operations experience a service slowdown, you could create a webhook to have your Jenkins system apply a backoff mechanism to prevent downstream errors.

A popover of all of the subscription options for consuming status state changes.

Deprecating the old status site

Over the next three months, we’ll continue to support our old status site, as well as its API. So you’ll have time to move any integrations over to the new site. Throughout February leading up to the deprecation, we will perform brownouts in an effort to help you identify systems that may be pointing at the deprecated site. At the end of February, we’ll be adding a redirect for web traffic to the new status page and fully shutting down the old API.

Testing out the new site

In addition to deprecating the old site, we will test the new one on our live systems. On December 18, 2018, we’ll be running a test of our new incident response workflow at 10:00 PST (18:00 UTC). Throughout this test, we will have an active incident that starts with "TEST". This test will not reflect the real status of our products, but will only serve as a way to test new tooling, processes, and the status site. Our component products will not be going through any disaster recovery processes. You will notice during that time that services may appear to be degraded via the status site but that won’t be the case. If you do find any issues or problems with the status site during this time, please reach out to us.

Reliability as a product feature

The new status site is the first of many public commitments we’ve made at GitHub to treat reliability and performance as a product feature. Doing so is a responsibility, not only of the engineers, but of our entire organization. This means that product managers and designers care about and prioritize reliability along with and against new features. Over the coming months, we’ll continue to build on this theme, so you can keep putting your trust and your software development workflows on GitHub.

Have feedback? Let us know what you think of the new status page.

Learning Lab: your new corporate trainer

GitHub Learning Lab is now available for Enterprise customers

Whether you have 100 developers or 100,000, onboarding new team members and sharing knowledge across the organization can be a challenge. At this year’s Universe, we announced GitHub Learning Lab for organizations to help solve this problem at a broader scale for our cloud customers.

We want to make it easier for developers to build their skills, without ever leaving GitHub. And now, with Learning Lab, teams of developers can onboard, train, and share knowledge across their organization, customized to their specific workflows. Since its launch, we’re happy to report that tens of thousands of developers have completed free, hands-on projects to build skills at their own pace.

We’ve been working with you to understand how we can help your teams onboard, train, and innovate faster. Many of you stated that you’d love to bring Learning Lab to your teams, but you need the learning to happen behind your firewall. As of today, Learning Lab for organizations is now available for our GitHub Enterprise customers, too.

We’re excited to see what Learning Lab can do to transform the way your developers learn and share knowledge at scale.

Get your team started on GitHub Learning Lab

Announcing the Content Attachments API

All of us share a lot of links on GitHub. In fact, nearly one-third of comments on issues and pull requests include a link. Hidden behind each of those links is important context that can inform the conversation. But each link that navigates you away from the conversation represents a context switch that reduces your focus and the timesaving benefits of productivity tools.

With the Content Attachments API (now in beta) and the growing ecosystem of GitHub Apps, content behind each URL can be embedded directly in the conversation you’re having on GitHub. Apps using the Content Attachments API help developers and their teams stay focused on what matters most: shipping beautiful code—all within GitHub.

New apps using the Content Attachments API

We’re excited to introduce you to four new GitHub Apps that use the Content Attachments API to help you communicate visually, file bugs, plan your projects, and document your system.


RunKit solves the “it works on my computer” problem by making it easy for you to file reproducible and runnable bug reports for Node.js projects. RunKit notebooks package a full environment within a container and can be shared with a URL to give project maintainers access. With RunKit and the Content Attachments API, a RunKit link in an issue or pull request now shows the contents of the entire notebook and its output.

RunKit in action

Install RunKit Notebook


Sometimes your team just needs to stand in front of a whiteboard to work through the details of an idea. LeanBoard brings this collaborative experience to remote teams across a shared board of sticky notes. Now, with Leanboard and the Content Attachments API, you can drop a link in an issue or pull request to preserve the conversation. Even better, screenshots in content attachments are updated automatically (every five minutes) as the board changes.

LeanBoard in action

Install LeanBoard


Sometimes visual communication is the most efficient way to quickly and clearly communicate an idea or concept. CloudApp brings the human connection back to digital workflows through video messaging, screen recording, screenshot annotation, and GIF creation. With CloudApp and the Content Attachments API, you can paste a URL to render a GIF or screenshot in your issue and ensure that your teams have clear visual context to resolve issues faster.

CloudApp in action

Install CloudApp


Use Lucidchart individually, or as part of a team to create and share architecture diagrams, mockups, user flows, and other visuals. These help communicate an idea visually, and clarify how applications and systems should function. With Lucidchart and the Content Attachments API, you can now add these visuals to a GitHub issue and, unlike static diagrams, they update as your system evolves.

Lucidchart in action

Install Lucidchart

Showcase your content on GitHub

The Content Attachments API brings the work behind your code to the forefront on GitHub. We can’t wait to see how you use it to bring more context to your conversations about software development.

Check out the partner apps and tell us what you think. Ready to make your own app? Head over to the Developer Blog to start building with the Content Attachments API.

The State of the Octoverse: communicating with emoji on GitHub

Emoji on GitHub This article is part of a series based on our 2018 State of the Octoverse report—trends and insights into GitHub activity, the open source community, and more from the GitHub Data Science Team.

On GitHub, developers can express themselves in their preferred medium: words, code, or tiny cartoon images if they choose. To get a sense of how our community expresses themselves with emoji, we looked at which ones they use in (and in reaction to) issue and pull request comments. Our data on emoji reactions covers public and open source repositories between October 1, 2017 and September 30, 2018.

To learn more about our numbers and methodologies, check out this year’s Octoverse report.


In 2016, we released emoji reactions to quiet the noise of contentless issue and pull request comments like +1. So how are you using reactions today?

Total reactions by emoji

Expressions of approval and celebration make up the most of your reactions. In fact, you’re giving the 👍 and celebrating with a 🎉 more than anything else.

Chart of total reactions by emoji

Percent of reactions by emoji type and programming language

Emoji usage by programming language Looking at projects tagged with a primary programming language, we can see which emoji language communities use most. Comments in Ruby projects had the most ❤️s, and C# users are casting nearly double the 👎s as any other group.

Emoji usage by continent

Beyond programming communities, geographic trends demonstrate how far some emoji reach. No matter their location, developers react to build consensus and to say, “job well done”. For all of our differences, 👍 is the most widely used reaction across continents. Similarly, more negative emoji like 😕 and 👎 are used less often, suggesting that sometimes, harder conversations require more words.

Zooming in, Japan spread positivity by reacting with more 👍s and ❤️s per user than any other country. And developers in the Czech Republic have something to celebrate. They reacted with the most 🎉s on average.

Reaction-provoking projects

You’ve reacted to public comments on topics from managing code to managing depression, expressing laughter, thanks, and support. In the last year, you:

Emoji in comments

Five emoji could never fully represent the complexity of human emotion. When a 👍 isn’t enthusiastic enough, you often post a 🚀. In the last 12 months, the GitHub community created almost 10,000+ issue comments containing no other content but this tiny craft. That’s a lot of warp-speed shipping.

Emoji used in open source issue comments is often tactical, supporting code reviews and to-dos like looking over code 👀, OK-ing changes 👌, fixing bugs 🔨, and applauding good work 👏.

Together, you’re using emoji to transcend borders, get work done, and express playfulness, agreement, and a whole lot of ❤️. We can’t wait to see what new trends in tiny images are up next.

Stay tuned for more posts that dive in data on the GitHub Blog—or check out our reports on projects and programming languages to see what a community of 31 million developers can accomplish in a year.




Discover new ways to build better

Try Marketplace apps free for 14 days

Learn more