Inform and Act

Read our official statements regarding recent executive orders and find resources to help you take action. Learn more

Introducing Projects for Organizations

You can now use GitHub Projects at the Organization level. All users in your Organization will have access to its Projects, so you and your team can plan and manage work across repositories. With organization-wide Projects, everyone can see what's already in motion and work together without duplicating efforts.

Projects for Organizations

Organization-wide projects can contain issues and pull requests from any repository that belongs to an organization. If an organization-wide project includes issues or pull requests from a repository that you don't have permission to view, you won't be able to see it.

Projects launched in September 2016. Check out the documentation to see how you can use them, and stay tuned—there's more to come.

Meet Nahi: Developer and Ruby Contributor

To highlight the people behind projects we admire, we bring you the GitHub Developer Profile blog series.

Hiroshi “Nahi” Nakamura

Hiroshi “Nahi” Nakamura, currently a Site Reliability Engineer (SRE) and Software Engineer at Treasure Data, is a familiar face in Ruby circles. Over the last 25 years, he has not only grown his own career but also supports developers all over the world as a Ruby code contributor. We spoke to Nahi about his work with Ruby and open source, as well as his inspiration for getting started as a developer.

You’ll notice this interview is shared in both Japanese (which the interview was conducted in) and English—despite our linguistic differences, open source connects people from all corners of the globe.

Aki: Give me the brief overview—who is Nahi and what does he do?


Nahi: I have been an open source software (OSS) developer since I encountered Ruby in 1999, as well as a committer to CRuby and JRuby. Right now, I am an SRE and software engineer at Treasure Data.

現在勤めているTreasure Data Inc.という会社では、SRE兼ソフトウェアエンジニアをやっています。

Aki: How long have you been developing software?


Nahi: I started to write my first Basic program when I was about twelve. During college, I began work at a Japanese system development company, and for the past 25 years, I’ve worked in software development at various companies and projects.


Aki: Who did you look up to in your early days?


Nahi: The research lab that I was part of in college had wonderful mentors. In addition, Perl and Common Lisp (of course!) had open source code and taught me that I could freely enhance those programming languages by myself.

The first addition that I made was to Perl (version 4.018), and I believe it was an enhancement on string processing to make it faster. Each program that runs Perl benefited from the change, and though it was small, it gave me an incredible feeling of accomplishment.

Since then, I have had great respect for the creator of the Perl programming language, Larry Wall, whose work has provided me with opportunities like this.


はじめて拡張したのはPerl(version 4.018)で、ある文字列処理の高速化だったと思います。Perlで動く各種プログラムすべてがよい影響を受け、小さいながらも、素晴らしい達成感を得られました。

その頃から、このような機会を与えてくれた、Perl作者のLarry Wallさんを尊敬しています。

Aki: Tell us about your journey into the world of software development (first computer, first project you contributed to, first program you wrote?)


Nahi: I discovered Ruby shortly after I started to work as a software engineer. Until then, I had written in languages like C, C++, and SQL for software for work, and in Perl for my own development support tools.

Without a strong understanding of object-oriented programming, I studied and picked up tools on my own and started contributing to projects. Back then the Ruby community was small, and even a neophyte like myself had many opportunities to interact with brilliant developers working on the project. Through Ruby, I learned many things about software development.

The first open source (we called it ‘free software’ back then) Ruby program I distributed was a logger library. To this day, whenever I type require ‘logger’ in Ruby, it reminds me of that embarrassing code I wrote long ago. The logger library distributed along with Ruby today no longer shows any vestiges of the previously-existing code—it has evolved magnificently, molded into shape on a variety of different platforms and for a variety of different use cases.



最初にOSS(その頃はfree softwareと呼んでいました)として配布したRubyのプログラムは、ログ取得ライブラリです。今でもRubyでrequire 'logger'すると、いつでも昔の恥ずかしいコードを思い出すことができます。今Rubyと共に配布されているものは、いろいろなプラットフォーム、いろいろな用途の元で叩かれて、立派に成長しており、その頃の面影はもうありません。

Aki: What resources did you have available when you first got into software development?


Nahi: I wrote SQL, Common Lisp, C—and everything on vi and Emacs. Perl was easy to modify and worked anywhere, so I really treasured it as a resource in my software developer’s toolbelt.

SQL、Common Lisp、C、なんでもviとemacsで書いていました。ソフトウェア開発者のツールベルトに入れる道具として、どこでも動き、変更がし易いPerlは大変重宝しました。

Aki: What advice would you give someone just getting into software development now?


Nahi: I think that I came to be the software engineer I am today by participating in the open source community with loads of great developers and engaging in friendly competition with them, as well as trying out the knowledge I learned from the community in my professional life. As opposed to when I first came across Ruby, there are several unique communities now and a great deal of opportunities to leverage them professionally. I really don’t have much advice to share, but I hope that everyone will seek the opportunity to get to know a lot of great engineers.

ソフトウェア開発者としての私は、よい技術者がたくさん居るOSSコミュニティに参加し、彼らの切磋琢磨に参加することと、そこで得た経験を業務で試した経験により作られたと思っています。 でも、私がRubyと出会った頃とは違い、今はそのようなコミュニティがたくさんありますし、それを業務に活かすチャンスもたくさんありますね。私ができるアドバイスはほとんどありません。みなさんがよい技術者とたくさん知り合えることを祈っています。

Aki: If you forgot everything you knew about software development, and were to start learning to code today, what programming language might you choose and why?


Nahi: I would choose either Ruby or Python. If I still knew what I know now, it would be Python. I would select a language in which the OS and network are hidden only behind a thin veil and easily identified.


Aki: On that note, you make a huge impact as part of Ruby's core contributing team. How specifically did you get started doing that?


Nahi: After releasing my first open source software, I went on to release several Ruby libraries that I made for work, such as network proxy, csv, logger, soap, httpclient, and others. With Ruby 1.8, Matz (Yukihiro “Matz” Matsumoto, the chief designer of Ruby) put a policy in place to expand the Standard Library in order to spread Ruby. This allowed the user to do everything they needed to do without additional libraries by simply installing it. A number of the libraries that I had made were chosen as candidates at the time, and I have mainly maintained the Standard Library ever since. The announced policy to expand the Standard Library was a great coincidence for me, since it allowed me to build experience.

初めてOSSで公開して以後、業務で使うために作ったRubyのライブラリをいくつか公開していきました。network proxy、csv、logger、soap、httpclientなど。Ruby 1.8の時、MatzがRubyを広めるために、標準添付ライブラリを拡充する方針を立てました。インストールすれば、追加ライブラリなしに一通りのことができるようにしよう、というわけです。その際に、私の作っていたライブラリもいくつか候補に選ばれ、以後主に、標準ライブラリのメンテナンスをするようになりました。標準添付ライブラリ拡充方針は、私が経験を積むことが出来たという点で、大変よい偶然でした。

Aki: For new contributors to Ruby, what do you think is the most surprising thing about the process?


Nahi: To be honest, I haven’t been able to contribute to Ruby itself over the past few years, so I am not aware of the details on the specific development process. However, I think the most surprising part is that it clearly does not look like there is a process.

In reality, a group of core contributors discuss and make decisions on the direction of development and releases, so to contribute to Ruby itself, you must ultimately propose an idea or make a request to those core contributors.

That’s the same with any community, though. One defining characteristic of the process might be that the proposals can be fairly relaxed, as there is no culture of creating formal documents.



Aki: Okay, we have to ask. What is the most interesting pull request you've received for Ruby?

お尋ねしなくてはならないことなのですが。。今までRubyの開発を行ってこられたなかで、(中村さんが)お受けになった最も興味深い/面白いPull Requestはどのようなものでしょうか?

Nahi: While not necessarily a “pull request,” I have received all sorts of suggestions that stand out: replacing the Ruby execution engine, swapping out the regular expression library, gemifying the Standard Library, etc. As for the most memorable pull request I have received personally, one was a request to swap out the CSV library I made for a different high-speed library. When I think about it with a clear mind, it was a legitimate request, but it took forever to make the right decision.

"Pull request"という名前ではありませんが、印象深いものはたくさんあります。Ruby実行エンジンの差し替え、正規表現ライブラリの置き換え、標準ライブラリのgem化など。私個人に関するものとしては、自身の作ったcsvライブラリを、別の高速ライブラリで置き換えたい、というリクエストが一番印象深いものでした。冷静に考えて正しいリクエストでしたが、適切な判断をするために、いちいち時間がかかりました。

Aki: Outside of your open source work, you also work full time as a developer. Does your participation in open source inform choices you make at work? How?

Open Sourceに関する活動とは別に、フルタイムのソフトウエア開発者としてご勤務されていますが、Open Sourceコミュニティへの参加は職場における(日々の)意思決定にどのような影響を与えていますか?

Nahi: Active involvement in open source is one of the pillars of business at the company I currently work for, and it informs the choices the other engineers and I make unconsciously. When developing something new for the business, we never begin work on a project without examining existing open source software and the open source community. As much as possible, we try not to make anything that replicates what something else does. However, if we believe it necessary, even if existing software does the same thing, we make products the way they should be made. Then, we compete with that and contribute our version back to the world as open source. The experiences and knowledge that we pick up, and also give back through the process, is the lifeblood of software development.

Until I came to my current company a year and a half ago, I led dozens of system development projects, mainly as a technical architect in the enterprise IT world for about 15 years. Back then, I participated in open source individually rather than at my company.

現在所属している会社は、Open Sourceへの積極的な関与をビジネスの柱の一つとしていることもあり、特に意識せずとも、私および各エンジニアの意思決定に影響を与えています。ビジネスのため、何か新しい物を開発する時、既存のOpen Sourceソフトウェア、またOSSコミュニティの調査なしに作り始めることはありません。可能な限り、用途が重複するものは作りません。しかしそうと信じれば、用途が同じでも、あるべき姿のものを作ります。そしてそれは、Open Sourceとして世の中に還元し、競争していきます。そのような中で得られる、また提供できる経験、知見は、ソフトウェア開発の血液のようなものです。


Aki: Tell us about your view on where the enterprise IT world is lagging behind. How do you see the open source developer community making a contribution to change that?

エンタープライズITの世界がどのような点で(Open Source等の世界)から遅れているとお考えになるか教えて頂けますか?Open Sourceコミュニティーのソフトウエア開発者の方々が、(エンタープライズITの状況を)変革させることに、どのような貢献ができるとお考えになっているか教えて頂けますか?

Nahi: In the enterprise IT world, we were trying to create a future that was predictable in order to control the complexity of business and the possibility of change. Now, however, it is hard to predict what things will be like one or two years down the road. The influence of this unpredictability is growing so significant that it cannot be ignored. Luckily, I was given the opportunity to lead a variety of projects, and what helped me out then was the experiences and knowledge I had picked up by being involved in the open source community.

To be honest, developers participating in the open source community now have already made a variety of contributions to the enterprise IT world, and I am one of those beneficiaries. To enhance the software development flow, developers in the enterprise IT world need to participate more in open source. I would venture to say that establishing such an environment and showing understanding towards it may be thought of as further contributions on the enterprise side.

エンタープライズITの世界では、ビジネスの複雑さと変更可能性をcontrolするため、予測可能な未来を作ろうとしていました。しかし今では、1年、2年後を予測するのは困難です。この予測できないことの影響は、無視できないほど大きくなっています。私は幸いにも、各種プロジェクトをリードする機会を与えられました。その時に役立ったのは、Open Sourceコミュニティとの関わりの中で得られた経験、知見でした。

正直に言うと、現在Open Sourceコミュニティに参加している開発者は、エンタープライズITの世界に、既に様々な貢献をされていると思います。私もその恩恵を受けた一人です。
ソフトウェア開発の血液を循環させるためには、エンタープライズITの世界に居る開発者が、もっとOpen Sourceコミュニティに参加できるようにならないといけません。しいて言えば、そのような環境を整えること、理解を示すこと、などは、更なる貢献として考えられることかもしれません。

To learn more about Nahi’s contributions to Ruby, visit his GitHub profile page here. You can also learn more about Ruby itself by visiting their homepage.

GitHub Shop: Octicon sticker packs are here

Octicons are meant to be shared. Get a pack of vinyl Octicon stickers to divvy up with friends—now available in the GitHub Shop.

Octicon Stickers

Top open source launches on GitHub

The open source community on GitHub has released some of the world's most influential technologies. Earlier this month, a new dependency manager for JavaScript called Yarn was launched and hit 10,000 stars by its second day on GitHub. Stars are an important measure of the community's interest and just one of the many ways to determine a project's success.

Based on the number of stars in a project's first week, here are the top open source releases on GitHub since 2015.

Chart of total stars in first week


Anime is a flexible and lightweight JavaScript animation library by @juliangarnier. Check out some of the incredible demos.

Released: June 27, 2016
Stars in the first week: 6,013


create-react-app was released by Facebook. Its success is a testament to the popularity of React, the fifth most starred project on GitHub.

Released: July 22, 2016
Stars in the first week: 6,348


Clipboard.js is a lightweight JavaScript library by @zenorocha that makes it easy to copy text to the clipboard, which used to require plugins in older browsers.

Released: November 27, 2015
Stars in the first week: 6,522

Visual Studio Code

VS Code is an Electron-based code editor from Microsoft. Whether it's text editors or libraries, Microsoft is using open source to build essential tools for developers.

Released: November 18, 2015
Stars in the first week: 7,847


N1 is an extensible desktop mail app built on Electron. Themes and plugins make N1 a powerful and customizable mail client.

Released: October 5, 2015
Stars in the first week: 8,588

Material Design Lite

Material Design Lite from Google lets you add a Material Design look and feel to your static content websites. Check out the showcase to see great examples of what the community has built.

Released: July 7, 2015
Stars in the first week: 9,609

React Native

Released by Facebook, React Native is a framework for building native apps and is the second React project in this list.

Released: March 26, 2015
Stars in the first week: 10,976


Tensorflow is an open source library for machine learning that was released by Google. With Tensorflow, developers can build intelligent systems using the same tools used by Google for Search, Gmail, Photos, speech recognition, and many other products.

Released: November 9, 2015
Stars in the first week: 11,822


Yarn is a dependency manager for JavaScript released by Facebook, Exponent, Google, and Tilde. It aims to ease the management of dependencies in JavaScript projects with features like deterministic dependency resolution, more efficient and resilient networking, and offline mode.

Released: October 11, 2016
Stars in the first week: 16,068


Swift is a general-purpose programing language originally unveiled by Apple in 2014 and open-sourced in 2015. Swift is already in the top 15 most popular languages used on GitHub by number of opened Pull Requests and grew by 262% in the last year.

Released: December 3, 2015
Stars in the first week: 23,097

Open source software is about more than code. Getting the community engaged early is important to building momentum, and a successful launch attracts developers, designers, community managers, users, and companies that help the project thrive.

This data was gathered from queries against the GitHub Archive dataset available on Google BigQuery.

Introducing GitHub Community Guidelines

Building software should be safe for everyone. The GitHub community is made up of millions of developers around the world, ranging from the new developer who created their first "Hello World" project to the most well-known software developers in the world. We want the GitHub community to be a welcoming environment where people feel empowered to share their opinion and aren't silenced by fear or shouted down.

Beginning today, we will be accepting feedback on proposed GitHub Community Guidelines. By outlining what we expect to see within our community, we hope to help you understand how best to collaborate on GitHub and what type of actions or content may violate our Terms of Service. The policy consists of four parts:

  1. Best practices for building a strong community - people are encouraged to be welcoming, assume no malice, stay on topic, and use clear and concise language at all times.
  2. What to do if something offends you - project maintainers are encouraged to communicate expectations and to moderate comments within their community — including locking conversations or blocking users when necessary.
  3. What behavior is not allowed on GitHub - the community will not tolerate threats of violence, hate speech, bullying, harassment, impersonation, invasions of privacy, sexually explicit content, or active malware.
  4. What happens if someone breaks the rules - GitHub may block or remove content and may terminate or suspend accounts that violate these rules.

As always, we will continue to investigate any abuse reports and may moderate public content on our site that we determine to be in violation of our Terms of Service. To be clear, GitHub does not actively seek out content to moderate. Instead, we rely on community members like you to communicate expectations, moderate projects, and report abusive behavior or content.

Additionally, we are releasing the guidelines under the Creative Commons Zero License in hopes of encouraging other platforms to establish similar norms to govern their respective communities.

These guidelines are first and foremost community guidelines and we'd like to hear your thoughts on them before they're finalized. Please get in touch with us with any feedback or questions prior to November 20th, 2016. Together, we can make the open source community a healthy, inclusive place we can all be proud of.

New to InnerSource? A panel of experts talk through the corporate version of open source

Most developers are already familiar with the concept of InnerSourcing, although many have never called it that. InnerSource is simply using best practices and methodologies from open source development in a confined corporate environment. Several large organizations have already embraced these processes to great advantage, and a few of them came together at GitHub Universe to discuss how their teams are benefitting.

Kakul Srivastava, VP of Product Management at GitHub, moderated a panel featuring Panna Pavangadkar, Global Head of Engineering Developer Experience at Bloomberg, Yasuhiro Inami, iOS Engineer at Line, Joan Watson, Director of Engineering IT at Hewlett-Packard Enterprise, Jeremy King, Senior Vice President and CTO for Global eCommerce at Walmart, and Jeff Jagoda, Senior Software Engineer at IBM.

During the course of the 45-minute discussion, panelists offered anecdotes and examples of the many positive ways InnerSource practices have impacted their teams — not a small feat when it comes to enacting change in highly structured, highly distributed companies with thousands of developers all over the world. Across the board, panelists reported seeing not only increased collaboration between previously siloed teams, but also a reduction in bottlenecks, as well as increased communication on projects.

“Once you embrace it [InnerSource] and see new teams come on, you show examples of places where not only can people contribute, you unlock bottlenecks,” said Walmart’s Jeremy King. “When you're working with large software companies, on lots of different projects, you end up having inherent bottlenecks in some team or another — and it’s awesome to have another team come in and say, ‘I can fix this bug’ or ‘I can add this feature’, without impacting the overall roadmap of that important group.”

From shorter shipping times to community development to designing innovative products, InnerSource has evolved the workflow of teams operating on an enormous scale — however, the advantages of the InnerSource process can benefit teams of all sizes by introducing the collaborative and creative principles of open source development.

Learn more about how InnerSource practices can impact your teams by watching the full video below:

Get testing with Taplytics in the Student Developer Pack

Taplytics is now offering mobile testing to students in the Student Developer Pack.

Taplytics joins the Student Developer Pack

Taplytics helps mobile developers create great experiences through: A/B testing, push notifications, and custom analytics. As part of the GitHub Student Developer Pack, Taplytics will give you complete access to its suite of tools for native mobile apps.

For members of the pack Taplytics is offering full, unlimited access to the platform free for 6 months. You will be able to do visual tests on your apps and make design decisions that work best for your users. You’ll be able to get analytics around your apps that help you iterate on your app in the future. Taplytics also includes tools that help you provide users with the right information at the right time.

The Student Developer Pack gives students free access to the best developer tools from different technology companies like Datadog, Travis CI, and Unreal Engine.

Students, get testing now with your pack.

Dismissing reviews on Pull Requests

Dismiss reviews on GitHub

Pull request reviews are a great way to share the weight of building software. Using protected branches to block merging when pull requests have reviews that request changes helps your team maintain quality, bug-free code. However, this requirement can sometimes block your team’s progress without good reason. If someone leaves a review that requests changes and then goes on vacation or runs into computer problems, your pull request could be blocked for days, even after you’ve addressed the reviewer’s concerns.

To improve this workflow, we’re adding the ability for pull request collaborators to dismiss reviews. When someone leaves a review that requests changes, dismissing the review changes it from a review that requests changes to a review comment. This will unblock your pull request, freeing you up to merge it!

You can also dismiss an approving review. This is useful when your pull request has changed significantly since the approval, and you think it’s important to get another review.

When one of your team members dismisses a review, they’ll have to leave a reason why. This keeps people from simply bypassing the protected branch review requirement out of convenience.

GitHub's game jam, Game Off, returns next month

GitHub Game Off - Game Jam Hackathon Logo

The GitHub Game Off, our very own game jam, returns next month! Participants will have the entire month of November to build a game based on a secret theme (to be announced later) and share their creations with the world.

Much like previous years, the use of open source engines, libraries, and tools is encouraged, but not a strict requirement. Unlike previous years, however, we're removing the restrictions! Previously you could only submit web-based games, but now all games are welcome - all platforms, operating systems, and devices.

The theme for this year's Game Off will be announced here on the GitHub blog on Nov 1st at 13:37 PDT, so please stay tuned.

We've seen some great games submitted in previous years. We can't wait to see what you come up with this year <3

The official Twitter hashtag for the Game Off is #ggo16.

Hacktoberfest is back

Hacktoberfest 2016

Celebrate open source this October by participating in Hacktoberfest, a month-long festival of code organized by our friends at DigitalOcean and hosted on GitHub.

To participate, simply open a pull request and contribute to any open source project. You can fix a bug, add a feature, or even improve some documentation. If you've never contributed to an open source project before, check out our contributing to open source guide.

Once you've made your contribution, tell the world about it with the #hacktoberfest hashtag on Twitter, Facebook, or Instagram. 🎉

If you make four pull requests by October 31st, you'll get the satisfaction of sharing your code with the world—and a t-shirt, of course.

Hacktoberfest 2016 t-shirt

To make your mark on open source (and secure your Hacktoberfest t-shirt) please visit for more details.

Rebase and merge pull requests

The merge button on pull requests supports two great workflows
with merge commits and commit squashing.
Now you can use the merge button to rebase and merge your changes, too.


How does it work?

When you select the new "Rebase and merge" option,
the commits from the pull request's branch are rebased on to the tip
of the base branch, and then the base branch itself is fast forwarded
to this newly rebased head. Rebases automatically set the committer of
the rebased commits to the current user, while keeping authorship
information intact.
The pull request's branch will not be modified by this operation.

If a rebase can't be performed due to conflicts, we'll let you know so
you can manually resolve them as necessary.

Rebase with conflicts

As with "Squash and merge", repository administrators can decide whether they
want to allow this new option on the repository settings page.

Learn more about rebase and merge in our Help docs.

License now displayed on repository overview

Licenses are now displayed in the repository overview, allowing anyone to easily see if a project has an open source license. This change is immediately available on GitHub, and will also ship with the upcoming Enterprise 2.8 release.

A shortened license name, linking to the repository’s license file, is displayed on the repository page:


We use an open source Ruby gem called Licensee to compare the repository's LICENSE file to a short list of known licenses. This is the same code we use to provide the Licenses API and understand how repositories on GitHub are licensed.

We don’t detect every open source license, nor complicated situations such as projects with multiple licenses. For those situations you can still find and read the project’s license(s) as before.

Open source is a fundamental part of GitHub’s community. Adding an open source license to your repository ensures that others can use, copy, modify, and contribute back to your project. It's an important step when creating an open source project. If your repository doesn’t have an open source license and you want others to get involved, consider adding one now.

Mission Report: GitHub Universe

Audience at GitHub Universe

On September 14 in San Francisco, more than 1,500 developers helped us kick off GitHub Universe and share stories about open source, workplace best practices, and how the GitHub Community builds software. In case you missed it, here are some highlights, along with the new features and community updates announced:

We started day one with a keynote by GitHub CEO Chris Wanstrath, who shared a few brand new developments from around the GitHub Universe. We were also joined by CEO of Black Girl's Code Kimberly Bryant and White House Senior Technology Officer Alvand Salehi. For more details, check out the launch post.

On day two, we heard a keynote from GitHub's VP Social Impact Nicole Sanchez, Dr. Kortney Ziegler, and David Molina of Operation Code who shared their thoughts on training new developers and expanding opportunities to participate in technology for people from all backgrounds

Code Review

Our new Reviews improves code review on GitHub and helps you share the weight of building software. Reviews allow you to comment on specific lines of code, formally “approve” or “request changes” to pull requests, and more. Our initial changes are only the first step of a much greater roadmap toward faster, friendlier code reviews.


With Projects, you can organize work from your GitHub repositories and integrate project management into your development cycle without skipping a beat (or even opening a new browser tab).

Although we’ll quickly add to Projects, our initial release currently supports:

  • A New Projects tab–at the same level as Code, Issue, Pull Requests within a repository–that lists all of your projects
  • Workflow columns that you can name and reorder
  • Cards that you can drag and drop between columns pointing to issues, Pull Requests, or notes
  • Tools built on top of Projects by some fantastic partners, including and ZenHub

Platform updates

We launched a few things to make integrating with GitHub a better, more enjoyable experience, including a public Platform Roadmap and the GitHub Platform Forum. We also launched two new projects to make our platform more flexible:

Breakout sessions

Our breakout sessions this year covered everything from product updates and applications to building more diverse and inclusive engineering teams. All of the talks from the general sessions are ready for you to watch from home—and recordings of the Launch, Flight, and Orbit breakouts will be available soon.

Benefit concert

We ended Monday at The Masonic with the Big Bang—a benefit concert for Black Girls Code. Artist and actor COMMON headlined with support from Lion Babe. Head to to learn more about BGC's work and find out how you can help them reach their mission to teach one million girls to code.


GitHub Universe would not have been possible without the support of our sponsors, who provided food, juice, coffee, bubble tea, and beautiful art installations for our enjoyment.

Sponsors of GitHub Universe

Thank you

And finally, thank you to our community for making all of this possible—and helping GitHub Universe take flight.

A whole new GitHub Universe: announcing new tools, forums, and features

Today I welcomed more than 1,500 people to our second annual Universe conference in San Francisco, an event designed to celebrate the people building the future of software. It’s an important reminder about who we’re here for—whether it’s the open source maintainer whose project is transforming healthcare, an automotive company building a self-driving car, or a teenager teaching herself how to program after she finishes her homework.

Our goal is to make building software easier for you. And with that goal in sight, we’re announcing our biggest update to the platform yet. We’re making it easier for you to work together to ship high-quality code through improved code review tools, and we’re giving our profiles an update to better show who you are as a developer. We’re making integrating with GitHub a first class experience through major API improvements. And we’re taking steps toward making GitHub a better place for businesses to get work done with added security measures for organizations.

I’m proud of our team for coming together to ship so many improvements to the platform, and I hope you’ll find them useful as you continue to build amazing things. Read on for more specifics, and keep an eye out for continued improvements to your GitHub experience in the coming months.

Manage your ideas with Projects

Taking projects from idea to launch isn’t easy. There’s a lot to coordinate behind the scenes, and so many tools out there to help you organize and distribute work. To help you integrate project management into your development cycle without skipping a beat (or even opening a new browser tab), we’re introducing Projects.


With Projects, you can manage work directly from your GitHub repositories. Create cards from Pull Requests, Issues or Notes and organize them into custom columns, whether it’s "In-progress," "Done," "Never going to happen" or any other framework your team uses. Drag and drop the cards inside a column to prioritize them or move them from one column to another as your work progresses. And with Notes, you can capture every early idea that comes up as part of your standup or team sync, without polluting your list of issues. For more on what's changed, watch this quick overview.

Although we’ll quickly be adding to Projects, our initial release currently supports:

  • A New Projects tab–at the same level as Code, Issue, Pull Requests within a repository–that lists all of your projects
  • Workflow columns that you can name and reorder
  • Cards that you can drag and drop between columns pointing to issues, Pull Requests, or notes
  • Tools built on top of Projects by some fantastic partners, including and ZenHub

Code better with Reviews

Collaboration is the core of building great software—and code review is critical to collaboration. When another person looks at your code and gives it the same level of critique that you did while writing it, your work gets better. We’re improving code review on GitHub to help you share the weight of building software and improve the software you build.

GitHub code review

Designing the best way for you to review code is a continuous process, but our first step is now available on all pull requests—Reviews. In addition to commenting on specific lines of code, Reviews let you formally “approve” or “request changes” to pull requests. You can also leave a review summary and delete, edit, or bundle comments before you submit them.

Reviewing code changes

To streamline conversations and cut down on noise, you can reply to inline comments without drafting a formal review or starting a new conversation. This also means you can have multiple conversations per line of code—creating more explicit feedback loops, smarter conversations, and better code review.

Finally, administrators can require Reviews before merging via protected branches. When Reviews are required, you must have a least one approval and no changes requested before you can merge.

Blocked Pull Request

These changes are only the first step of a much greater roadmap toward faster, friendlier code reviews. We’re working on a handful of follow-up feature improvements—including the ability to request reviews from your peers. For more information on Reviews, including what we’ve shipped today, check out the documentation or a quick tutorial video on Reviews.

Integrate seamlessly with GitHub

Developers use a variety of tools to ship their software and we’ve seen hundreds of integrations built to work with GitHub. Now we’re shipping some major improvements to our API and adding new ways to collaborate transparently not only with GitHub engineers but also the broader community of integrators. As host to the largest community of developers, we want to make the GitHub platform uniquely enjoyable for integrators to build applications that change how people work. Here’s what we’re launching right away:

  • A public Platform Roadmap that demonstrates what GitHub Platform Engineers are launching next and why
  • A formalized process to solicit feedback and launch updates to our platform
  • Early-access and pre-release programs that let you access new features and APIs and provide you with the support you need to ensure launch readiness for the software you build on top of GitHub
  • The GitHub Platform Forum which provides a direct communication channel between ecosystem developers and GitHub engineers.

With that, we are excited to announce two new projects that aim to make our platform more flexible:

Integrations Early Access

We’re rethinking our integrations model to provide better ways for tools to extend and integrate with GitHub. We’ve added the ability for an integration to act on its own behalf instead of impersonating a user—making it a first class actor on GitHub without using a paid seat. Admins will have the ability to configure integrations directly on Organizations and control which repositories they allow access to. Read more about Integrations on our Developer Blog or check out the documentation.

The GitHub GraphQL API Early Access

The GraphQL API simplifies your product development by letting developers access all the data they need, and only the data they need, with one API call. With the GitHub GraphQL API, you get the same API we use to build GitHub features. To learn more and see how it works, check out our Engineering Blog.

Have a friendlier business experience on

Organizations on GitHub are the best way for teams of developers to build and ship software together, and with the added security of two-factor authentication enforcement and upcoming product enhancements, they’ve never been better.

Easily enforce security

Now Organization administrators can require two-factor authentication for all members—making it easier to support security policies.

Enforced two-factor authentication in an organization

Admins will be asked to confirm the two-factor authentication requirement and a confirmation modal will list members and forks that will be removed as a result. GitHub will notify members if they’re being removed from an organization with email and in-product notifications. Finally, as always, admins can invite members back with their forks and settings intact once their security is up to speed. Read more about requiring two-factor authentication in your organization.

Take greater control over your permissions

Over the last few years, we’ve rolled out LDAP and CAS to securely and efficiently manage permissions on GitHub Enterprise. Now we’re making sure businesses on have the tools they need to automate identity and access management. Our first public launch is a SAML-based Single Sign-on (SSO) option. Administrators will have the ability to manage their GitHub users through the identity provider that already manages access to the host of applications they use in their current workflow. This option isn’t ready quite yet, but it will launch as a beta in the coming months. Sign up to try it out when it does.

Get help from the GitHub Community

We’re grateful to have a community of more than 16 million developers. While developers gain experience implicitly on GitHub as they work alongside other developers, we know that’s not enough. To help, we’re creating a dedicated space for you to learn from each other—and to have conversations about GitHub itself.

The GitHub Community Forum will become a place where developers can talk shop, get help, and learn together. It will also help us introduce new features and improvements and give developers the ability to share thoughts and feedback with us directly. Look out for the GitHub Community Forum in 2017.

See what’s behind your green squares

New user profiles

Your profile now contains your entire history of work on GitHub, from your first commit to your most recent pull request. And a per-repository breakdown reveals where you're spending your time each month. You can see special events in your history—the day you signed up for GitHub, opened your first pull request, or joined an organization—and showcase your best work by pinning favorite projects to your profile. For more on what’s changed, take a look at the documentation or watch the video.

While I’m really excited about these improvements to GitHub, I’m more excited to see what you’ll create with them.

The State of the Octoverse

Join us on a trip through the Octoverse

As we take this moment to celebrate our community at GitHub Universe, we're amazed yet again by how the Octoverse has expanded and changed. Our community has grown to more than 16 million people strong, hacking on things like Free Code Camp, an open source curriculum that helps nonprofits; and Batavia, an implementation of the Python virtual machine.

We want to welcome the more than 5.2 million new developers who joined our community in the last year and applaud the more than 800,000 of you for creating your first pull request. Many of you have joined us from all over the world—we saw explosive international growth from China, Indonesia, India, Russia, Brazil, and Japan.

GitHub is about bringing people together to collaborate on world-changing technology, and in doing so, creating a constantly expanding universe of code. Join us for a spin through the latest installment of the Octoverse in 2016 and we can't wait to see how you help us grow the Octoverse in 2017 and beyond.