GitHub的现在、过去与未来

昨天第二天的主旨演讲里，你也看到过一些这样的例子。

You saw some of those in the second day keynote yesterday as well.

事实上，就在周一，我们今年夏天的实习生团队正式入职了。

And and in fact, you know, just on Monday, our intern class for this for the summer started.

我们分了三批人，分别在不同时间开始，轮流参与实习项目。

We have three groups that start on different days and go through the internships.

这些是刚进入职场、经验还很浅的年轻人。

So those are the very early in career folks that often oh, no.

并不是经常这样。

Not often.

他们大多还在上大学或研究生。

That still go to college or university.

这个项目是我们疫情结束后，恢复线下办公时正式建立起来的——不管是全线下、还是线上线下混合，至少能让他们有机会来我们的旧金山总部，或者太平洋西北区，以及其他全球办公室，跟大家面对面交流。

And this is a program that we institutionalized after the pandemic was over, you could bring people back in person, because obviously, or half in person, where they at least have, you know, a way to meet with folks at our San Francisco headquarters or here in the Pacific Northwest or elsewhere in the world.

所以我们有完整的实习生计划，很多实习生实习结束时都会收到全职录用通知，也有人会回来再干一年。

And so we have an intern program, and often, you know, these interns get a full time offer at the end of the internship, or maybe they come back for a second year.

所以能看到这些年轻人带来新鲜的想法、充沛的精力，还有从大学里学到的最新知识，以及多元的背景，真的特别棒。

And so it's, A, lovely to see that, you know, those folks that bring fresh ideas, a great amount of energy, you know, the latest learnings from College University, and often, you know, a different, you know, diverse background into the company.

而且，像韩国这样年轻一代的员工，常常会给团队带来全新的视角，直接说：‘咱们为什么不试试这个？’

And, you know, come in and often, you know, the folks, you know, that are younger in Korea, bring a new perspective to the team and say, here, this is, you know, why don't we try this?

或者：‘我想孵化一下这个点子。’

Or I want to incubate this idea.

所以我们特别高兴公司里既有经验丰富的老员工，也有充满活力的新人。

And so we are excited about having this kind of like both junior and senior population in the company.

这不光是工程团队如此，你看销售和市场部门也是一样。

And it's not only twin engineering, you know, it's the same if you look into sales or into marketing.

现在的市场营销方式，跟五年前、十年前早就大不一样了，那时候传统媒体还占主导地位。

Obviously, the way, you know, marketing works today is very different than it was, you know, five, ten years ago when the press, you know, traditional media played a much bigger role.

现在你得上播客、做YouTube、玩TikTok，得跟上当下的节奏。

Today, you gotta be, you know, in a podcast and you have to be on YouTube and TikTok and play like today.

就得跟上现在的发展。

Just like today.

但你越来越常看到这种情况发生。

But you see more and more of that happening.

当然了，招刚入行的年轻人，他们总会带来新点子和宝贵的意见。

And of course, you know, when hire people earlier in career, they give you those ideas, they give you that input.

你懂的，跟很多公司的人聊过，总免不了有争论。

You know how it is, you talk to a lot of people in companies, there's always a debate.

一方坚持老办法，毕竟像微软这样五十多年的老公司，一直这么干过来的；另一方则提出新想法。

There's always a debate between those that are defending how we've always done it in a fifty year old company like Microsoft that obviously exists.

他们说：我同龄人里，根本没人看电视了，更别说CNBC，全都在刷三分钟的TikTok视频。

And those that come in and say, hey, you know, nobody in my peer group, you know, watches TV anymore or CNBC or whatever, and they're all watching just, you know, three minute videos on TikTok.

我觉得这特别重要。

And so I think that's really important.

我们正努力在初级工程师和资深工程师之间保持一个良好的平衡。

And we're trying to have, you know, a nice balance between early career engineers, senior engineers.

我们有不少资深专家，他们都在为我们的平台贡献力量。

We have, you know, a number of distinguished engineers and they all contribute back to our platform.

不，我特别喜欢，因为我以前当项目经理和工程师的时候，有实习生真的特别提士气。

No, love it because like when I worked both as an injury manager or as an engineer, having an intern, it's just like boosted morale.

我们整个人都更有干劲了。

Like we were so much more enthusiastic.

我可不是说我们因此多做了多少活儿。

I'm not going to say that we necessarily did more work.

可能确实多做了，但关键是他们带来了新想法，回头看那些实习生，真的特别有成就感。

I think we might have, but we got fresh ideas and it's just so rewarding looking back at those interns.

现在，好多年过去了，我还能见到他们。

You know, I now see them many, many years later.

有些人已经成了首席工程师，有些人当上了CTO。

Some are now principal engineers, some are CTOs.

但很多不太懂技术、没体会过实习价值的人，他们会想：现在不是都说AI多高效吗？连微软都在大会上讲AI同事了。

But the one question that a lot of people who are maybe less technical than you and who have not seen the benefit of internships, they're thinking like, Oh, I'm hearing all these AI things, including Microsoft is saying it's so efficient.

他们现在都在会上谈什么AI同事了。

Know, they're now talking about AI colleagues on the keynote.

为什么呢？

Why?

现在不只是微软的人这么说，谷歌那边也有人讲，说AI现在已经能达到初级工程师的水平了。

And now this is not Microsoft people, but we're hearing people at Google say like, oh, it's now at the level of a junior engineer.

他们就开始想，也许可以先别招应届生了，因为有人告诉他们，这些所谓的专家都说，AI现在本事已经跟初级工程师差不多了。

And they're thinking, maybe let's hold off on hiring new grads because they're telling us, you know, some of these so called experts that it's now at the level of a junior engineer.

所以也许我们真不需要初级工程师了。

So maybe we don't need junior engineers.

那你对那些还在这么想、信息还不够全面的人，有什么建议？

What would you suggest to people who are in this thinking and maybe not as informed?

因为你明显是觉得这事儿值得做。

Because clearly you've decided it makes sense.

而且我知道，这情况不适用于所有人，但他们的顾虑确实是真实的。

And, you know, this thing doesn't apply, but their thinking is real.

我觉得这种想法在很多方面是颠倒的。

I think that's backwards in many ways.

我觉得，实际上现在上高中、大学，甚至更早开始接受教育的孩子们，他们能更快地接触到AI。

I think actually folks that go to high school now or to college or even kids earlier in their education, they get to use AI much faster.

而且他们能理解并接受它，因为他们是以一种开放的心态来对待这项技术的。

And they get it because they are, you know, taking this with an open mind.

没必要非得按老办法来，千万别动核心系统。

Don't have to this is how we always done it, don't touch never touch the cutting system.

他们没经历过那种情况，就是管理层或者工程师自己做了些改动，结果导致大规模服务中断之类的问题。

They haven't been in an experience where some change that was applied, you know, from upper management or from the engineers themselves has led to, you know, a big outage and things like that.

所以他们的思想更开放。

So they're more open minded.

就像我们之前讨论过的，你看现在的媒体就能发现这一点。比如孩子们更愿意快速浏览各种内容，只看他们想看的。而像我们小时候，电视节目都是线性的，只能在客厅看爸妈决定今晚播什么。

You know, you kind of see that when you look at media, as we already talked about, like kids are much more open to just scoring through shots and consuming the content they'd like to consume while, you know, when you and I were a child, we had linear TV and you got to watch on the living room TV, what your mom and dad decided is on tonight.

对吧？

Right?

所以他们拥有更大的自由度。

And so they have much more freedom.

我觉得这最终会让刚入行的工程师或者实习生一进来就带着提示工程的思维，熟悉各种模型的使用。

And I think this will lead to ultimately junior engineers coming or interns coming into the companies and thinking in like prompting skills, you know, like experience with different models.

你知道，实习生并不意味着我之前没在别的公司干过。

Like, you know, intern doesn't mean I haven't worked for another company before.

这可能是我第三次、第四次实习，或者我早就和一群同学自己搞项目、开发应用了。

It might be my third my second or third internship, or I might have already been coding with, you know, a group of students on on my own project, on my own app.

所以他们会带来很多新鲜的想法和外部视角，这对市场竞争至关重要。

So you get a lot of good new ideas and outside perspective that is ultimately crucial to compete in the market.

反过来，这些实习生回到学校后，已经有实际项目的经验了。

And I think vice versa, you know, these interns then go back into college and they have worked on something real.

我上大学的时候就总感觉，得早点进业界，看看真实的工作是怎么做的——毕竟学校里虽然教编程，但根本谈不上工程体系。

I remember my time at university, I always had the feeling I gotta get out in the industry and learn how it's actually done because while, you know, there's, you learn coding in university, but you don't really have an engineering system.

你不会遇到技术债。

You're not having tech debt.

也不会去维护遗留代码。

You're not working on a legacy code base.

进了公司当工程师，就意味着你要接手别人的代码，现在经常是 GitHub 上十几年前的代码，你还得去理解别人当年做的那些决定。

Becoming an engineer in a company means you're working on somebody else's code, often now, you know, GitHub seventeen years old code, and you have to follow-up on decisions other people made.

但这可不是大学里学编程的方式。

And that's not how you learn coding in university.

所以对我们来说，既需要公司里有这些新鲜的想法，也需要回馈给那些将来可能成为 GitHub 用户的年轻人。

And so I think it's both for us important to have those fresh ideas within the company, but also for us important to give back to those that in the future become GitHub customers.

我特别认同。

I love it.

我觉得这其实也是最省钱的做法，毕竟新人的薪资也不会高到哪儿去。

I feel it's also just a very, it's the cheapest way to do it, just like it, you know, you're not going to have the highest salary for the new people.

这么想确实有点傻。

This is a silly way to think about it.

我最近刚和产品经理聊过，你刚说完，我就有种似曾相识的感觉。

I talked with the product manager recently and I just like had a deja vu when you said it.

那位产品经理当时也在做关于 Z 世代的研究，她说的就是这个事儿。

This product manager was saying, she was saying, this is while we were doing the Gen Z research about the latest generation.

她说，我特别喜欢Z世代。

She said, I love Gen Z.

她常说，这么多年当产品经理，我总坐在工程师面前说：要有好的产品思维，要站在用户角度想。

She's like, she's like for years as a product manager, I'm sitting in front of engineers telling them, oh, you know, good product thinking, think about the customer.

可他们总是说：你直接告诉我们该做什么就行。

And they're like, just tell us, you know, what we need to do.

但这一代新人进来后，他们有自己的想法。

And she's like, the new generation comes in and they have opinions.

他们会说：我觉得我们的用户会喜欢这个。

They're like, I think our customers would like this.

我亲自试过竞争对手的产品。

I have tested a competitor.

他们现在是这么做的。

Here's what they're doing.

她就说：这太棒了。

Here's, and she's like, I love it.

如果雇用这些人，同时像你说的那样，抛开那些过时的思维，说不定就能培养出下一代软件工程师。

Like they, so I I I I if, like, by hiring these people and actually just ignoring, as you say, the backward thinking, you might get the next generation of of software engineers.

我觉得，从某种程度上说，Z世代已经有点老了。

Gen z is already too old, I think, to some degree.

有道理。

Fair.

因为Z世代，我记得是从1980年左右开始的吧。

Because Gen z, I think, starts 1980 or something like that.

应该是千禧一代和Alpha世代吧？

The millennials, Gen Alpha, right?

现在都六十岁的人还在写代码呢。

Like the 60 years old are coding today.

所以那应该是Alpha世代，再往后，说不定就是什么B世代了。

And so that's Gen Alpha or, you know, soon the whatever the Gen B, guess is the next one.

不过你说得对，你接触到的这批人，没在Commodore 64或者早期PC上学编程，没有那种底层思维，他们成长的环境也不一样，是智能手机和随时在线的一代人。

And so, but you're right, you know, you're getting folks that didn't learn to code on a on a on a Commodore 64 on a PC that, you know, have a lot of low level thinking, but also, you know, learned in different environment than those, you know, that grew up with smartphones, that grew up with being always connected.

他们只是，从期望的角度来看，他们看待这些系统性问题的方式不同，视角也不一样。

They just have, just from an expectation perspective, they're looking at this often systems problem they're trying to solve, but the different, with a different perspective.

对，我在想一个有点傻的问题，你是更愿意雇一个有传统编码背景、大学科班出身、经验丰富的工程师，还是找一个年龄相仿但经验相当的？

Yeah, I wonder just like a silly thing, would you rather hire an engineer with the same years of experience of like someone who has, you know, like has traditional coding and learned in university or same years old.

你是在大学里学的，做过一些大学项目；而这位工程师或应届毕业生，虽然也上过大学，但在此之前，他们已经有五年实际构建程序和解决障碍的经验，甚至搭建过上百人规模的东西。

You learned in university and did some university projects or this engineer or this fresh grad who did the university, but they actually have before that five years of building programs and roadblocks, and they actually built this, like, 100 person thing.

关键是这个人带来的技能和思维方式，他们看待问题的方式完全不同。

It's like the skills that that person brings and the the mindset, you know, the way they think about things.

还有第三类人，而且有很多人，比如在微软和GitHub，他们并没有接受过正规教育，要么是中途辍学，要么是其他情况。

And there's a third group, and and there's lots of folks, you know, at Microsoft and GitHub that don't have a formal education and either dropped out another event.

对吧？

Right?

这又回到了我们之前讨论的远程优先公司的话题。

That's that goes back to the earlier discussion about being a a remote first company.

你招聘员工，是因为他们对产品充满热情。

You hire people because they're passionate about the product.

我们招人，是因为他们在 GitHub 上的贡献图很漂亮，因为他们确实为 Ruby on Rails、Git 这些开源项目做过实际贡献。在 GitHub，我们一直倾向于聘用那些长期参与维护 Git 并和开源社区紧密合作的人。

You hire people because they have a great contribution graph on their GitHub profile, because they have shown they contributed back to the Ruby on Rails code base, to the Git, you know, open source code base where, you know, at GitHub, we traditionally have employed folks that are spending a lot of time on maintaining Git together with the open source community.

所以我觉得，真正对我们重要的，是候选人是否具备真正适合 GitHub 的思维方式。

So I think a lot, you know, what actually plays a role to us is that folks have shown the right mindset to join GitHub.

如果你的 GitHub 贡献图没有绿色，这比你有没有在两家公司各干了五年重要得多。

If you don't have a green contribution graph on your GitHub profile, that I think matters more to us than whether you have five years at one company and five years at another company.

当然，我们还是会安排候选人走完整的面试流程。

Of course, we, you know, take people to an interview loop.

而且我们越来越在思考，怎么把 AI 用在面试流程里。

I think increasingly we are thinking about how do we leverage AI within the interview loop.

从我角度看，这没什么不对。

There's nothing wrong about that from my perspective.

事实上，如果你最近想进一家科技公司，很可能会被要求展示你的提示词技巧、Copilot 使用能力，比如怎么用我们这周推出的编码助手模式或智能代理来完成任务——因为未来工程师的目标，已经不再是事事从零开始写了。

In fact, I would say if you want to, you know, get a job in a tech company very soon, you're going to be asked to show your prompting skills, Copilot skills, if you will, and how you use something like agent mode or the coding agent that we introduced this week to get the exercise done, you know, to basically Because the goal of the future engineer is no longer to run it all from scratch.

现在的目标是，把你的提示技巧和开源代理库结合起来，比两三年前的人更快地解决问题。

And the goal is to combine their prompting skills and agent open source libraries into getting that problem solved much faster than they could have done two, three years ago.

所以，以上就是一些有趣的事实。

So with that, these were some of the, like a bunch of interesting facts.

我想先聊聊GitHub的过去，然后再谈现在和未来。

I wanted to talk about the past and then later the present and the future of GitHub starting with the past.

说到Git，我之前和Linux内核维护者Greg做过一期播客，他讲了Git在2005年是怎么诞生的故事。

So Git, I did a podcast episode with Linux kernel maintainer, Greg and he told a story about how Git was created in 2005.

其实最近还有一期播客，是GitHub的一位资深工程师采访了Linux的创始人林纳斯。

In fact, recently there's a podcast with a GitHub, a staff engineer at GitHub, interviewed Linux Store Worlds.

是的。

Yeah.

2005年的时候，Linux内核项目的开发者们对当时的版本控制系统感到非常不满。

In 2005, Linux Store Worlds got frustrated with source control for the Linux project specifically.

我们可以从历史中看到一些商业层面的东西。

There were some commercial things we can see history.

他十天就搞定了。

He sat down in ten days.

他写了Git，当然是开源的。

He wrote Git, which was obviously open source.

本来是专门为Linux开发的，但发布后发现特别好用。

It was meant for Linux only, but they released it and turned out it's pretty good.

GitHub是2008年左右成立的，我记得是这样。

GitHub was founded in, I believe, 2008.

你能跟我讲讲那些早期的日子吗？

Can you tell me about these early days?

后来发生了什么？

What what what happened then?

你从和早期创始人们的交谈中了解到什么？

What do you understand from talking with the early founders?

第一次提交是在2007年10月。

The first commit was October 2007.

那时候，距离Linux推出Git已经过去了大约两年。

So it was about two years after Linux had done Git.

对吧？

Right?

从2007年10月到2008年2月左右，他们开始在Ruby on Rails社区里进行内测。

And then October 2007 to, I believe, February 2008 is when they started beta testing it with with folks in the Ruby Rails community.

对。

Mhmm.

到了4月，GitHub的公开版本正式上线了。

And then April is when the public version of of GitHub launched.

所以发展速度真的很快。

So it was really fast as well.

你看，从10月到4月，大概也就六个月。

You know, October to to April, roughly six months.

如果你回溯那段历史，我记得是克里斯、汤姆·普雷斯顿-沃纳和克里斯·冯斯特鲁特在酒吧碰面，看到Git之后意识到，当时根本没人提供一个能同时托管开源和私有代码仓库的地方。

You know, if you go back, you know, to to the history books, it's Chris and Tom Tom Preston Werner and Chris Vonstrutt meeting in a bar, as as I remembered, and and having seen Git and and and figuring out that there isn't a place where you can host your open source repositories and your private repositories together.

当然，那时候已经有SourceForge这样的平台了。

There was obviously things like SourceForge.

是的，我当时

Yeah, was I

那时候最流行的开源平台，但用起来特别麻烦。

the most popular open source platform back then, but also, you know, painful to use.

我觉得这么说没错，我自己也把几个项目放在SourceForge上。

I think that's fair to say, like those that I had a couple of projects on source as well.

它其实是为早期的网页环境设计的。

It was kind of designed for different era of the web.

没错。

Yep.

没跟上时代的转变，后来所谓的Web 2.0

And and didn't and didn't make the jump and then what ultimately, you know, became known as as web two

或者云原生时代。

point zero

就出现了。

or cloud native.

所以我觉得当时的想法是，好吧，Git已经出现了，Git很棒，但我想托管它，又不想自己去架设服务器、安装后端、管理SSH访问这些麻烦事。

And so I think the idea was, okay, Git is here, Git is amazing, but I wanna host it without, you know, setting up a server and installing, you know, the backend and managing, you know, SSH access.

于是他们就围绕这个想法开始构建。

And so they started building around that idea.

GitHub之所以一直是GitHub，就是因为他们始终把开发者放在第一位。

What always made GitHub GitHub is that they put the developers first.

就像你去看早期的Wavyack机器，看看最初的GitHub主页，它其实并不花哨。

Like if you go on the Wavyack machine and look at the first, you know, GitHub homepage, it isn't very fancy.

它看起来就像一个提交日志。

It looks like a commit log.

就是很简短地宣布一下，嘿，我们发布了这个新功能。

It's very short announcement of, hey, you know, we shipped this new feature.

欢迎试用，然后告诉我们你的想法。

Try it out and let us know what you think.

对吧？

Right?

对。

Mhmm.

关于我们的标志，就是现在大家熟知的 Octocat，这背后有个挺有意思的故事。

The story about, you know, our logo, what is now known as the Octocad, you know, is a funny one.

我是从《Acquired》播客里听说的，他们了解到推特的创始人是怎么搞到他们标志的——从一个英国设计师的图库网站上买了一张图。

And I learned that actually from the Acquired podcast because they learned from the Twitter founders how they got their logo when they bought it on some stock graphic page from a British designer, I believe.

于是他们就去找这位设计师的其他作品，挑了张章鱼和猫的混合图，把它做成了标志。

And so they looked, you know, for other graphics that the same designer had done and bought, you know, this hybrid of an octopus and a cat and made that the logo.

作为一个资源有限、非常拼的初创公司，他们手上有项很酷的技术，可能将成为版本控制的未来。

So there was a lot of, you know, as a bootstraf startup that's scrappy, that has a cool technology that might become the future of version control.

然后他们打造了如今被称为云原生公司的模式。

And then they built what is now known as cloud native company.

发展得特别快。

And it grew fast.

那时候，这个产品可能是市场上最快实现产品契合度的。

And back in the day, probably the product was the fastest product market fit.

现在有不少公司也做了类似的东西，

Nowadays, there are other companies that have built similar,

但时代已经不一样了。

but It's a different time.

现在的环境跟以前完全不一样了。

It's a different time now.

当时它发展得这么快，简直让人难以想象。

And I think it was unheard of how quickly it spread like wildfire.

2008年的时候，我还在汽车行业的公司上班。

I was in 2008 still working in the automotive industry.

那时我在博世，头一年根本没用过GitHub。

I was at Bosch, so I didn't use GitHub in the first year.

我后来离开博世，不是因为GitHub，而是因为iPhone的SDK出来了。

And then I quit Bosch at the 2008, not because of GitHub, but because of the iPhone SDK.

之后我就成了一个为德国公司开发App的独立软件供应商。

And it became, you know, an ISV building apps for German companies.

所以我记得我是在2009年初创建的GitHub账号。

And so I created, I think my GitHub account in early two thousand and nine.

我们可以查一下，大概是2009年3月或4月。

We can look it up, I think March or April 2009.

后来我参加了2009年在拉斯维加斯举办的Ruby和Rails大会，看到克里斯·冯·斯特雷奇正在介绍GitHub以及他们正在做的事情。

And then I was at RailsConf, the Ruby and RailsConf in Las Vegas in 2009 and saw Chris Von Stretch giving a talk about GitHub and then what they were up to.

可以说从那时起，我就成了GitHub的粉丝，也开始在自己的项目中使用GitHub了。

And that's, I would say, when I became a GitHub fan and and when I started using GitHub in in my projects.

但在此之前，你得用一些自托管的工具，还得把它装到某个根服务器上，或者可能你已经有云服务了，然后所有东西都得自己维护。

But until that point, you would use some some help self hosted tool, you know, and install it on some root server or maybe you already had the cloud and and and may maintain all that yourself.

从那以后，大家就直接用GitHub登录，然后创建代码仓库就行了。

And ever since, people just, know, log in with GitHub and then create repo.

对。

Yeah.

我查了一下能找到的历史资料，最让我惊讶的是，这家公司最早是在2007年成立的，而服务是在2008年上线的。

When I looked through the history of just the things that I could find, what struck me as like so like as the first company was in 2007 and 2008, the service was launched.

我记得你好像说是三月，或者差不多是四月。

I think you said March or something like April.

不好意思。

Sorry.

到了2008年，Reddit、雅虎、推特和脸书都已经用上GitHub了。

And already in 2008, Reddit, Yahoo, Twitter and Facebook already onboarded.

脸书让我挺意外的，因为我知道他们用Mercurial，结果发现他们只是拿它来管开源项目。

Facebook was surprising to me because I knew they used Mercurial, but apparently they use it for their open source things.

那时候，这些公司可都是最时髦、最前沿的。

And these are, these were very hip and very trendy companies at the time.

当然了，就像你刚才说的，到了2009年，GitHub就成了大家的首选。

And obviously from there on, as you said in 2009, this was the obvious place to find.

你觉得它当时为啥这么火？

Why do you think it was so popular?

到底是什么原因让它这么受欢迎？

Like what was the reason?

它是开源的吗？

Was it open source?

那时候Git还没流行，2009年之前根本没人当回事，现在我们知道Git有多好用。

Was it, Because Git wasn't even like back by talking 02/2009, like now we know Git is great and it works.

但那时候谁都不确定它能不能行。

But back then this was not clear.

当时用的是SVN。

There was SVS.

大家都用SVN。

Everyone was using SVN.

我记得那时候微软还大力投入了自己的Team Foundation Server。

I remember at the time and Microsoft had their own really heavily invested TFS, Team Foundation Server.

为什么这个产品正好踩中了开发者的需求，大家一下子都觉得GitHub才是正经选择？

Why do you think this product market fit just hit so so bad and devs were like, yeah, GitHub is the place to be?

Git解决了我们用其他版本控制系统时遇到的所有痛点。

Git solved the pain point that we had with all these other version control systems.

像Subversion和TFS，它们原本都有自己的一套版本控制系统，直到后来才加上了对Git的支持。

You know, subversion TFS, you know, had its own version control until much data when they added git support

没错。

Yes.

用起来特别麻烦。

Were painful to use.

尤其是当多个团队在同一个代码库上协作的时候，那真是又慢又折腾。

And they were painful to use, especially when you had multiple teams working together within the same code base.

Git引入了一个全新的理念：你本地就拥有完整的代码仓库。

Git bought this concept of you have the full repository on your machine.

即使没有网络，你也能自由地在不同分支间切换。

You can switch from one branch to another, even without having an internet connection.

所有操作都直接在你的电脑上完成。

And you did always everything on your computer.

你可以同时在多个分支上做修改，等准备好了再推送到远程，或者跟同事分享。

So, you know, you could make changes to multiple branches and then pushed upstream or shared with your coworkers.

某种程度上，GitHub 其实是软件开发工具的一个讽刺——你有 Git 这种去中心化的系统，结果全世界现在却都依赖一个中心化的平台，所有人都往这儿推代码。

And in some ways, you know, GitHub, I think, is the irony of software development tools because you have a decentralized system like Git, then you have a central hub that the world depends on today and where everybody pushes to.

所以，去中心化这个概念，听上去在开发者聊天时特别酷，特别有吸引力。

So this notion of decentralized systems is still something that sounds great when developers are chatting about technology.

但我觉得，人本质上还是想有个家。

But I think humans are longing for home.

现在 GitHub 的口号就是：我们是软件开发者的家，大家在这里人与人协作，以后还会有人和智能代理协作。

And, you know, today at GitHub, have the saying, we're the home of software developers, where they collaborate human to human and soon human to agent.

我觉得这一点起了很大作用。

So I think that played a big role.

当时出现了一个新的版本控制系统，大家之所以愿意主动去试，是因为他们对用 WordPress 那些老工具早就烦透了。

You had a new virtual control system that people were intrinsically motivated to try out because they were frustrated with using some version WordPress.

或者连 CPS 都算上。

Or even in

还有类似的东西。

CPS, you know, and something like that.

就是想找个新的办法来解决这个问题。

And just wanted something new to solve that problem.

然后注册个账号试一下，特别简单。

And then it was just easy to shoot an account and try it out.

比如浏览代码库、点开文件树这些界面操作，GitHub 在这方面比以前的工具进步太多了，用 Ajax 加载，速度飞快，不用等整页刷新。

You know, even user interfaces like browsing the repo, clicking the file tree, GitHub, you know, innovated a lot in that compared to what was there before and making that Ajax request so they would load really fast and you wouldn't wait to follow full page reload.

GitHub 还首创了拉取请求这个功能，你可以 fork 别人的项目，自己改一改。

GitHub invented the pull request, you know, this notion of that you can fork people, make your modifications.

如果你想保留自己的分支，随时都可以。

If you'd like to keep your fork, you can just do that.

这简直太棒了。

That's totally cool.

或者你也可以把修改发回去，提个拉取请求。

Or you can send a pull request back.

我们其实是请其他维护者在合并之前，先看看你做的改动。

So we're asking the other maintainer to merge in your changes before that diff files were exchanged.

本集由 Augment Code 赞助播出。

This episode is brought to you by Augment Code.

你是个专业的软件工程师，靠感觉可不行。

You're a professional software engineer, vibes will not cut it.

Augment Code 是专为真实开发团队打造的 AI 助手。

Augment Code is the AI assistant built for real engineering teams.

它能读取你整个代码库，数百万行、上万文件，所有建议都精准贴合上下文，让你专注不被打断。

It ingests your entire repo, millions of lines, tens of thousands of files, so every suggestion lands in context and keeps you in flow.

借助 Augment 新推出的远程代理，你可以一次性安排多个任务——修复 bug、开发新功能、重构代码，然后合上笔记本，回来时已经收到待审的拉取请求。

With Augment's new remote agent, queue up parallel tasks like bug fixes, features and refractors, close your laptop, and return to ready for review pull requests.

别的工具卡壳的时候，Augment Code 却在飞速前进。

Where other tools stall, Augment Code sprints.

Augment Code 从不训练或出售你的代码，你的团队知识产权始终属于你。

Augment Code never trains or sells your code, so your team's intellectual property stays yours.

而且你根本不用换工具。

And you don't have to switch tooling.

继续用 VS Code、JetBrains、Android Studio，甚至 Vim 都行。

Keep using Versus Code, JetBrains, Android Studio or even Vim.

别靠感觉去雇一个 AI。

Don't hire an AI for vibes.

选一个最懂你和你代码库的助手。

Get the agent that knows you and your code base best.

前往 augmentcode.com/pragmatic，免费试用十四天。

Start your fourteen day free trial at augmentcode.com/pragmatic.

我觉得，很多人忽略了一点，就是真正理解这一点。

Well, think this is one of the biggest thing that people miss as I understood, like understanding.

Linux 内核的开发用的是 Git，GitHub 上很多 Git 功能其实都源自那里。

So like Linux Toro is designed Git and a lot of GitHub or the Git functionality comes from there.

但 Linux 的工作流程是靠邮件来推进的。

But the Linux workflow was email based.

其实 Git 里有一个专门的命令。

So actually in git there is a command.

我不记得具体那个命令了，但好像是用邮件发送包含你修改内容的补丁包。

I don't remember the exact command where I think it's something email where you send an email with your changes bundled, with your git changes bundled.

Linux 就是这么运作的。

And that's how Linux works.

他们纯粹靠邮件来协作。

They just use email.

但 GitHub 完全不是这么做的。

And GitHub does not do this.

事实上，GitHub 推出了拉取请求这个功能，这至今仍是 Linux 和 GitHub 使用 Git 的核心区别。

Indeed, GitHub invented the pull request, which is a big difference between even today how Linux uses Git and GitHub does.

这确实是一次巨大的突破。

And yeah, it was a smash.

拉取请求是什么时候发明的？

When was the pull request invented?

你知道吗？

Do you know?

是那时候吗？

Was it

早期就出现了？

early on?

我查了一下时间点。

I'm getting the date from it.

我觉得是在GitHub成立一年左右的时候。

I think it was a year or so in into GitHub.

确实挺早的。

It's pretty early.

肯定不是刚上线就有了。

It wasn't definitely, it wasn't there on day one.

是后来才推出的。

It it came sometime later.

我们可以查一下，然后加到节目笔记里。

We can, you know, look it up and add add to the show notes.

但那时候这还是个新鲜事。

But it was a new thing at the time.

我觉得这对软件开发者来说最终是一种解放——你提交一个合并请求，如果维护者不喜欢，直接关闭就行，或者就搁在那里不管。

And I think it's ultimately liberating for for software developers where you send a pull request and, you know, if the maintainer doesn't like it, they can just close the pull request or just leave it open.

是的。

Yeah.

其他人也能看到，如果他们想用，可以直接去你的分支里拿过去继续用。

Others can see it, you know, and and if they wanna pick it up, they can just jump over to your fork and and keep using it there.

所以你会看到，很多人干脆就让自己的分支独立运行，因为他们不想承担参与主项目的责任。

And so you see, you know, see a lot of that also happening that people just keep their forks independent because they wanna they don't wanna have the obligation to to engage with the main project.

比如我有几个分支，都是为了我自己的兴趣项目做了一些小修改。

Like, I have a bunch of forks where I made some small modification for my own, you know, hobby project.

我觉得这些改动没必要非得合并回主分支。

I don't see, you know, I don't see a big reason that that needs to go back into the main branch

因为有些

because some

这部分可能也靠一些临时凑合的办法。

of that might be just with hackery as well.

对吧？

Right?

这样一来，想要协作的开发者之间就更容易合作了。

And so it makes it much easier for developers that want to collaborate to collaborate with each other.

对其他人来说，这也让参与开源、学习开源、自由组合使用变得更为平等开放。

And for the others, it democratizes how they engage with open source, how they learn from it, how they mix and match and so on.

那关于这种聚集现象，

So what about kind

如果我这么理解的话，开源显然是其中一部分，这种新的协作方式，尤其是在开源领域，但还有一件事你没提到，我想知道你是否也觉得，哪怕你用 GitHub，也随时可以迁移到自己的 Git 服务器。

of a gathering, if I'm putting it together, like open source was clearly one thing, this new collaborative workflow, especially with open source, but also, and I think one thing you didn't mention, but I wonder if you're, if it is a part is how even if you use GitHub, you can always move to your own Git server.

迁移起来非常简单。

It's very easy to migrate.

而且它还支持离线使用。

It also works offline.

所以，即便GitHub宕机了，没错，它是个中心枢纽。

So even if GitHub is offline, like, yes, it's a central hub.

但如果GitHub出故障了，说真的，我们肯定都不乐意。

But if there's a GitHub outage, I mean, we're not happy about it.

现在抱怨的人其实不多，老实说。

People complain these days and there's not many of them to be fair.

但就算真发生了，我是说，哦，我想我还能在本地继续工作。

But even when that happens, I mean, oh, I guess I can keep working locally.

我可以继续推送代码。

Like I can keep pushing.

所以你可能根本不会察觉到，因为你在本地操作。如果只是三十秒或一分钟的中断，当然不是鼓励这种情况，但你很可能注意不到。

So you might not, it's just, again, if it's just like a thirty second outage or a one minute one, not advocating for it, but you might not even notice because you're just like doing your local thing.

所以作为一名开发者，我觉得我们很看重这一点：知道自己不会被锁定，而且它还是免费的。

So think as a developer, like, I think we appreciate when we know we are not locked into by the way, it's free.

很多这类工具确实如此。

Like a lot of the Yeah.

抱歉，不是说GitHub本身，而是开源项目一直以来都是免费的。

Sorry, not not GitHub per se, but for open source, was always free.

对吧？

Right?

开源项目从来都是免费的。

It was always free for open source.

你可能会说，GitHub开创了一种非广告驱动的免费增值模式，而传统意义上的免费增值通常是靠广告的。

And you you might say GitHub invented a version of the freemium model that is not ad based, where traditionally freemium is ad based.

没错。

Yes.

免费用户能免费使用一些功能，但会看到广告；付费用户则能去掉广告，获得更多功能。

The free users get it get something for free with advertisement, and then the paid users get get rid of the advertisement and get more features.

GitHub最初把所有公开操作都设为免费，因为这有助于社区发展，显然也促进了它的社交网络属性，对吧？

GitHub originally had the separation between everything you do in public as free because it helps the community, obviously helps the social network, quote, unquote Yes.

或者说是GitHub的成长。

Or a GitHub growing.

当你需要私有仓库时，就得付费了。

And then when you wanted private repositories, you you had to pay for them.

微软收购后不久，2019年初，我们就改了这个政策。

Shortly after the acquisition, early twenty nineteen, we changed that.

不再让用户为私有仓库付费，而是直接免费开放了私有仓库。

And instead of paying for private repositories, we actually made private repositories free as well.

是的，我们确实这么做了。

We did, yeah.

因为很多独立开发者给了我们反馈，尤其是你走遍世界各地的时候。

Because we had a lot of individual developers giving us feedback, especially, you know, when you travel around the world.

对美国人来说，每月四美元可能不算什么，但对其他国家的人来说，这相对于他们的收入可是一笔不小的数目。

For an American, four a month might not be a lot, but for somebody in a different country, that is much more money relative to their income.

所以我们把私有仓库免费了，现在收费的是那些企业级功能，比如单点登录、分支保护之类的，学生或者爱好者一般用不上这些。

Hence, we were private depositors free, and today we charge for what you could call enterprise features, like single sign on or branch protection, things that a student or hobbyist, you know, probably doesn't need.

说实话，我自己搞个人项目的时候，根本懒得写测试。

If I'm honest, when I work on my hobby projects, I barely write any tests.

我肯定不会给自己发拉取请求。

I certainly don't send myself a pull request.

然后我就得自己审查自己的代码。

Then I have to review my own code.

直接合并到主分支就完事了。

Just merge, into main branch and that's cool.

不过话说回来，GitHub 在商业模式上也做了不少创新。

And so, but yeah, GitHub innovated in this, in the business model space as well.

你刚才提到，在某些情况下用 GitHub 或者本地 Git 会很有帮助。

And, you know, you mentioned that the scenarios where it's helpful to use GitHub or Git on on your local machine.

2007、2008 年的时候，飞机上基本都没有 Wi-Fi。

In 2007, 2008, flights didn't have Wi Fi, at least normally.

没有。

No.

根本连不上。

Couldn't.

当时还没有Wi-Fi。

Wi Fi wasn't.

而且，我记得那时候飞机上基本都没有Wi-Fi。

That's And, like, the guys very have Wi Fi as far as I remember.

我不确定星巴克是不是已经有了。

I don't know if Starbucks, maybe Starbucks already had it.

但在很多地方，你都得在本地机器上工作好一阵子，然后才能提交到代码仓库里。

But, like, there was much more places where you would work just local on your machine for for quite a while and and and being able to commit into the repository.

要知道，那时候Subversion还没有推送功能。

There wasn't, you know, subversion didn't have a push.

所有操作，比如提交到上游、切换分支、回滚等等，现在用Git都很自然，但当时可不是这样。

Would always commit into the into the upstream, change branches, you know, roll back all these operations that are now natural with Git.

在2007、2008年那会儿，这还很不常见。

They weren't natural in 2007, 2008.

所以GitHub起步后，真正开始获得巨大关注是在2008年，到2010年2月左右。

So GitHub started off, it starts to get real big traction, 2008, 02/2010.

从开发者角度来看，下一个重要的里程碑是，那时候用 GitHub 只能靠网页版或者本地命令行。

The next big kind of milestone I remember from a developer's perspective is until then to use GitHub, you you could use the web version and use the local command line interface.

你得把所有命令都记下来。

You just learned all the commands.

那时候出过不少书，说哪些命令简单，哪些像挑拣提交啊之类的就比较复杂。

You know, there's books about like the easy ones are easy and then like cherry picking and all that.

我老是搞不清楚那些东西。

Was always confused by that.

大概到 2014 年，GitHub 首次推出了桌面应用，而且不只推出了桌面端，还推出了 Atom 编辑器，我特别喜欢。

And then in around 2014 was the first time that GitHub actually released desktop applications, but not only did it release desktop applications, it actually released the Atom text editor, which I loved.

我用了好多年。

Used it for so long.

它是个轻量级的编辑器。

It was a lightweight editor.

它还发布了 Electron 框架，Atom 就是靠这个跑的，之后 GitHub Desktop 也在 2014 到 2015 年陆续上线了。

It released the Electron framework, which powered Atom, and then GitHub Desktop in twenty fourteen, twenty fifteen.

你觉得 GitHub 为什么等了这么久才推出桌面应用？

Why do you think GitHub waited that long to have these desktop applications?

Atom 的目标是什么？它到底带来了什么帮助？

What what what was the goal with AppTom, and and how how did this help?

它有没有真正吸引到那些喜欢界面友好、不喜欢用命令行的用户？

Did it actually help, like, get more people who just liked a nice user interface and were not the command types?

我对这些软件的发展历史不太清楚。

I don't know the history of of all these apps.

我的猜测是，你说‘等了这么久’，但对一家初创公司来说，先做出核心产品，再慢慢扩展其他功能，其实已经不算慢了，多线发展反而可能分散精力。

My my suspicion is that, you when know, you say waited this long, I'd make the counterargument in how long is long for a startup to form a core product, to having multiple other products that may or may not become a distraction.

我觉得每一款产品都是为了解决团队当时遇到的具体问题。

I think each of those solved the specific problems that the team saw.

Atom 是在 VS Code 发布前一年左右推出的。

Adam came out, you know, I think a year or so before Versus Code launched.

很明显，那时候正是新一代 IDE 火起来的时机。

So clearly, the time was hype, you know, for a new generation of IDEs.

这两个项目都是开源的。

Both of them were open source.

被收购后，它们都并入了同一家公司。

For the acquisition, they both ended in the same company.

后来，Oddi决定继续专注于VS Code，并且招聘新人——这其实回归到了开发者优先的文化。

And then Oddi made the decision to continue our journey on Versus Code and hire But it goes back to this developer first culture.

这跟GitHub早期的风格一脉相承，那时候你加入公司，没有直属经理，也不用

It goes back to GitHub's origins where you would join as an employee, and you wouldn't have a manager, and you wouldn't

没有任务清单。

have a backlog.

所以那时候，真的完全没有经理吗？

You would have the So so back then, really, there were no managers?

倒也不是完全没有，毕竟有CEO，还有少量管理层，但整体结构非常扁平。

There were no Well, there was obviously a CEO and like a little bit, but that was very flat.

而且新员工入职，一直都是在总部进行的。

And people, they onboarding was always at headquarters.

所以，尽管我说我们是远程优先的公司，但你还是得在旧金山的总部待上一周左右，学习怎么制作意式浓缩咖啡。

So even though I said remote first company, you would spend a week or so in our headquarters in San Francisco and to learn how to make an espresso.

这还真是入职培训视频里的内容之一。

And that was literally one of the onboarding videos.

要知道，他们总得有点

You know, they got to have some

某种

kind of

那种天马行空的未来，那种随心所欲的文化。

whimsical future, whimsical culture.

然后你会被告知，你知道吗，就选一个你感兴趣的事情去做。

And you got told, you know, pick pick something that you're interested in.

这样一来，自然就导致开发者们会去选择解决那些他们自己关心、想要处理的问题。

And and that naturally leads, you know, to developers picking things that they wanna solve for themselves, that they care about.

所以亚当，也就是当时的CEO克里斯·冯斯特拉特，在GitHub被收购之前的大部分时间里，其实都是艾伦项目的核心维护者之一。

And so Adam was actually, you know, Chris Vonstrat, the CEO at the time, and then for most of GitHub's journey until the acquisition, was one of the, you know, core maintainers of the Allen project.

所以，我

And and so I

我认为你问的关于CEO是核心维护者那部分。

think part of your question about the CEO being a core maintainer.

这很大程度上源于在那里工作的人们的热情。

A lot of that is was about the passion of of the people working there.

我对桌面版的历史了解得不是特别清楚，但我推测，他们当时是看到了一个需求，那就是让更多人能够使用GitHub，而不必精通Git的所有复杂细节。

Don't I know exactly the history of desktop, but my assumption there would be that they saw a need to expand the people that can use GitHub without knowing all the intricacies of Git.

从很多方面来说，GitHub官网的用户界面其实也起到了这个作用。

In many ways, you know, the GitHub user interface on github.com also served that purpose.

举个例子，比如那个‘追责’视图，在GitHub官网上，你只需要点一下按钮，就能看到是谁改了哪个文件、文件的哪一行。

If you think, for example, about blame views, blame on github.com is just clicking a button and see who modified which file, which line in the file.

但如果你在评论行里被指责，要搞清楚怎么回事就难多了，特别是如果你对软件开发不太了解的话。

But if you do get blame on the comment line, it's much, much harder to to figure out what's what, especially if you don't know a lot about software development.

所以这一切都是为了扩大用户群，让更多人能从中获得实际用处。

So it's all about growing the user base and expanding the people that get get, you know, utility out of it.

我经常用 GitHub Desktop。

I'll I'll say that I I use GitHub Desktop a lot.

我的意思是，虽然情况不一样，我也懂命令行，但就是喜欢不用再操心这些事。

Mean, never is different, and I know how to use command line, but I just like that I don't have to think about it again.

当初它上线的时候，我真的很欣赏。

So, like, I I I appreciate it when it when it came out.

我几乎不用它，但我经常用 VS Code 里的 GitHub 集成功能，也是为了同样的目的。

I barely even use it, but I use, you know, the GitHub integration in Versus Code a lot for the same purpose.

我觉得，像 Git 这种协议，支持 SSH 和 HTTP 访问，其实当年 GitHub 刚起步时并不常见，现在却用得越来越多，因为 HTTP 比 SSH 更容易接入。

So there's I think even that, you know, Git as a protocol with SSH access and HTTP access, which were also, by the way, wasn't something that was very prevalent in the early days of GitHub and is now much more used because it's easier to access through HTTP than than through SSH.

我觉得这些功能加在一起，慢慢造就了我们现在觉得理所当然的开发者体验，但二十年前，这根本不是常态。

I think all of these pieces, you know, ultimately helping, you know, to create the developer experience that we now consider normal, but by no means was normal twenty years ago.

那我们现在就说到微软收购的事了。

So then we're getting to the Microsoft acquisition.

时间已经过了 2015 年，现在是 2016 年左右了。

So we've now passed 2015, it's now 2016 or so.

你当时就在微软内部。

You were in the inside of Microsoft.

你那时候已经在那儿工作了。

You were already working there.

这事儿是怎么发生的？

How did this come about?

微软当时是怎么想的？

What was Microsoft thinking?

微软为什么会对GitHub感兴趣？

Why was even Microsoft interested in GitHub?

从你的角度看，这笔收购是怎么推进的？

And then, you know, how did the purchase go from your perspective?

那是2018年初，当时我老板内德·弗里德曼在微软CDP部门负责移动开发工具，他原本来自Xamarin，是通过收购加入微软的。

It was 2018, early twenty eighteen, that back then, Ned Friedman, my boss within Microsoft CDP in the developer division doing mobile developer tools, Nat came from from Xamarin, so had joined Microsoft himself for an acquisition.

我是通过Hockey App的收购加入微软的。

I had joined for the Hockey App acquisition.

所以我们当时在微软内部就像一个外来团队，来了很多人

So we were like a bit of a, you know, outside in team within Microsoft with lots of people coming

来自其他公司

from other

都是有云原生经验的，跟微软传统的技术栈很不一样。

companies, lots of, you know, cloud native experience, a non traditional stack for Microsoft.

同时，微软自己也变了。

At the same time, also Microsoft had changed.

那时候，萨提亚·纳德拉当CEO已经快四年了。

It was now about four years since Satya Nadella had become the CEO.

萨提亚很早就拥抱了开源，比如VS Code上线了，.NET也开源了。

Satya had very early on embraced open source, you know, then Versus Code was launched, .net became open source.

微软在开源态度、技术栈选择和未来方向上，已经接连做了好几项重大调整。

So a number of steps had happened where Microsoft changed its fundamental position on how to use open source, how to use, you know, the stack and where the future is going.

你可能还记得，那时候他们的战略是‘云优先，移动优先’。

You may remember this part of the strategy back then was cloud first, mobile first.

而且在很多方面，这个说法放到今天依然成立。

And in many ways, that is still true today.

我们现在已经不这么提这两点了。

We are no longer saying those two things.

现在想想看，你每天怎么用微软的产品，它们无处不在——不管是什么设备，谁家造的，跑什么操作系统。

If you think about how you interact with Microsoft products today, they are on every device, regardless of who makes the device, what operating system that I'm This

这在当时可没那么明显，因为那时候还是Windows优先。

was not obvious then because it was still Windows first.

当时还是有不少人觉得微软只会做Windows。

There was still a feeling that Microsoft is only Windows.

对，而且我在哪都能听到这种说法。说实话，哪怕是微软内部的人，其实心里也打问号。

And, yeah, and I heard this was said everywhere, I think outside of Microsoft, we were skeptical, honestly.

但你看，现在微软提供的云技术栈、算力技术栈，不光支持自己的产品，更是能给行业里任何一家企业用，这是实打实的变化。

But, you know, and obviously the cloud stack, the compute stack that Microsoft offers today, not only to its own products, but to any company in the industry, really.

我刚进微软的时候学到一件事：在小创业公司工作的时候，我们会把同赛道的其他公司当成竞争对手，也就是所谓的“敌人”。

One thing I learned early in my journey at Microsoft is that when you're a small startup, you consider other companies in the space competitors and say, quote unquote, the enemy.

在微软，竞争对手同时也是我们的客户，很多时候还是合作伙伴。

At Microsoft, competitors are at the same time also customers and often partners.

比如我们提供的Azure AI Foundry，也就是大型语言模型的推理平台，不仅服务于我们自己的Copilot，也提供给许多其他公司，它们可能直接或间接地与GitHub或其他微软产品形成竞争。

We are providing, you know, if you take, for example, Azure AI Foundry, our inference stack for large language models, are providing those not only to our own Copilot, are providing those to many other companies that may directly or indirectly compete with GitHub or with other Microsoft products.

到了2018年，微软内部的世界观已经发生了变化。

And so 2018, the worldview in Microsoft had changed.

我觉得外界对我们的看法也开始转变了。

I think that reputation started to change.

我们开始相信，像收购GitHub这样的事是能做到的——让GitHub成为微软的一部分，同时不会让所有的开源维护者流失，因为他们原本担心微软会搞砸GitHub。

We at Microsoft started to believe that we could pull off an acquisition like GitHub, you make GitHub part of Microsoft and not lose all the open source maintainers because they feel like Microsoft is not going to be a good steward of GitHub.

我们很早就明确了这一原则的具体内容。

And we said very early on clear principles of what that looks like.

2018年距离收购LinkedIn大约两年，距离收购Minecraft则更久一些。

And 2018 was about two years after the LinkedIn acquisition, a bit longer since the Minecraft acquisition.

所以我们已经有了两个成功的收购案例，都是保留了品牌和平台的独立性，直到今天依然如此。

So we had kind of like two examples of acquisitions where we kept the brand and the platform independent even today.

你去LinkedIn的主页看看，基本上看不到什么微软的影子。

When you go to the LinkedIn homepage, you don't see a lot of Microsoft there.

GitHub被收购七年了，它的主页上也没有微软的痕迹，除非你用的是Entra ID作为单点登录提供商。

Seven years after the GitHub acquisition, there's no Microsoft on the GitHub homepage unless you're using Entra ID as a single sign on provider.

当然，我们也会发布博客文章，聊聊微软的Copilot以及Fi这类产品。

Or, of course, we have blog posts where we talk about Copilot the Microsoft and Fi things like that.

至于《我的世界》，很多孩子可能是在童年后期才意识到，他们最爱的游戏之一，其实和开发操作系统、职业社交平台以及GitHub的是同一家公司。

And Minecraft, many kids, I think, realize much later, you know, in their childhood that one of their favorite games is actually the same company that also produces the operating system and the professional network and GitHub.

不过，当你审视这两次收购，再看GitHub时，就会觉得这似乎是顺理成章的结果，是微软沿着这条路走下去的必然下一步。

But part of when, you know, when you look at those two acquisitions and then you see GitHub, it feels like a natural consequence, the natural next step for Microsoft to go down that path.

微软始终是一家以开发者为先的公司。

Microsoft always has been a developer first company.

要知道，第一款产品BASIC，就是为那个——你看，就像这个会议中心里，我不知道你有没有体验过1975年的那种感觉，就是在一台模拟的Altair电脑上工作，通过一些编程测试。

Know, the first product And, was based for the you know, here at the conference center, I don't know if you had the 1975 experience where you work on a fake Altair and pass some coding tests.

后来，BASIC又为Apple II开发，再后来，到了90年代，显然就演变成了Visual Studio。

Then that was basic for the Apple II and obviously Visual Studio in 1990s.

我最早用的 Visual Studio 应该是 Visual C++ 1.0，还附带一本手册，后来又出了 Visual J，算是微软版的 Java 克隆。

I think my first version of Visual Studio was Visual C one point zero, came with a book and then had Visual J, which was like Microsoft's Java clone.

那时候我花了不少钱，买了一整套 Visual Studio 7，现在想想真贵。

And then I bought like a full scale Visual Studio seven for way too much money back then.

至少对我一个高中生来说，那笔钱可真不是小数目。

At least, you know, for where I was as a high school student, right?

如今要是还靠一次性卖 IE，根本没人买账了。

Obviously in today's world, selling an IE at a one time price would be something that has no market fit anymore.

微软那时候根本接触不到开源生态。

You know, Microsoft lacked access to the open source ecosystem.

对云原生开发者也没什么吸引力。

Didn't have, you know, the same attraction to cloud native developers.

完全不流行。

It was just not trending at all.

是啊。

Yeah.

从商业角度看，拥有这个生态系统非常重要。

And that was important from a business perspective to have that ecosystem.

我们必须再次把开发者放在首位。

It was important for us to put developers first again.

这实际上是三大原则中的第一条。

And so that was actually the first principle of three principles.

我们相信，我们能重新推动GitHub的发展，因为2018年的GitHub已经有点被认为不再具备创新能力了，原因有很多。

And we believe we can reaccelerate GitHub because GitHub in 2018 had a bit of the reputation of not being able to innovate anymore for various reasons.

关于这一点，我们后面可以更详细地聊。

And we can talk about that as more in detail.

但关键在于，收购这件事不能只看微软能从GitHub捞到多少好处，而要看微软是否愿意为GitHub投入资源。

But it was really important to think about the acquisition, not a Microsoft gets a lot out of GitHub, but Microsoft is willing to invest into GitHub.

2018年我们刚开始和他们谈的时候，GitHub总共大约有700名员工。

GitHub in 2018, the time we started the conversation with them was about 700 employees all up.

我们前面提到过，现在员工已经超过3000人了。

And we mentioned earlier, it's now over 3,000 employees.

所以这笔投资确实已经实现了。

So that investment surely has happened.

我们充分利用了微软的整个技术栈，比如Copilot，就是基于Azure AI Foundry和与OpenAI的合作，打造了AI代码生成产品。

And we have leveraged a lot of the Microsoft stack and Copilot comes to mind where we're using Azure AI Foundry and the relationship with Open you know, to build AI code generation product.

当然，微软也希望从中获得回报。

And then the last one was, of course, also Microsoft wanted something back.

GitHub的崛起反过来也推动了微软的发展。

And so GitHub accelerated Microsoft.

那具体是怎么做到的呢？

And the easy answer there is how did we achieve that?

靠的是收入增长。

By growing revenue.

去年七月，也就是大约一年前，我们宣布收入已经突破了每年20亿美元的年经常性收入。

And we announced last July, so about a year ago now, that revenue has grown to over 2,000,000,000 annual recurring revenue run rate.

这个数字还在持续增长，我们对这些业务成果能反哺微软的盈利感到非常满意。

And that keeps growing, and we are very happy with these business results contributing back to Microsoft's earnings.

但顺序是这样的，对吧？

But in that order, right?

先是开发者把产品做好，推动GitHub发展，然后GitHub反过来推动微软，无论是在产品上比如Copilot，还是在收入上，用我们自己的业绩回馈微软。

Like developers first making good to develop a product, accelerate GitHub, and then eventually GitHub accelerating Microsoft and giving back both on the product side, Copilot or on the revenue side with our own results.

但我觉得最后这一点特别值得强调，作为开发者，我真的很喜欢用那些我知道会长期存在的产品。

But I think this this last thing is just worth emphasizing in the sense that I think as a developer, really like that I like using products where I know they'll be around.

所以你的意思是，GitHub的收入一直在稳步增长，越来越多的企业、公司和团队愿意为专业用途付费，帮助他们的工作，对吧？

So you're saying that, you know, GitHub's revenue has been consistently going up more enterprises, more, more companies, more teams paying for professional use cases, right, to help their work.

我记得清楚，GitHub在被收购前最后一次公开收入数据是在2017年，当时年经常性收入大约是两亿美元。

If I remember correctly, 2017 was the last official revenue announcement that GitHub made before the acquisition and they were at about $200,000,000 run rate.

他们当时宣布正在寻找新的首席执行官。

They announced at that time that they were looking for new CEOs.

克里斯准备卸任了。

Chris ready to step down.

最终在2018年6月，微软完成了收购，并任命了新的CEO内德·弗里德曼。

Then that ultimately resulted in the acquisition then in June 2018 through an acquisition and a new CEO, Ned Friedman.

但看看吧，2017年两亿美元，到2024年，七年时间，收入翻了十倍。

But like 2017, dollars 200,000,000 to 2024, in seven years, revenue went up factor 10.

是的。

Yeah.

听到这些其实挺让人安心的，毕竟我们知道微软是个营利性公司。

Well, is also, it's kind of reassuring to hear that because there's always a risk, we know Microsoft is a for profit company.

毕竟他们得向股东交代，看到这些指标表现不错，确实让人放心。

You know, like, such an adult reports to shareholders, good to know that those things are going well as well.

而且我觉得，长期以来，开发者工具在业界一直不被认为是能赚钱的业务。

Well, and I think, you know, for a long time, developer tools were not seen as a revenue driver in industry.

以前确实有少数几个例子，比如JetBrains或者JFrog这样的公司。

I think, you know, there were a few examples like companies and JetBrains comes to mind or JFrog.

有不少公司专注做开发者工具，但你要回溯五年前，甚至七年前，你跟我聊起一个开发者工具创业点子的时候，

There's a bunch of companies that, you know, were focusing on developer tools, but I think, you know, you you try time to go back five years or before that, let's say seven and a half years, and we talked with venture capitalists about an idea that we have, you and I, about a developer tools startup.

风险投资人会说，光靠开发者工具不够，你得有别的东西，因为真正的钱不在那儿。

They're going to tell you, you need something else beyond just developer tools because that's where the big money is.

如今，这个世界显然已经发生了翻天覆地的变化。

Today, this world obviously has dramatically changed.

没错。

Absolutely.

我跟斯科特·古特里聊天时发现，上一家能让开发者为开发工具花大钱的公司，还是2000年代的微软——那时候互联网还没现在这么发达，开发者不光买开发工具，还得花钱买MSDN和文档才能用上最新的软件。

But as I was talking with Scott Guthrie, the interesting thing was that the last company that was able to make developers pay for developer tools a lot of money, we're talking thousands of dollars, was Microsoft in the 2000s, where this was pre when Internet was small and developers didn't just pay for developer tools, but they paid for MSD and documentation for access to the latest software.

那种时代早就过去了。

And that time has passed.

我们聊到斯科特的一些经验，挺有意思的是，微软是怎么想通这一点的。

And we were talking about Scott on some of the learnings, but it's interesting how Microsoft figured that out.

微软特别擅长找到一个绝佳的平衡点，就像以前那样——我当年在一家匈牙利公司工作时，

Feel Microsoft is very good at figuring out this great mix where again, back then, and I worked at a Hungarian company.

每个开发者每年得花一千美元，但那笔钱花得值，效率提升太多了。

We paid about $1,000 per developer in Hungary because it made us so much more productive.

所以咱们还是回到现在来说。

So we'll go with today.

这部分也值得一提。

Part on this one.

不过你提到一件事，我也注意到了。

But you mentioned something interesting, which I also noticed.

我回想起GitHub Desktop刚推出的时候，确实很棒。

So I was looking back and I remember back when GitHub Desktop came out, it was great.

那时候我开始更多地用GitHub，但从2015年起，就没什么新动静了。

I think I started to use GitHub more, but then from like 2015, nothing really happened.

微软收购GitHub，这事儿没错。

Microsoft bought GitHub great.

当时网上论坛里也有人在说，GitHub没什么进展。

And I remember on online forums as well, people were saying like GitHub is not doing anything.

后来我翻了下更新日志，发现真正值得关注的功能，是从2021年才开始出现的。

And then the next thing I looked at the change log and the only notable thing I've seen shipped, it started in 2021.

之后才推出了GitHub Sponsors、包注册表、Copilot和Codespaces。

Then GitHub sponsors came out, the package registry, Copilot, Codespaces.

但从2015年到2020年，这段时间到底发生了什么？

But what happened there from 2015 to 2020?

给人的感觉几乎是……我确信员工们都在工作，但从外部看，就像什么都没发生一样，原地踏步，只是招了更多人。

It almost felt like from, I'm sure people were working, but from the outside, it just looked like nothing, like bare on land and more people being hired.

你刚才也提到了这一点。

You alluded to this.

当时背后到底发生了什么情况？

What was going on behind the scenes?

确实，在微软收购之前，也就是2015到2018年那段时间，我们基本只能听到一些传闻和零星的内部消息。

I mean, obviously, the time before Microsoft, you know, 2015 to 2018, only have hearsay and a little bit of insight.

对。

Yeah.

我觉得GitHub当时面临的一个大问题，尤其是在被微软收购之前以及之后的一段时间里，就是平台发展得太大了，太多人都依赖它保持可用且不出问题。

Think a big problem that GitHub had, especially before the Microsoft acquisition and for some time after that, was that the platform had grown so much and so many people were relying on it being available and not broken.

而且你也知道，很多开发者都对它情有独钟，现在依然非常喜爱这个品牌。

Plus, you know, many developers did the Big Ben and still are very much in love with the brand.

那个Octocat，我们内部都叫它Mona。

The Octocad, you know, internally we call it Mona.

Mona。

Mona.

Mona Lisa，就是Mona。

Mona Lisa, know, Mona.

这形象大家都知道。

It's something that is recognized.

你在街上、咖啡馆，甚至乐高店里都会被人认出来，毕竟那里的员工很多是大学生，碰巧也用GitHub。

You get asked about it on the street or in a coffee shop or in the LEGO store, because obviously the employees there are often also college students and happen.

说实话，我坐飞机的时候，空乘人员都问我关于GitHub的事。

Mean, I've been, you know, on an airplane, the crew member asking me about GitHub.

我就会问，你怎么会知道GitHub？

I'm like, how do you know GitHub?

她说，以前上计算机课的时候用过。

She was like, well, used that in college for some computer science course that I took.

如果你的东西在圈子里这么受欢迎，那大家的期待自然也会非常高。

And I think if you have something that is so beloved by space, that also means that expectations are really high.

你越在乎一样东西，一旦失望，那种失落感反而越强烈。

Like, it's often that the disappointment is even bigger if you actually care about something.

但如果你根本不在乎，那它好也好、坏也罢，你压根不关心，反正你也不喜欢。

But if you don't give a damn about this thing, then whether it's up or down or whether it's broken doesn't really matter to you because you hate it anyway.

所以我觉得，正是这两点叠加，让大家对发布新功能特别紧张——你改一点东西，开发者们的反应往往就是网上一群人大吵大闹。

And so I think those two things combined led to people really being worried about shipping stuff because you would change something and the reaction from developers when you change something, whether it's from the user interface or things work or hate limits and things like that, is often there's a loud minority yelling on the internet.

但实际上，大多数用户是默默接受的，根本不会发声。

And there's a silent majority that are actually fine with the change, but don't say anything.

哪怕只是个小改动，也可能引发系统宕机。

And a small change might lead to an outage.

结果你第一周才改了三行代码，就让整个 GitHub 崩了。

And then you're the one that made three lines of change in your first week and you brought GitHub down.

这种经历，对新人来说确实挺打击信心的。

That's obviously not encouraging in your journey.

所以这造就了一个虽然内部持续发布很多功能，但被称为‘员工专属发布’的组织，微软那边叫‘库存共享’。

So I think that created an organisation that actually still shipped a lot of things and what we call staff ship, what Microsoft called stock pooling.

那些只在 GitHub 内部团队使用的功能，Hubbers 看到的时候，有个挺有意思的现象：直到今天，我们每天都在用 GitHub，但我常常不知道某个功能你能不能看到，因为我看到的全是 Hubber 版本的界面。

So features that landed within the GitHub organization that Hubbers would see when they use, you know, one funny thing is we have, even today, we're using GitHub every day, I often actually don't know if that feature is available to you because I only see GitHub how a Hubber would see it.

其实有个办法可以关掉这些功能，不过，等等，我其实可以隐藏员工工具栏，这样就自动屏蔽了你看不到的功能。

And there's a way to disable all these features, but how Well, no, I can hide the staff bar and then disables the features that you don't see.

但你真会经常去这么做吗？

But how often do you really do that?

然后你还能记得住，Gurgenge 那边没有这个功能，但我这边有？

And do you then remember that in the conversation that Gurgenge doesn't have the feature, but I have it.

我还以为这功能已经上线了，结果才发现它其实排在下周才发布。

And I thought it already shipped, but it is actually slated for next week.

所以我觉得，这种做法形成了一种文化：功能内部早就发布了，但就是 never 能推到公网上，因为每个人都在担心：这东西够不够好，能发布吗？

So I think that created a culture where things were internally shipped, but but never made it, you know, to to public because everybody was worried, is that is that good enough to to ship it?

你知道吗，那时候 CEO 的变动也正在进行中。

You know, CEO change was in flight.

当时存在不少文化上的问题。

There were a number of cultural issues.

等交易完成、我们接手后，很快就将私有仓库公开了。

And then as as we closed the deal and we came in, we made private repos public relatively fast.

这个动作挺快的。

That was a fast one.

对。

Yes,

确实如此。

That's true.

在2018年那个阶段，GitHub Actions的第一个版本发布了。

At that universe in 2018, the first version of GitHub Actions was announced.

甚至是在交易正式完成之前。

Was even before the deal closed.

当时开发这个功能的团队，希望他们别介意，其实这玩意儿是基于Google Cloud的容器临时搭出来的，有点像打补丁。

It was, you know, hopefully the folks building it, forgive me, it was a bit of a hack built on top of containers in Google Cloud.

我们很快从数据中发现，这个产品其实没满足开发者的实际需求。

We quickly saw from the data that product wasn't actually meeting the requirements from developers.

很多开发者想要完整的CI/CD，而GitHub Actions最初设计的其实是工作流自动化。

Many developers wanted full CICD, while GitHub actions, obviously, was designed was workflow automation.

我们保留了工作流自动化的核心，但把它逐步演变成了今天的样子。

And we kept that workflow automation part, but evolved it into what it is now.

2019年，也就是2019年年中，在柏林举办的最后一届卫星大会上，GitHub Actions正式发布了。

Over the course of 2019, twenty twenty sponsors was announced in mid twenty nineteen at the last ever satellite conference in Berlin.

紧接着疫情来了，打乱了我们原本的计划。

And then COVID came in that wound to kind of like the plans that we had as we came back from it.

考虑到当时还有很多旅行限制，我们非常谨慎地以较小规模重启了Universe大会。

You know, we were very careful with bringing back Universe in a smaller scale, given that there was still lots of travel restrictions.

但要让整个团队重新恢复到既能快速创新、又能稳住基础——比如安全、可用性、可访问性这些你平时注意不到却至关重要的东西——花了我们不少时间。毕竟，系统运行顺畅时，没人会察觉它的存在，但背后其实投入了大量工作。

But it took us a while to get the organisation back into a state where we could both innovate really fast and keep the fundamentals in place, keep security, availability, you know, other things like accessibility, things that you might not actually see have changed because, you know, if everything is working, you don't notice it, but that, you know, created a lot of investment behind the scenes.

所以我们现在对创新的节奏挺有信心的，不过说实话，让这艘大船掉头可真花了不少功夫。

So we we are feeling good about the pace of innovation that we have today, but yeah, it took us a while to turn the ship around.