I write Interconnected as a place to help me think and a space for anyone to think with me. One of the big themes I’ve been thinking about is what will the next phase of globalization look like and what kind of people, products, paradigms, and opportunities that will be “global by nature” -- transcending borders and addressing a global market from day 1.

This is Part I of a four-part series to explore this “global by nature” theme.

Nativism energy has been on the rise around the world for the last half decade. It is a natural reaction to the first wave of globalization -- fueled mostly by free trade -- that both created unprecedented wealth and unprecedented inequalities.

I do not think the “globalization genie” will ever be put back into the bottle. However, it will take on a different form. If Globalization 1.0 was all about trade, then Globalization 2.0 is all about technology.

In Globalization 2.0, the most important people (or persona) to understand is: developers -- the builders and kingmakers of technology. It is the single most important demographic that will shape Globalization 2.0.

Global Persona

It’s worth first defining what a developer is. My plain language working definition is: someone who uses digital technology to build things. This includes your classically trained software engineers, who formally studied at a computer science program and went on to work at a Google or Apple; your scrappy entrepreneurs who prototyped her idea from watching free videos on iOS development; your mid-career lawyers who changed profession by joining a coding bootcamp; and everything else in between.

Admittedly, it is a broad definition. But it’s one that most reflects where reality is now and where the future is heading, because as technology know-how’s become cheaper and more accessible than ever before, the act of building is also occurring more frequently and by more people in more places than ever before.

In one sense, developers are not that different from assembly workers in a car factory or even a blacksmith in the Middle Ages. Technology is but a fancier word for “tools that make building things easier.” What makes this current 40-million-or-so (and growing) cohort of digital technology developers different is, regardless of where they were born, how old they were when they became a developer, or how they learned to develop, they tend to have global exposure and thus a global mindset.

This global persona is fostered from two motivations: utilitarian and communal.

Utilitarian: whether you were a hacker as a teenanger or switched mid-career, becoming and staying competent as a developer is an ongoing learning process. Generally speaking, the field of engineering has one of shortest half-lives of knowledge -- some estimates suggest between 2.5 and 5 years. Putting this observation in context, it takes between 10 and 20 hours of study per week just to slow down the natural progression of engineering’s half-life.

With this predicament in mind, developers who want to stay developers are constantly learning new technologies, frameworks, computer languages, etc. It’s a utilitarian need. While the technology industry is dominated by the US with China closely nibbing at its heels, the creation of new technologies comes from many places around the world. That’s because practitioners of technology are increasingly distributed.

An example: to prototype a real-time data analysis system, a few developers may stitch together a transactional database like MySQL (Swedish), with a fast analytical database like ClickHouse (Russian, out of Yandex), connected by an ETL solution like Talend (French), monitored by a tool like Prometheus (German, out of SoundCloud), and visualized by Apache ECharts (China). Like many technologies, these five tools I picked out as examples all have open source versions, which make for easy access on a global scale. (More about open source in Part III.)

The point of this example isn’t to point out the national origin of these technologies as if that’s relevant. Quite the opposite. They are irrelevant to a developer’s utilitarian need to get a job done, solve a problem, or learn a new skill to stay sharp and productive. When a developer Googles an error message or “how to [fill in the blank]”, checks out the top StackOverflow thread, reads the documentation on GitHub, and eventually downloading a possible solution to test out -- a typical learning process -- the entire world’s available technology is at her disposal. And the technology that can best serve her needs also has a global market of developers to cater to.

Communal: many developers don’t just transactionally Google for solutions and be done with it. They end up forming communities and tribes over technologies, computer languages, tools, and frameworks. This formation is also global by nature.

Whether you show up at an intimate 15-person meetup in a co-working space or a massive 15,000-people conference in a convention hall, you will notice that even though the scene looks like a UN General Assembly gathering, what you hear are conversations centered around technologies and their practical uses, not bickerings about national interests or fault lines between cultures.

There is not much of: are you Chinese or Israeli or Canadian or Russian. But more of: do you use Rust or C++ for your low-level systems? Are you a MySQL or a PostgreSQL person? Are you into OpenStack or Kubernetes?

Developers don’t just talk about the technologies that brought them together; they are people too! They have dinners, happy hours, yoga sessions, and even go karaoke together. It’s a communal connection.

One fascinating thing I observed, having gone to my fair share of these meetups and conferences, is that while the default language of communication is English, it is spoken in a smorgasbord of beautiful accents. For most people, they learned English as they became developers. As someone who picked up English as a second language, I find these developer-focused gatherings some of the most welcoming and forgiving venues for people who do not speak English as their first language -- perhaps because English is secondary to the language of technology which they all speak.

I’m not suggesting that developer communities are some post-racial, post-gender utopias. Awful things still happen, toxic cultures still form, and moderating human behaviors is a constant challenge for all developer communities. On the issue of gender balance alone, the 2020 State of DevOps Report reminds us just how far the ecosystem still has to go, with only 16% of self-identified females responding to its survey versus 82% of self-identified males (though it’s improving compared to previous years of the same survey).

Source: 2020 State of DevOps Report

Many institutions like the Linux Foundation are providing diversity scholarships to level the opportunity imbalances. More and more developer-focused companies, large and small, are doing the same. With more of these efforts taking shape in the next 10 years (I hope), they will unlock new developer potentials in any region with a reasonably fast Internet -- coalescing around technology languages, not human languages. What you end up with is a global developer network effect that will grow as demand for technology grows.

Builders to Kingmakers

Why does understanding the “global by nature” persona of developers matter from an investment or opportunity perspective?

Only the product that can address developers’ needs as both builders and human beings will earn their long term approval and adoption. And the companies that create such products will, quite literally, be world-changing, because they are addressing a world-wide demographic need. This global audience is addressable from day one. For an ad-driven business like Facebook, you’d first appeal to a younger audience in a particular country, then expand to cover the 18-49 year old demographic (traditionally the group that commands the highest ad rate) in that same country, before expanding to other places. For a developer-driven business, the world is immediately for the taking.

It’s no easy feat to accomplish. This vast opportunity also presents a vast array of unique company-building challenges, most of which do not have settled playbooks. But that’s where the puck is headed, to paraphrase the hockey GOAT Wayne Gretzky. (See a few public companies that I think are doing a good job in Part IV.)

The core reason why I focus on “developers” in Part I of this series is that they are no longer just builders, but also kingmakers, of technology. This rise in importance is a relatively recent phenomenon. The decision-making process of technology adoption used to be top-down and a secondary priority. (Depending on which industry you are in, that may still be the case.) A company used to be a “Java shop” simply because the CTO or CIO said so, possibly due to other business dealings with Oracle. And no one got fired for using IBM.

Only in the last 20 years or so did developers start to gain more power and independence in deciding which technologies they could use. The developer-focused analyst firm RedMonk, founded in 2002, has been on the forefront of this trend.

Book on developers as kingmakers written by co-founder of RedMonk, Stephen O'Grady

Even so, building a successful product, commercialization strategy, and durable company that is purely developer-focused has been challenging. Published in 2017, the post-mortem blog post by the founder of RethinkDB serves as a raw and thought-provoking reminder of those difficulties for many people in the industry.

Timing is everything, and it’s fair to ask whether the developer-focused market opportunity is still too early. I believe the right timing is now because of two factors.

One: every company must become a technology company to survive. For new startups, it’s obvious. For older companies, incorporating new technologies is the only way to remain relevant and thrive in Globalization 2.0. Otherwise, obsoletion will swallow you no matter how iconic the company once was (see Sears).

In order for these older companies to “technologize” themselves, they have an insatiable demand for developers. They also tend to emulate their tech-native startup peers: Walmart emulates Amazon, Visa emulates Stripe, Charles Schwab emulates Robinhood, PingAn emulates Ant, etc.

This emulation is the smart thing to do, because they are fighting to hire and retain the same, scarce pool of developers. Based on the survey and research shown in “Accelerate”, a great book with a rigorous framework for understanding technology delivery inside an organization, giving developers the freedom to choose and experiment with technology is a major determinant of their job satisfaction and productivity. The older companies may be used to doing other things top-down, but when it comes to technology adoption, the smart ones give their developers the rein if only because the companies’ survival depends on retaining them.

Two: the surface area of “technologizing” is larger than most people realize. What people tend to expect is existing products and services being delivered more digitally with software, e.g. Target or Costco adding e-commerce. That makes sense, because it is the easiest to see and foresee. However, developer-driven technology adoption permeates both software and hardware, and both external and internal to an organization.

For hardware, there is a new wave of developer-focused hardware design technologies, led by RISC-V, that is making prototyping and building semiconductors easier and cheaper than before, with an experience and speed akin to developing software. Even though the RISC-V developer ecosystem is still young, its laser focus on improving the developer experience is the right direction. (I’ve written numerous posts about RISC-V if you are interested in a deep dive.)

As for internal, the best tech companies have technologies permeating inside them as well. The marquee example is probably Tesla. Not only is its EVs built from scratch solely by Tesla, so is the internal organs of the company itself. During Tesla’s Q3 2020 earnings call, Elon Musk went out of his way to compliment his internal applications team, describing them as the “nervous system” and the “operating system” of Tesla. Successful internal applications often become ideas for new startups that will get adopted by developers in other companies, especially places that try to emulate a market leader or industry icon. This kicks off a virtuous ripple effect of new technology adoption. GraphQL, first developed inside Facebook and has spawned a few startups, is a good example.

Very few companies are at the level of Tesla and Facebook, but many companies, old and new, are working to emulate them. The kingmakers who will decide and the builders who will create are these “global by nature” developers.

ICYMI: please give the other three parts of the "Global by Nature" series a read: APIs, open source, public companies to watch.

If you like what you've read, please SUBSCRIBE to the Interconnected email list. To read all previous posts, please check out the Archive section. New content will be delivered to your inbox (twice per week). Follow and interact with me on: Twitter, LinkedIn.

生来全球化（第一篇）：开发者

我写《互联》的初心是想通过写作帮自己更清晰的思考，也同时给读者提供一个和我一起思考的空间。我一直在思考的一个大主题，就是全球化的下一个阶段会是什么样的。在这个新阶段里，什么样的人、产品、模式和机会会是 “生来全球化”的 -- 从第一天起就超越国界，面向全球市场。

本篇探讨这个 “生来全球化” 主题的四部系列的第一篇。

过去五年里，本土主义的能量在世界各地不断上升。这是对第一阶段主要由自由贸易推动的全球化的自然反应。全球化既创造了前所未有的财富，也造就了前所未有的不平等。

我不认为 "全球化精灵" 会被放回瓶子里。然而，它将以不同的形式继续出现。如果说 “全球化1.0” 是被贸易推动的，那么“全球化2.0” 将是被科技推动的。

在全球化2.0中，最需要了解的人群（或角色）就是：开发者。他们是科技的建设者和决策者。这是塑造全球化2.0走向最重要的一个人群。

全球化视角

首先应该定义一下什么是“开发者”。我个人的定义是：使用数字科技来创造任何事物的人。这包括科班出身的软件工程师，他们在高校计算机系经历过正式的学术训练，然后去谷歌或苹果这种大厂工作；也包括屌丝的创业者，他们会通过看免费的iOS开发视频教材来把自己的创业想法hack出来；还包括像律师这种白领行业通过加入编码训练营去改行；以及其他一切介于两者之间的人。

诚然，这是一个极为宽泛的定义。但它也是最能反映现实和未来走向的定义，因为随着技术知识变得比以往任何时代都更廉价、更容易获得，创造构建新生事物的行为也比以往任何时候都更频繁，也来自于更多地域的更多人。

从某种意义上说，开发者与汽车厂的装配工人甚至中世纪的铁匠并没有什么不同。科技不过是 "让创造事物更容易的工具" 而已。但目前这批4000多万（而且还在不断增长）的使用数字科技的开发者的不同之处在于，无论他们出生在哪里，成为开发者一员时的年龄有多大，或是如何学会做开发的，他们往往都有全球的视角，从而也具有全球化的思维方式。

这种“生来全球化”的视角是由两种动机培养出来的：功利性和社区性。

功利性：无论您是少年黑客，还是在其他职业生涯中期转行，作为开发者，保持自己的能力是一个持续学习的过程。一般来说，工程领域是知识半衰期最短的领域之一，有人估算在2.5到5年之间。换个角度看，每周需要10到20个小时的自发学习，才能减缓半衰期步伐的自然进度。

在这种环境下，想要保持开发者的身份，就要不断学习新的技术、框架、计算机语言等，这是一种功利性的需求。虽然科技行业以美国为主导，中国紧随其后，但新技术的创造却来自全球各个地方。这是因为天天用科技做事情的人越来越分散。

举个例子：为了打造一个实时数据分析系统，几个开发者可能会把 MySQL（瑞典）这样的事务性数据库与ClickHouse（俄罗斯，出自Yandex）这样的大数据分析数据库拼接在一起，由Talend（法国）这样的ETL解决方案连接，由Prometheus（德国，出自SoundCloud）这样的工具监控，由Apache ECharts（中国）把数据可视化。和许多技术一样，我选取的这五个工具都有开源版本，全球各地的开发者都可以任意使用。(关于开源，请看本系列的第三篇。)

这个例子的重点不是要点出这些技术的“母国”是哪里。恰恰相反。它们的“国籍”与能不能帮助开发者完成一项工作、解决问题或持续学习新技术的这些功利性需求完全无关。当一个开发者在谷歌上搜索一条error message或打入 "如何做 [随意填空]"，查看票数最多的StackOverflow帖子，阅读GitHub上的文档，并最终自己下载一版来做测试的时候（这是个典型的开发者学习过程），整个世界的可用技术都在她的眼前。最能满足她需求的技术，就是她认可和采用的技术，无论技术的母国是哪里。

社区性：很多开发者并不只是在谷歌上找到答案就完事了。他们会在技术、计算机语言、工具和框架中找到自己的社区和“部落”。这种社区性的自然形成也是全球化的。

无论是只有十几个人的meetup，还是上万人的大型会议，您都会发现，尽管场面看起来像联合国大会的聚会一样，您听到的对话都是围绕技术和实际用法的，而不是关于国家之间的利益冲突或不同文化的隔阂。

没有太多的：你是中国人，还是以色列人，还是加拿大人，还是俄罗斯人。更多的是：你的底层系统里用的是Rust还是C++？你擅用MySQL还是PostgreSQL？你喜欢OpenStack还是Kubernetes？

开发者也不是只会聊技术的机器人，他们也是有血有肉的人!  聊技术以外，他们会一起出去吃饭，喝酒，做瑜伽，甚至一起唱K。这是些真正的社区。

我参加过很多这种meetup和会议，也观察到了一件很有意思的现象。虽然默认的交流语言是英语，但所有人都带着各色各样的口音来对话。对于很多人来说，他们是在成为开发者的过程中学习英语的。作为一个英语是第二语言的人来说，我发现这些以开发者为中心的社区活动是最欢迎和宽容那些英语不是母语的人的场所。这也许是因为对开发者来说，英语是次要的，科技的语言才是主要的。

我并不想给大家一个错觉，好像开发者社区是一些超越种族、超越性别歧视的乌托邦。糟糕的事情绝对发生，有毒的文化绝对形成，对所有开发者社区来说，调节人与人的行为是个长期持续的挑战。仅就以性别平衡这个问题而言，今年刚出炉的《2020年DevOps行业状态报告》提醒了我们，整个生态还有很远的路要走。只有16%的自认女性回应了报告的调查，而自认男性的比例是82%（尽管与前几年相比有所改善）。

《2020年DevOps行业状态报告》链接：https://puppet.com/resources/report/2020-state-of-devops-report/

许多机构，如Linux基金会，在以提供多元化奖学金的方式来平衡开发者行业机遇的不平等。越来越多以开发者为中心的公司，无论大小，也都在做同样的努力。随着更多这样的项目在未来10年内启动（起码这是我的期望），它们将促使任何网速够快的地域里挖掘和释放新的开发者潜力，他们会围绕技术的语言，而不是人类的语言，来凝聚。最终会产生的是一个全球开发者的网络效应，它将随着对科技的需求增长而增长。

从建设者到决策者

从投资或寻找机遇的角度来看，为什么了解开发者 "生来全球化"的特性很重要呢？

只有能够满足开发者作为建设者的需求的产品，才能赢得他们的长期认可和采用。而能创造出这种产品的公司，将会真正改变世界，因为所解决的是个全球规模的需求。这种全球受众从第一天就存在。对于像Facebook这样广告主导的公司来说，它首先要吸引某个国家的年轻人，然后在这个国家里扩展到覆盖18-49岁的人群（传统上这个群体的打广告价值最高），然后再扩展到其他国家。对于一个开发者主导的公司来说，全球化是第一天就可以做的事。

当然，这不是一件容易的事。这种巨大的机会也带来了许多独特的公司建设挑战，很多挑战还没有固定有效的玩法。但是，借用一句冰球大师 Wayne Gretzky的名言，就是要去球要去的方向发展，而不是球现在的地方。（请看本系列的第四篇，其中我分析了几家在这方面做的不错的上市公司。）

我之所以在本系列的第一篇探讨 "开发者"，核心原因是他们的角色不仅仅是技术的建设者，也是选择技术的决策者。这种转变还是个比较新的现象。技术采用的决策过程曾经是自上而下的，也是次要的。(在有些行业里，仍然是这种情况。) 以前一家公司只用 Java，可能只是因为CTO或CIO就这么拍板决定了，也许与Oracle的其他业务关系有关，而具体做事情的开发者没有什么话语权。传统来讲，也没有人因为选择IBM而被解雇过。

只有在过去的20多年里，开发者才开始有更多的独立空间和自主权来决定他们可以用哪些技术。成立于2002年的以开发者为中心的分析公司RedMonk一直走在这一趋势的前列。

Redmonk cofounder写的关于开发者的书

即便如此，建立一个以开发者为中心的成功产品、商业化战略和持久成熟的公司一直是个挑战。RethinkDB创始人在2017年发表的博文，对自己创业失败的复盘，时时提醒着许多业内人士这些种种困难。

抓对时机就是一切。一个合理的问题是：以开发者为中心的市场机遇是否还为时过早。我认为现在是契机，因为两个因素。

其一：每种公司都必须成为科技公司才能生存下去。对于新的创业公司来说，这就不用说了。对于老牌公司来说，融入新技术是在“全球化2.0”中保持发展的唯一途径。否则，无论公司曾经多么辉煌，都离淘汰不远（看看Sears）。

为了能更快的 "科技化"，这些老牌公司对开发者有巨大的需求。它们也倾向于模仿作为科技公司出身的更年轻的同行。沃尔玛效仿亚马逊，Visa效仿Stripe，Charles Schwab效仿Robinhood，平安效仿蚂蚁，等等。

这种效仿是明智的，因为它们正在争取雇佣和留住同一批稀缺的开发者。根据《加速》（《Accelerate》）这本书中所展示的调查和研究来看，给开发者对技术的自由选择和实验空间是决定他们工作满意度和产出力的主要因素。这本书提供了少见的一套严谨的学术框架来分析理解公司内部的对科技交付的做法和管理方式，值得一读。老牌公司可能习惯于自上而下地做其他事情，但对技术应用方面，聪明的公司会给开发者很大的自控权，因为公司本身的生存取决于是否能留住他们。

其二：公司"科技化"的影响范围要比大多数人的想象大很多。人们对科技化的一般期待是把现有的产品和服务通过软件数字化，比如Target或Costco做电商业务。这是合理的，因为这是最容易看到和预见的。然而，开发者驱动的技术采用渗透软件和硬件，也渗透公司的外部和内部。

对于硬件来说，以RISC-V为首的以开发者为中心的新一批硬件设计技术浪潮正在成形，把设计半导体产品的过程变得更容易、更便宜，体验和速度与开发软件类似。尽管RISC-V的开发者生态还很年轻，但它已经开始专注提高改善开发者体验，这个大方向是正确的。(如果您有兴趣深入了解RISC-V，可以读读我写的关于RISC-V的很多文章)。

至于内部科技化，在最顶尖的科技公司里，新技术也无处不在。最标杆的例子可能就是特斯拉了。不仅其电动车是完全由特斯拉从头到尾打造的，公司本身的内部机关也是如此。在特斯拉2020年第三季度财报电话会议上，Elon Musk不遗余力地赞扬了他的内部应用开发团队，称他们是特斯拉公司的 "神经系统" 和 "操作系统"。成功的内部应用科技产品往往会成为新创业公司的启发。这些创意被其他公司的开发者采用，尤其是那些试图效仿某行业标杆企业的公司，从而掀起一波新技术应用的良性涟漪效应。最早在Facebook内部开发并催生了好几家创业公司的GraphQL就是个好例子。

很少有公司目前能达到特斯拉和Facebook的水平，但很多公司，不管是老公司还是新公司，都在努力效仿它们。在这个过程当中，有做决策能力和建设能力的人们就是这些 “生来全球化”的开发者。

ICYMI：请看“生来全球化”的其他三篇：APIs，开源，值得关注的上市公司。


如果您喜欢所读的内容，请用email订阅加入“互联”。要想读以前的文章，请查阅《互联档案》。每周两次，新的文章将会直接送达您的邮箱。请在Twitter、LinkedIn上给个follow，和我交流互动！