♪ (jazz music) ♪ Welcome to GitHub Universe. This is my third time here,
and every year I come in and I'm like, "Oh, I know
what it's going to be like." But how amazing is this? This place is so incredible. It's so great to see so many of you.
Thank you for joining us. I want to start by just giving
a huge round of applause and to thank you to, specifically,
the GitHub events team and everyone involved in pulling this off. Thank you so much, everyone. This is going to be a really great
couple of days. (applause) And it's already started. We had a great partner day yesterday;
we got tons of events going on. No matter what you're interested in,
or what kind of software you're building, there's someone here for you;
there's something here for you. So, please enjoy it, explore,
ask questions. We're all here together. So, I want to again, thank you all
for coming, taking time out of your days and weeks to talk about software,
talk about the GitHub Universe, spend some time with the Hubot
and the Octocats. This is always a special time
of year for us. October is when we started
working on GitHub. And actually, this year
is a little bit special, because we first began working
on GitHub in October of 2007. So, next Friday, the 19th,
will be the 10-year anniversary of our very first git commit
for building GitHub itself. Which is pretty amazing. Unfortunately, it's a default
Rails app import. So, the commit itself
is not that interesting. I think it's says like "default import"
as the commit message. But it's really the content
that counts, right? Or I guess more importantly,
it's the journey. And where we've all come together
since then-- that's really amazing. 2007, I know some of you
maybe weren't born then-- but it was a very different time
in the world. Twitter was just a baby bird,
not the social media monster that it is today. Only a few people
in the world had iPhones. I think Android still had a keyboard. So, smart phones and bringing
computers with us everywhere-- that was called a laptop
back in our day. But things were changing. The world was about to go through--
or at least the U.S.-- a recession. And we were still recovering
form the dotcom bust, but things were different. Open source was really starting
to catch on, and this is before GitHub. It was a real power in the industry. Software was becoming cheaper,
more inexpensive. The Cloud was starting to become
more than a thing in the sky, but a way to talk
about using other people's computers for your own purposes. And thing were generally becoming
more accessible to people, whether it was building a business,
finding a community, or just working on something on your own. GitHub, I think, didn't start
any movement. We were a part of a movement
that was beginning around 2007. When I think
about the early days of GitHub, I think a lot about the software projects
that inspired us, and the philosophies
that those projects had and what we brought in to our own product. We were using open source heavily
by the time we started GitHub. I grew up on open source. I was a heavy, heavy SourceForge user
for a long time. And-- I love SourceForge. RIP. But a huge fan of open source,
I learned about Linux, I learned about all these things
that people just put online for free, and I learned how to code that way. But more importantly, I learned
how to think about software that way. There were three philosophies
that we talked about a lot in the early days of GitHub,
that we were inspired by projects like Rails, projects like Django,
new programming languages that put the developer front and center, that thought about ease of use
and accessibility and sort of getting out of the way. So, the three things that we used to say
were "Developers first." Obviously, we're talking
about developers. But it's important
because it doesn't mean developers only. We wanted to build GitHub as a platform
that people can jump onto and use. Hopefully, other people could use it
that weren't developers, but primarily, we were building this thing
for the people using it, specifically, for software developers,
and not for any other audience or agenda. Why was that important? Well, obviously, a product for developers,
you think, should be built for developers. But it didn't feel
like many were at the time. And my favorite software to use
were projects like Rails, and projects like Django. Things that were explicitly built
by and for developers. So, why not build a development tool,
a commercial one even, with that same philosophy behind it? The other two are just approaches
that we took based on these sort of software workflow tools
that we used, as well. One was reducing friction,
and one was lowering barriers. We wanted to take out friction
in your workflow, whatever that may have been. Whether you have ten open source projects
that you're jumping between, maintaining every single morning,
and it's just a lot of meta-work on top of the actual coding. Or whether you're working
in a big enterprise and you have the compiling joke
where you have to take a coffee break every time you try to build
or commit or review code with someone. We wanted to remove that friction,
so you can really get into the zone, really get into the flow, and focus
on the unique problem you're solving, which isn't drinking coffee
while your code is compiling or the build is running. The lowering barriers one is
a little bit selfish, I think. But I had a hard time
getting into software. I had a hard time
getting into programming. I don't have a lot of patience. I'm stubborn. And so, I had many false starts
trying to become a gaming programmer when I was a kid, trying to find
a school that had a great course for me that I would really click with. And many times, I just didn't think
I would ever become a programmer, because the tools I was trying to learn,
they seemed impossible. And it seemed like you had to be
a lot smarter than me, or have a lot more experience
than I had to get to use them. In many cases, some of that was true,
some of the tools were inaccessible, not through any purpose,
but because the person that wrote it was writing it for an audience
that had a certain skill level. They made certain assumptions about it. Git was this way. Git was very hard for me to use. It was not really focused on UI,
it wasn't built for a web generation. It was really great at what it did, which was a distributed version
control tool that came out of the kernel community
for a group of people that collaborated through mailing lists,
and have it down to a science. One of the biggest software projects
of all time was built-- Git was built to help manage it. I've not worked on
the biggest software project of all time. And most of my projects are not
the biggest projects of all time. So, Git at first, I wanted
to use the power. I believed in the vision. I loved the idea of social coding,
of this idea of not having a canonical technological center
of development, where the gold master is
or the server lives. But having that be something social-- having that be something decided
that people pass around and talk about. Linus's kernel is the real one,
because that's the one that gets put to press,
not because he flipped a certain config or he has a special piece of software. It's because that's the address
people go to. I wanted to be a part of that world, but I had a hard time setting up SSH,
I had a hard time setting up my VPS slice, or whatever we were using at the time. And I had a hard time collaborating
through mailing lists. I grew up on AOL and message boards,
and the internet. I wanted to use the web to collaborate. I'd already signed up for and quit
Facebook a few times by that point. So, for me, I had a hard time
getting into all these things, getting into Git, and what we saw
was something like Rails, something like Django,
a lot of these dynamic scripting languages like PHP that were becoming
more and more popular and less of a joke, I think, at the time, was this is a way for people to get in. This is a way for software
to become more accessible. This is a way for people to get
to the real meat of software development. Which, at the end of the day,
isn't the coding, it isn't the typing, it isn't the compilers--
this stuff's all awesome and it's super important. At the end of the day,
it's what you're building and the effect it has
on the person you are building it for. We are all builders. We're all creators. And software and technology
and all these tools, including GitHub, are super, super important. We can't lose sight of why they matter. Because they help us do something. Either for ourselves or for someone else. They help us have an impact. They help us make something better
or maybe worse, but hopefully, that's unintentional. Software is a means to an end. And the more people
we can invite into that, the easier we can make it
to get to that end, I think the better
the world would be for all of us, the more powerful software will be, and the brighter the future will be. We were not thinking
about that at the time, We were thinking, "I want to use Git,
and I just can't." I'm almost going to give up. So, how can we make it easier?
How can we make it more approachable? How can we take a cue from this movement,
this developer friendly movement, this tool-focused movement,
and how do we bring that into the products that we love,
and the products that we use everyday? So, we never thought that GitHub
would be this big, because that community
seemed niche at the time. This idea that open source
was going to produce software that massive enterprises
were going to use. Even though Linux, in 2007,
was the biggest thing ever. It still didn't seem real
that for someone like me, I could have an impact
on a company like an IBM or a Facebook, or a stranger across the planet
that was building something real. Again, I used SourceForge. I knew the power of open source. But there really was a barrier
and a divide between what seemed to me the real projects--
the Linuxes of the world. And the things I was working on,
which some of them-- maybe they were little companies,
maybe they were little app ideas, maybe they were the world's
500,000th blog software. Didn't matter. I wanted to tinker with that stuff;
I wanted to share it with the world. And a lot of people did too. But we just didn't realize how many people
really wanted to get into this movement, this developer-focused movement. At the same time, we started talking
about software is eating the world. And as we know, software
is powered by developers, but the real surprise, I think,
was how many people that resonates with,
and the power of software continues to grow today. Maybe I'm just preaching literally
to the choir here-- we all know this. But the point I am trying to make
is we never thought GitHub would be this big. And that wasn't about thinking
about our own ambitions, or our own abilities, but we never thought
there'd be so many people that believed the same things
that we believed. We should've, right? Because focusing on people,
focusing on reducing friction, focusing on lowering barriers,
and building great things-- that all sounds wonderful. And so, why you're here, why I'm here,
why we're able to have such an awesome space like this,
why the GitHub community has grown so big, and people
have heard of us-- it's not about the founders
and our three philosophies from 10 years ago,
as much as I really like-- list of three and these ideas. It's about all of you. GitHub is a business, right? It is a product; it is software,
but what is code that doesn't run? What is a social network
with no one on it, right? GitHub is about the people,
it's about the community. And I don't just say that in the way,
"Thank you for signing up." The reason people go to GitHub
is to meet you, is to use your code, is to learn and to get better. When people think about GitHub,
they think about the things that they can do with it,
and all of those things come from other people. Whether it's reviewing code,
whether it's finding a mentor, whether it's finding a new job,
or an open source project. All these things come out of you. It's all about the people
that are on GitHub and sharing together. And we take that very seriously. We talk about the community a lot. We talk about the open source developers;
we talk about software developers, but what we really mean
is what we're thinking about is how to connect you. Whether it's your software to one another,
whether it's your ideas to one another, we believe in that power,
because we're you too. We came from the same world. A lot of GitHub employees
are GitHub fans first and foremost. They learn to develop software on GitHub
and then came to work for us. We are a part of this community.
We use GitHub everyday, as well. And I love finding new projects on GitHub
that I can use in hobbyist projects, or I can just learn and see something new. The future of software
is very bright, obviously. Because I think the future
of humanity is bright. Maybe not a popular thing
to say right now, but I'm an optimist. And I've seen the negative
side effects of technology, but I've also seen the positive
side effects of technology. And it's really amazing;
it's really inspiring. And the scale that we're at right now
is just the very beginning. A lot of us were developers
before GitHub. Some of us, I think,
have become developers after GitHub. But many of us were developers
before GitHub. Time marches on. What we're thinking about now
are the next hundred million developers, for whom their expectations,
their ideas about collaboration, their demands of what it means
to learn, build software, work together, it's going to be a lot more imaginative,
a lot more creative than someone like me who grew up
in the world of AOL AIM, before something like Git. We can see this in the numbers. So, we have 67 million repositories
on GitHub right now, which is pretty cool, but it doesn't speak
to the fact-- this isn't 67 million Linuxes, as we know. There's all sorts of projects. We have little ones. We have big ones.
They're growing at a rapid rate. I think what this speaks to
is the scale of collaboration on GitHub, which I think we all know is pretty huge
and still growing rapidly. We get over 50 million people
to visit GitHub.com every month, downloading code, reading it,
looking for help-- all of the things I listed before. There are millions and millions
of unique people visiting GitHub.com everyday, which means that the programming
community, the software community, it's a lot bigger than I think anyone
has ever imagined. There's over a million
and a half teams on GitHub, groups of people,
whether they're businesses, community groups, even churches,
non-profits-- everything. Over a million teams using GitHub
to build software together and collaborate. Some of the biggest companies in the world
and maybe someone starting a company right here during this talk, hopefully,
putting it on GitHub, right? We have a huge number of students
that are using GitHub, from actual classrooms,
like Harvard, Berkeley-- teaching computer science using GitHub, to people that are hobbyists,
and they're using GitHub in their free time to learn. Maybe they're making games with Unity,
or just trying to figure out how compilers actually do work. Over a million students on GitHub. I think I said this last year,
but when I was a student, I pirated most
of the software that I used. So, if you're a student,
and you want to use GitHub, it's free. You don't have to pirate anything. Check out the student developer pack. We're going to cut that from the video. I didn't pirate anything. (laughter) So, we're about building software. And one of the most key parts
of building software is obviously the text editor. If you haven't checked out Atom already,
it's our open source collaborative text editor. It's hackable. It's all written
in JavaScript, CoffeeScript. You can get inside the internals, HTML. There's tons and tons
of packages out there. Over 2 million people are using it
every single month. And I think the best part of Atom
is that it's an open source project. The features of Atom are great. What it can do is great. The price tag is really great. But I think the future
is the brightest part about Atom. It can be anything. It can be wherever it needs to go,
and it can always adapt to what's happening,
because it's an open source project, and if it can't, we'll fix it,
we'll do something, we'll change it-- that's the nature of open source. It evolves and it grows. So, I'm extremely optimistic
about Atom's future. And if you haven't checked it out, there's been some
really cool releases lately, like the Atom IDE. So there are-- we have this platform
called Electron, which is pretty cool, if you haven't checked that out. It lets you build desktop apps locally
using web technologies similar to Atom. So, there's 404 registered
on our Electron directory. Which is sort of poignant in a way,
because we don't know how many Electron apps
there are out there. We think there's thousands of them. We know companies use them
to build internal apps really quickly. Remember the days of building
an internet app really quickly using Rails or something like that,
spinning it up. A lot of companies are now moving
to something like Electron, where they can just
distribute the package. They have a server.
It's a really easy web-like experience for building something internally. So, 404 not found. We really don't know how many
are out there. But a lot, I think. We've had over 100 million
pull requests merged in the history of GitHub. Which is pretty amazing. Not just created, right? There's probably been a lot
created that haven't been merged. I'm guilty of the not clicking
the button in many cases. But over 100 million pull requests
have been merged since we wrote our pull request
some time in 2009, 2010, which is really remarkable,
but my favorite stat is how many people are creating
their first pull request every single day. This goes up every year,
which is great, right? Right now, it's actually closer to 4,000. So, not 4,000 new pull requests,
not 4,000 new projects-- 4,000 people everyday create
their first pull request. Collaboration is growing. And this is probably my favorite--
I mean just because it's a big number. I'm pretty sure those zeros are right. Over 1.5 billion commits
pushed to GitHub this year. Past 12 months, 1.5 billion. There are more-- that's more
than there are grains of sand in all of-- no, that's not true at all. But it's a really huge number,
like 1.5 billion commits. And obviously, a lot of them
are rolling back previous changes and whatnot, but still the activity
is growing-- it's astronomical. I first saw this number,
I thought this was all-time on GitHub. I just can't believe the scale
of what's going on right now. I like to think these numbers are big
because network effects, our business model, talks like these--
I'm sure you're all signing up and creating more repos, but I think at the end of the day,
the core of it is this stuff is useful. You're building things for other people;
you're having an impact. People go to GitHub because they
can get something out of it. It benefits them; they get a cool piece
of software; they find a job-- these are good things. They're useful. And so, it grows. People see and they do it more. What we may forget
is it hasn't always been this way. When open source started,
it was called free software. It was in the 80s. There really wasn't an internet
as we think of it today. And the problem was that
you would get a piece of software that you would pay for.
You would own it. And if it would break, you're out of luck. You couldn't do anything with it;
you couldn't change it. That was very frustrating
to a lot of people, especially folks who thought
it's your property, you should be able to do
whatever you want with it. So, free software came out
of that and other ideas where, now, with free software,
I get some piece of software, it breaks, I can fix it. Of course, I need to have the skills.
I need to have the knowledge. But I own it, I can do
whatever I want with it. Free software pushed that forward. What they never could have predicted
was the impact that the internet had on free software and open source. Free software came a lot out of ideologies
and property ownership. But really, the massive thing,
the thing the reason why we're all here, is that it's just not about me
being able to fix software that I bought for myself. When I give it back to you,
it goes from me benefiting, to you benefiting, surely. But when you post that online,
everyone benefits. Anyone involved in the project
gets something out of that. And not only that-- I benefit
from every one of you who contributes to your project, as well. So, the effect of open source
is not just linear from can't fix it, to I can fix it, to now,
two people benefit, to three people. It's exponential. Everyone in that little community;
everyone in part of that project benefits if there was something
beneficial in there. Open source is amazing for this reason. It's not just a linear improvement
on collaboration. Multiple people can get involved. So, the thing is, why stop there? What if we went from everyone
in a project winning when there's some good collaboration,
to everyone in the world winning? And I'm not talking
about participation trophies. Okay? I'm talking about actual victory. Actual benefit, actual improvement. What if when we collaborated
on a piece of software, everyone got something out of that? What if every change you contributed
made all software better? Right? What if you didn't just make
one project better, but every project on GitHub? And what if while you were sleeping,
your projects were getting better? Not because people were actively,
synchronously sending you pull requests sitting at their computer,
but because the system was learning? That we're all in this together. And we could passively collaborate
with each other. Why not? We have 10 years of data. You're all putting out
over a billion commits every year. All this knowledge is being shared
in the open, in the public, on GitHub, on open source,
in the community. What if we can take the step
from me contributing to your project benefiting everyone in that project,
to benefiting the entire community? I've never been a fan of "what ifs." I've read some of those
"what if" comic books where Batman is an accountant,
or Wolverine is actually Batman. Not interested in that. I'm not interested in what if
we could all get better. I'm much more interested
in how do we do that and let's start doing that today. So, we've been working very hard
and thinking very deeply about how can we take all of the data
that's out there-- not just code-- and how can we use it
to make everyone better? How can we make not just software better,
but developers better too? How can we benefit each other
while we're sleeping? And to talk about that,
I'd like to introduce to the stage Miju Han from GitHub. Miju? Thank you. ♪ (rock music) ♪ Thanks, Chris. Hello, Universe. My name is Miju Han,
and I'm an engineering manager on the data science team at GitHub. And today, I'm really excited to talk
to you how at GitHub, we're preparing and evolving ourselves for the next phase
of software development. As Chris mentioned, there's a huge amount
of data and activity on GitHub. And that can be focused
on changing how we develop. That's because GitHub
is one of the largest software datasets in the world. And maybe the largest, even. You have created
almost half a petabyte of code. You made more than 1.5 billion commits
in the past year only, and you've merged
over 100 million pull requests. The next phase of our products,
and therefore, the next phase of software development in general,
is turning all of that data into useful and actionable information. We want to capture
the collective intelligence that's sitting inside that data,
and bring it back to you to help us all work better and smarter. So, now, I'm going to try to make
that less handwavy by talking about
how we're going to get there. We want to demonstrate what's possible
with our data by showcasing different applications of it. The first piece of data
I want to talk about is community actions. And that means the things you do,
your interests in your social graph. We're using that data to solve
one of the biggest challenges on GitHub, which is actually finding
a project to work on. Now, we know there are several barriers
to ramping up to GitHub. The first of which is learning Git
and GitHub itself. And even if you do know Git,
and you do get GitHub, there's real fear involved,
like Chris was talking about, when you're making your first contribution
to a public project. And that's really why our community
and safety teams' work is so important. But still, it can be really daunting
to figure out which projects you want to follow,
and ultimately contribute to. And at the same time, we know
that there are a ton of projects that need more help
from enthusiastic people. That's why we're launching a newsfeed
that has better highlights and interesting events from your network. Now, you can see the best highlights
from your network with redesign events in front
of a better and smarter algorithm. But the real magic happens
in the <i>Discover repositories</i> tab. Here, we're personalizing suggestions
specifically for you. Though it's not actually magic,
like I said. It's machine learning. It's science. Populated by things like stars,
contributions, and followers. We'll recommend you new projects
based on your interest each day. We know that there are some of you
who want to go down a rabbit hole of Haskell projects all weekend long. We see you doing this. With the <i>Discover repositories</i> tab,
we can be your guide. And even if you're new,
and you're just starting to explore GitHub--
we'll help you find content that's popular and trending
based on our understanding of the activity of millions and millions
of people doing interesting things on GitHub everyday. We're not stopping there. We're not just going
to throw you on to a repo. We're also launching
some onboarding call-outs to help new contributors
get up to speed on the projects they've just discovered. For example, we're offering standard ways
for maintainers to specifically designate which issues are good ones
to get started with, or which issues really need
some extra help. Together, the newsfeed,
with its improved highlights, the <i>Discover repos</i> tab,
and onboarding experiences make finding projects to follow
and build with, then contribute to, easier than ever. So, sometimes, you want to go deeper
into your own interests. But sometimes, you want to do things
that are totally different. If you're a front end dev,
you might want to dabble in machine learning,
or the opposite is true too. We know that one of the core values
of being a developer-- this is true whether you just learned
to code a few months ago, or you've been working
as a professional software engineer for decades, is always learning
new things, new skills, new technologies. And that's why a second type of data
that I want to talk about is community curation. Information that comes
from our community experts themselves. We're shipping an all new <i>Explore</i> tab which is one of the best ways to see
what's going on in GitHub. It's a great resource for new
and aspiring developers, in particular. To highlight the amazing efforts
across our community, part of the new <i>Explore</i>
is all new collections, which are hand curated by our experts. Collections introduce you to concepts
like user security, or machine learning. And they connect you to resources,
and repos, and people so that you can dive deeper. Another part of <i>Explore</i>
is brand new topic pages. Earlier this year, we launched the ability
for you to label your repos with topics which are either programmatically
generated by machine learning, or manually entered by you. And you all created more than
a quarter million distinct topics to learn more about. Now, you can not only find projects
by relevant topic tags, but you also can learn more
about those topics on dedicated pages. And they're community curated. So, if you want to suggest improvements,
you can submit a PR to the GitHub/explore repo. These features use the data we have
across over 67 million repos. And this is the best <i>Explore</i>
we've ever built. Together, with our newsfeed,
anyone using GitHub can tap into the wealth of knowledge
in the open source community and stay up to date
with the latest technologies. Developers can become
more productive at work. And more people
can become developers if they want to. So, the next type of data
I want to talk about is probably the first thing you think of
when you think of GitHub's data. And that's the code itself. For awhile now, we've done
a lot of the work under the hood
to help make sense of the various parts of code itself, its structure, its grammar, its syntax,
and ultimately, its meaning. Conversational human language,
like English, also has structure, grammar, syntax, and meaning. One way to think about what we're doing
with code is to think about labeling the words in a sentence
with their part of speech. Once we have their parts
of speech identified, the process of creating a sentence
can become modular. That means that we can start
to create sentences by pairing up verb and noun combinations. We can verify that sentences
are grammatically correct. And then, we can take a run-on sentence
and break it down into more digestible and more understandable parts. The first feature to use
our semantic understanding of code is <i>Table of Contents,</i>
which launched earlier this year. It allows you to navigate
directly to methods and functions and pull requests. But the Table of Contents feature
is only the tip of the iceberg of what we can do once we have
a semantic understanding of code. We can start stitching code together. We can simplify it. We can evaluate complexity. Or perhaps, most exciting-- when you make a pull request,
we can tell you all the parts of your code base that are affected. This type of functionality
is going to streamline code review. And the code review of the future
is going to look very different than it does today. It's pretty exciting. Another piece of data we have
is code metadata. That's data that provides
information about code, for example, say, the upstream
and downstream dependencies of a project. You all know that the code that we write
is increasingly connected and increasingly interdependent. If you start to dig into the stats,
it's pretty crazy. Over 75% of our repos use dependencies. And of the ones who do,
well over half of them use more than ten. It is super common for us to see projects
with more than a hundred dependencies. That's a norm on GitHub now. It's yet another signal of the strength
of our community. At the same time, it's a lot to manage. So, to help you manage those connections,
today we're launching the dependency graph in JavaScript, Ruby, and soon, Python. In our redesigned <i>Insights</i> tab,
you can see both which dependencies your project uses,
and if you're a public project, who depends on you in the <i>Dependents</i> tab. But it's going to go further than that we know that once we introduce
dependencies into our projects, there's a bunch of stuff
that we have to keep track of, right? So, we're not just drawing
the dependency graph. We're also enriching it
with useful information. One of those things was inspired
by our inaugural open source survey. You told us that open source users
value security and stability above all else. And realistically,
we know closed source users value that too. And in the open source survey,
58% of you responded that you believe open source
to be more secure. But we all know that security
is not a feature of open source. Security is a process-- of always being aware
and checking on what's going on. So, we're going to make that easier
by doing the checking for you. We're announcing that security alerts
are coming soon to GitHub. With our understanding
of the dependency graph, you don't have to scroll
through a hacker newsfeed to see whether or not you're affected
by the versions that they're announcing. Instead, repo admins
can specify a user or team to manage private security alerts
as they are announced for your dependencies, specifically. And that brings me
to the fifth type of data that I want to talk about today, which is code changes or diffs. Sometimes, we learn the most
about code when you change it, either your code or someone else's code. And we learn even more
if you tell us why you did that. So, we're not stopping with just alerts. We're combining public data sources
with output from our machine learning team to go further and deliver suggested fixes
if a known remediation is available. Sometimes public data
includes a safe version, but sometimes we see reputable sources
doing the same thing over and over. We want to combine both signals so that you can help--
so that we can help you keep your project safe. And over time, our fix suggestions
are going to get smarter and smarter and smarter. We're going to add security alerts
and suggested fixes to both public and private repos. And then, we're going to bring
the dependency graph with the alerts and the fixes to GitHub Enterprise. We know from recent events,
if we already didn't know it before, that vulnerabilities and our dependencies
have real world consequences. But apart from that,
building the frameworks for better security management
is not just a new feature. It's a platform responsibility for us
to make it easier for you to keep your projects more secure. And our security needs change
as our community changes. For example, JavaScript
is not only our most popular language, but if you can believe it,
it's also our fastest growing. And at the same time, we know
that for all software systems, public vulnerability coverage
is just a subset of the true number
of vulnerabilities out there. It's particularly true for JavaScript
for several reasons. First of all, it's a younger community,
and can be legitimately really difficult to verify exploitability. At the same time, we know for a fact
that there exists lists of JavaScript dependency
vulnerabilities that outnumber the publicly identified ones
by at least the hundreds. And that's why the GitHub
open ecosystem is so important. Some of our ecosystem partners
have deep security expertise to keep your project secure,
including data on vulnerabilities that aren't yet public. You can work with Gemnasium,
Snyk, or SourceClear today using their GitHub integrations. As a platform, it's our job to connect
their expertise to your projects. And we can do so much more together
than we can accomplish separately. We're excited to work with partners
like these, and many more with expertise in many different areas. You'll hear more about that tomorrow. I want to end by admitting
that even though I describe these types of data separately
and distinctly, at GitHub, we don't really think of them
as that different. So, the five types of data: Community actions,
community curation, code, code metadata, and code changes. They're really a part
of one connected piece of data, the code graph. Your actions, your curation,
your code, your documentation-- they're all annotations on top
of a giant connected web of software. Or if you want to get technical,
it's a really big, highly enriched abstract syntax tree, or AST. So, our ability to learn
and help you walk the code graph comes from the relevance
and the quality of our data, and that comes from you. It's quality in, and quality out. These new features are the first steps
of how we can give your data back to you. And to be clear, we're not talking
about launching autonomous coding on GitHub today,
because autonomous coding is an AI complete problem. But we are talking about launching
autonomous coding features. And that is where we believe
the next era of development has to go. In the future, we will continue launching
data-powered experiences on GitHub. And then, we'll have more data. And then, we will continue launching
better data-powered experiences on GitHub, and then we'll have
better data and so on. You'll start to see more and more of it
in our core areas like code review, pull requests, the <i>Insights</i> tab,
and even the process of writing code itself. Now, we know the next phase
of software development, it can't happen
without really solid fundamentals. Artificial intelligence
and machine learning-- they aren't going to revolutionize
or take away the work that we all have to do next week. So, for us to be able to bring you
anything actionable from the code graph, we need to fully support developers,
integrators, teams, and businesses. To share more about what we've been up to
in the past year in those areas, I'd like to welcome
Kyle Daigle to the stage. Kyle. ♪ (rock music) ♪ Thanks, Miju. Thank you, Miju.
My name is Kyle Daigle. And I'm the director of ecosystem
engineering at GitHub. I'm so excited to be here
with you at Universe. As Miju said, this past year
has been about changing the trajectory of software development. We want to lower the barriers to entry
for developers to start writing code on GitHub, for businesses to start taking
in open source best practices, and for integrators to work
in our rich ecosystem and build on top of our platform. It's been an amazing year,
but I have more to share with you today. But first, I want to start
with sharing the Octoverse, our yearly update
about the GitHub community. Every year, we're impressed
by the projects you build, the people who contribute
to open source for the first time, and how much our community has grown. There's a lot of fun stats in this, like how our 100 millionth PR
was a documentation update. Or how Microsoft Visual Studio code
had the most contributors this year. It's a beautiful in-depth guide
of the state of the Octoverse. So please check it out
at octoverse.github.com. We're really excited to see
what you all do in 2018. Now, though, I want to share
how we're going to help you have your best year on GitHub. And I want to talk about four audiences. Community, businesses,
integrators, and developers. But first, let's start with community. As Chris mentioned, GitHub started
with open source. We want to make it easier
for everyone to contribute to open source code. We want to help open source contributors,
but we also want to help open source maintainers. And we shipped a variety
of improvements in this way. But first up, we have
the first time contributor badge. Now, when you contribute to a project
for the first time, we'll put a badge next to your name
to signal to the maintainers that they might want to take
a little extra time reviewing your PR. A study showed that a quick response
within the first 48 hours to a first time contributor's PR
is one of the best ways to keep that new contributor
in your project. This has been a really great experience
for new contributors so far. Codes of conduct are an important part
to ensure that a friendly, respectful, and collaborative community
grows around your project. In May, we launched the feature
to make it easier for you to add a code of conduct to your project. You can pick a template on the left,
fill in some details on the right, and then we create the code of conduct
and put it in your repository. Since this launched in May,
we've seen a 50% increase in medium and large open source projects
adopting a code of conduct. This has us really excited. I want to give a shout out
to the GitHub community and safety team who really helped drive
some of this adoption. (applause) But we also want to give you
control about your experience on GitHub. And that includes who you interact with. We've introduced better blocking features
to make it easier to manage the people that you've blocked on GitHub. But also, we'll show you
when you go to a new open source project and want to contribute--
if one of the contributors is someone that you've blocked. It's important that we make sure
you're comfortable, confident, and safe when you start
your open source journey. And better blocking tools
is a great way for us to do that. But it's not just project features. We also built opensource.guide,
which is a bevy of data to help new contributors
and people wanting to start their first open source project. Before building a community,
we want to make sure we set you up for success. And so there's documents in here
about project governance, making money on open source,
and the legal side of open source projects,
where you can learn from successful open source maintainers. Now, one of the best parts about
open source is learning from each other. We answer questions; we solve problems,
and we work together. And today, we have a new way
you can do that, with the GitHub Community Forum. We want to allow you
to start a conversation, ask questions, and help one another. With 24 million developers,
you can write your best code, and support one another in our forum. You can start a conversation
with the community and GitHub staff from across the company. We'll recognize
your contributions in the forums. That way, everyone knows
you're an important part of our community. We've been working on this for a while,
because we wanted to make sure that we got it right. But I'm excited to share
that the GitHub Community Forum is launching October 31st. And that's our update for <i>Community.</i> (applause) The GitHub community
isn't just limited to open source, though. As Miju mentioned, over half
of our repositories are private. Whether you write open
or closed source code, GitHub is the best place to do that. We want to meet you where you are
and be the best place to collaborate on code. Earlier this year, we launched
GitHub for Business, which brought
many enterprise-level features to GitHub.com-- things like SAML single sign-on,
SSH authentication, user provisioning, and an UptimeSLA. GitHub for business makes it easier
for small startups, all the way up to enterprise companies
to get up and running with the Enterprise level tools
that they expect. And thousands of teams
have signed up for Business. Speaking of teams, as Chris mentioned,
today, we have 1.5 million teams. Side by side
with the open source community, and just clicks away from buying
and installing powerful integrations from GitHub Marketplace. We also have our on premises offering,
GitHub Enterprise, which is used by 50% of the Fortune 50. GitHub Enterprise gives you
complete control over your GitHub environment,
hosted on your environment. In September, we released
GitHub Enterprise 2.11. And 2.11 had three major features
that customers have been asking us for: Geo-replication, which allows you
to put your instance into distributed data centers
with multiple replicas. We'll always give the fastest route to you
by choosing the closest server. Governor, which dynamically
adapts Git traffic. So, if you're doing CI builds,
we're not going to stop you from letting a developer do a clone
due to all the traffic. And finally, Hotpatching
is out of early access. Now, you can take your patch releases,
put them into your instance, with zero downtime. So, you can put those security releases
into production a lot faster. Breaking down the walls
between closed and open source is so important to us. Great software innovation
happens at big companies, like IBM, and HP, and Facebook. We'll be talking
in sessions today, as well. So, go check those out. Starting today, we'd like to make it
even better on GitHub Enterprise. If you needed help, or had trouble
with your GitHub Enterprise instance, we've asked you
to put a request in via a portal. But now, we have another option. I'd like to introduce Premium Support
for GitHub Enterprise customers. Now, your admin
can pick up the phone, call us, and start getting help right away. Urgent tickets will get a response
within 30 minutes. And high severity tickets
will get a response withing four hours. We're looking to expand
this offering in the future. But I'm excited to offer this to you
available today by talking to your sales team. And that's <i>Businesses.</i> (applause) It's been a pivotal year
for the GitHub ecosystem. The platform is more powerful than ever,
with features like our GraphQL API, and GitHub apps. Earlier this year, we launched
GitHub Marketplace at our satellite conference in London. The Marketplace has 26 powerful,
full feature developer tools that are built by passionate teams
that want to solve your pain points in your specific workflows. And we're working with dozens
of more companies to go into the Marketplace. 9.3 million GitHub users
have used an integration. And the growth is huge. It's up more than 4 million from just May. More people than ever
are trying integrations. It's because you told us that integrations
are an important part of your workflow. That's why 60% of teams
use an integration. Integrations make your developers stronger
and more efficient. We now have 200 million daily queries
to GraphQL from our own engineers and integrators. With GraphQL, you get the same API,
the same tools, and the same data that GitHub engineers use. And when I talk about integrators,
I'm not just talking about folks like Codec, CircleCI, or Snyk. I'm talking about you-- our customers. Building tools, building workflows,
using our API. And that's why we've seen huge growth
in OAuth apps as well. We're at 400,000 OAuth apps,
which is also up about 100,000 since May. It's an amazing time to build
an integration on GitHub and bring it to market. We want to make it easier for you. So, you can try integrations,
and find your perfect tool. And we're going to do that
with Marketplace free trials. For example, folks like Waffle
can allow their customers to take a look at what
their integration is offering. And then go down and find the plan
that works best for them-- Personal, in this case-- And start a 14 day free trial. We really think this is going to help
customers find the tools that work best for them,
but also give integrators a better way to grow their businesses. With Marketplace free trials,
customers can find the best in class tool and sell it for 14 days,
and then ultimately choose the plan that's best for them. Integrators can choose
whether they want to offer free trials, and customers will get
an easier upgrade flow. I'm excited to share
that free Marketplace trials will be available to all integrators
starting on October 31st. We believe this helps GitHub users
find their perfect integration, integrators to find the right customer. And that's our update for <i>Integrators.</i> (applause) There's a unifying thread--
community, integrators, businesses-- we're all developers. And as Chris mentioned,
there's still too much friction in writing code, reviewing code,
managing projects. Our product and engineering teams
have been chipping away at that friction. Our desktop apps have seen immense growth,
and have amazing workflow updates, like our Git and GitHub
integration for Atom. You can commit code,
manage pull requests, in the world's most hackable editor. In collaboration with Facebook,
we released Atom IDE, an optional set of packages
to bring IDE functionality hacked right into Atom. If not having IDE features
was stopping you from giving Atom a try, now's a great time. We've also rebuilt our desktop application
on Electron, and it's blazing fast. We also completely
open sourced the client. It's the best GitHub
desktop client to date. And we're very excited
to work with the community to bring new features
and evolve GitHub desktop over time. We also brought Git and GitHub
to more developer communities, like our native extension
for Visual Studio. You could connect to GitHub,
clone repositories, list and create pull requests,
and view and reply to pull requests comments. If you're a game developer,
or if you want to be, it's easier to use Git and GitHub
with our GitHub for Unity extension. You can bring your Git repos into Unity, use LFS for large file support,
and then use file locking to ensure that you don't run over
each other's assets. And in collaboration with Apple,
we released a new <i>Open in Xcode</i> button for Swift and Objective C projects. Developer workflows aren't limited
to writing code, though. We spend a lot of time talking
about code, triaging issues, and collaborating on code. As Miju mentioned, as we understand
the semantics of code, we can allow you to browse
pull request gits by method and function. You jump to the method
with the table of contents, you can see all of the other methods
that have changed in the PR, and you can review PRs faster
and more efficiently than before. We added branch protections
with code owners. You can create a code owners file, assign ownership
of file types and folders, and then assign those file types
and folders to teams, individuals, or even email addresses. That way, you can ensure the right people
are seeing the changes in your code. And if you want, you can turn on
branch protections for your PRs to stop PRs from being merged
until a code owner has reviewed this. We've seen many companies
build internal tools for this. And we wanted to offer it
to the entire GitHub community. This past summer, our interns,
with some help from GitHub engineers, made it a lot easier to share snippets. Now, you can go into your code,
select a range, copy a permalink, and then paste that permalink
into issues or pull requests. Then, we'll automatically expand
that snippet so you can see the code around your discussion. It's really slick. We also launched nested teams,
which mirror your org on GitHub. This is what GitHub's
technology team looks like. It starts with the technology team,
that has an application engineering team, which then has other
nested teams within that. A big benefit of this flow
is that the permissions can cascade from parent teams to child teams. And it's a lot easier to create and manage
teams of developers. Today, I want to share something with you
that we've been working on for developers. We want to make it easier to collaborate
outside of the code. So, I'd like to introduce you
to Team Discussions, an all new, yet instantly familiar way
of collaborating with your team. Here, we have the awesome
Panda Rocket team, which now has a new profile page,
and can choose an avatar that works best for them. You can use features that you know
and love, like GitHub Flavored Markdown, browse the members of the team,
the repositories the team has access to, and any nested teams. Or simply catch up with your teammates
in the all new discussion timeline. For the most important messages,
you can pin them. And your team can react to messages,
leave comments, embed images, just like you would expect. If you want to have a bit more
of a limited audience, you can post messages to just your team,
and mark them as private. Team Discussions
have a new profile page, custom avatars, where you can see your team
and any nested teams. You can post messages
to your discussion timeline, pin the most important ones,
post just to your team, and then we'll use
your notification preferences to keep you up to date,
whether that be with the web UI or email. Team Discussions
are currently in private beta. We're working with large and small teams
to try the feature out. I've been using it internally at GitHub,
and it's a really great way to share information
and collaborate with my teams. We'll be sharing more information
about Team Discussions in the next couple of months. So, let's recap. First, we have a better way
to collaborate with our community and GitHub staff,
with the GitHub Community Forum launching October 31st. GitHub Enterprise customers
can purchase premium support by talking to our sales team today. Integrators can offer free trials
for their Marketplace apps starting October 31st. And Team Discussions,
which bring a better way to collaborate with your teams outside
of pull requests and issues. All of these features,
all the features that Miju talked about, this entire event is a huge undertaking,
and we couldn't have done it on our own. I want to thank our sponsors
for making this amazing event possible, and giving us an opportunity
to meet all the GitHub users face to face. Let's give them a round of applause. (applause) Make sure you visit them, too,
because they have a lot of really awesome experiences. I'd like to also thank
the hundreds of GitHub employees that brought these features to you
from across the company. We're passionate about giving you
the best software development and collaboration experience in the world. And that takes a team effort. I'd like to invite you to say "hi"
to the ask GitHub section, where we have GitHubbers
from across the company available to talk to you
about these features, or anything about GitHub. We're really excited to see what you do
with these features, and where you'll take GitHub
in the next year. Thank you so much.
And now back to Chris. ♪ (rock music) ♪ Thank you, Kyle, thank you, Miju. That was a lot.
There's some awesome stuff there. Alright. So, I like writing code. I'm not allowed to really work
on GitHub.com anymore, but I still really like it. I've always loved writing code. Someone once recommended
that I get this book called the <i>The Little Schemer</i>. It's short. And I do all the exercise
in it on paper. Step away from the computer,
step away from the keyboard, and just think and reason
and try to figure out this mind-bending way
of software development. So, I was once on an airplane, and I had my hipster little Moleskine with me
and I was doing <i>The Little Schemer.</i> It was fun, it was a couple
of hours flight. And I got off the flight,
and this really nice older lady next to me said, "Excuse me.
Are you a poet? Or are you a writer? I saw you writing." I was like, "You're going to be very
disappointed with my answer." But no, I was writing code,
actually, on paper. I'm not crazy, I promise. But writing code is an amazing act.
It's challenging. But in some ways, it can be a barrier. And what we're interested in
is the future of coding being less about coding. We used to use this tagline,<i>
social coding</i>, which I've always loved. But as Miju was saying, coding
is not the main event, anymore. Building software is the main event. Coding is just one small part of it. The more data we have,
the more we put onto GitHub, the more we share and innovate together,
we're not really standing on the shoulders of giants as much
as we're all doing this together. We're standing on each other's shoulders. We think the future of coding
is no coding at all. We think autonomous coding
is a very real thing. Software development isn't going anywhere. In fact, software development itself is getting more
and more important than ever. But the actual act of coding,
the act of sitting there and typing or dictating to a screen--
that's not what humans are great at. That's not what we do best. What we do really well is we think. And we solve problems. And we're experts. And we take in input
and we devise a solution. That's the essence
of software development. That's the essence
of overcoming challenges. That's the essence
of building something great. I started becoming a software developer
not because I wanted to learn Scheme, or PHP, or C. I saw a screen. And I want to make things move
on that screen. And when I figured out
that the way to do that was software development,
I really fell in love. But a part of me still cares very deeply
about making something move on a screen. And there are a lot of people out there
that want to make something move on a screen or on a watch
or on a tractor or a jumbotron. But software development is impenetrable;
it's inaccessible; it's hard for them to get up and running. What we think about
is the next 100 million developers, what they want to do,
how we can make it easier for them. And when I say <i>we</i>,
I'm talking about everyone in this room, everyone here, together. The next generation of development
is going to be more powerful and mind-blowing than we can ever imagine,
because the current generation is already astounding. And what we can do by working together,
by sharing our data, by building more on GitHub,
by changing our own technologies, it's we can bring more people
into that fold, who are then doing the same thing
and we're all benefiting. Software is a universe
that we know almost nothing about. We don't know anything
about our real universe, basically. And we know even less about software. But what we're doing here
is we're exploring it. We're charting out new paths. We're finding new planets. We're experimenting with, you know,
teleporters and all sorts of weird things. But ultimately, what we're trying to do
is we're trying to make something happen. We are builders; we are creators;
we're trying to create something that has an impact. At GitHub, we think that we can make
your impact larger by working together, by building the largest
software development community and not just sharing words and ideas,
but sharing insights passively all the time. The next 100 million developers
are going to think about this very differently. And it's not Clippy. It's not someone
that's telling you what to do. It's something more akin to the internet. What we're excited about is--
if you think about Moore's law, if you think about a lot
of the great predictions that came out of the early 20th century--
they were linear. You can imagine screens getting smaller. Moore correctly pointed out
you can imagine chips getting smaller and more powerful. But we could have
never imagined the internet. We could have never imagined
this invisible thing that changes the way we interact
with each other. And then to carry around in our pockets-- I don't think there are a lot of theories
about how society would be transformed when we're all connected. Not just through PDFs and documents,
but through our thoughts and more so, through our code. The future of software
development, we believe, is ripe for a change like that. Coding has been getting
smaller and smaller since the beginning. I mean, we know this.
We used to measure by lines of code. But now, we're standing
on all these great libraries that have come before us,
meaning, we write less code. It's a big part
of why open source is so great. So, if you play that out,
eventually, there's going to be zero code, not for everything, but for some projects,
you're not going to have to code at all. I see that as a little screen prediction. I see that as a linear prediction. What we're really excited about
is the inflection point that we're on the precipice of. There are more developers now than ever. There are more joining now than ever. We're writing more software. We're focusing more on the craft
of development than ever. And all around us, the world is changing. Automation, which is a word
that developers have embraced forever-- I mean automation's
the greatest thing, ever-- means I have to do less stuff--
that is now one of the biggest buzz words in the entire world, right? And who's pushing that forward? Who is automating the robots? Who are the people
that are actually making this change happen? It's us. It's the people in this room. It's you, your colleagues,
the future developers. And what's most exciting to me about that,
is we don't just have to automate warehouses, and doctor's offices,
and all these great things in the real world, which is amazing. We can also automate software development. All the changes with self-driving cars,
with VR, with the world becoming more networked, those all apply equally
to software development. Typing on a computer
is such a low fidelity way of exchanging information with a system. Right? Voice is great. This is why conversational UXs
are taking off. You're experiencing one right now. And in fact, even if you can't hear
what I'm saying, there's a way for human language to be-- there's an argument that human language
is a really great interface into each other. We're really excited about seeing
what this does for the future of software development, and what all
the future software developers do with this, but we're really
most excited about seeing what you're going to do. What comes out of today,
what comes out of the next ten years, what comes out of the next 50 years
of software development. Because we are just at the very beginning. We talk about software
as eating the world. We talk about all these great
technological innovation, and yet at the end of the day,
we're still just hitting buttons on a keyboard. So, I'm going to leave you with a quote,
a Bill Gates quote, which I feel like is appropriate. And this might not even be true. But I'm pretty sure he said this,
or I can at least promise you I read once that someone told me
that he said this, which was-- someone asked Bill Gates--
this is the 80s, when Microsoft is a little bit smaller, but still,
a dominant force. "What makes a good programmer
to you, Bill?" And specifically, "How do you know
who the great programmers are in Microsoft?" And his answer was a bit of an allegory. It was, "If I walked past someone's office
10 times a day, and every time I walked past their office,
they're typing, that raises some concern for me." And they said,
"What do you want them to be doing?" He says, "Well, you know, programming
isn't about typing. We're not typists. Programming
is about thinking. It's about solutions.
It's about solving problems. So, I want to walk by someone's office
and I want to see them typing, but I want to see them thinking. I want to see them considering input,
making decisions, and then using their fingers
or whatever input device they have, to share those insights
with the computer." It's not about the typing.
It's not about the coding. It's about the solving problems,
the building things. And that doesn't mean this is going away. That means this is going
to become more awesome. There's going to be more great tools
and more ways for you to communicate to the computer, to the system
what you want to build, than ever before. We're going to have more control
over the software we build in the future, and it's going to be way better,
because all software is increasing together. A rising tide lifts all boats,
someone once told me. That's what we're trying to do
with the open source community with the entire software
development community. We want to work together
to make all the future generations great, but at the end of the day,
we want to reduce the friction; we want to lower the barriers;
we want to help you build something great, and we want to do this all together. So, we are the pioneers
of the universe's software. The world is going
to get really weird in the future. Software is going to be very different. And I cannot wait to see
what it looks like. So, thank you, everyone. Thank you to everyone that put this on. I hope you have a really great three days. Enjoy GitHub Universe. I'll see you next time.
Thank you, everyone. (applause) ♪ (jazz music) ♪
