什么是低代码(Low-Code)?

一、前言

如果选择用一个关键词来代表即将过去的2020年,我相信所有人都会认同是“新冠”。疫情来得太快就像龙卷风,短短数月就阻断了全世界范围内无数人与人之间的物理连接。但好在,我们已经全面迈入互联网时代:N95口罩再厚,也阻挡不了信息比特流的顺畅流通(宅男:B站依然香);居家隔离再久,也妨碍不了钉钉消息的准时送达(社畜:工作依然苦)。逍遥子在9月份的云栖大会上说:“新技术代表的新生产力,一定是我们全速战胜疫情、开创未来最好的原动力。” 那么在后疫情时代,究竟需要什么样的新技术,才能真正解放IT生产力,加速社会数字化转型,Make The World Great Again?我认为是低代码(Low-Code)。

基于经典的可视化和模型驱动理念,结合最新的云原生与多端体验技术,低代码能够在合适的业务场景下实现大幅度的提效降本,为专业开发者提供了一种全新的高生产力开发范式(Paradigm Shift)。另一方面,低代码还能让不懂代码的业务人员成为所谓的平民开发者(Citizen Developer),弥补日益扩大的专业人才缺口,同时促成业务与技术深度协作的终极敏捷形态(BizDevOps)。本文将重点介绍低代码相关背景知识,包括低代码的定义与意义、相关概念、行业发展等,期望能帮助大家更好地认识与理解低代码这个新兴领域。

二、什么是低代码

“Low-Code”是什么?如果你是第一次听说,没准也会跟我当年从老板口中听到这个词后的内心戏一样:啥?“Low-Code”?“Code”是指代码我知道,但这个“Low”字是啥意思?不会是老板发现我最近赶工写的代码很丑很“Low”吧… 想多了,老板怎么可能亲自review代码呢。那难道是指,“Low-level programming”里的“Low”?老板终于发现让我等编程奇才整天堆Java业务代码太浪费,要派我去闭关写一个高性能C语言网络库… 显然也不是,老板哪能有这技术情怀呢。那到底是什么意思?作为一名搜商比情商还高的程序员,能问Google的绝不会问老板。于是我一顿操作后,不假思索地点开了第一条搜索结果。果不其然,这是一条充满自由芳香只有翻墙才能闻到的Wikipedia词条:Low-code development platform。

Wikipedia定义

2.png

从Wiki的这段定义中,我们可以提炼出几个关键信息:

  • • 低代码开发平台(LCDP)本身也是一种软件,它为开发者提供了一个创建应用软件的开发环境。看到“开发环境”几个字是不是很亲切?对于程序员而言,低代码开发平台的性质与IDEA、VS等代码IDE(集成开发环境)几乎一样,都是服务于开发者的生产力工具。
  • • 与传统代码IDE不同的是,低代码开发平台提供的是更高维和易用的可视化IDE。大多数情况下,开发者并不需要使用传统的手写代码方式进行编程,而是可以通过图形化拖拽、参数配置等更高效的方式完成开发工作。

Forrester定义

顺着Wiki的描述还能发现,原来“Low-Code”一词早在2014年就由Forrester提出了,它对低代码开发平台的始祖级定义是这样的:

3.png

相比Wiki的版本,这个定义更偏向于阐明低代码所带来的核心价值:

  • • 低代码开发平台能够实现业务应用的快速交付。也就是说,不只是像传统开发平台一样“能”开发应用而已,低代码开发平台的重点是开发应用更“快”。更重要的是,这个快的程度是颠覆性的:根据Forrester在2016年的调研,大部分公司反馈低代码平台帮助他们把开发效率提升了5-10倍。而且我们有理由相信,随着低代码技术、产品和行业的不断成熟,这个提升倍数还能继续上涨。
  • • 低代码开发平台能够降低业务应用的开发成本。一方面,低代码开发在软件全生命周期流程上的投入都要更低(代码编写更少、环境设置和部署成本也更简单);另一方面,低代码开发还显著降低了开发人员的使用门槛,非专业开发者经过简单的IT基础培训就能快速上岗,既能充分调动和利用企业现有的各方面人力资源,也能大幅降低对昂贵专业开发者资源的依赖。

低代码核心能力

基于上述的定义和分析,不难总结出如下这3条低代码开发平台的核心能力:

4.png

  • 全栈可视化编程:可视化包含两层含义,一个是编辑时支持的点选、拖拽和配置操作,另一个是编辑完成后所及即所得(WYSIWYG)的预览效果。传统代码IDE也支持部分可视化能力(如早年Visual Studio的MFC/WPF),但低代码更强调的是全栈、端到端的可视化编程,覆盖一个完整应用开发所涉及的各个技术层面(界面/数据/逻辑)。
  • 全生命周期管理:作为一站式的应用开发平台,低代码支持应用的完整生命周期管理,即从设计阶段开始(有些平台还支持更前置的项目与需求管理),历经开发、构建、测试和部署,一直到上线后的各种运维(e.g. 监控报警、应用上下线)和运营(e.g. 数据报表、用户反馈)。
  • 低代码扩展能力:使用低代码开发时,大部分情况下仍离不开代码,因此平台必须能支持在必要时通过少量的代码对应用各层次进行灵活扩展,比如添加自定义组件、修改主题CSS样式、定制逻辑流动作等。一些可能的需求场景包括:UI样式定制、遗留代码复用、专用的加密算法、非标系统集成。

不只是少写代码

回到最初那个直击心灵的小白问题:Low-Code中的“Low”,到底是啥意思?答案已经显而易见:既不是指抽象程度很低(相反,低代码开发方式的抽象程度要比传统编程语言高一个level),也不是指代码很low(也相反,低代码所生成的代码一般都经过精心维护和反复测试,整体质量强于大部分手写代码),而是单纯的“少写代码” —— 只在少数需要的情况下才手写代码,其他大部分时候都能用可视化等非代码方式解决。

再往深一点儿看,低代码不只是少写代码而已:代码写得少,bug也就越少(正所谓“少做少错”),因此开发环节的两大支柱性工作“赶需求”和“修bug”就都少了;要测的代码少了,那么测试用例也可以少写不少;除了开发阶段以外,平台还覆盖了后续的应用构建、部署和管理,因此运维操作也更少了(Low-Code → Low-Ops)。

然而,少并不是最终目的:如果单纯只是想达到少的效果,砍需求减人力、降低质量要求也是一样的。低代码背后的哲学,是少即是多(Less is More),或者更准确说是多快好省(Do More with Less) —— 能力更多、上线更快、质量更好,成本还更省,深刻践行了阿里“既要,又要,还要”的价值观精髓。

image.png

平台的职责与挑战

上面说的是低代码给开发者提供的能力与吸引力,那么作为服务的提供方与应用的承载者,低代码开发平台自身应该承担怎样的职责,其中又会遇到多大的挑战?是否就一定要如阿里云所主张的那样,“把复杂留给自己,把简单留给别人”?虽然这句话听起来很深明大义,但不知道大家有没有想过,为什么我们一定要抱着复杂不放,平白无故给自己找事?就不能直接干掉复杂,也给咱阿里云自己的员工留点简单吗?是工作太容易就体现不出来KPI价值了,还是家里的饭菜不如公司的夜宵香?

冥思苦想许久后,我从热力学第一定律中找到了答案:开发一个应用的总复杂度是恒定的,只能转移而不可能凭空消失。要想让开发者做的更少,安心享受简单的快乐,那么平台方就得做的更多,默默承担尽可能多的复杂度。就像一个满身腱子肉的杂技男演员,四平八稳地托举着在高处旋转与跳跃的女搭档;上面的人显得越轻盈越毫不费力,下面的人就得越稳重越用尽全力。当然,不是说上面的女演员就很轻松没压力,只是他们各自的分工不同,所承担的复杂度也不一样。

根据《人月神话》作者Fred Brooks的划分,软件开发的复杂度可以划分为本质复杂度(Essential complexity )和偶然复杂度(Accidental complexity)。前者是解决问题时固有的最小复杂度,跟你用什么样的工具、经验是否丰富、架构好不好等都无关,而后者就是除此之外在实际开发过程中引入的复杂度。通常来说,本质复杂度与业务要解决的特定问题域强相关,因此这里我把它称为更好理解的“业务复杂度”;这部分复杂度不是任何开发方法或工具能解决的,包括低代码。而偶然复杂度一般与开发阶段的技术细节强相关,因此我也相应把它称为“技术复杂度”;而这一部分复杂度,恰好就是低代码所擅长且适合解决的。

为开发者尽可能屏蔽底层技术细节、减少不必要的技术复杂度,并支撑其更好地应对业务复杂度(满足灵活通用的业务场景需求),这是身为一个低代码开发平台所应该尽到的核心职责。

6.png

在尽到上述职责的同时,低代码开发平台作为一个面向开发者的产品,还需要致力于为开发者提供简单直观的极致开发体验。这背后除了巨大的工作量,还得能在“强大”和“易用”这两个很难两全其美的矛盾点之间,努力找到一个符合自己产品定位与目标客户需求的平衡点 —— 这也许是设计一个通用低代码开发平台所面临的最大挑战。

三、低代码相关概念对比

纯代码(Pro-Code / Custom-Code)

“纯代码”可能算是我杜撰的一个词,更常见的说法是专业代码(Pro-Code)或定制代码(Custom-Code);但意思都一样,就是指传统的以代码为中心(Code-Centric)的开发模式。之所以我选择用“纯代码”,是因为如果用“专业代码”会显得似乎低代码就不专业了一样,而用“定制代码”又容易让人误解成低代码无法支持定制的自定义代码。

当然,更准确的称谓我认为是“高代码”(与低代码恰好对应,只是名字太难听,被我嫌弃了…),因为即便是使用传统的代码IDE,有些开发工作也支持(甚至更适合)以非代码方式完成,比如:iOS端开发时使用的SwiftUI界面设计器、服务端开发数据库应用时使用的PowerDesigner建模工具。不过这部分可视化工作在传统开发模式下只是起辅助作用,最后通常也是生成开发者可直接修改的代码;开发者仍然是以代码为中心来开展主要工作。

低代码与纯代码之间的关系,其实跟视频和文章之间很像:

  • • 低代码就像是现代的“视频”,大部分内容都由直观易理解、表达能力强的图片组成,因此更容易被大众所接受。但与此同时,视频也不是死板得只能有图片,完全可以添加少量文字(如字幕、标注)来弥补图片表达不够精确的问题。BTW,关于“图”和“文字”之间的辩证关系,可以进一步参考《架构制图:工具与方法论》[1]这篇文章中的相关描述。
  • • 纯代码则更像是传统的“文章”,虽然很久以来都一直是信息传播的唯一媒介,但自从视频技术诞生以及相应软硬件基础设施的普及以来,便逐渐开始被抢走了风头。如今,视频已成为大部分人获取信息的主要渠道(从电视电影到B站抖音),而经常读书读文章的人却越来越少。但不可否认的是,文章依然有它存在的意义和受众(不然我也不会费这劲敲这么多字了),即使“市场份额”一直在被挤压,但永远会有它立足的空间。

7.png

如果按上面这种类比关系推导,低代码未来也会遵循与视频类似的发展轨迹,超越纯代码成为主流开发模式。Gartner的预测也表达了相同的观点:到2024年,所有应用程序开发活动当中的65%将通过低代码的方式完成,同时75%的大型企业将使用至少四种低代码开发工具进行应用开发。

但同样地,就像是视频永远无法取代文章一样,低代码也永远无法彻底取代纯代码开发方式。未来低代码和纯代码方式将以互补的形态长期共存,各自在其所适合的业务场景中发光发热。在后面的“低代码业务场景”章节,会详细列出哪些场景在现阶段更适合用低代码模式开发。

零代码(Zero-Code / No-Code)

从分类的完备性角度来看,有“纯代码”自然也应该有完全相反的“零代码”(也称为“无代码”)。零代码就是完全不需要写代码的应用开发平台,但这并不代表零代码就比低代码更高级和先进,它只是做了一个更极端的选择而已:彻底拥抱简单的图形可视化,完全消灭复杂的文本代码。选择背后的原因是,零代码开发平台期望能尽可能降低应用开发门槛,让人人都能成为开发者(注意:开发 ≠ 写代码),包括完全不懂代码的业务分析师、用户运营,甚至是产品经理(不懂装懂可不算懂)。

即便是专业开发者,在技术分工越来越精细的趋势下(前端/后端/算法/SRE/数据分析..),也很难招到一个能独立开发和维护整套复杂应用的全栈工程师。但零代码可以改变这一切:无论是Java和JavaScript傻傻分不清楚的技术小白,还是精通深度学习但没时间学习Web开发的算法大牛,都可以通过零代码实现自己的技术梦或全栈梦。“改变世界的idea已有,就差一个程序员了”,这句玩笑话或许真的可以成真;哦不,甚至都用不着程序员,有idea的人自己就能上。

8.png

当然,所有选择都要付出代价,零代码也不例外。完全抛弃代码的代价,就是平台能力与灵活性受限:

  • • 一方面,可视化编辑器的表达能力远不及图灵完备的通用编程语言,不引入代码根本没法实现灵活的定制与扩展(当然,理论上也可以做成Scrach/Blockly那样的图形编程语言,但那样不过是换一种形式在手写代码而已)。
  • • 另一方面,由于目标受众是非专业开发人员,平台能支持的操作会更趋于“傻瓜化”(e.g. 页面只支持大块业务组件的简单堆叠,不支持细粒度原子组件和灵活的CSS布局定义),同时也只会透出相对“亲民化”的模型和概念(e.g. 使用“表格”表示数据,而不是用“数据库”),无法支撑强大专业的底层开发原语和编程理念。

9.png

虽然零代码与狭义上的低代码有着上述明显差异,但从广义上来说,零代码可以当作低代码的一个子集。Gartner在其相关调研报告中,就是将“No Code”划在了范围更广的低代码应用平台“LCAP”(Low-Code Application Platform)中。而当前市面上很多通用的低代码开发平台,也都兼具一定程度的零代码能力;比如低代码领域领头羊Mendix,既提供了简单易用的零代码Web IDE – Mendix Studio,也包括一个功能更强大的低代码桌面IDE – Mendix Studio Pro。

HpaPaaS(高生产力应用PaaS)

上文提到,“Low-Code”一词是拜Forrester所赐。作为同样是国际知名调研机构(a.k.a 造词小能手)的Gartner,显然不会轻易在这场可能决定低代码领域江湖地位的新概念作词大赛中认输,于是也于2017年发明了“HpaPaaS”(High-productivity application Platform as a Service)这个听上去更高大上的缩写词。

按照Gartner的定义,HpaPaaS是一种支持声明式、模型驱动设计和一键部署的平台,提供了云上的快速应用开发(RAD)、部署和运行特性;这显然与低代码的定义如出一辙。但事实证明,名字起得太专业并不见得是好事,“HpaPaas”最终还是败给了起源更早、更接地气也更顺口的“Low-Code”:从2019年开始,Gartner在其相关调研报告中也开始全面采用“Low-Code”一词(如LCAP),亲手为“HpaPaaS”打上了 @deprecated 印记。

10.png图源:https://blog.kintone.com/business-with-heart/difference-saas-iaas-paas-apaas-hpapaas

值得补充的是,“HpaPaaS“这个词也并非横空出世,而是传承自更早之前Gartner提出的“aPaaS”,它俩之间的关系是:HpaPaaS只是aPaaS的一个子类;除了HpaPaaS这种通过低代码实现的高生产力应用开发平台以外,aPaaS还包括面向纯代码的传统应用开发平台(High-control aPaaS,即可控度更高的纯代码开发方式)。

不值得但就想八卦一下的是,“aPaaS”这个词也非凭空捏造,而是与云计算的兴起渊源颇深。相信各位云道中人都已猜到,aPaaS与IaaS/PaaS/SaaS这些云计算远古概念是一脉相承的:aPaaS介于PaaS和SaaS之间,相比PaaS提供的服务更偏应用,但又不像SaaS一样提供现成的软件服务(更详细的说明可参考配图来源文章)。

四、为什么需要低代码

低代码是什么可能并没那么重要,毕竟在这个信息爆炸的世界,永远不缺少新奇而又短命的事物。大部分所谓的新技术都只是昙花一现:出现了,被看到了;大部分人“哦”了一声,已阅但表示不感兴趣;小部分人惊叹于它的奇思妙想,激动地点了个赞后,回过头来该用什么还是什么。真正决定新技术是否能转化为新生产力的,永远不是技术本身有多么优秀和华丽,而是它是否真的被需要,即:为什么需要低代码?如果用不同的主语填充上面这个问句(冷知识:这叫做“延迟主语初始化”),可以更全面地看待这个问题:

为什么「市场」需要低代码?

在这个大爷大妈都满嘴“互联网+”和“数字化转型”的时代,企业越来越需要通过应用(App)来改善企业内部的信息流转、强化与客户之间的触点连接。然而,诞生还不太久的IT信息时代,也正面临着与我国社会主义初级阶段类似的供需关系矛盾:落后的软件开发生产力跟不上人民日益增长的业务需求。

11.png

Gartner预测,到2021年应用开发需求的市场增长将至少超过企业IT交付能力的5倍。面对如此巨大的IT缺口,如果没有一种革命性的“新生产力”体系,很难想象仅凭现有传统技术体系的发展延续就能彻底解决问题。而低代码技术正是带着这样的使命而降临,期望通过以下几个方面彻底革新应用开发生产力,拯救差一点就要迈入水深火热的IT世界:

提效降本 & 质量保障

虽然软件行业一直在高速发展,新的语言、框架和工具层出不穷,但作为从业者我们不得不承认:软件开发仍处于手工作坊阶段,效率低、人力成本高、质量不可控。项目延期交付已成为行业常态,而瓶颈几乎总是开发人员(对机器能解决的问题都不是问题);优秀的开发人才永远是稀缺资源,还贼贵;软件质量缺陷始终无法收敛,线上故障频发资损不断。

相比而言,传统制造业经过几百年工业革命的发展,大部分早已摆脱了对“人”的强依赖:从原料输入到制品输出,中间是各种精密仪器和自动化流水线的稳定支撑,真正实现生产的标准化和规模化。虽然信息化号称是人类的第三次工业革命,但以软件行业目前的状况,远远还没到达成熟的“工业化”阶段。

所以,亲爱的程序员朋友,当你与前端联调了一上午接口,又与产品撕逼了一下午需求,再与自己的bug抗争了一整晚,好不容易遁入梦乡又被一连串报警短信吵醒时,是否有抬头对着星空憧憬过:“I have a dream… that one day,软件开发也能像工业制品一样,批量流水化生产,稳定高效没烦恼。” 事到如今,不管你有没有意识到,这个憧憬正在慢慢变成现实。

12.png

是的,低代码正在将应用软件开发过程工业化:每个低代码开发平台都是一个技术密集型的应用工厂,所有项目相关人员都在同一条产线内紧密协作。开发主力不再是熟知for循环一百种写法的技术Geek,而是一群心怀想法业务sense十足的应用Maker。借助应用工厂中各种成熟的基础设施、现成的标准零件、自动化的装配流水线,开发者只需要专注于最核心的业务价值即可。即便是碰到非标需求,也可以随时自己动手,用最灵活的手工定制(代码)方式来解决各种边角问题。

扩大应用开发劳动力

通过让大部分开发工作可以仅通过简单的拖拽与配置完成,低代码(包括零代码)显著降低了使用者门槛,让企业能够充分利用前面所提到的平民开发者资源。部分纯零代码需求场景下,低代码还能让业务人员实现自助式(self-service)应用交付,既解决了传统IT交付模式下的任务堆积(backlog)问题,避免稀缺的专业开发资源被大量简单、重复性的应用开发需求所侵占,也能让业务人员真正按自己的想法去实现应用,摆脱交由他人开发时不可避免的桎梏。

13.png

至此,应用开发能力不再是少数专业开发者的专利和特权,且今后所需要的技能门槛与拥有成本也会越来越低,真正实现所谓的“技术民主化”(democratization of technology)。

加强开发过程的沟通协作

多方调查结果显示,软件项目失败的最主要原因之一就是缺乏沟通(poor communication)。传统开发模式下,业务、产品、设计、开发、测试与运维人员各司其职,且各有一套领域内的工具和语言,长久以来很容易形成一个个“竖井”(silos),让跨职能的沟通变得困难而低效。这也是为什么当前热门的敏捷开发和DevOps都在强调沟通(前者是协同Biz与Dev,而后者是协同Dev和Ops),而经典的DDD领域驱动设计也主张通过“统一语言”来减少业务与技术人员之间的沟通不一致。

14.png

有了低代码后,这一状况将得到根本改善:上述各角色都可以在同一个低代码开发平台上紧密协作(甚至可以是同一个人),这种全新的协作模式不仅打破了职能竖井,还能通过统一的可视化语言和单一的应用表示(页面/数据/逻辑),轻松对齐项目各方对应用形态和项目进度的理解,实现更终极的敏捷开发模式,以及在传统DevOps基础之上更进一步的BizDevOps[2]。

统一开发平台下的聚合效应

低代码尝试将所有与应用开发相关活动都收敛到同一个平台(one platform)上后,将会产生更多方面的聚合效应与规模收益:

  • 人员聚合:除了上一点所提到的各职能角色紧密协作以外,人员聚合到统一的低代码开发平台进行作业后,还能促进整个项目流程的标准化、规范化和统一化。
  • 应用聚合:一方面,新应用的架构设计、资产复用、相互调用变得更容易;另一方面,各应用的数据都天然互通,同时平台外数据也能通过集成能力进行打通,彻底消除企业的数据孤岛问题。
  • 生态聚合:当低代码开发平台聚合了足够多的开发者和应用后,将形成一个巨大的、连接一切、有无限想象力的生态体系,彻底放飞低代码的价值。

为什么「这个时代」才需要低代码?

如果你了解过市面上各种低代码产品,不难发现其实这个领域的许多玩家在低代码概念诞生之前就已经存在了,比如:低代码领域的另一个巨头OutSystems,早在2001年就已经创立;而去年也被Forrester评为低代码行业leader之一的FileMaker,更是诞生于遥远的1985年(正好35岁,似乎在疯狂暗示什么)。那么,如果低代码像前面说的那么好,为什么以前没有火起来呢?从技术和业务两个角度看,可以归纳为以下原因:

技术成熟度不足

低代码底层的各项核心技术(可视化、模型驱动、RAD、BPMS…)都已经有漫长的发展历史,看上去似乎只是新瓶装旧酒。然而理智的人都知道,任何技术都会遵循所谓的“技术成熟度曲线”(The Hype Cycle),不可能刚一诞生就跳过发育直接秀翻全场,被大规模采纳和投入生产。以模型驱动技术为例,虽然十几年前就已经有体系化的理论研究(e.g. MDA)和配套工具(e.g. EMF),但在当时的技术背景下,由于能力不完备、过于理想化、技术门槛高等原因,一直没能在工业界走向主流。

15.png

而如今这个时代,支撑低代码的那些“老”技术都已经过长时间的发展酝酿与市场检验,而另一些完美互补的“新”技术(e.g. 云原生、响应式Web)也在飞速发展和走向成熟,是时候通过“低代码”这个新酒瓶重新包装上市,为亟需新生产力的传统IT市场带来一场真香之旅了。

业务收益不明显

即使十几年前的低代码技术已经足够成熟,也一定不会在当年的应用开发市场上产生现在这样的影响力。为什么?因为技术都是为业务服务的,而当时的应用开发业务需求可比现在简单多了:没有如今的多渠道(Multi-channel)、多样化体验(Multi-experience)和各种集成与定制需求,也不会奢求如今已成为企业级应用标配的弹性、分布式和高可用,更是缺乏快速变化的IT业务场景来推动持续集成与快速交付。

虽然低代码可以完美解决上述所有问题(e.g. 多端应用生成、云原生架构、API集成能力),但放在当年的市场和业务背景下,加上前面所说的技术不成熟度,整体的投入产出比会很低,不足以让企业大面积采纳低代码解决方案。

16.png

而如今这个时代,企业都快被新技术带来的能力和收益“惯坏了”,动不动就是:我想做一个送菜应用。用户端?安卓、iOS、H5、小程序都来一套。运营端?一般都在电脑上看,但记得手机上也得适配啊。服务端?上云,必须的。哦,我听技术合伙人说现在流行多云架构,也给我整一套哈。运维还要钱?啥是运维?应用有了不就能用了嘛,运维还要花我钱?你当投资者给我的钱是大风刮来的啊!

如果用传统的开发模式,这么全套下来的工时与报价,可能早就吓跑了这群跟产品经理一样天真可爱的人;但现代化的低代码技术,可以圆了上面这位创业者的卖菜梦,用白菜一般的价格,实现白粉一样的价值。当年的程维如果能用上现在的低代码,第一版的滴滴App也就不至于被外包做得乌烟瘴气直接报废了(至少能多扛一阵子…)。

为什么「专业开发者」也需要低代码?

虽然零代码确实是设计给非专业开发者用的,但其所能支撑的业务场景确实有限,无法真正革新传统开发模式,替代那些仍需专业开发者参与的复杂业务场景。而狭义上的低代码却有潜力做到这一点,因为它天生就是为专业开发者而量身定制的。Gartner最近的一项调研报告显示,“66%的低代码开发平台用户都是企业IT部门的专业开发者”。这充分说明了,专业开发者比平民开发者更需要低代码。

屏幕前一批穿格子衬衫的同学要发问了:“低代码都不怎么写代码了,怎么能算是为我们程序员服务呢?”。虽然程序员讨厌重复自己,但重要的事情还是得多说一遍:开发 ≠ 写代码。1万年前蹲在洞穴里的原始人,在用小石子画远古图腾;100年前坐在书桌前的徐志摩,在用钢笔给林徽因写情书;而今天趴在屏幕前的很多人,相信都已经开始用上手写板或iPad涂涂写写了。千百年来,人类使用的工具一直在演进,但所从事活动的本质并没有多大改变。无论是用小石子还是小鼠标,写作绘画的本质都是创造与表达,最终作品的好坏并不取决于当时你手中拿着什么;同样地,应用开发的本质是想法和逻辑,最终价值的高低也不取决你实现时是用的纯代码还是低代码。

而相比纯代码而言,低代码极有可能成为更好的下一代生产力工具:

减少不必要的工作量

可视化拖拽与参数配置的极简开发模式,结合模型驱动的代码自动生成机制,可以消灭绝大部分繁琐和重复的boilerplate代码;一站式的部署和运维管理平台,无需自己搭建CI/CD流水线、申请环境资源、配置监控报警;一次搭建同时生成、构建和发布多端应用,免去人工同步维护多个功能重复的端应用;开箱即用的组件库、模板库、主题库、连接器等,让最大化软件复用成为可能。总而言之,低代码能够让专业开发者更专注于创新性、有价值、有区分度的工作,而不是把宝贵开发时间都耗费在上面那些不必要的非业务核心工作上。

强大的平台能力支撑

虽然上面列的技术支撑性工作并不直接产生业务价值,但却会直接影响业务的性能、成本、稳定性、安全性、可持续发展能力等。有远见的企业,绝不允许牺牲这些重要指标,来换取短暂的业务加速。低代码开发平台深知这一点,因此在简化和屏蔽底层技术细节的同时,也会尽可能把自己所cover的部分做到最好(至少能和纯代码开发方式一样好),包括但不限于:

  • • 现代化的技术架构和实现:现代化的低代码开发平台,在支撑用户应用时所选择的技术架构与实现方案,也会是现代化且符合业界最佳实践的,例如,前端基于主流的HTML5/CSS3标准和React框架,后端基于成熟的Java语言、SpringBoot框架和MySQL数据库,部署环境基于云原生的Docker镜像、CI/CD流水线、K8s集群和Service Mesh技术(相关知识可参考《正确入门Service Mesh:起源、发展和现状》)。
  • • 零成本的技术升级和维护:低代码的高维抽象开发方式,让应用的核心业务逻辑与底层技术细节彻底解耦。开发者在大部分情况下都不需要关心底层技术选型,同时也无需亲自跟进这些技术的版本升级与漏洞修复,免费享受与时俱进的技术红利和应用安全性提升。即便遇到某些底层技术或工具需要进行彻底更换(比如不再维护的开源项目),开发者也完全不必感知;技术迁移再费劲再难搞,平台自己努力就行,对开发者来说只要服务一直在线,岁月就依然静好;事后可能还会惊喜地发现,应用访问突然就变得更快了,仿佛冥冥中自有天助,感激上苍和低代码。

一体化生态能力复用

复用(Reuse)是提升软件开发效率和工程质量的最有效途径。传统的代码开发模式下,开发者可以通过提取公共类/函数、引用共享库、调用外部API服务、沉淀代码片段和模板等方式实现复用。在低代码的世界里,平台也可以提供对应的多层次多粒度复用手段,比如页面组件库、逻辑函数库、应用模板库等。

但更重要的是,低代码平台还可以充分发挥其一体化的生态优势,提供强大易用的可复用能力(资产)的发现、集成与共享体系:以页面组件为例,你可以直接用系统组件,也可以在平台自带的组件市场上搜索和引用更合适的组件,还可以自己用代码开发一个自定义组件并发布到市场中。平台的生态体系越大,积累的可复用能力就越多,应用的开发成本也会越低。

相比而言,虽然传统代码世界整体生态更庞大和深厚,但由于各类技术不互通、缺乏统一平台与市场、代码集成成本高等原因,一直以来都没有形成有类似规模潜力的生态能力复用体系,导致重复造轮子和低水平重复建设的现象司空见惯,还美名为“新基建”。

说到这里,另一批裹着冲锋衣头顶锃亮的同学也忍不住了:“万一低代码真的发展起来了,是不是就不需要那么多程序员了啊?上有老下有小的,同是码农身,相煎何太急!”。低代码虽然是一场应用开发生产力革命,但并不会革掉程序员的饭碗。它去掉的只是难懂的编程语法、繁琐的技术细节和一切可自动化的重复性工作,并没有也无法去掉应用开发最核心的东西:严谨的业务逻辑、巧妙的算法设计、良好的工程风格等。对于真正的程序员,即使剥去他一层又一层的编程语言和工具熟练度技能外壳,最终剩下的仍然是一个有价值的硬核开发者。

当然,如果你坚持要用纯粹的写代码方式来改变世界,也不至于失业。要么,你可以选择那些低代码暂时不太适用的领域,比如底层系统驱动、3D游戏引擎、火箭发射程序;或者,你也可以选择去写低代码中那一部分不可或缺的自定义代码扩展,为平民开发者提供高质量的积木。最后,你也完全可以选择为低代码平台本身的底层代码添砖加瓦,比如加入阿里云云原生应用研发平台EMAS团队 (〃’▽’〃) ,与作者一起共建下一代云原生低代码开发平台“Mobi”,内推直达邮箱:pengqun.pq@alibaba-inc.com。

为什么「我不」需要低代码

即使所有人都认同上述“为什么要用低代码”的理由,但仍不时会有试水者跳出来,给大家细数“为什么我不需要低代码”。实践出真知没错,而且大部分质疑背后也都有一定道理;但在我看来,更多的可能是主观或无意识的偏见。这里我列了一些对低代码的常见质疑和我个人的看法,期望能帮助大家看到一个更全面和客观的低代码。

质疑1:低代码平台不好使

“试用过一些所谓的低代码开发平台,要么能力很弱,要么体验太差,只能开发点玩具应用。”

作为调研过国内外多款低代码产品的深度体验用户,我的观点是:不能以偏概全。低代码市场在国内正处于爆发初期,所以许多与低代码只沾一点边的产品也都在蹭热点;但它们并不能代表低代码目前的业界水平和发展方向。市面上真正成熟的企业级低代码开发平台,完全有能力以高效的开发方式满足大部分复杂场景的功能需求,以及企业级应用所需要的安全、性能、可伸缩等非功能需求,这一点在国外市场已得到充分验证(不然也不会这么被寄予厚望)。

当然,国内市场尚处于鱼龙混杂的混战阶段,遇到真龙的概率很低,但碰上金鱼鲤鱼甚至木头假鱼都在所难免。相信随着时间推移,真正有实力和口碑的产品都能脱颖而出,为大家展现低代码该有的样子。

质疑2:低代低开发不可控

“平台上的各种可视化组件、逻辑动作和部署环境都是黑盒,如果内部出问题无法排查和解决。”

作为同样不搞清楚底层原理不舒服斯基的程序员,我更愿意相信:问题只是暂时的。虽然这确实是目前使用低代码平台时绕不开的一个痛点,但并不属于低代码技术本身的固有缺陷。计算机领域有一句至理名言:任何问题都可以通过增加一个间接的中间层来解决。低代码的思路亦是如此:与当年的操作系统和现在的云平台一样,都是想通过建立一个黑盒化的中间层抽象来降低开发者的工作量与心智负担。

当然,所有额外增加的中间层都不是完全免费的,低代码也不例外。作为一个尚未成熟稳定的新的中间层,低代码必然会出现各种让使用者束手无措的问题,就跟当年的操作系统内核bug、如今的云主机I/O hang一样。但历史规律也告诉我们,所有伟大的技术最终都会走向成熟;只要低代码领域一直健康发展,问题总会越来越少,最终降到一个绝大部分人感知不到的范围内。过去萦绕在Windows用户心中挥之不去的“蓝屏”问题,对如今的新用户来说早已不知为何物;今天低代码开发者所遇到的种种“蓝瘦”问题,未来也终将成为被遗忘的历史(谁还没段黑历史呢)。

质疑3:低代码应用难维护

“应用一旦复杂起来,各种复杂逻辑流穿插着自定义代码,看不懂也改不动,还不如全用代码呢。”

作为对软件可维护性深有感触的无脑级布道者(见《救火必备!问题排查与系统优化手册》),我不得不说:用低代码开发,也要讲基本法。一般来说,无论是使用低代码开发还是纯代码开发,造成应用可维护性低的根本原因往往不在于开发工具,而是开发者自身没有去遵循一些软件开发的普适原则,比如工程规范性、命名可读性、DRY/KISS/SOLID原则等。

好的低代码平台绝不会阻碍开发者去改善应用的可维护性;恰恰相反,还会尽可能提供引导和帮助。以Mendix为例,除了支持基本的模型分析与重构(e.g. 无用模型、对象重命名、子逻辑流提取)以外,甚至还提供了基于ISO/IEC 25010标准的应用质量监控(AQM)能力。另一方面,让应用变得难以维护的一个客观原因也是应用本身过于复杂,而低代码作为高度抽象和自动化的开发模式,在降低应用复杂度方面是专业的。

综合来看,低代码虽然不是能解决一切问题的银弹,但更不是会带来更多问题的炸弹:在提高应用可维护性方面的上限,一定比传统开发模式更高;但决定应用可维护性下限的,依然还是开发者自己。

五、低代码行业发展

回应质疑的最好方式,就是做好你自己,用实际的表现说话。对于一个行业而言,判断它当前的表现是否够好,或者未来是否有潜力做到更好,可以从以下这三个方面进行衡量:市场规模(蛋糕够不够大)、适用场景(是否可落地)、竞品状况(有没有被验证过)。

市场规模

“Talk is cheap,show me the code money.”

—— Linus Starcraft

文章可以忽悠,但市场不会说谎:

  • • Forrester在2015年曾预测过,低代码的市场将从2015年的17亿美元增长至2020年的150亿美元。
  • • Marketsandmarkets在今年四月份的分析报告中预测,低代码的市场将从2020年的130亿美元(估算值,可以看出来与Forrester当年的预测是接近的)增长到2025年的450亿美元(年复合增长率:28.1%)。
  • • PS Inteligence在2018年的分析报告中预测,全球的低代码开发平台市场中,亚太地区将在今后五年(2019-2024年)中保持最高的增长速度。
    17.png

总结一下就是两点:

  • • 低代码的市场规模足够大,且一直都在高速增长。
  • • 作为亚太地区的经济大国与IT强国,中国的低代码市场将会引来一个爆发期,未来几年内的增速都会超过全球平均水平。

适用场景

理论上来说,低代码是完全对标传统纯代码的通用开发模式,应该有能力支撑所有可能的业务场景。但理论也只是理论,低代码一统江湖的梦想尚未照进现实,也不可能完全取代现实。前文中提到过,低代码与纯代码方式是互补关系,未来也将长期共存,各自在其所适合的业务场景中发光发热。同时还需要指出的是,当前阶段的低代码技术、产品和市场都尚未完全成熟,因此部分本来可能很适合用低代码来开发的场景,目前也只能先用纯代码来替代。

Gartner在2019年的低代码调研报告中,曾经绘制过一张用来阐述低代码适用场景的“应用金字塔”:

18.png

  • 应用级别划分:从下往上,分别为工作组级(Workgroup Class)、部门级(Departmental Class)、企业级(Enterprise Class)、可扩展需求极强的企业级(Extreme-Scale Enterprise Class)。容易看出来,它主要的划分维度就是应用所面向的用户基数(基数越大,可扩展需求也越高)。
  • 任务关键性:从下往上,各级别应用的任务关键性(Mission Criticality)逐级递增。例如一个只在工作组内使用的后台管理应用,一般都不会涉及到影响整个企业的关键任务。脱离企业这个视角来看,整个软件产业中也有很多通用的任务关键型应用,比如:实时操作系统、航空调度系统、银行对账系统。
  • 实现复杂度:从下往上,各级别应用的复杂度(Complexity)也逐级递增。例如最上层的企业级应用,除了功能覆盖面大导致业务复杂以外,往往还需要满足更多苛刻的非功能需求,包括但不限于:用户体验、性能、可靠性、安全性、可伸缩性、可维护性、兼容性。其他一些复杂软件的案例包括:3D游戏界面(交互复杂)极其底层的游戏引擎(逻辑复杂)、超大型CRM系统(一方面是实现很复杂,另一方面,这种成熟软件的标准化程度较高,大部分情况下可以直接用现成的SaaS软件)。
  • 应用需求量:从上往下,各级别应用的需求体量(Volume)逐级递增,呈现一个金字塔形状。这个特征可以用万能的2/8原则来理解:20%的“全民”应用,由于需求的通用性和普适性,可以覆盖至少80%的用户群体(例如企业大部分人都要用的考勤系统);而剩下那80%的“小众”应用,由于需求的定制化和特殊性(例如蚂蚁的期权系统…),就只能覆盖各自小圈子里那20%的用户了。
  • 与低代码的契合关系:从上往下,各级别应用与低代码越来越契合(Relevant)。也就是说:越简单的应用,越契合低代码;越不太关键的任务,也越契合低代码。同时,由于契合低代码的应用更偏金字塔底层,而这些应用的需求量都更大,所以可以得出如下判断:低代码能够适用于大部分业务场景(而且这个比例会一直上升,逐步往金字塔的更上层应用逼近),例如:B2E类应用(表单、审批流、ERP系统)、B2B类应用(企业商城、工业控制台)、B2C类应用(企业展示、营销页、店铺装修)。

竞品概况

低代码虽然是一个新兴概念,但这个行业本身并不算很新(前文也有提到),这些年以来早就积累了不少资深的荣耀王者。同时,低代码作为一个朝阳产业和资本热点,近几年也不断有更多的新玩家在加入这个刺激战场。

19.png

上图分别是Gartner给出的低代码平台魔力象限和Forrester给出的低代码平台技术波谱。从图中可以看到:

  • • OutSystems和Mendix一马当先,是公认的低代码领域头牌。这两家都是很纯粹的通用低代码开发平台,且都经过了长时间的发展和积累:OutSystems成立于2001年,员工人数1000+,年营收超过1亿美元;2018年6月获得了KKR和高盛的3.6亿美元融资,目前估值超过10亿美元;Mendix成立于2005年,员工人数500+,年营收超过2300万美元(18年数据),2018年8月被西门子以7.3亿美元收购。
  • • Salesforce和Microsoft紧随其后,都处于行业领先者地位。但这两家的公司性质和发展路径都很不一样:Salesforce是以SaaS起家,公司规模就不用多说了,反正就是SaaS届的巨无霸。这类SaaS厂商做低代码的动力,是为了解决客户对成品SaaS软件的定制诉求。M$更不用多介绍,只说下他们做低代码的天然优势:一方面,作为办公软件航空母舰,低代码可以帮助他们的客户实现从Excel表单到定制App的能力与体验升级;另一方面,作为云计算三巨头之一,低代码可以帮助他们连接内部的云计算生态体系,为开发者提供一个统一和易用的上云界面。
  • • 国外市场已经得到充分验证,但国内市场还刚刚兴起,还没有一家能够赢得上述调研机构的芳心,挤进上面这两张方图。国内目前的一些竞品和融资情况包括:2018年5月,搭搭云完成A轮的千万级融资;2018年9月,宜创科技得到清源创投的战略融资;2018年12月,轻流完成千万级Pre-A融资;2019年8月,数式科技得到盈动资本的数千万人民币天使轮融资;2019年8月,ClickPaas获得晨兴资本数百万美元的A轮融资;2019年,奥哲分别获得阿里5千万的A+轮融和高榕资本上亿元的B轮融资。(注:竞品数据来源于我们组PD的辛勤整理;为此我决定这篇文章剩下内容再也不黑PD了;下篇再说。)

六、结语

本文总结了低代码领域的基本概念、核心价值与行业现状。虽然这些内容都比较基础和偏理论,但我始终认为,深刻理解一个系统的前提,正是这些务虚的东西 —— 技术架构只会告诉你这个系统是怎么实现的(How),无法准确表述它到底能用来做什么(What),以及为什么要做这样一个东西(Why);而后面这两个问题的答案,才是后续系统所有设计与演进的根因和驱动力。

陆奇为什么去Y Combinator,这家公司是做什么的

离开百度之后,陆奇的去向一直是个谜。就在沉寂了三个月之后,陆奇的最终去向确定,于2018年8月正式加入Y Combinator(以下简称YC),担任YC中国创始人及首席执行官,并任YC全球研究院院长。

在加入YC之前,陆奇曾担任百度集团总裁兼首席运营官,主要负责百度的产品、技术、销售及市场运营,兼任百度智能驾驶事业部群组总经理。陆奇也曾在微软、雅虎和IBM等公司任职,曾担任微软集团全球执行副总裁、雅虎执行副总裁等职位。

究竟陆奇为什么要加入YC?这家公司又是何方神圣?陆奇下一步如何计划?就在刚结束的YC中国媒体活动上,陆奇一一正面做出回应。

成立于2005年的Y Combinator是一家加速器投资机构,它的核心能力和业务是帮助初创公司、创业者快速提高,特别是从0到1的提升。十多年来,虽然YC服务的创业公司遍布世界各地,但他们却一直只在硅谷运营。进入中国是YC设立的首个海外业务拓展团队,是其迈向全球化的第一步。陆奇也笑称,自己是YC中国第一号员工,是天时地利人和,让他和YC栓在了一起。

“我个人的职业生涯也已经到了一个阶段,YC这个全球平台,我的两份工作(YC中国的创始人兼CEO、YC全球研究院院长)更适合我参与新一代的技术驱动创新的波浪”。“由于个人和家庭的原因,我希望在美国和中国都花时间,YC这份工作可以非常好地满足我个人和家庭的需求”。“我个人在美国科技圈的人脉,和我在中国的个人文化基因,也可以相互有机地融合在一起”。

接下来,陆奇将全面负责YC在中国市场的业务和战略拓展,他表示,上任后的第一件事就是招兵买马,建立YC中国一流的团队,充分发挥YC全球研究院持久的科研潜力,充分展示本地化“基因”:由中国顶尖人才组建(By China)、为中国创业者和经济发展服务(For China)、成为中国社会的组成部分并作出贡献(Of China)。

同时,YC中国的新业务会包括四个重心:创业孵化、人才培训、科研和公益。未来,在陆奇的操刀下,这些计划都将以前所未有的方式运作。陆奇说,他要的不仅仅是新技术,技术只是变革社会的一种能力;他要建立新的生态支持新技术对社会的变革,那才是他心目中新世界的正确打开方式。

以下内容根据陆奇发言内容编辑整理:

我想现在大家可能都很好奇,由于种种原因在沟通会前我们不能提前跟大家沟通太多,所以在开场之前,我想给大家分享两个比较重要的背景。

1、加入YC的两个背景

第一个是我个人的背景,是我长期的理念。我自己其实是一个非常幸运的人,在过去几十年有机会直接参与了一系列大规模的平台技术的开发,也直接一线地参与了和观察了巨大的产品商业创新,由于这样的技术平台所驱动的互联网也好、软件也好,整个生态在全球范围内造成了巨大的正面影响。我在这个过程中学了很多,也思考了很多,从而形成了一个非常坚信不疑的理念,社会的进步,人类文明的进步,最终将由技术而驱动,这是一个不可阻挡的历史长河。因为社会进步最大的驱动因素是创新,科学技术的进步是驱动创新的动力,所以从我个人的角度来讲,站在技术驱动创新的前沿,寻找机会能够参与、做贡献,并继续学习将是我永久的驱动力,也是我个人职业生涯上长期的指南。

第二个背景是关于当前整个全球的机会窗口。大家都知道,基于人工智能等一系列前沿技术,创新将在全球范围内对整个社会经济产生前所未有的影响。在这个大的浪潮下,中国将来可能会成为一个创新大国。对此,我们需要建立更强的技术驱动创新的能力;我们需要科技做更多、更有效、更长期的投入。同时,由于这些技术所带来的新的生产能力,对体系的创新,尤其是创新的源头、早期生态、创业者、投资者,我们需要探索和建立一个把资本、人才、科研、商业机会有机地连在一起的契机。激活更多的创新机会,带来更多的创新效益,最终,造福于社会和人类的进步,这是第二大背景。 基于这两个背景,这就是我为什么会到这个媒体沟通会现场的原因。今天我会正式发布一个重要的消息,也就是Y Combinator(以下简称YC),将正式进入中国。

2、YC究竟是一家什么样的公司?

YC是一家全球知名的非常成功的创业投资和加速器公司,YC将为中国的创新生态提供宝贵的、杰出的、技术驱动创新的力量。另外,我将担任YC中国的创始人和首席执行官,全面负责在中国组建YC中国的团队,拓展YC中国的业务。同时,我也将担任YC全球研究院的院长,在美国西雅图的YC研究院总部,更全面地推动科技研究。

这就是我今天想要分享的两个消息。接下来我想大家一定会有很多问题。第一,YC是谁?第二,YC为什么在美国会这么成功?第三,YC为什么要进入中国?第四,YC进入中国之后,会开展哪些业务,并在中国做一些贡献?接下来我会把这几个点一一跟大家分享。

首先,YC是2005年由Paul Graham成立的,它是历史上第一家创业加速器公司,总部在美国加利福尼亚州山景城,它的核心能力和业务是帮助初创公司、创业者快速提高,特别是从0到1的提升,YC今天的掌门人——Sam Altman,他是2014年加入YC的。YC在他的领导下高速成长,已经加速超过1900多家初创公司,这些初创公司的总估值已经超过了1000亿美元,并且有15家估值超过10亿美元的独角兽公司。

3、YC为什么在美国非常成功?

YC是一个有非常强的使命驱动的公司,YC有非常强大和长远的愿景和使命,YC的愿景是最大化实现创新,并确保全人类能从中公平受益。同时YC的使命是助力不同发展阶段的初创公司实现真正的腾飞,加入YC三个月后进入更佳状态。另外,YC是有它强大的文化基因,它的文化基因是由YC的创始人团队所建立的,由今天的掌门人Samn Altman进一步发扬光大。

YC有四个联合的创始人,Paul和Jessica是志同道合的一对夫妇,他们做了很多珍贵的努力。另外Trevor Blackwell、Robert Morris跟Paul三个人其实是长期合作伙伴,他们在哈佛大学一起念博士的时候就开了一家初创公司。这四个合伙人都是一流的开发人员,他们有共同的强烈的理念。所以在2005年他们一起建立了YC,我也非常有缘分,2005年在哈佛大学第一期YC暑期夏令营的时候,Paul也让我去了,我也代表雅虎致辞,同时也是因为这样一个契机我认识了Sam Altman,他的初创公司是YC第一期支持的公司。Sam在2014年接管YC,他是非常年轻杰出的人才,才华出众。Sam除了担任YC要职外,还是Open AI的联席主席。YC成功的很大原因是因为它有很好的核心文化,是建立在创始人和现在领导人之上的。

YC为什么在美国会这么成功?是因为YC有独特的方法论和有效的实现方法,它能系统化地、全方位地对早期初创公司提供支持,其中有5个组成部分:

提供早期投资资金,并换取少量的股份; YC一年举办两次的为期3个月的丰富培训,重头戏是其中的路演日和投资者日,通过这个培训来帮助初创企业更快地找到从0到1的提升,同时也帮助创始人能够获得更好、更多的融资,以及资金的支持;庞大的YC校友网络资源,YC每个参与者都有着非常强的社会归属感,他们进入到YC的家庭之后,不光得到了帮助,同时他们也非常愿意帮助新的YC校友,这形成了一个强大的文化、一个重要的资源,目前YC校友社区已经超过了4000多个人,对每个创业公司、创业者来讲,是长期的取之不尽的资源,各个层面都有帮助; YC有固定的机制,让创业者得到专家的点评和支持,通过办公时间可以和YC的合伙人和行业专家进行交流。品牌的可信度,由于YC在业务上发展的比较成功,它的口碑越来越好。YC提升是一个强大的品牌,可以为创业者提供品牌背书,一个初创公司如果得到YC的支持,代表着很大程度上的认可,也可以帮助他们获得更多的融资,获得其他的商业机会。

YC不光在过去成功,将来也会越来越成功,因为它的基础越来越坚实,它的规模越来越大。YC所加速的公司,已经形成了一批一流的将来可以成为在美国和全球成为骨干的企业,比如说全球领先的短租平台Airbnb、云储存服务供应商Dropbox、数字支付供应商Stripe、美国社交新闻互联网公司Reddit和开放源代码平台Docker等。同时,YC的业务也不断在扩展。从原来的加速器,培训以及在线的创业者学校,包括YC在美国成立的YC研究院等等,这就是为什么YC在全球范围内会持续增长、不断加速的重要原因。

4、YC为什么要进入中国?

其实YC在中国支持了不少的中国公司,但比例相当小,这就是YC为什么要进入中国的原因之一。更重要的原因,是Sam对中国特别看好,我们坚信中国的发展生态、创新速度,长期对全球的贡献是至关重要的。Sam经常讲这句话,他坚信,接下来10年,肯定有一批像Google、微软、苹果、亚马逊、脸书这样颇具影响力的公司会被建立起来,这些公司大部分都会在中国和美国,其中有好几家我们坚信是将诞生在中国的。

我们都坚信不疑地相信YC在中国有很大的用武之地。简单归纳一下就是天时、地利、人和。

我先讲天时,我们今天所处的时间窗口是很特殊的,中国随着创新的大浪潮,一定会成为一个创新大国,中国的创新生态需要技术驱动的创新,大家都知道中国的创新生态在过去几十年有很大的进步。但是很多层面的创新是模式的创新,产品的创新,体验的创新。但是到下一个阶段,技术驱动创新会扮演越来越重要的角色,而这正是YC最擅长的。YC有自己独特的方法论和行之有效的手段,YC有非常强大的创业者群体资源。通过充分的本地化,YC毫无疑问将对中国的早期创新生态提供强大的技术驱动创新的推动力,这从时机上、长远发展的机会上是非常有契机的。

地利也很重要,基于下一代技术所进行的全球创新,将由美国和中国一起驱动,在这个大环境下,中国有很大的、独特的优势,中国整体的创新能力在不断提高。同时,美国拥有全球最顶尖的技术,拥有全球最顶尖的技术人才。YC将通过YC中国帮助中国的创新生态、中国的创业者,更快、更有效地获取美国的成功经验。同时,YC中国也可以帮助中国的创新企业到美国发展,因为中国的创新企业会越来越多地全球化,地利上YC和YC中国能为中国的创新生态带来独特的价值。

第三是人和,YC通过YC中国将为中国的创业者带来一个独特的国际人脉,就是YC越来越庞大的创业者生态、YC的校友,通过连接中国的创业者提供长期的、珍贵的帮助。同时,我们也坚信中国的创业者加上美国的创业者会形成一个全球的创业生态,这个人脉会在全球范围内推动更多更好的创新。

5、选择加入YC的三个关键原因

我为什么选择YC?这个答案应该也比较明确了,也是天时、地利、人和。

前面我已经介绍过我个人职业生涯长期的指南,同时今天的机会、时间窗口点,天时是很显而易见的,同时我个人的职业生涯也已经到了一个阶段,YC这个全球平台,我的两份工作(YC中国的创始人兼CEO、YC全球研究院院长)更适合我参与新一代的技术驱动创新的波浪,并找到更多、更好的机会来贡献,从我个人的角度来讲,能直接参与到中国成为创新大国的过程中,是每次想起来都会振奋人心的机会。当然,YC也提供了很多让我学习的机会,这很重要,每天都要学习,有机会学习,所以从时间上来讲是非常吻合的。

地利也是很特殊的,由于个人和家庭的原因,我希望在美国和中国都花时间,YC这份工作可以非常好地满足我个人和家庭的需求。

人和,我和Sam、YC有这么好的缘分,这是一个起点,共同的理念见仁见智。同时,我个人在美国科技圈的人脉,和我在中国的个人文化基因,也可以相互有机地融合在一起。所以YC对我来讲是一个非常好的平台,YC给我的工作是非常适合我在下一阶段持续个人长期的、一直追求的一个梦。

6、YC中国如何推进中国的业务?

第一点很重要的是完全地本地化,建立属于当地的业务,我把它总结为By China、For China、Of China。

By China建于中国是由中国的人才所组建的当地的团队,这是特别重要的,也是我工作的重要优先点,必须要努力吸引中国一流的人才,特别是对创新、创业,有经验、有热情的人才来参与,这是一个起点和基础。

For China为了中国,YC所做的一切都是基于驱动中国创新的发展,为中国的发展而服务,我们所扶持的公司和选择的公司也将秉持这样一个宗旨,将一心一意为中国的发展做贡献。

Of China属于中国,YC在中国创新的结果须回报给中国社会,YC融入中国社会并持续地为中国的发展做出贡献。

基于这些,我们在YC中国将开展4个核心业务:

投资:这是我们的起点和核心,早期我们将继续推动创业者、初创企业的加速,我们将采纳YC美国行之有效的方法论和一些实现的手段,充分把它本地化,运用到中国的业务上来。同时我们也准备在中国当地融资,这是我们本地化重要的一环。 培训:这与YC中国投资的业务是完全有机地结合在一起的,我们也准备首先要引入YC在美国行之有效的一些经验,并将这些本地化和长期开发,为中国创业者提供行之有效的培训方法和内容。 科研:我们准备通过多种方法更长期、更有效地投入科研,这将成为YC全球研究院重要的组成部分。 公益:我前面讲到YC创新的结果必须回报给社会,我们的目的是把创新的结果更多的投入公益和慈善事业,我们准备重点将在于帮助人们,和社会,更好地解决由于技术发展而带来地就业影响。

在我们驱动所有业务的过程中,一定要保持不忘初心,这是我们YC中国的核心价值观和理念。我们坚信社会的进步、人类文明的进展,最终将由技术进步而驱动;永远相信远大抱负,相信只要坚持都有机会改变世界,把世界变得更好;相信长期专注,真正一项做得大的事业都需要长期的努力,都需要信心、恒心和耐心;对科研的投入,这不光是YC要对科研做投入,我们希望更多与YC合作的公司也都对科研做投入,相信对科研的投入一定会有很强、很好、长期的回报;坚信全球化,我们相信在全球范围内共享创新的经验,在全球范围内共享创新的成果。

7、YC中国如何与中国各行各业合作?

最后我想讲一下与中国各行各业如何合作、如何互动,一起把创新更强、更快地往前推动。

首先,我们欢迎中国所有的创业者广泛地跟我们互动、交流、合作,在此,我也想用这个机会感谢YC的合伙人Eric,他在过去作出了非常出色和努力的工作,帮助中国很多的创始人与YC的社区互动,得到了YC的帮助。

第二,与中国的投资者合作,这是一个很大的空间,我们在投资层面、各种商机有很多合作的空间,我们希望找到更多的、长期的、共赢的合作。

第三,与中国的企业和科研机构合作,我们愿意完全地开放,长期找到共赢的合作。与此同时,得到中国政府有关部门的支持,寻找长远有意义的合作。

最后,与在座各位媒体合作。希望通过我们之间的合作,中国的社会群体对YC更了解。我个人在此利用这个机会感谢大家过去对我的关心,希望将来继续支持YC,我也愿意与大家一起互动,保持长期的交流。

谷歌正为神秘Fuchsia OS招募外部开发者

雷锋网按:四年前,我们首次发现谷歌正在开发一款名为“Fuchsia”的新操作系统,该操作系统的独特之处在于,其并不是基于Linux内核打造,而是使用了一个名为Zircon的全新微内核。此外,尽管该操作系统也是开源的,但是却没有人知道它的真正用途,谷歌的高管对此也是避而不谈。

近期,谷歌公司对外发布的一个公告,显示着其仍在持续开发这个新的操作系统。公告显示,谷歌将从公司外部寻求更多的开发者,以便于让该操作系统变得更加开放。

谷歌方面表示,其已经为该项目的讨论创建了新的公共邮件列表,添加了一个专门阐述如何制定战略决策的管理制度,并为开发者开放了问题跟踪程序,以便查看正在进行的工作。

虽然有一些早期的UI事例,但在我们已经看到谷歌提供的关于此操作系统的代码和文档有一段时间了,但谷歌刚刚发布的公告仍然强调:“Fuchsia操作系统还没做好应用到产品中的准备,也并没有成为被开发的目标。”但此声明可能会引发另一轮猜想。

图注:疑似Fuchsia操作系统界面截图

我们知道,Fuchsia并一定是android或chrome操作系统的替代品,最有趣的是,据了解,Fuchsia已经在智能硬件产品,即谷歌的智能音箱上进行了实际的测试。不过,在智能音箱发布之后,他们也并没有运行Fuchsia操作系统。9to5Google的Kyle Bradshaw简单的列举了几个可能集成了Fuchsia操作系统的谷歌设备。

谷歌将Fuchsia简单的定义为安全、可更新、具有包容性和实用性的生产级操作系统。在2019年的一次采访中,谷歌中Android 和Chrome OS的负责人Hiroshi Lockheimer表示Fuchsia可以对除了手机和笔记本电脑外的某些其他产品进行优化。

他表示:“我们正在研究一个新的操作系统会是什么样子,所以我知道人们可能会很兴奋的说’哦,这是新的安卓系统,或者这是新的Chrome系统’,但Fuchsia只是我们在推动操作系统层面上最新技术的发展,从而使我们在这个过程中学到的东西,能够更好的应用到其他产品上。”

除了建立新的邮件列表和征集开发者之外,谷歌还发布了一份“技术路线图”,但这份技术路线图主要集中在底层操作系统上,比如“一个独立于驱动程序更新内核的驱动程序框架”和“Fuchsia接口定义语言”。该路线图表明,Fuchsia操作系统中,通过使用一个新的IO库和组件架构,许多最初的子系统正在被改造。

Google运行了很多开源项目,这些项目名义上是由任何人开发的,但实际上大部分都是由谷歌的工程师完成,Fuchsia看起来也是一样。在谷歌发布的新的管理方式中显示:“谷歌引导着Fuchsia操作系统的发展方向并做出平台决策”,但它更鼓励外部的开发者来共同开发Fuchsia操作系统。

通讯录App Sunshine Contacts获2000万美元种子轮融资,工具类App还有春天?

2020 年 11 月 18 日,由雅虎前首席执行官兼 Google 早期员工 Marissa Mayer 创立的公司 Sunshine(原名:Lumi Labs)推出了其首款正式产品 Sunshine Contacts。

本质上,这是一款工具 APP,目的是成为一款更高效的为用户梳理、升级和分享通讯录信息的工具。Sunshine Contacts 上线的同时,公司也会继续设想一系列面向消费者的 APP,可能面向的细分需求是用户的事件记录、家庭成员信息共享、日程安排,让他们只需使用 Sunshine 旗下的 APP 就可以被满足上述全部需求。

乍一看,这个新应用似乎和过去几年推出的应用没有不同,与 Full contact、Mingle 等 APP 属于同一个类别,不同的是,Sunshine Contacts 会通过向用户申请授权,抓取用户手机中的商务名片或者其他各类通讯、社交平台的信息,将一个联系人分散在各处的所有信息统一起来,做成一个个人信息更详细的通讯名录

图片1.png

Sunshine Contacts 运作方式 | 图片来源:Sunshine 官网

在 2020 年推出这样一款 APP 似乎没有竞争力。但是,这家初创公司在今年 5 月依然从内部和外部投资者那里筹集了 2000 万美元的种子轮资金。这种融资能力一方面可能与 Mayer 本人的影响力有关,另一方面也让人猜想这款 APP 会不会有创新模式或者不错的获利前景。难道工具类 APP 的春天又回来了吗?

一款通讯录 App 获 2000 万美金融资凭什么?

仔细看了 App 的介绍和相关的信息,感觉投资人看中这款产品和背后企业,大概有 2 个原因,一个是 AI 技术的应用,让通讯录收集到的信息粒度更高。另一个是,其未来的一整套产品。也就是说,投资人看的并不是这一款产品,而是后续的一系列产品。

过去的 APP 对联系人进行合并的方法通常是非常基本的,简单说就是“识别到通讯录中有两个 Adam Smith,就删掉一个”。但假如利用 AI 技术,APP 就可以深入细节,了解到两个 Adam Smith 究竟是不是同一个人。如果用户允许 APP 获取位置或者授权其他访问权限,App 还可以整合各处的信息,甚至进一步推断出用户在与哪些联系人进行更多的交流。

虽然AI技术在融资新闻里比较像个噱头,但 Sunshine Contacts 所属的公司 Sunshine 其实做AI有一段时间了。 自 2018 年成立以来,便一直致力于使用 AI 等复杂技术来改善人们日常使用的应用程序功能。如同 Mayer 所说的那样:“如果技术可以驱动汽车,那它怎么会做不到整理通讯录这种小事,从而让这种日常应用变得更好呢?”。

就 Sunshine Contacts 来说,对 AI 的应用在于获得许可的情况下从 iPhone 联系人和 Google 联系人中提取基础数据,然后通过识别联系人的工作地点或者查找对方在领英上的个人资料来自动补充基础数据中缺失的信息,例如照片、工作地点等。该 APP 还可以通过合并来消除重复地址。

图片2.png

iPhone 与 Sunshine Contacts 整合后的联系人名片对比图 | 图片来源: Sunshine 官网

可以看出,Sunshine 希望通过提供更细粒度且更丰富的信息来吸引并维持有需求的用户群,并凭这一点从同类应用中脱颖而出。

Sunshine Contacts 的另一个亮点是做产品矩阵,实际上许多公司早就开始这么做了,但 Sunshine 以及一些国外企业更擅长的可能是品牌的打造

首先,和大多数工具类 APP 一样,Sunshine Contacts 未来可能会在满足基本功能的基础上,鼓励用户通过付费升级获取更高级的功能集。但值得注意的是,Sunshine 公司还希望通过它的第一款产品吸引对功能改进感兴趣的用户群,最终为用户提供 Sunshine 下一整套完整的消费者服务,从而形成一个品牌。

一方面,企业可以以工具类 APP 为起点,拓展业务领域,以品牌方式铺开业务。另一方面,APP 内收集的客户数据可以是开展其他业务的基础。这些客户的数据质量更高,真实性更强。虽然 Sunshine 提供了一个隐私保证,承诺遵守数据安全惯例,不出售用户数据,但这并不意味着这些用户数据不会被 Sunshine 利用来发展其新的业务。

其实,出海厂商也早已经在利用这些方法,并且有不少的成功案例。在此基础上,提升品牌构建的能力或许可以帮助工具 APP 在海外有长远发展。

从融资交易,工具出海开发者可以参考的3点小趋势

传统的工具 APP 是企业出海的起点,Camera360、Battery Saver 等 APP 早年间为各自的公司赚到一大桶金。但随着市场发展,这些工具成了昨日黄花。很明显的原因有两点:

1、APP 提供的功能已经不再针对用户刚需。随着手机本身性能更新,以及手机厂商入局,工具 APP 对手机用户不再有必要性,并且无差异化的产品也没有市场;

2、靠流量获取广告实现变现的商业模式跟不上生态的变化。之前已经有大量文章做过论述,这里就不再展开了。

尽管出海不易,但工具类 APP 依旧是数量最多的出海 APP 种类。首先,这类应用在出海过程中不需在本土化问题上考量太多,运营模式相对简单。另外,在刚需之外,用户又产生了更多的需求,例如随着整个视频内容繁荣发展起来的视频剪辑 APP。

数据显示,如今的出海工具集中服务于用户的社交和影音制作需求。短视频的流行推动了移动音视频 APP 的发展。但短视频市场的这块蛋糕眼看被分得差不多了,倚靠它生存的工具类 APP 的竞争也必然激烈。

结合上述文章及对赛道的观察,笔者也提出了工具产品出海开发者可以参考的几点:

在成熟市场,工具类 App 的商业化,不论是为高级功能的付费、还是广告变现,都更容易打正。而成熟市场的用户更愿意尝新,且发展阶段也决定了他们的需求更深度和多样化。这里面有出海开发者可以再继续深挖的空间。

这款应用程序目前仅在美国 iOS 平台上线,随后将发布 web 版本,并在国际市场上线。从用户反馈来看,受邀体验者对这款 APP 的感受总体不错,主要的不满集中在页面设计,大多数受邀者认为这款 APP 界面色彩过多,不够整洁。要知道,愿意使用这类 APP 的用户如果希望自己的通讯录更有条理和简洁,应该也会希望 APP 本身不那么花哨吧。尽管不同地区市场对工具类 APP 的包容度普遍较高,但为了脱颖而出,开发者还是有必要考虑到目标地区的本土文化与用户的生活习惯。

图片3.png

Sunshine Contacts界面图 | 图片来源: Sunshine 官网

另一方面,工具不仅仅是对于用户更深度需求的挖掘,用户的体验也是一个可拓展的方向。例如 Branch 的 CEO 兼联合创始人 Dayton Mills 最近在做的一个项目,在疫情的大背景下,让办公变得更有趣。

Dayton Mills 说:“工作既然是无法逃避的地方,那为什么不让它变得更有趣一点呢?”。最近,他和伙伴致力于开发虚拟办公室,让办公工具变成办公游戏。(详情可参看Virtual HQs race to win over a remote-work-fatigued market| 来自: TechCrunch)

图片4.png

虚拟总部平台 Gather 界面 | 图片来源:Tech Crunch

这款 App 尽管还在研发中,没有上线,但已经从多个投资者那里筹集到 150 万美元。美国用户是愿意为“有趣”买单的,不过核心还是在于如何在有趣的同时,不忘记基本刚需。

最后一点,品牌,虽然更多可能是消费品考虑的事情,但品牌对于其他企业来说,未来也会越来越重要。品牌之间的产品的协同力量也应该得到重视。