Disclaimer: The opin­ions ex­pressed herein are my own per­sonal opin­ions and do not rep­re­sent my em­ploy­er’s view in any way.

We are dis­clos­ing a sig­nif­i­cant state-backed in­for­ma­tion op­er­a­tion fo­cused on the sit­u­a­tion in Hong Kong, specif­i­cally the protest move­ment and their calls for po­lit­i­cal change.

What we are dis­clos­ing

This dis­clo­sure con­sists of 936 ac­counts orig­i­nat­ing from within the People’s Republic of China (PRC). Overall, these ac­counts were de­lib­er­ately and specif­i­cally at­tempt­ing to sow po­lit­i­cal dis­cord in Hong Kong, in­clud­ing un­der­min­ing the le­git­i­macy and po­lit­i­cal po­si­tions of the protest move­ment on the ground. Based on our in­ten­sive in­ves­ti­ga­tions, we have re­li­able ev­i­dence to sup­port that this is a co­or­di­nated state-backed op­er­a­tion. Specifically, we iden­ti­fied large clus­ters of ac­counts be­hav­ing in a co­or­di­nated man­ner to am­plify mes­sages re­lated to the Hong Kong protests.

As Twitter is blocked in PRC, many of these ac­counts ac­cessed Twitter us­ing VPNs. However, some ac­counts ac­cessed Twitter from spe­cific un­blocked IP ad­dresses orig­i­nat­ing in main­land China. The ac­counts we are shar­ing to­day rep­re­sent the most ac­tive por­tions of this cam­paign; a larger, spammy net­work of ap­prox­i­mately 200,000 ac­counts — many cre­ated fol­low­ing our ini­tial sus­pen­sions — were proac­tively sus­pended be­fore they were sub­stan­tially ac­tive on the ser­vice.

All the ac­counts have been sus­pended for a range of vi­o­la­tions of our plat­form ma­nip­u­la­tion poli­cies, which we de­fine as:

Next steps

Covert, ma­nip­u­la­tive be­hav­iors have no place on our ser­vice — they vi­o­late the fun­da­men­tal prin­ci­ples on which our com­pany is built. As we have said be­fore, it is clear that in­for­ma­tion op­er­a­tions and co­or­di­nated in­au­then­tic be­hav­ior will not cease. These de­cep­tive strate­gies have been around for far longer than Twitter has ex­isted. They adapt and change as the geopo­lit­i­cal ter­rain evolves world­wide and as new tech­nolo­gies emerge. For our part, we are com­mit­ted to un­der­stand­ing and com­bat­ing how bad-faith ac­tors use our ser­vices.

Today we are adding archives con­tain­ing com­plete Tweet and user in­for­ma­tion for the 936 ac­counts we’ve dis­closed to our archive of in­for­ma­tion op­er­a­tions — the largest of its kind in the in­dus­try.

We will con­tinue to be vig­i­lant, learn­ing from this net­work and proac­tively en­forc­ing our poli­cies to serve the pub­lic con­ver­sa­tion. We hope that by be­ing trans­par­ent and open we will em­power fur­ther learn­ing and pub­lic un­der­stand­ing of these ne­far­i­ous tac­tics. You can ac­cess rel­e­vant in­for­ma­tion on these ac­count sets be­low.

August 2019, set 1:

Note: We have di­vided these archives into two parts to bet­ter en­able re­view of the in­ter­sect­ing net­works of ac­counts which com­prise this cam­paign. We have ev­i­dence to in­di­cate that both sets are as­so­ci­ated with the same en­tity.

Information op­er­a­tions on Twitter: prin­ci­ples, process, and dis­clo­sure

Updating our ad­ver­tis­ing poli­cies on state me­dia

By us­ing Twitter’s ser­vices you agree to our Cookies Use. We use cook­ies for pur­poses in­clud­ing an­a­lyt­ics, per­son­al­i­sa­tion, and ads.

Who We Are

Who We Are

Software has char­ac­ter­is­tics that make it hard to build with tra­di­tional man­age­ment tech­niques; ef­fec­tive de­vel­op­ment re­quires a dif­fer­ent, more ex­ploratory and it­er­a­tive ap­proach.

Why Bad Software Happens to Good People

Bad soft­ware is one of the few things in the world you can­not solve with money. Billion dol­lar air­lines have flight search apps that are of­ten in­fe­rior to those built by groups of stu­dents. Established taxi com­pa­nies the world over have ter­ri­ble book­ing apps de­spite the threat they face from ride-shar­ing ser­vices. And painful cor­po­rate IT sys­tems are usu­ally pro­jects with mas­sive bud­gets, built over the course of many years. Whatever the cause of bad soft­ware is, it does not seem to be a lack of fund­ing.

Surprisingly, the root cause of bad soft­ware has less to do with spe­cific en­gi­neer­ing choices, and more to do with how de­vel­op­ment pro­jects are man­aged. The worst soft­ware pro­jects of­ten pro­ceed in a very par­tic­u­lar way:

The pro­ject own­ers start out want­ing to build a spe­cific so­lu­tion and never ex­plic­itly iden­tify the prob­lem they are try­ing to solve. They then gather a long list of re­quire­ments from a large group of stake­hold­ers. This list is then handed off to a cor­re­spond­ingly large ex­ter­nal de­vel­op­ment team, who get to work build­ing this highly cus­tomised piece of soft­ware from scratch. Once all the re­quire­ments are met, every­one cel­e­brates as the sys­tem is launched and the pro­ject is de­clared com­plete.

The root cause of bad soft­ware has less to do with spe­cific en­gi­neer­ing choices, and more to do with how de­vel­op­ment pro­jects are man­aged.

However, though the sys­tem tech­ni­cally meets spec­i­fi­ca­tions, se­vere is­sues are found when it is put in the hands of ac­tual users. It is slow, con­fus­ing, and filled with sub­tle bugs that make us­ing it an ex­er­cise in frus­tra­tion. Unfortunately, by this time the ex­ter­nal de­vel­op­ment team has been dis­missed and there are no re­sources left over to make the nec­es­sary fixes. By the time a new pro­ject can be ini­ti­ated years later, all knowl­edge of what caused these prob­lems has left the or­gan­i­sa­tion and the cy­cle starts over again.

The right cod­ing lan­guage, sys­tem ar­chi­tec­ture, or in­ter­face de­sign will vary wildly from pro­ject to pro­ject. But there are char­ac­ter­is­tics par­tic­u­lar to soft­ware that con­sis­tently cause tra­di­tional man­age­ment prac­tices to fail, while al­low­ing small star­tups to suc­ceed with a shoe­string bud­get:

• Reusing good soft­ware is easy; it is what al­lows you to build good things quickly;

• Software is lim­ited not by the amount of re­sources put into build­ing it, but by how com­plex it can get be­fore it breaks down; and

• The main value in soft­ware is not the code pro­duced, but the knowl­edge ac­cu­mu­lated by the peo­ple who pro­duced it.

Understanding these char­ac­ter­is­tics may not guar­an­tee good out­comes, but it does help clar­ify why so many pro­jects pro­duce bad out­comes. Furthermore, these lead to some core op­er­at­ing prin­ci­ples that can dra­mat­i­cally im­prove the chances of suc­cess:

1. Start as sim­ple as pos­si­ble;

2. Seek out prob­lems and it­er­ate; and

3. Hire the best en­gi­neers you can.

While there are many sub­tler fac­tors to con­sider, these prin­ci­ples form a foun­da­tion that lets you get started build­ing good soft­ware.

Software is easy to copy. At a me­chan­i­cal level, lines of code can lit­er­ally be copied and pasted onto an­other com­puter. More gen­er­ally, the in­ter­net is full of tu­to­ri­als on how to build dif­fer­ent kinds of sys­tems us­ing ready-made code mod­ules that are avail­able on­line. Modern soft­ware is al­most never de­vel­oped from scratch. Even the most in­no­v­a­tive ap­pli­ca­tions are built us­ing ex­ist­ing soft­ware that has been com­bined and mod­i­fied to achieve a new re­sult.

The biggest source of reusable code mod­ules is the open source com­mu­nity. Open source soft­ware is soft­ware in which code is freely pub­lished for any­one to see and use. Many of the largest con­trib­u­tors to the open source com­mu­nity are gi­ant tech com­pa­nies. If you want to use a state-of-the-art planet scal­able data­base as Facebook does, just down­load the code for Cassandra that they open sourced in 2008. If you want to try out Google’s cut­ting-edge ma­chine learn­ing for your­self, down­load the TensorFlow sys­tem pub­lished in 2015. Using open source code does not just make your ap­pli­ca­tion de­vel­op­ment faster, it gives you ac­cess to tech­nol­ogy that is far more so­phis­ti­cated than any­thing you could have de­vel­oped your­self. For the most pop­u­lar open source code, it is even more se­cure as there are many more peo­ple pay­ing at­ten­tion and fix­ing vul­ner­a­bil­i­ties. This is the rea­son dig­i­tal tech­nol­ogy has made such rapid progress: even the newest en­gi­neers can build upon the most ad­vanced tools our pro­fes­sion has to of­fer.

The ad­vent of cloud ser­vices has taken reusabil­ity even fur­ther, of­fer­ing the full use of even pro­pri­etary sys­tems for just a sub­scrip­tion fee. Need a sim­ple web­site? Just con­fig­ure one in a few clicks us­ing a web­site build­ing ser­vice like Squarespace or Wix. A data­base? Subscribe to a vir­tual one from Amazon Web Services or Microsoft Azure. Cloud ser­vices al­low de­vel­op­ers to ben­e­fit from spe­cial­i­sa­tion; the ser­vice provider han­dles the setup, main­te­nance, and con­tin­ued de­vel­op­ment of a re­li­able, high-qual­ity piece of soft­ware that is used by all its sub­scribers. This al­lows soft­ware de­vel­op­ers to stop wast­ing time on solved prob­lems and in­stead fo­cus on de­liv­er­ing ac­tual value.

You can­not make tech­no­log­i­cal progress if all your time is spent on re­build­ing ex­ist­ing tech­nol­ogy. Software en­gi­neer­ing is about build­ing au­to­mated sys­tems, and one of the first things that gets au­to­mated away is rou­tine soft­ware en­gi­neer­ing work. The point is to un­der­stand what the right sys­tems to reuse are, how to cus­tomise them to fit your unique re­quire­ments, and fix­ing novel prob­lems dis­cov­ered along the way.

Software en­gi­neer­ing is about build­ing au­to­mated sys­tems, and one of the first things that gets au­to­mated away is rou­tine soft­ware en­gi­neer­ing work.

How use­ful a piece of soft­ware can be is usu­ally lim­ited by its com­plex­ity rather than the amount of re­sources in­vested in build­ing it.

IT sys­tems are of­ten full of fea­tures but are still hated by users be­cause of how con­fus­ing they be­come. In con­trast, highly ranked mo­bile apps tend to be lauded for their sim­plic­ity and in­tu­itive­ness. Learning to use soft­ware is hard. Beyond a point, new fea­tures ac­tu­ally make things worse for users be­cause the ac­cu­mu­lated com­plex­ity starts to be­come over­whelm­ing. For ex­am­ple, af­ter serv­ing as the hub of Apple’s me­dia ecosys­tem for al­most 20 years, iTunes was split into three dif­fer­ent apps (for mu­sic, pod­casts, and TV shows) this year, as its fea­tures had grown too com­plex for one app to han­dle. From a us­abil­ity per­spec­tive, the limit is not how many fea­tures can be im­ple­mented, but rather what can fit into a sim­ple in­tu­itive in­ter­face.

Even ig­nor­ing us­abil­ity, en­gi­neer­ing progress slows to a halt once a pro­ject be­comes too com­plex. Each new line of code added to an ap­pli­ca­tion has a chance of in­ter­act­ing with every other line. The big­ger an ap­pli­ca­tion’s code­base, the more bugs are in­tro­duced when­ever a new fea­ture is built. Eventually, the rate of work cre­ated from new bugs can­cels out the rate of work done from fea­ture de­vel­op­ment. This is known as “technical debt” and is the main chal­lenge in pro­fes­sional soft­ware de­vel­op­ment. It is the rea­son why many large IT sys­tems have is­sues that go un­fixed for years. Adding more en­gi­neers to the pro­ject just adds to the chaos: they start run­ning faster in place as the code­base keels over from its own weight.

In such cases, the only way for­ward is to take a step back to ra­tio­nalise and sim­plify the code­base. The sys­tem ar­chi­tec­ture can be re­designed to limit un­ex­pected in­ter­ac­tions. Non-critical fea­tures can be re­moved even if they have al­ready been built. Automated tools can be de­ployed to check for bugs and badly writ­ten code. Bill Gates once said “Measuring pro­gram­ming progress by lines of code is like mea­sur­ing air­craft build­ing progress by weight”. Human minds can only han­dle a fi­nite amount of com­plex­ity, so how so­phis­ti­cated a soft­ware sys­tem can get de­pends on how ef­fi­ciently this com­plex­ity bud­get is used.

Building good soft­ware in­volves al­ter­nat­ing cy­cles of ex­pand­ing and re­duc­ing com­plex­ity. As new fea­tures are de­vel­oped, dis­or­der nat­u­rally ac­cu­mu­lates in the sys­tem. When this messi­ness starts to cause prob­lems, progress is sus­pended to spend time clean­ing up. This two-step process is nec­es­sary be­cause there is no such thing as pla­ton­i­cally good en­gi­neer­ing: it de­pends on your needs and the prac­ti­cal prob­lems you en­counter. Even a sim­ple user in­ter­face such as Google’s search bar con­tains a mas­sive amount of com­plex­ity un­der the sur­face that can­not be per­fected in a sin­gle it­er­a­tion. The chal­lenge is man­ag­ing this cy­cle, let­ting it get messy enough to make mean­ing­ful progress, but not let­ting it get so com­pli­cated that it be­comes over­whelm­ing.

There is no such thing as pla­ton­i­cally good en­gi­neer­ing: it de­pends on your needs and the

prac­ti­cal prob­lems you en­counter.

Software Is about Developing Knowledge More than Writing Code

In soft­ware de­vel­op­ment, most ideas are bad; this is not any­one’s fault. It is just that the num­ber of pos­si­ble ideas is so large that any par­tic­u­lar idea is prob­a­bly not go­ing to work, even if it was cho­sen very care­fully and in­tel­li­gently. To make progress, you need to start with a bunch of bad ideas, dis­card the worst, and evolve the most promis­ing ones. Apple, a paragon of vi­sion­ary de­sign, goes through dozens of pro­to­types be­fore land­ing on a fi­nal prod­uct. The fi­nal prod­uct may be de­cep­tively sim­ple; it is the in­tri­cate knowl­edge of why this par­tic­u­lar so­lu­tion was cho­sen over its al­ter­na­tives that al­lows it to be good.

This knowl­edge con­tin­ues to be im­por­tant even af­ter the prod­uct is built. If a new team takes over the code for an un­fa­mil­iar piece of soft­ware, the soft­ware will soon start to de­grade. Operating sys­tems will up­date, busi­ness re­quire­ments will change, and se­cu­rity prob­lems will be dis­cov­ered that need to be fixed. Handling these sub­tle er­rors is of­ten harder than build­ing the soft­ware in the first place, since it re­quires in­ti­mate knowl­edge of the sys­tem’s ar­chi­tec­ture and de­sign prin­ci­ples.

In the short term, an un­fa­mil­iar de­vel­op­ment team can ad­dress these prob­lems with stop­gap fixes. Over time though, new bugs ac­cu­mu­late due to the makeshift na­ture of the ad­di­tional code. User in­ter­faces be­come con­fus­ing due to mis­matched de­sign par­a­digms, and sys­tem com­plex­ity in­creases as a whole. Software should be treated not as a sta­tic prod­uct, but as a liv­ing man­i­fes­ta­tion of the de­vel­op­ment team’s col­lec­tive un­der­stand­ing.

Software should be treated not as a sta­tic prod­uct, but as a

liv­ing man­i­fes­ta­tion of the de­vel­op­ment team’s col­lec­tive un­der­stand­ing.

This is why re­ly­ing on ex­ter­nal ven­dors for your core soft­ware de­vel­op­ment is dif­fi­cult. You may get a run­ning sys­tem and its code, but the in­valu­able knowl­edge of how it is built and what de­sign choices were made leaves your or­gan­i­sa­tion. This is also why hand­ing a sys­tem over to new ven­dors for “maintenance” of­ten causes prob­lems. Even if the sys­tem is very well doc­u­mented, some knowl­edge is lost every time a new team takes over. Over the years, the sys­tem be­comes a patch­work of code from many dif­fer­ent au­thors. It be­comes harder and harder to keep run­ning; even­tu­ally, there is no one left who truly un­der­stands how it works.

For your soft­ware to keep work­ing well in the long term, it is im­por­tant to have your staff learn­ing along­side the ex­ter­nal help to re­tain crit­i­cal en­gi­neer­ing knowl­edge in your or­gan­i­sa­tion.

1. Start as Simple as Possible

Projects that set out to be a “one-stop shop” for a par­tic­u­lar do­main are of­ten doomed. The rea­son­ing seems sen­si­ble enough: What bet­ter way to en­sure your app solves peo­ple’s prob­lems than by hav­ing it ad­dress as many as pos­si­ble? After all, this works for phys­i­cal stores such as su­per­mar­kets. The dif­fer­ence is that while it is rel­a­tively easy to add a new item for sale once a phys­i­cal store is set up, an app with twice as many fea­tures is more than twice as hard to build and much harder to use.

Building good soft­ware re­quires fo­cus: start­ing with the sim­plest so­lu­tion that could solve the prob­lem. A well-made but sim­plis­tic app never has prob­lems adding nec­es­sary fea­tures. But a big IT sys­tem that does a lot of things poorly is usu­ally im­pos­si­ble to sim­plify and fix. Even suc­cess­ful “do it all” apps like WeChat, Grab, and Facebook started out with very spe­cific func­tion­al­ity and only ex­panded af­ter they had se­cured their place. Software pro­jects rarely fail be­cause they are too small; they fail be­cause they get too big.

Software pro­jects rarely fail be­cause they

are too small; they fail be­cause they get too big.

Unfortunately, keep­ing a pro­ject fo­cused is very hard in prac­tice: just gath­er­ing the re­quire­ments from all stake­hold­ers al­ready cre­ates a huge list of fea­tures.

One way to man­age this bloat is by us­ing a pri­or­ity list. Requirements are all still gath­ered, but each are tagged ac­cord­ing to whether they are ab­solutely crit­i­cal fea­tures, high-value ad­di­tions, or nice-to-haves. This cre­ates a much lower-ten­sion plan­ning process be­cause fea­tures no longer need to be ex­plic­itly ex­cluded. Stakeholders can then more sanely dis­cuss which fea­tures are the most im­por­tant, with­out wor­ry­ing about some­thing be­ing left out of the pro­ject. This ap­proach also makes ex­plicit the trade-offs of hav­ing more fea­tures. Stakeholders who want to in­crease the pri­or­ity for a fea­ture have to also con­sider what fea­tures they are will­ing to de­pri­ori­tise. Teams can start on the most crit­i­cal ob­jec­tives, work­ing their way down the list as time and re­sources al­low.

We fol­lowed a sim­i­lar process for all our most suc­cess­ful apps. Form.gov.sg started out as a man­ual Outlook Macro that took us six hours to set up for our first user but to­day has processed about a mil­lion pub­lic sub­mis­sions. Data.gov.sg started out as a di­rect copy of an open source pro­ject and has since grown to over 300,000 monthly vis­its. Parking.sg had a mas­sive list of al­most 200 pos­si­ble fea­tures that we never got around to build­ing but still has over 1.1 mil­lion users to­day. These sys­tems are well re­ceived not in spite of their sim­plic­ity but be­cause of it.

In truth, mod­ern soft­ware is so com­pli­cated and changes so rapidly that no amount of plan­ning will elim­i­nate all short­com­ings. Like writ­ing a good pa­per, awk­ward early drafts are nec­es­sary to get a feel of what the fi­nal pa­per should be. To build good soft­ware, you need to first build bad soft­ware, then ac­tively seek out prob­lems to im­prove on your so­lu­tion.

This starts with some­thing as sim­ple as talk­ing to the ac­tual peo­ple you are try­ing to help. The goal is to un­der­stand the root prob­lem you want to solve and avoid jump­ing to a so­lu­tion based just on pre­con­ceived bi­ases. When we first started on Parking.sg, our hy­poth­e­sis was that en­force­ment of­fi­cers found it frus­trat­ing to have to keep do­ing the men­tal cal­cu­la­tions re­gard­ing pa­per coupons. However, af­ter spend­ing just one af­ter­noon with an ex­pe­ri­enced of­fi­cer, we dis­cov­ered that do­ing these cal­cu­la­tions was ac­tu­ally quite sim­ple for some­one do­ing it pro­fes­sion­ally. That sin­gle con­ver­sa­tion saved us months of po­ten­tially wasted ef­fort and let us re­fo­cus our pro­ject on help­ing dri­vers in­stead.

Beware of bu­reau­cratic goals mas­querad­ing as prob­lem state­ments. “Drivers feel frus­trated when deal­ing with park­ing coupons” is a prob­lem. “We need to build an app for dri­vers as part of our Ministry Family Digitisation Plans” is not. “Users are an­noyed at how hard it is to find in­for­ma­tion on gov­ern­ment web­sites” is a prob­lem. “As part of the Digital Government Blueprint, we need to re­build our web­sites to con­form to the new de­sign ser­vice stan­dards” is not. If our end goal is to make cit­i­zens’ lives bet­ter, we need to ex­plic­itly ac­knowl­edge the things that are mak­ing their lives worse.

Having a clear prob­lem state­ment lets you ex­per­i­men­tally test the vi­a­bil­ity of dif­fer­ent so­lu­tions that are too hard to de­ter­mine the­o­ret­i­cally. Talking to a chat­bot may not be any eas­ier than nav­i­gat­ing a web­site, and users may not want to in­stall yet an­other app on their phones no mat­ter how se­cure it makes the coun­try. With soft­ware, ap­par­ently ob­vi­ous so­lu­tions of­ten have fa­tal flaws that do not show up un­til they are put to use. The aim is not yet to build the fi­nal prod­uct, but to first iden­tify these prob­lems as quickly and as cheaply as pos­si­ble. Non-functional mock-ups to test in­ter­face de­signs. Semi-functional mock-ups to try dif­fer­ent fea­tures. Prototype code, writ­ten hastily, could help gar­ner feed­back more quickly. Anything cre­ated at this stage should be treated as dis­pos­able. The de­sired out­put of this process is not the code writ­ten, but a clearer un­der­stand­ing of what the right thing to build is.

Beware of bu­reau­cratic goals mas­querad­ing as prob­lem state­ments. If our end goal is to make cit­i­zens’ lives bet­ter, we need to ex­plic­itly ac­knowl­edge the things that are mak­ing their lives worse.

With a good un­der­stand­ing of the right so­lu­tion, you can start work on build­ing the ac­tual prod­uct. You stop ex­plor­ing new ideas and nar­row down to iden­ti­fy­ing prob­lems with your par­tic­u­lar im­ple­men­ta­tion. Begin with a small num­ber of testers who will quickly spot the ob­vi­ous bugs that need to be fixed. As prob­lems are ad­dressed, you can in­creas­ingly open up to a larger pool who will find more es­o­teric is­sues.

Most peo­ple only give feed­back once. If you start by launch­ing to a large au­di­ence, every­one will give you the same ob­vi­ous feed­back and you’ll have nowhere to go from there. Even the best prod­uct ideas built by the best en­gi­neers will start out with sig­nif­i­cant is­sues. The aim is to re­peat­edly re­fine the out­put, sand­ing down rough edges un­til a good prod­uct emerges.

Even af­ter all this it­er­a­tion, af­ter launch is when prob­lems with a prod­uct mat­ter the most. A prob­lem that hap­pens only 0.1% of the time may not get no­ticed dur­ing test­ing. But once you have a mil­lion users, every day the prob­lem goes un­re­solved is a thou­sand more an­gry peo­ple you have to deal with. You need to fix prob­lems caused by new mo­bile de­vices, net­work out­ages, or se­cu­rity at­tacks be­fore they cause sub­stan­tial harm to your users. With Parking.sg we built a se­ries of sec­ondary sys­tems that con­tin­u­ously check the main sys­tem for any dis­crep­an­cies in pay­ments, du­pli­cate park­ing ses­sions, and ap­pli­ca­tion crashes. Building up an “immune sys­tem” over time lets you avoid be­ing over­whelmed as new is­sues in­evitably come up.

Overall, the ap­proach is to use these dif­fer­ent feed­back loops to ef­fi­ciently iden­tify prob­lems. Small feed­back loops al­low for quick and easy cor­rec­tion but miss out on broader is­sues. Large feed­back loops catch broader is­sues but are slow and ex­pen­sive. You want to use both, re­solv­ing as much as pos­si­ble with tight loops while still hav­ing wide loops to catch un­ex­pected er­rors. Building soft­ware is not about avoid­ing fail­ure; it is about strate­gi­cally fail­ing as fast as pos­si­ble to get the in­for­ma­tion you need to build some­thing good.

3. Hire the Best Engineers You Can

The key to hav­ing good en­gi­neer­ing is hav­ing good en­gi­neers. Google, Facebook, Amazon, Netflix, and Microsoft all run a dizzy­ing num­ber of the largest tech­nol­ogy sys­tems in the world, yet, they fa­mously have some of the most se­lec­tive in­ter­view processes while still com­pet­ing fiercely to re­cruit the strongest can­di­dates. There is a rea­son that the salaries for even fresh grad­u­ates have gone up so much as these com­pa­nies have grown, and it is not be­cause they en­joy giv­ing away money.

Both Steve Jobs and Mark Zuckerberg have said that the best en­gi­neers are at least 10 times more pro­duc­tive than an av­er­age en­gi­neer. This is not be­cause good en­gi­neers write code 10 times faster. It is be­cause they make bet­ter de­ci­sions that save 10 times the work.

A good en­gi­neer has a bet­ter grasp of ex­ist­ing soft­ware they can reuse, thus min­imis­ing the parts of the sys­tem they have to build from scratch. They have a bet­ter grasp of en­gi­neer­ing tools, au­tomat­ing away most of the rou­tine as­pects of their own job. Automation also means free­ing up hu­mans to work on solv­ing un­ex­pected er­rors, which the best en­gi­neers are dis­pro­por­tion­ately bet­ter at. Good en­gi­neers them­selves de­sign sys­tems that are more ro­bust and eas­ier to un­der­stand by oth­ers. This has a mul­ti­plier ef­fect, let­ting their col­leagues build upon their work much more quickly and re­li­ably. Overall, good en­gi­neers are so much more ef­fec­tive not be­cause they pro­duce a lot more code, but be­cause the de­ci­sions they make save you from work you did not know could be avoided.

This also means that small teams of the best en­gi­neers can of­ten build things faster than even very large teams of av­er­age en­gi­neers. They make good use of avail­able open source code and so­phis­ti­cated cloud ser­vices, and of­fload mun­dane tasks onto au­to­mated test­ing and other tools, so they can fo­cus on the cre­ative prob­lem-solv­ing as­pects of the job. They rapidly test dif­fer­ent ideas with users by pri­ori­tis­ing key fea­tures and cut­ting out unim­por­tant work. This is the cen­tral the­sis of the clas­sic book “The Mythical Man-Month”1: in gen­eral, adding more soft­ware en­gi­neers does not make a pro­ject go faster, it only makes it grow big­ger.

Building soft­ware is not about avoid­ing fail­ure; it is about strate­gi­cally fail­ing as fast as pos­si­ble to get the in­for­ma­tion you need to build some­thing good.

Smaller teams of good en­gi­neers will also cre­ate fewer bugs and se­cu­rity prob­lems than larger teams of av­er­age en­gi­neers. Similar to writ­ing an es­say, the more au­thors there are, the more cod­ing styles, as­sump­tions, and quirks there are to rec­on­cile in the fi­nal com­pos­ite prod­uct, ex­pos­ing a greater sur­face area for po­ten­tial is­sues to arise. In con­trast, a sys­tem built by a smaller team of good en­gi­neers will be more con­cise, co­her­ent, and bet­ter un­der­stood by its cre­ators. You can­not have se­cu­rity with­out sim­plic­ity, and sim­plic­ity is rarely the re­sult of large-scale col­lab­o­ra­tions.

The more col­lab­o­ra­tive an en­gi­neer­ing ef­fort, the bet­ter the en­gi­neers need to be. Problems in an en­gi­neer’s code af­fect not just his work but that of his col­leagues as well. In large pro­jects, bad en­gi­neers end up cre­at­ing more work for one an­other, as er­rors and poor de­sign choices snow­ball to cre­ate mas­sive is­sues. Big pro­jects need to be built on solid re­li­able code mod­ules in an ef­fi­cient de­sign with very clear as­sump­tions laid out. The bet­ter your en­gi­neers, the big­ger your sys­tem can get be­fore it col­lapses un­der its own weight. This is why the most suc­cess­ful tech com­pa­nies in­sist on the best tal­ent de­spite their mas­sive size. The hard limit to sys­tem com­plex­ity is not the quan­tity of en­gi­neer­ing ef­fort, but its qual­ity.

Good soft­ware de­vel­op­ment starts with build­ing a clear un­der­stand­ing of the prob­lem you want to solve. This lets you test many pos­si­ble so­lu­tions and con­verge on a good ap­proach. Development is ac­cel­er­ated by reusing the right open source code and cloud ser­vices, grant­ing im­me­di­ate ac­cess to es­tab­lished soft­ware sys­tems and so­phis­ti­cated new tech­nol­ogy. The de­vel­op­ment cy­cle al­ter­nates be­tween ex­plo­ration and con­sol­i­da­tion, quickly and mess­ily pro­gress­ing on new ideas, then fo­cus­ing and sim­pli­fy­ing to keep the com­plex­ity man­age­able. As the pro­ject moves for­ward, it gets tested with suc­ces­sively larger groups of peo­ple to elim­i­nate in­creas­ingly un­com­mon prob­lems. Launching is when the real work ramps up for a good de­vel­op­ment team: lay­ers of au­to­mated sys­tems should be built to han­dle is­sues quickly and pre­vent harm to ac­tual users. Ultimately, while there are in­fi­nite in­tri­ca­cies to soft­ware de­vel­op­ment, un­der­stand­ing this process pro­vides a ba­sis to tackle the com­plex­i­ties of how to build good soft­ware.

Li Hongyi leads a team of en­gi­neers, de­sign­ers, and prod­uct man­agers who build tech­nol­ogy for the pub­lic good. Projects they have worked on in­clude Parking.sg—an app to re­place park­ing coupons, Form.gov.sg—a web app for build­ing on­line gov­ern­ment forms in min­utes, and Data.gov.sg—the gov­ern­men­t’s open data repos­i­tory. Prior to join­ing the pub­lic sec­tor, Hongyi worked at Google on the dis­trib­uted data­bases and im­age search teams. In his free time, he works on per­sonal pro­jects like ty­pograph­ing.com and chat­let.com.

More in this is­sue

Services 4.0: A New Wave of Innovation and Partnerships

FormSG: From Idea to Hit Platform in a Year

The Agile Way of Working

The in­for­ma­tion in this pre­lim­i­nary prospec­tus is not com­plete and may be changed. These

se­cu­ri­ties may not be sold un­til the reg­is­tra­tion state­ment filed with the Securities and Exchange Commission is ef­fec­tive. This pre­lim­i­nary prospec­tus is not an of­fer to sell nor does it seek an of­fer to buy these se­cu­ri­ties in any ju­ris­dic­tion

where the of­fer or sale is not per­mit­ted. This is an ini­tial pub­lic of­fer­ing of shares of Class A com­mon stock of Cloudflare, Inc. Prior to this of­fer­ing, there has been no pub­lic mar­ket for our Class A com­mon stock. It is cur­rently es­ti­mated that the ini­tial pub­lic of­fer­ing price per share will be be­tween $                and $                . We have ap­plied to list the Class A com­mon stock on the New York Stock Exchange un­der the sym­bol “NET.” We have two classes of au­tho­rized com­mon stock, Class A com­mon stock and Class B com­mon stock. The rights of the hold­ers of Class A com­mon stock and Class B com­mon stock are sub­stan­tially iden­ti­cal, ex­cept with re­spect to vot­ing and con­ver­sion. Each share of Class A com­mon stock is en­ti­tled to one vote per share. Following the com­ple­tion of this of­fer­ing, each share of Class B com­mon stock will be en­ti­tled to 10 votes per share and will be con­vert­ible at any time into one share of Class A com­mon stock. Following this of­fer­ing, out­stand­ing shares of Class B com­mon stock will rep­re­sent ap­prox­i­mately    % of the vot­ing power of our out­stand­ing cap­i­tal stock. We are an “emerging growth com­pany” as that term is used in the Jumpstart Our Business Startups Act of 2012 and, as such, may elect to com­ply with cer­tain re­duced pub­lic com­pany re­port­ing re­quire­ments in fu­ture re­ports af­ter the com­ple­tion of this of­fer­ing. See “Risk Factors” be­gin­ning on page 16 to read about fac­tors you should con­sider be­fore buy­ing shares of our Class A

com­mon stock. Neither the Securities and Exchange Commission nor any other reg­u­la­tory body has ap­proved or dis­ap­proved of these se­cu­ri­ties or passed upon the ac­cu­racy or ad­e­quacy of

this prospec­tus. Any rep­re­sen­ta­tion to the con­trary is a crim­i­nal of­fense.

See the sec­tion ti­tled “Underwriting” for a de­scrip­tion of the com­pen­sa­tion payable to the un­der­writ­ers.

To the ex­tent that the un­der­writ­ers sell more than                shares of Class A com­mon stock, the un­der­writ­ers have the op­tion to pur­chase up to an ad­di­tional                shares from Cloudflare, Inc. at the ini­tial pub­lic of­fer­ing price less the un­der­writ­ing dis­count. The un­der­writ­ers ex­pect to de­liver the shares against pay­ment in New York, New York, on or about                 , 2019.

20M Internet Properties as of August 15, 2019 10% of Fortune 1,000 are Paying Customers as of August 15, 2019 98% Internet Users in the

Developed World within 100ms as of August 15, 2019 44B Cyber Threats Blocked per Day ap­prox­i­mate av­er­age over three months ended June 30, 2019 77% GAPP Gross Margin six months ended June 30, 2019 51% Revenue Growth F16-F18 CAGR see

“Prospectus Summary Consolidated Financial and Other Data”

SUMMARY CONSOLIDATED FINANCIAL AND OTHER DATA

SELECTED CONSOLIDATED FINANCIAL AND OTHER DATA

MANAGEMENT’S DISCUSSION AND ANALYSIS OF FINANCIAL CONDITION AND RESULTS OF OPERATIONS

MATERIAL U. S. FEDERAL INCOME TAX CONSEQUENCES TO HOLDERS OF OUR CLASS A COMMON STOCK

WHERE YOU CAN FIND ADDITIONAL INFORMATION

Through and in­clud­ing                 , 2019 (the 25th day af­ter the date of this

prospec­tus), all deal­ers ef­fect­ing trans­ac­tions in these se­cu­ri­ties, whether or not par­tic­i­pat­ing in this of­fer­ing, may be re­quired to de­liver a prospec­tus. This is in ad­di­tion to the deal­ers’ oblig­a­tion to de­liver a prospec­tus when act­ing as

un­der­writ­ers and with re­spect to their un­sold al­lot­ment or sub­scrip­tions. Neither we nor any of the un­der­writ­ers have au­tho­rized any­one to pro­vide any in­for­ma­tion or to make any rep­re­sen­ta­tions other than those con­tained in this prospec­tus or in any free writ­ing prospec­tuses we have pre­pared. Neither we nor any of the un­der­writ­ers take re­spon­si­bil­ity for, and can pro­vide no as­sur­ance as to the re­li­a­bil­ity of, any other in­for­ma­tion that oth­ers may give you. This prospec­tus is an of­fer to sell only the shares of­fered hereby, but only un­der cir­cum­stances and in ju­ris­dic­tions where it is law­ful to do so. The in­for­ma­tion con­tained in this prospec­tus is cur­rent only as of its date, re­gard­less of the time of de­liv­ery of this prospec­tus or of any sale of our Class A com­mon stock. For in­vestors out­side the United States: Neither we nor any of the un­der­writ­ers have done any­thing that would per­mit our ini­tial pub­lic of­fer­ing or pos­ses­sion or dis­tri­b­u­tion of this prospec­tus in any ju­ris­dic­tion where ac­tion for that pur­pose is re­quired, other than in the United States. Persons out­side the United States who come into pos­ses­sion of this prospec­tus must in­form them­selves about, and ob­serve any re­stric­tions re­lat­ing to, the of­fer­ing of the shares of our Class A com­mon stock and the dis­tri­b­u­tion of this prospec­tus out­side the United States.

This sum­mary high­lights se­lected in­for­ma­tion that is pre­sented in greater de­tail else­where in this prospec­tus. This sum­mary does not con­tain all of the in­for­ma­tion

you should con­sider be­fore in­vest­ing in our Class A com­mon stock. You should read this en­tire prospec­tus care­fully, in­clud­ing the sec­tions ti­tled “Risk Factors” and “Management’s Discussion and Analysis of Financial

Condition and Results of Operations,” and our con­sol­i­dated fi­nan­cial state­ments and the re­lated notes thereto in­cluded else­where in this prospec­tus, be­fore mak­ing an in­vest­ment de­ci­sion. Unless the con­text oth­er­wise re­quires, the terms

“Cloudflare,” “the Company,” “we,” “us,” and “our” in this prospec­tus re­fer to Cloudflare, Inc. and its con­sol­i­dated sub­sidiaries, and ref­er­ences to our “common stock” in­clude our

Class A com­mon stock and Class B com­mon stock.

Cloudflare’s mis­sion is to help build a bet­ter Internet. Today, the Internet is the lifeblood of busi­ness and the pri­mary ve­hi­cle of com­merce and com­mu­ni­ca­tion for peo­ple around the world. While it was bril­liantly ar­chi­tected to de­liver fault tol­er­ance and ro­bust con­nec­tiv­ity, it was not de­signed to de­liver the se­cu­rity, mil­lisec­ond per­for­mance, and re­li­a­bil­ity re­quired for busi­nesses to­day.

For decades, a num­ber of ven­dors have looked to ad­dress the core lim­i­ta­tions and vul­ner­a­bil­i­ties of the Internet for busi­nesses that op­er­ate on­line. These ven­dors built a range of stand­alone hard­ware boxes to ad­dress the emerg­ing re­quire­ments for se­cu­rity, per­for­mance, and re­li­a­bil­ity. These boxes could be de­ployed in data cen­ters to de­liver func­tions such as vir­tual pri­vate net­work (VPN), fire­wall, rout­ing, traf­fic op­ti­miza­tion, load bal­anc­ing, and other net­work ser­vices. While they cre­ated mas­sive com­plex­ity, cost, tech­ni­cal debt, and a tan­gled web of de­pen­den­cies for the or­ga­ni­za­tions that de­ployed them, the ap­proach gen­er­ally worked and these boxes” were able to al­le­vi­ate some of the Internet’s fun­da­men­tal se­cu­rity, per­for­mance, and re­li­a­bil­ity prob­lems. And then the cloud hap­pened. In re­cent years, the tech­nol­ogy in­dus­try has un­der­gone a mas­sive tran­si­tion from hard­ware and soft­ware that cus­tomers buy, to ser­vices in the cloud that they rent. This tran­si­tion has swept through the ap­pli­ca­tion, com­pute, and stor­age lay­ers of en­ter­prise com­put­ing ar­chi­tec­tures. Organizations now ex­ist in a com­plex, het­ero­ge­neous in­fra­struc­ture en­vi­ron­ment which ex­ac­er­bates the fun­da­men­tal prob­lems of the Internet more than ever, and the boxes that they once re­lied upon to solve these prob­lems were never de­signed to work in such an en­vi­ron­ment. An box will not solve the prob­lems or­ga­ni­za­tions now face. Nor can a busi­ness ship a box to a cloud ven­dor. Even if they wanted to, there is lit­er­ally no place to in­stall such a box in the cloud. The re­sult is that a ma­jor ar­chi­tec­tural shift at the net­work layer is now un­der­way. Cloudflare is lead­ing this tran­si­tion. We have built a global cloud plat­form that de­liv­ers a broad range of net­work ser­vices to busi­nesses of all sizes and in all ge­o­gra­phies—mak­ing them more se­cure, en­hanc­ing the per­for­mance of their

busi­ness-crit­i­cal ap­pli­ca­tions, and elim­i­nat­ing the cost and com­plex­ity of man­ag­ing in­di­vid­ual net­work hard­ware. Our plat­form serves as a scal­able, uni­fied con­trol plane to de­liver se­cu­rity, per­for­mance, and re­li­a­bil­ity across hy­brid, cloud, and (SaaS) ap­pli­ca­tions. Today, ap­prox­i­mately 10% of the Fortune 1,000 are pay­ing Cloudflare cus­tomers. Additionally, across the broader Internet, ap­prox­i­mately 10% of the top mil­lion, 17% of the top 100,000, and 18% of the top 10,000 web­sites use at least one prod­uct on our plat­form on a paid or free ba­sis.(1) We started by build­ing an ef­fi­cient, scal­able net­work. This net­work forms the foun­da­tion of our plat­form on which we can rapidly de­velop and de­ploy our prod­ucts for our cus­tomers. Together, the de­vel­op­ment of our net­work and prod­ucts cre­ate the in­ter­con­nected fly­wheels that drive our busi­ness and have al­lowed us to achieve our mar­ket po­si­tion.

Network Flywheel: We have cre­ated a net­work ar­chi­tec­ture that is flex­i­ble, scal­able, and be­comes more ef­fi­cient as it ex­pands.

Product Flywheel: We have lever­aged this net­work to de­ploy prod­ucts that are easy to use, con­tin­u­ously im­proved, and can be de­liv­ered with­out adding sig­nif­i­cant in­cre­men­tal cost. We have ex­pe­ri­enced sig­nif­i­cant growth, with our rev­enue in­creas­ing from $84.8 million in 2016 to $134.9 million in 2017 and to $192.7 million in 2018, in­creases of 59% and 43%, re­spec­tively. As we con­tinue to in­vest in our busi­ness, we have in­curred net losses of $17.3 million, $10.7 million, and $87.2 million for 2016, 2017, and 2018, re­spec­tively. For the six months ended June 30, 2018 and 2019, our rev­enue in­creased from $87.1 mil­lion to $129.2 mil­lion, an in­crease of 48%, and we in­curred net losses of $32.5 mil­lion and $36.8 mil­lion, re­spec­tively. The Internet was not built for what it has be­come. Originally con­ceived as a de­cen­tral­ized, wired net­work to in­ter­con­nect aca­d­e­mic in­sti­tu­tions, the Internet has evolved into a global plat­form for busi­ness and com­mu­ni­ca­tions, host­ing a wide va­ri­ety of of­ten mis­sion-crit­i­cal ap­pli­ca­tions. While the Internet was bril­liantly ar­chi­tected to de­liver fault tol­er­ance and ro­bust con­nec­tiv­ity, it was not de­signed to de­liver the se­cu­rity, mil­lisec­ond per­for­mance, and re­li­a­bil­ity re­quired now that it has be­come the lifeblood for busi­ness and the pri­mary ve­hi­cle of com­merce and com­mu­ni­ca­tion for hu­man­ity.

Despite the Internet’s lim­i­ta­tions, busi­nesses re­ly­ing on it must meet cus­tomer ex­pec­ta­tions for ac­cess to their ser­vices, low la­tency, to­tal re­li­a­bil­ity, and high lev­els of se­cu­rity and pri­vacy. Furthermore, busi­nesses are ac­count­able for the de­liv­ery of these re­quire­ments

to every cus­tomer and em­ploy­ee’s desk­top or mo­bile de­vice, forc­ing them to ad­dress se­cu­rity, per­for­mance, and re­li­a­bil­ity glob­ally and well be­yond what they once thought of as the perime­ter of their own in­fra­struc­ture.

To meet evolv­ing ex­pec­ta­tions and nav­i­gate the lim­i­ta­tions of the Internet, busi­nesses have tra­di­tion­ally re­lied on a broad ar­ray of hard­ware de­vices de­ployed in data cen­ters to de­liver

These per­cent­ages are de­rived from Datanyze, Market Share, from January 2019, based on the av­er­age per­cent­age mar­ket share for web­site op­ti­miza­tion, do­main name sys­tem, se­cu­rity, and con­tent de­liv­ery net­work so­lu­tions for web­sites in the Alexa top mil­lion, top 100,000, and top 10,000. Refer to the sec­tion ti­tled “Industry and Market Data.”

func­tions such as VPN, fire­wall, rout­ing, traf­fic op­ti­miza­tion, load bal­anc­ing, and other net­work ser­vices. These boxes were meant to patch the Internet and ad­dress its core lim­i­ta­tions. While the boxes added some se­cu­rity, per­for­mance, and re­li­a­bil­ity ben­e­fits, they con­tributed to mas­sive com­plex­ity, cost, tech­ni­cal debt, and a tan­gled web of de­pen­den­cies. In spite of the draw­backs, the boxes were suf­fi­cient to en­sure the safety, func­tion­al­ity, and re­silience re­quired by busi­nesses that could af­ford them in the par­a­digm. But these boxes were never de­signed to work in the cloud.

In re­cent years, the tech­nol­ogy in­dus­try has been un­der­go­ing a tran­si­tion from hard­ware and soft­ware that cus­tomers buy, to ser­vices in the cloud that they rent. Application ven­dors led this tran­si­tion as com­pa­nies like Salesforce, Workday, and NetSuite pro­vided cloud-based, multi-ten­ant so­lu­tions that dis­rupted legacy,

soft­ware from com­pa­nies like SAP, Oracle, and Microsoft. Compute and stor­age fol­lowed, with pub­lic cloud ven­dors such as Amazon Web Services, Microsoft Azure, Google Cloud Platform, and Alibaba Cloud dis­rupt­ing server and stor­age ven­dors like HP, Dell, Lenovo, and Sun Microsystems. The Network Layer Transitions to the Cloud

The rise of cloud com­put­ing ar­chi­tec­tures along­side the mas­sive in­crease in mo­bile de­vices vastly com­pli­cates the al­ready dif­fi­cult task of se­cur­ing and op­ti­miz­ing ap­pli­ca­tions. Organizations ex­ist in a com­plex, het­ero­ge­neous in­fra­struc­ture en­vi­ron­ment of pub­lic cloud, and hy­brid de­ploy­ments. The threat land­scape, func­tional re­quire­ments, and scale of busi­ness ap­pli­ca­tions are evolv­ing faster than ever be­fore, and the vol­ume and so­phis­ti­ca­tion of net­work at­tacks can strain the de­fen­sive ca­pa­bil­i­ties of even the most ad­vanced en­ter­prises.

The hard­ware-based, in­flex­i­ble, boxes that or­ga­ni­za­tions once re­lied upon to meet these chal­lenges were never de­signed to work in an en­vi­ron­ment like this. And even if the boxes could scale to meet the chal­lenges of the mod­ern en­ter­prise, a busi­ness can­not sim­ply ship a box to a cloud ven­dor. There is lit­er­ally no place to in­stall such a box in the cloud. This is forc­ing a ma­jor ar­chi­tec­tural shift in how en­ter­prises ad­dress se­cu­rity, per­for­mance, and re­li­a­bil­ity at the net­work layer. The func­tion­al­ity pro­vided by com­pa­nies such as Cisco Systems, Juniper Networks, F5 Networks, Check Point Software, Palo Alto Networks, FireEye, Riverbed Technology, and oth­ers is be­ing el­e­vated, ab­stracted, and uni­fied into the cloud.

We have built a global cloud plat­form that de­liv­ers a broad range of net­work ser­vices to busi­nesses of all sizes around the world—mak­ing them more se­cure, en­hanc­ing the per­for­mance of their busi­ness-crit­i­cal ap­pli­ca­tions, and elim­i­nat­ing the cost and com­plex­ity of man­ag­ing and in­te­grat­ing in­di­vid­ual net­work hard­ware. We pro­vide busi­nesses a scal­able, uni­fied con­trol plane to de­liver se­cu­rity, per­for­mance, and re­li­a­bil­ity across their hy­brid, cloud, and SaaS ap­pli­ca­tions. Previously, en­ter­prises would of­ten string to­gether a di­verse set of boxes from dif­fer­ent ven­dors to solve their net­work chal­lenges. As these so­lu­tions move to the cloud, the net­work

la­tency, sup­port com­plex­ity, and cost of over­head makes string­ing to­gether mul­ti­ple point-cloud so­lu­tions that only ad­dress a spe­cific net­work need un­ten­able. Customers are there­fore look­ing to con­sol­i­date be­hind a sin­gle plat­form. We of­fer this uni­fied con­trol plane. Customers who join our plat­form us­ing one prod­uct can adopt our other seam­lessly in­te­grated prod­ucts with a sin­gle click. We serve com­pre­hen­sive cus­tomer needs across se­cu­rity, per­for­mance, and re­li­a­bil­ity. Our plat­form and busi­ness model are de­signed to make rolling out our new prod­ucts fast and ef­fi­cient. We be­lieve that plat­forms with the broad­est cat­a­logue of prod­ucts will ul­ti­mately beat point-cloud so­lu­tions. To achieve what we have, we started by build­ing an ef­fi­cient, scal­able net­work. This net­work forms the foun­da­tion of our plat­form on which we can de­velop and de­ploy our prod­ucts for our cus­tomers. Together the de­vel­op­ment of our net­work and prod­ucts cre­ate the in­ter­con­nected fly­wheels that drive our busi­ness and have al­lowed us to achieve our mar­ket po­si­tion.

We have cre­ated a net­work ar­chi­tec­ture that is flex­i­ble, scal­able, and gets more and more ef­fi­cient as it ex­pands. We de­signed and built our net­work to be able to grow ca­pac­ity quickly and in­ex­pen­sively; to al­low for every server, in every city, to run every Cloudflare ser­vice; and to al­low us to shift cus­tomers and traf­fic across our net­work ef­fi­ciently. We re­fer to this ar­chi­tec­ture as “serverless” be­cause it means we can de­ploy stan­dard, com­mod­ity hard­ware, and our prod­uct de­vel­op­ers and cus­tomers do not need to worry about the un­der­ly­ing servers. Our soft­ware au­to­mat­i­cally man­ages the de­ploy­ment and ex­e­cu­tion of our prod­uct de­vel­op­ers’ code and our cus­tomers’ code across our net­work. Because we man­age the ex­e­cu­tion and pri­or­i­ti­za­tion of code run­ning across our net­work, it means that we are both able to op­ti­mize the per­for­mance of our high­est pay­ing cus­tomers and also ef­fec­tively lever­age idle ca­pac­ity across our net­work. We have cho­sen to uti­lize this idle ca­pac­ity to cre­ate a free tier of ser­vice—which has gen­er­ated sub­stan­tial global scale for us. In turn, this scale makes us at­trac­tive part­ners for Internet Service Providers (ISPs) glob­ally, which re­duces our and band­width costs. As our net­work grows, these dy­nam­ics be­come even more pow­er­ful. Today, our net­work spans 193 cities in over 90 coun­tries and in­ter­con­nects with over 8,000 net­works glob­ally, in­clud­ing ma­jor ISPs, cloud ser­vices, and en­ter­prises. We es­ti­mate that we op­er­ate within 100 mil­lisec­onds of 98% of the Internet-connected pop­u­la­tion in the de­vel­oped world, and 93% of the Internet-connected pop­u­la­tion glob­ally (for con­text, the blink of an eye is 300-400 mil­lisec­onds).(2) And, we have built this pow­er­ful net­work while achiev­ing U. S. GAAP gross mar­gin of 77% in the year ended December 31, 2018 and the six months ended June 30, 2019, demon­strat­ing the cost and cap­i­tal ef­fi­ciency of our model.

We be­gan with the idea of serv­ing the broad­est pos­si­ble mar­ket. To do this, we made our prod­ucts easy to use and af­ford­able and were able to pro­vide our en­try level plan for free in part be­cause of the cost ad­van­tage of our net­work. We lever­age the re­sult­ing cus­tomer scale and di­ver­sity to con­tin­u­ously make our prod­ucts bet­ter. Our ma­chine learn­ing sys­tems im­prove our prod­ucts with every cus­tomer’s re­quest, op­ti­miz­ing our se­cu­rity, per­for­mance, and re­li­a­bil­ity glob­ally. The over 20 million Internet prop­er­ties (e.g., do­mains, web­sites, ap­pli­ca­tion pro­gram­ming in­ter­faces, and mo­bile ap­pli­ca­tions) that use our plat­form com­prise a global sen­sor net­work, which func­tions like an im­mune sys­tem for the Internet—routing around con­ges­tion, op­ti­miz­ing for traf­fic con­di­tions, and us­ing data on cy­ber at­tacks

These per­cent­ages are de­rived from our ob­served round-trip time for all unique IP ad­dresses send­ing or re­ceiv­ing traf­fic through our net­work in the Organisation for Economic Co-operation and Development coun­tries and in all coun­tries, re­spec­tively.

against any one of our cus­tomers to bet­ter pro­tect them all. We lever­age these in­sights to block cy­ber threats every day, which in the three months ended June 30, 2019 av­er­aged ap­prox­i­mately 44 billion per day. Feedback from our di­verse, global cus­tomer base helps us ex­pand into new, ad­ja­cent prod­uct ar­eas. Since our cus­tomers’ traf­fic is al­ready pass­ing through our net­work, our server­less ar­chi­tec­ture means we can add prod­ucts on our plat­form to solve new net­work chal­lenges with­out sig­nif­i­cantly in­creas­ing our in­cre­men­tal costs. This al­lows us to pro­vide new prod­ucts at com­pet­i­tive prices and fur­ther ex­pand the over­all mar­ket.

We be­lieve our plat­form dis­rupts sev­eral large and well-es­tab­lished IT mar­kets. The key mar­kets that are ad­dressed by our plat­form in­clude VPN, in­ter­nal and ex­ter­nal fire­walls, web se­cu­rity (including web ap­pli­ca­tion fire­walls and con­tent fil­ter­ing), dis­trib­uted de­nial of ser­vice (DDoS) pre­ven­tion, in­tru­sion de­tec­tion and pre­ven­tion, ap­pli­ca­tion de­liv­ery con­trols, con­tent de­liv­ery net­works, do­main name sys­tems, ad­vanced threat pre­ven­tion (ATP), and wide area net­work (WAN) tech­nol­ogy. From our analy­sis based on IDC data, $31.6 billion was spent on those prod­ucts in 2018, which is ex­pected to grow to $47.1 billion in 2022, rep­re­sent­ing a com­pound an­nual growth rate of 10.5%. We also are ac­tively de­vel­op­ing new prod­ucts to ad­dress ad­ja­cent mar­kets in­clud­ing com­pute, stor­age, 5G, and Internet of Things (IoT) that are not in­cluded in the es­ti­mate of our ad­dress­able mar­ket.

We have six dis­tinct ad­van­tages that uniquely po­si­tion us to win:

Disruptive Business Model. Our busi­ness model is de­signed for ef­fi­ciency. Our net­work and prod­uct fly­wheels cre­ate a vir­tu­ous cy­cle that has dri­ven down our unit costs over time while we in­crease the di­ver­sity and qual­ity of our prod­ucts. We be­lieve that our server­less plat­for­m’s flex­i­bil­ity, as well as our aligned in­ter­ests with our ISP part­ners, al­lows us to con­tinue to be­come more ef­fi­cient as we ex­pand our net­work. At the same time, this ar­chi­tec­ture al­lows us to add new prod­ucts and fea­tures across our plat­form with­out sig­nif­i­cant ad­di­tional op­er­at­ing costs.

Ease of Use. A new cus­tomer can sign up in min­utes, re­gard­less of its tech­ni­cal abil­ity or bud­get. The ease of use of our prod­ucts sig­nif­i­cantly in­creases our to­tal ad­dress­able mar­ket and has also al­lowed our en­ter­prise cus­tomers, which con­sist of cus­tomers that sign up for our Enterprise plan, to sim­plify and stream­line their net­work op­er­a­tions.

Efficient Go-to-Market Model. Our strat­egy is de­signed to ef­fi­ciently ad­dress the broad mar­ket we serve. Our self-serve of­fer­ing, cou­pled with our at­trac­tive pric­ing, al­lows cus­tomers to eas­ily adopt our prod­ucts. We aug­ment our self-serve of­fer­ing with a highly pro­duc­tive sales force to serve larger cus­tomers.

Product Innovation and Velocity. We drive prod­uct in­no­va­tion by con­tin­u­ously im­prov­ing our plat­form through ma­chine learn­ing and di­verse cus­tomer feed­back. Our sys­tems learn from every re­quest that passes through our net­work. This al­lows us to au­to­mat­i­cally mit­i­gate new at­tacks, op­ti­mize pro­to­cols for the best per­for­mance, and reroute traf­fic to avoid net­work out­ages. Many of our free cus­tomers vol­un­teer to test new fea­tures early in the de­vel­op­ment cy­cle, which al­lows us to en­sure prod­uct ex­cel­lence be­fore de­ploy­ing to our pay­ing cus­tomers.

Integrated, Global Offering. Our net­work spans 193 cities in over 90 coun­tries, and this flex­i­ble, server­less plat­form of­fers the same set of core fea­tures in every city and coun­try. This gives our cus­tomers a uni­fied con­trol plane—whether they are run­ning with SaaS ven­dors, in hy­brid en­vi­ron­ments, or solely in the pub­lic cloud. Additionally, be­cause we of­fer an in­te­grated so­lu­tion, we do not force our cus­tomers to choose be­tween safer, faster, or stronger—our so­lu­tion of­fers se­cu­rity, per­for­mance, and re­li­a­bil­ity by de­sign.

Trust and Neutrality. As busi­nesses move to the cloud, there are in­creas­ing con­cerns over in­ter­op­er­abil­ity and avoid­ing be­ing locked into any one pub­lic cloud ven­dor. We em­power cus­tomers to over­come these con­cerns through our in­de­pen­dence and neu­tral­ity. Moreover, un­like some pub­lic cloud providers, our busi­ness model aligns with the in­ter­ests of our cus­tomers. We do not sell user data. Nor do we aim to com­pete with our cus­tomers.

Acquire New Customers: We be­lieve that any per­son or busi­ness that re­lies on the Internet to de­liver prod­ucts, ser­vices, or con­tent can be a Cloudflare cus­tomer. We will con­tinue to grow our cus­tomer base across all of our ser­vice of­fer­ings—free, self-serve, and en­ter­prise.

Expand Our Relationships with Existing Customers: Today, ap­prox­i­mately 10% of the Fortune 1,000 are pay­ing Cloudflare cus­tomers. Additionally, across the broader Internet, ap­prox­i­mately 10% of the top one mil­lion, 17% of the top 100,000, and 18% of the top 10,000 web­sites use at least one prod­uct on our plat­form on a paid or free ba­sis. Customers ex­pand their re­la­tion­ships with us by up­grad­ing to pre­mium plans, in­creas­ing their us­age of our plat­form, or adding prod­ucts. Once a cus­tomer has adopted one prod­uct on our plat­form, it can eas­ily add ad­di­tional prod­ucts with a sin­gle click. Over 70% of our en­ter­prise cus­tomers al­ready lever­age four or more of our prod­ucts.

Develop New Products: We con­tinue to in­vest in new prod­uct de­vel­op­ment, and as we on­board more cus­tomers and more traf­fic on our net­work, our abil­ity to iden­tify promis­ing new av­enues for in­no­va­tion im­proves.

Extend Our Serverless Platform Strategy: We have opened our server­less plat­form to out­side de­vel­op­ers with a prod­uct called Cloudflare Workers. This en­ables our cus­tomers to write and de­ploy their own code in sec­onds di­rectly onto our global cloud plat­form and have it run close to their users. We have seen a grow­ing num­ber of cus­tomers bring ap­pli­ca­tions to mar­ket us­ing Cloudflare Workers. This opens up an en­tirely new mar­ket for us: com­pute and stor­age.

Our busi­ness is sub­ject to nu­mer­ous risks and un­cer­tain­ties, in­clud­ing those high­lighted in the sec­tion ti­tled “Risk Factors” im­me­di­ately fol­low­ing this prospec­tus sum­mary. These risks in­clude, but are not lim­ited to, the fol­low­ing:

We have a his­tory of net losses and may not be able to achieve or sus­tain prof­itabil­ity in the fu­ture.

We have ex­pe­ri­enced rapid rev­enue growth, which may not be in­dica­tive of our fu­ture per­for­mance.

If we are un­able to at­tract new pay­ing and free cus­tomers, our fu­ture re­sults of op­er­a­tions could be harmed.

Our busi­ness de­pends on our abil­ity to re­tain and up­grade pay­ing cus­tomers and, to a lesser ex­tent, con­vert free cus­tomers to pay­ing cus­tomers, and any de­cline in re­newals, up­grades, or con­ver­sions could ad­versely af­fect our fu­ture re­sults of op­er­a­tions.

Problems with our in­ter­nal sys­tems, net­works, or data, in­clud­ing ac­tual or per­ceived breaches or fail­ures, could cause our net­work or prod­ucts to be per­ceived as in­se­cure, un­der­per­form­ing, or un­re­li­able, our rep­u­ta­tion to be dam­aged, and our fi­nan­cial re­sults to be neg­a­tively im­pacted.

Activities of our pay­ing and free cus­tomers or the con­tent of their web­sites and other Internet prop­er­ties could sub­ject us to li­a­bil­ity.

Activities of our pay­ing and free cus­tomers or the con­tent of their web­sites or other Internet prop­er­ties, as well as our re­sponses to those ac­tiv­i­ties, could cause us to ex­pe­ri­ence ad­verse po­lit­i­cal, busi­ness, and rep­u­ta­tional con­se­quences with cus­tomers, em­ploy­ees, sup­pli­ers, gov­ern­ment en­ti­ties, and oth­ers.

Although of­fer­ing a free self-serve plan for cer­tain of our prod­ucts is an im­por­tant part of our busi­ness strat­egy, we may not be able to re­al­ize all of the ex­pected ben­e­fits of this strat­egy and the costs and other detri­ments as­so­ci­ated with our free plan could out­weigh the ben­e­fits we re­ceive from our free cus­tomers.

The ac­tual or per­ceived fail­ure of our prod­ucts to block mal­ware or pre­vent a se­cu­rity breach could harm our rep­u­ta­tion and ad­versely im­pact our busi­ness, re­sults of op­er­a­tions, and fi­nan­cial con­di­tion.

If our global net­work that de­liv­ers our prod­ucts or the core fa­cil­i­ties we use to op­er­ate our net­work are dam­aged or oth­er­wise fail to meet the re­quire­ments of our busi­ness, our abil­ity to pro­vide ac­cess to our plat­form and prod­ucts to our cus­tomers and main­tain the per­for­mance of our net­work could be neg­a­tively im­pacted, which could cause our busi­ness, re­sults of op­er­a­tions, and fi­nan­cial con­di­tion to suf­fer.

If our cus­tomers’ or chan­nel part­ners’ ac­cess to our plat­form and prod­ucts is in­ter­rupted or de­layed for any rea­son, our busi­ness could suf­fer.

Detrimental changes in, or the ter­mi­na­tion of, any of our

re­la­tion­ships, ISP part­ner­ships, or our other in­ter­con­nec­tion re­la­tion­ships with ISPs could ad­versely im­pact our busi­ness, re­sults of op­er­a­tions, and fi­nan­cial con­di­tion.

The dual-class struc­ture of our com­mon stock will have the ef­fect of con­cen­trat­ing vot­ing con­trol with those stock­hold­ers who held our cap­i­tal stock prior to the com­ple­tion of this of­fer­ing, and it may de­press the trad­ing price of our Class A com­mon stock.

Investors, the me­dia, and oth­ers should note that, fol­low­ing the com­ple­tion of this of­fer­ing, we in­tend to an­nounce ma­te­r­ial in­for­ma­tion to the pub­lic through fil­ings with the Securities and Exchange Commission (the SEC), the in­vestor re­la­tions page on our web­site, press re­leases, pub­lic con­fer­ence calls, we­b­casts, our com­pany news site at https://​www.cloud­flare.com/​press, and our cor­po­rate blog at https://​blog.cloud­flare.com.

The in­for­ma­tion dis­closed by the fore­go­ing chan­nels could be deemed to be ma­te­r­ial in­for­ma­tion. As such, we en­cour­age in­vestors, the me­dia, and oth­ers to fol­low the chan­nels listed above and to re­view the in­for­ma­tion dis­closed through such chan­nels. Any up­dates to the list of dis­clo­sure chan­nels through which we will an­nounce in­for­ma­tion will be posted on the in­vestor re­la­tions page on our web­site. We were in­cor­po­rated in the state of Delaware in July 2009. Our prin­ci­pal ex­ec­u­tive of­fices are lo­cated at 101 Townsend Street, San Francisco, California 94107, and our tele­phone num­ber is (888) Our web­site ad­dress is www.cloud­flare.com and our cor­po­rate blog’s ad­dress is https://​blog.cloud­flare.com. Information con­tained on, or that can be ac­cessed through, our web­site or blog does not con­sti­tute part of this prospec­tus and in­clu­sions of our web­site and blog ad­dresses in this prospec­tus are in­ac­tive tex­tual ref­er­ences only.

“Cloudflare,” our logo, and our other reg­is­tered or com­mon law trade­marks, ser­vice marks, and trade names ap­pear­ing in this prospec­tus are the prop­erty of Cloudflare, Inc. Other trade­marks and trade names re­ferred to in this prospec­tus are the prop­erty of their re­spec­tive own­ers. We are an “emerging growth com­pany” as de­fined in the Jumpstart Our Business Startups Act of 2012 (the JOBS Act). An emerg­ing growth com­pany may take ad­van­tage of spec­i­fied re­duced re­port­ing re­quire­ments that are oth­er­wise ap­plic­a­ble gen­er­ally to pub­lic com­pa­nies. These re­duced re­port­ing re­quire­ments in­clude:

an ex­emp­tion from com­pli­ance with the au­di­tor at­tes­ta­tion re­quire­ment on the ef­fec­tive­ness of our in­ter­nal con­trol over fi­nan­cial re­port­ing;

an ex­emp­tion from the re­quire­ments to ob­tain a ad­vi­sory vote on ex­ec­u­tive com­pen­sa­tion or stock­holder ap­proval of any golden para­chute arrange­ments; and

ex­tended tran­si­tion pe­ri­ods for com­ply­ing with new or re­vised ac­count­ing stan­dards.

We may take ad­van­tage of these pro­vi­sions un­til we are no longer an emerg­ing growth com­pany. We would cease to be an “emerging growth com­pany” upon the ear­li­est to oc­cur of: (i) the last day of the fis­cal year in which we have greater than $1.07 billion in an­nual rev­enue; (ii) the date we qual­ify as a “large ac­cel­er­ated filer,” with at least $700 million of eq­uity se­cu­ri­ties held by (iii) the date on which we have, in any three-year pe­riod, is­sued greater than $1.0 billion in debt se­cu­ri­ties; and (iv) the last day of the fis­cal year end­ing af­ter the fifth an­niver­sary of this of­fer­ing. We may choose to take ad­van­tage of some but not all of these re­duced re­port­ing bur­dens. We have taken ad­van­tage of cer­tain re­duced re­port­ing bur­dens in this prospec­tus. Accordingly, the in­for­ma­tion con­tained herein may be dif­fer­ent than the in­for­ma­tion you re­ceive from other pub­lic com­pa­nies in which you hold stock.

The JOBS Act per­mits an emerg­ing growth com­pany like us to take ad­van­tage of an ex­tended tran­si­tion pe­riod to com­ply with new or re­vised ac­count­ing stan­dards ap­plic­a­ble to pub­lic com­pa­nies. We have elected to use this ex­tended tran­si­tion pe­riod un­til we are no longer an emerg­ing growth com­pany or un­til we af­fir­ma­tively and ir­rev­o­ca­bly opt out of the ex­tended tran­si­tion pe­riod. As a re­sult,

our fi­nan­cial state­ments may not be com­pa­ra­ble to com­pa­nies that com­ply with new or re­vised ac­count­ing pro­nounce­ments as of pub­lic com­pany ef­fec­tive dates.

See the sec­tion ti­tled “Risk Factors—Risks Related to Ownership of Our Class A Common Stock—We are an “emerging growth com­pany” and we can­not be cer­tain if the re­duced dis­clo­sure re­quire­ments ap­plic­a­ble to emerg­ing growth com­pa­nies will make our Class A com­mon stock less at­trac­tive to in­vestors.”

Class A com­mon stock to be out­stand­ing af­ter this of­fer­ing

Class B com­mon stock to be out­stand­ing af­ter this of­fer­ing

Total Class A com­mon stock and Class B com­mon stock to be out­stand­ing af­ter this of­fer­ing

Underwriters’ op­tion to pur­chase ad­di­tional shares of Class A com­mon stock from us

We es­ti­mate that the net pro­ceeds to us from the sale of shares of our Class A com­mon stock in this of­fer­ing will be ap­prox­i­mately $             (or ap­prox­i­mately $             if the un­der­writ­ers’ op­tion to pur­chase ad­di­tional shares of our Class A com­mon stock from us is ex­er­cised in full), based upon the as­sumed ini­tial pub­lic of­fer­ing price of $             per share, which is the mid­point of the of­fer­ing price range set forth on the cover page of this prospec­tus, and af­ter de­duct­ing un­der­writ­ing dis­counts and com­mis­sions and es­ti­mated of­fer­ing ex­penses.

The prin­ci­pal pur­poses of this of­fer­ing are to in­crease our cap­i­tal­iza­tion and fi­nan­cial flex­i­bil­ity, cre­ate a pub­lic mar­ket for our Class A com­mon stock, and en­able ac­cess to the pub­lic eq­uity mar­kets for us and our stock­hold­ers. We in­tend to use the net pro­ceeds we re­ceive from this of­fer­ing for gen­eral cor­po­rate pur­poses, in­clud­ing work­ing cap­i­tal, op­er­at­ing ex­penses, and cap­i­tal ex­pen­di­tures. Additionally, we may use a por­tion of the net pro­ceeds we re­ceive from this of­fer­ing to ac­quire busi­nesses, prod­ucts, ser­vices, or tech­nolo­gies. However, we do not have agree­ments or com­mit­ments for any ma­te­r­ial ac­qui­si­tions at this time. See “Use of Proceeds” for ad­di­tional in­for­ma­tion.

Shares of our Class A com­mon stock are en­ti­tled to one vote per share.

Following the com­ple­tion of this of­fer­ing, shares of our Class B com­mon stock will be en­ti­tled to 10 votes per share.

Holders of our Class A com­mon stock and Class B com­mon stock will gen­er­ally vote to­gether as a sin­gle class, un­less oth­er­wise re­quired by law or our amended and re­stated

cer­tifi­cate of in­cor­po­ra­tion. The hold­ers of our out­stand­ing Class B com­mon stock will hold ap­prox­i­mately     % of the vot­ing power of our out­stand­ing cap­i­tal stock fol­low­ing this of­fer­ing and will have the

abil­ity to con­trol the out­come of mat­ters sub­mit­ted to our stock­hold­ers for ap­proval, in­clud­ing the elec­tion of our di­rec­tors and the ap­proval of any change in con­trol trans­ac­tion. Additionally, our ex­ec­u­tive of­fi­cers, di­rec­tors, and hold­ers of 5%

or more of our com­mon stock will hold, in the ag­gre­gate, ap­prox­i­mately     % of the vot­ing power of our out­stand­ing cap­i­tal stock fol­low­ing this of­fer­ing. See “Principal Stockholders” and “Description of Capital

Stock” for ad­di­tional in­for­ma­tion.

The num­ber of shares of our Class A com­mon stock and Class B com­mon stock that will be out­stand­ing af­ter this of­fer­ing is based on 46,360,728 shares of our Class A com­mon stock and 211,982,959 shares of our Class B com­mon stock out­stand­ing as of June 30, 2019, and re­flects:

31,381,152 shares of re­deemable con­vert­ible pre­ferred stock that will au­to­mat­i­cally con­vert into shares of Class A com­mon stock im­me­di­ately prior to the com­ple­tion of this of­fer­ing pur­suant to the terms of our amended and re­stated cer­tifi­cate of in­cor­po­ra­tion;

14,979,576 shares of our Class B com­mon stock held by for­mer em­ploy­ees that will au­to­mat­i­cally con­vert into shares of Class A com­mon stock im­me­di­ately prior to the com­ple­tion of this of­fer­ing pur­suant to the terms of our amended and re­stated cer­tifi­cate of in­cor­po­ra­tion; and

134,276,690 shares of re­deemable con­vert­ible pre­ferred stock that will au­to­mat­i­cally con­vert into shares of Class B com­mon stock im­me­di­ately prior to the com­ple­tion of this of­fer­ing pur­suant to the terms of our amended and re­stated cer­tifi­cate of in­cor­po­ra­tion, which to­gether with the con­ver­sion of re­deemable con­vert­ible pre­ferred stock and shares of Class B com­mon stock into Class A com­mon stock, we re­fer to as the Capital Stock Conversions. The shares of our Class A com­mon stock and Class B com­mon stock out­stand­ing as of June 30, 2019 ex­clude the fol­low­ing:

23,558,731 shares of our Class B com­mon stock is­suable upon the ex­er­cise of op­tions to pur­chase shares of our Class B com­mon stock out­stand­ing as of June 30, 2019, with a weighted-av­er­age ex­er­cise price of $2.27 per share;

No shares of our Class B com­mon stock is­suable upon the ex­er­cise of op­tions to pur­chase shares of our Class B com­mon stock granted af­ter June 30, 2019;

177,410 shares of our Class B com­mon stock is­suable pur­suant to war­rants to pur­chase an ag­gre­gate of 177,410 shares of our re­deemable con­vert­ible pre­ferred stock out­stand­ing as of June 30, 2019, with a weighted-av­er­age ex­er­cise price of $0.34 per share;

Get Involved

A pass­word will be e-mailed to you.

Good News

World’s Largest Rooftop Urban Farm is Set to Open in Paris Next Year

Watch Youngsters Challenge Strangers on the Street to Watergun Fight During Hot Summer Day

No More ‘Sniff Tests’: Cheap Biodegradable Sensors Can Tell Smartphones When Food Has Gone Bad

Foot Doctor Saves Passenger’s Life by Following His Instincts and Ignoring Orders From the Ground

Good Talks

Man’s Emotional Tale of How His Father’s Rebellious Blues Song Helped Him Escape Sleepy Southern Town

This Simple Morning Practice Can Pave Your ‘Path to Wealth’ and Prosperity

Listen to Woman’s Sweet Marriage Proposal Story About Popping the Question to Her Longtime Boyfriend

American Brothers Successfully Save Irish Girl Swept Out to Sea in Serendipitous Twist of Fate (GNN Podcast)

Good Gifts

The GNN Paperback Book: “And Now, The Good News”

The Nutrition Company On a Mission to Help Others

Buy Men’s Shoes, And a Free Pair Goes to the Homeless

Get Involved

This Tasty Seaweed Reduces Cow Emissions by 99%—and It Could Soon Be…

This Tasty Seaweed Reduces Cow Emissions by 99%—and It Could Soon Be a Climate Gamechanger

A puffy pink sea­weed that can stop cows from burp­ing out methane is be­ing primed for mass farm­ing by Australian re­searchers.

The par­tic­u­lar sea­weed species, called Asparagopsis, grows pro­lif­i­cally off the Queensland Coast, and was the only sea­weed found to have the ef­fect in a study five years ago led by CSIRO. Even a small amount of the sea­weed in a cow’s diet was shown to re­duce the an­i­mal’s gases by 99%.

Associate Professor Nick Paul, who is the leader of the Seaweed Research Group at the University of the Sunshine Coast (USC), said that if Australia could grow enough of the sea­weed for every cow in the na­tion, the coun­try could cut its green­house gas emis­sions by 10%.

“Seaweed is some­thing that cows are known to eat. They will ac­tu­ally wan­der down to the beach and have a bit of a nib­ble,” Dr. Paul said.

RELATED: Student Treks to Yellowstone and Finds Bacteria That Eats Pollution and ‘Breathes’ Electricity

“When added to cow feed at less than 2% of the dry mat­ter, this par­tic­u­lar sea­weed com­pletely knocks out methane pro­duc­tion. It con­tains chem­i­cals that re­duce the mi­crobes in the cows’ stom­achs that cause them to burp when they eat grass.”

The USC team is work­ing at the Bribie Island Research Centre in Moreton Bay to learn more about how to grow the sea­weed species, with the goal of in­form­ing a scale-up of pro­duc­tion that could sup­ple­ment cow feed on a na­tional—and even global scale.

“This sea­weed has caused a lot of global in­ter­est and peo­ple around the world are work­ing to make sure the cows are healthy, the beef and the milk are good qual­ity,” Dr. Paul said.

“That’s all hap­pen­ing right now. But the one miss­ing step, the big thing that is go­ing to make sure this works at a global scale, is to make sure we can pro­duce the sea­weed sus­tain­ably.

LOOK: Trees Growing Out of Buildings Could Help Heal China’s Air Pollution Problem

“If we’re able to work out how to scale up the sea­weed to such a level to that can feed all of the cows and the sheep and the goats around the world, then it’s go­ing to have a huge im­pact on the cli­mate; it’s go­ing to ad­dress a whole lot of car­bon-neu­tral agen­das that dif­fer­ent coun­tries have; and it’s ul­ti­mately go­ing to save us all bil­lions of dol­lars,” he con­cluded.

This ar­ti­cle was reprinted from the University of the Sunshine Coast.

Feed Your Friends Some Positivity By Sharing The Good News To Social Media…

SUMMER SALE! 20% Off, Plus Free Shipping on our GOOD NEWS Book

Quote of the Day

Check Out the Weekly GNN Radio Stories From Our Good News Guru

”We fi­nally got a 3D cre­ation tool like pa­per and pen­cil”

The rea­son why Khara, Inc. started mov­ing to Blender.

Khara, Inc. is known as Hideaki Anno’s mo­tion pic­ture plan­ning and pro­duc­tion com­pany. They are cur­rently work­ing on “EVANGELION:3.0+1.0”, film to be re­leased in June 2020.

It was ti­tled “Supporting Blender Development Fund”, an­nounc­ing that they sup­port Blender Foundation on de­vel­op­ing the open source 3D cre­ation soft­ware “Blender”.

Of course, it was not only a story of fund­ing.

Khara and Anime/CG pro­duc­tion com­pany “Project Studio Q, Inc.” are prepar­ing to switch their pri­mary 3D CG tools to Blender. Blender will be used for some parts of “EVANGELION:3.0+1.0” they are cur­rently work­ing on.

3D CG is es­sen­tial to mod­ern Anime pro­duc­tions. Not only the so called “animation films” such as those from Pixar and Dreamworks, but it’s now com­mon for 3D CG to be used in many Anime films. 3D CG and hand-draw­ing make a great com­bi­na­tion that im­proves pro­duc­tiv­ity and qual­ity of Anime.

Khara is a com­pany fo­cus­ing on a “hybrid of 3D CG and hand-draw­ing”. They are cur­rently work­ing on “EVANGELION:3.0+1.0” with the same pol­icy. They also founded “Project Studio Q, Inc.” in 2017, a com­pany fo­cus­ing mainly on the movie pro­duc­tion and the train­ing of Anime artists as the joint ven­ture with Dwango Co., Ltd. and Aso College Group.

Khara has been us­ing Autodesk “3ds Max” as their pri­mary tool so far. “EVANGELION:3.0+1.0” pro­duc­tion is mainly done with 3ds Max. They are now start­ing to switch from 3ds Max to Blender. Usually the rea­son be­ing “due to dif­fer­ences such as qual­ity and func­tion­al­i­ties”, but Khara’s rea­son is dif­fer­ent.

Hiroyasu Kobayashi, General Manager of Digital Dpt. and Director of the Board of Khara and President of Studio Q, and Daisuke Onitsuka, CGI Director of Digital Dpt. of Khara and General Manager of Production Dpt. of Studio Q, told about their sit­u­a­tion.

“Simply, the pro­ject scale got big­ger than what was pos­si­ble with 3ds Max.”

– Hiroyasu Kobayashi

“We need more pro­duc­tion re­sources from out­side, not only from Studio Q. We need co­op­er­a­tive work with friend com­pa­nies for our pro­duc­tion. However, many of those com­pa­nies are small or mid­dle-sized, so if we stick to 3ds Max it will cause higher man­age­ment costs.”

– Daisuke Onitsuka

You may need a bit fur­ther ex­pla­na­tion about this.

3dx Max is of­fered by Autodesk on sub­scrip­tion fee ba­sis, this fee is ex­pen­sive. According to Autodesk’s web­site, an an­nual fee for a sin­gle user is JPY 254,880. It is ex­pen­sive still when they of­fer dis­counts for mul­ti­ple users and years. A large com­pany can ab­sorb this cost with a num­ber of users as it has large rev­enue. But it turns out to be dif­fi­cult to re­coup those costs of 3ds Max for all users in a com­pany of 20-30 peo­ple size.

Different tools are used de­pend­ing on the stu­dios and works in Anime pro­duc­tion. Productivity de­creases un­less they use the same tools and as­sets (materials such as mod­els, an­i­ma­tion data, etc.). Due to this, they tend to work with com­pa­nies that use the same tools.

3ds Max is an ex­cel­lent tool and one of the in­dus­try stan­dards, but in some cases it causes a “lack of artists” due to its high costs.

In the past, Khara thought of mov­ing to “Maya” which has as many users as 3ds Max in the in­dus­try. “We worked with data pre­pared for both 3ds Max and Maya, for Maya users.” said Onitsuka. But re­sulted in a du­pli­ca­tion of work re­sources to have the same data twice. Now, Blender at­tracted their at­ten­tion.

Onitsuka: “As a mat­ter of course, we can pro­duce with the same qual­ity and sched­ule to max­i­mize the ef­fi­ciency of our lim­ited bud­get. Blender is an open source soft­ware and avail­able for free. Also, it has al­most the same func­tion­al­i­ties with other soft­ware, so it was un­doubtly at­trac­tive to us. While we still have the chal­lenge whether a new part­ner com­pany can use Blender or not, but at least, cost-wise is much sim­pler, so we are propos­ing them to use Blender as we use it.”

No lack of func­tion­al­i­ties are block­ing the switch. In fact, “Grease Pencil” was key to make the move.

Of course they can not switch the tools if a new tool is lack­ing func­tion­al­i­ties for pro­duc­tion. Blender’s rep­u­ta­tion has been “for be­gin­ners” or “for stu­dents” be­cause it was free soft­ware. However, the lat­est ver­sion has more func­tion­al­i­ties and the dif­fer­ence be­tween Blender and other tools is get­ting smaller.

Khara had started think­ing of the use of Maya 3 years ago, and also about Blender right af­ter that.

Kobayashi: “We have been watch­ing on it and got the feel­ing that we can use it as our pri­mary soft­ware. Discussing with Onitsuka, we de­cided that we may be bet­ter to use Blender as our pri­mary tool than to use var­i­ous soft­ware in the fu­ture.”

Takumi Shigyo at pro­duc­tion dpt. of Studio Q, has been us­ing Blender also for pri­vate use. He is a top “Blender wiz­ard” at Khara and Studio Q. Artists like him helped Khara’s de­ci­sion to move to Blender. Shigyo spoke about Blender as fol­lows.

“I feel the lat­est Blender 2.8 is in­ten­tion­ally ‘filling the gap’ with 3ds Max to make those users feel at home when com­ing to Blender. I think the learn­ing curve should be no prob­lem.”

– Takumi Shigyo

And there was a key func­tion­al­ity that brought Khara to Blender as pro­duc­tion stu­dio of “2D Anime works”. It was “Grease Pencil”.

You can draw lines in 3D space di­rectly with a pen, and not only by mak­ing 3D mod­els but you can also draw ex­tra de­tails in the an­i­ma­tions them­selves.

Onitsuka: “As for our work, we cre­ate an im­age in 3D, and mod­ify it into each frame as ‘2D Anime’. Even a chief an­i­ma­tion di­rec­tor di­rectly mod­i­fies each frame man­u­ally. We also even add shad­ows with tools like After Effect af­ter­wards. For ex­am­ple, if we wanted a more sharp el­bow in a char­ac­ter, we had to mod­ify the 3D model and in­sert cus­tom rigs (skeleton) into them. This was time con­sum­ing. But Blender en­ables us to draw with Grease Pencil af­ter the an­i­ma­tion is fin­ished. It may not be the way for photo-real CG but it’s a good way for 2D Anime. This helps re­duc­ing rig­ging costs.”

“More an­i­ma­tors who are not from 3D are choos­ing Blender as a ‘steppin-up’ tool not only be­cause it is free soft­ware but be­cause of Grease Pencil. This is an im­por­tant fac­tor for our de­ci­sion.”

– Hiroyasu Kobayashi

Studio Q is also a fa­cil­ity for train­ing new an­i­ma­tors. They are host­ing a con­test for cre­ators “Award:Q”, more and more can­di­dates are us­ing Blender nowa­days.

Shigyo: “We are get­ting more artists that started by us­ing Blender in Studio Q. We are also see­ing more high qual­ity works by Blender users from high school stu­dents in Award:Q. I ex­pect these new gen­er­a­tions to be the ma­jor­ity work­ing at stu­dios in the fu­ture.”

As men­tioned, Khara uses Blender, not only the soft­ware it­self but also helps the Blender Foundation by join­ing the Development Fund as a cor­po­rate mem­ber.

Masahiro “Rocky” Iwami, Production Manager of Digital Dpt. of Khara and General Manager of Overseas Dpt. of Studio Q, who is the pri­mary con­tact per­son with the Foundation, said “We had no spe­cial re­la­tion­ship with Blender Foundation be­fore this”.

Iwami: “We had the con­tact in­for­ma­tion of Foundation chair­man Mr. Ton Roosendaal, on their web­site. We got in touch with him from there. It was lucky that the name of ‘Evangelion’ at­tracted his at­ten­tion. He kindly replied back to us im­me­di­ately. We were glad to know that he thought the news that Japanese Anime com­pa­nies us­ing Blender was im­por­tant for both of us. We be­came the first, lead­ing player in Japanese Anime in­dus­try. As a cor­po­rate mem­ber of the Blender Development Fund, we are ex­pect­ing our pro­pos­als may be closer to the de­vel­op­ment team. We would like to get closer with the Blender de­vel­op­ers com­mu­nity.”

One of the ad­van­tages of Blender is be­ing open source, any­one can de­velop and add their own func­tion­al­i­ties to Blender. Regarding this, Kobayashi said “Development de­tails are to come”.

Onitsuka: “Please un­der­stand that we are keep­ing a good re­la­tion­ship with Autodesk. Not only with Autodesk but also with other com­pa­nies, we keep re­quest­ing im­prove­ments. However, it takes time for those im­prove­ments to make it to pro­pri­etary soft­ware. We ex­pect faster im­prove­ments by us­ing open source soft­ware.”

The full switch will take place af­ter “EVANGELION:3.0+1.0”, but Blender is al­ready used in it.

Some peo­ple may think “EVANGELION:3.0+1.0” can be made by Blender from the be­gin­ning. But pipelines do not switch that fast in re­al­ity.

Kobayashi: “Preliminary test­ing has been done al­ready. We are now at the stage to cre­ate some cuts ac­tu­ally with Blender as ‘on live test­ing’. However, not all the cuts can be done by Blender yet. But we think we can move out from our cur­rent stress­ful sit­u­a­tion if we place Blender into our work flows. It has enough po­ten­tial ‘to re­place ex­ist­ing cuts’.”

Onitsuka: “We will be work­ing on ‘EVANGELION:3.0+1.0’ un­til June 2020, so all the process can­not be changed be­fore that. But we think we can say that ‘we use Blender from this time on­wards’ for the next pro­ject. We would like to use and test Blender ag­gres­sively in our cur­rent ‘EVA’ for the on­go­ing year.”

Kobayashi: “There are cur­rently some ar­eas where Blender can­not take care of our needs, but we can solve it with the com­bi­na­tion with Unity. Unity is usu­ally enough to cover 3ds Max and Maya as well. Unity can be a bridge among en­vi­ron­ments.”

Onitsuka: “Hand-draw an­i­ma­tors can start draw­ing only with pa­per and pen­cil. Just like that, 3D CG an­i­ma­tors can start cre­at­ing only with Blender at the same level cost with ‘paper and pen­cil’. We al­ready started speak­ing to part­ner com­pa­nies ‘let’s use Blender to­geth­er’. We are just start­ing now but high qual­ity work Blender can be the best proof that our choice is the right one. What shows our value is the pic­tures we make, not the tech­niques and tech­nolo­gies. We want to share the know-hows with stu­dios so that the Blender com­mu­nity will grow through those.”

OpenDrop is a com­mand-line tool that al­lows shar­ing files be­tween de­vices di­rectly over Wi-Fi. Its unique fea­ture is that it is pro­to­col-com­pat­i­ble with Apple AirDrop which al­lows to share files with Apple de­vices run­ning iOS and ma­cOS. Currently (and prob­a­bly also for the fore­see­able fu­ture), OpenDrop only sup­ports send­ing to Apple de­vices that are dis­cov­er­able by every­body as the de­fault con­tacts only mode re­quires Apple-signed cer­tifi­cates.

OpenDrop is ex­per­i­men­tal soft­ware and is the re­sult of re­verse en­gi­neer­ing ef­forts by the Open Wireless Link pro­ject. Therefore, it does not sup­port all fea­tures of AirDrop or might be in­com­pat­i­ble with fu­ture AirDrop ver­sions. OpenDrop is not af­fil­i­ated with or en­dorsed by Apple Inc. Use this code at your own risk.

To achieve com­pat­i­bil­ity with Apple AirDrop, OpenDrop re­quires the tar­get plat­form to sup­port a spe­cific Wi-Fi link layer. In ad­di­tion, it re­quires Python >=3.6 as well as sev­eral li­braries.

Apple Wireless Direct Link.

As AirDrop ex­clu­sively runs over Apple Wireless Direct Link (AWDL), OpenDrop is only sup­ported on ma­cOS or on Linux sys­tems run­ning an open re-im­ple­men­ta­tion of AWDL such as OWL.

Libraries.

OpenDrop re­lies on cur­rent ver­sions of OpenSSL and libarchive. ma­cOS ships with rather old ver­sions of the two, so you will need to in­stall newer ver­sion, for ex­am­ple, via Homebrew. In any case, you will need to set the two en­vi­ron­men­tal vari­ables LIBARCHIVE and LIBCRYPTO ac­cord­ingly. For ex­am­ple, use brew to in­stall the li­braries:

brew in­stall libarchive openssl@1.1

ex­port LIBARCHIVE=/usr/local/opt/libarchive/lib/libarchive.dylib

ex­port LIBCRYPTO=/usr/local/opt/openssl@1.1/lib/libcrypto.dylib

Linux dis­tri­b­u­tions should ship with more up-to-date ver­sions, so this won’t be nec­es­sary.

Installation of the Python pack­age re­lease is straight for­ward us­ing pip3:

pip3 in­stall open­drop

You can also in­stall the cur­rent de­vel­op­ment ver­sion by first cloning this repos­i­tory, and then in­stalling it via pip3:

git clone https://​github.com/​seemoo-lab/​open­drop.git

pip3 in­stall ./opendrop

We briefly ex­plain how to send and re­ceive files us­ing open­drop. To see all com­mand line op­tions, run open­drop -h.

Sending a file is typ­i­cally a two-step pro­ce­dure. You first dis­cover de­vices in prox­im­ity us­ing the find com­mand. Stop the process once you have found the re­ceiver.

$ open­drop find

Looking for re­ceivers. Press en­ter to stop …

Found in­dex 0 ID ec­cb2f2d­cfe7 name John’s iPhone

Found in­dex 1 ID e63138ac6ba8 name Jane’s MacBook Pro

You can then send a file us­ing

$ open­drop send -r 0 -f /path/to/some/file

Asking re­ceiver to ac­cept …

Receiver ac­cepted

Uploading file …

Uploading has been suc­cess­ful

Instead of the in­dex, you can also use ID or name. OpenDrop will try to in­ter­pret the in­put in the or­der (1) in­dex, (2) ID, and (3) name and fail if no match was found.

Receiving is much eas­ier. Simply use the re­ceive com­mand. OpenDrop will ac­cept all in­com­ing files au­to­mat­i­cally and put re­ceived files in the cur­rent di­rec­tory.

$ open­drop re­ceive

OpenDrop is the re­sult of a re­search pro­ject and, thus, has sev­eral lim­i­ta­tions (non-exhaustive list be­low). I do not have the ca­pac­ity to work on them my­self but am happy to pro­vide as­sis­tance if some­body else want to take them on.

Triggering ma­cOS/​iOS re­ceivers via Bluetooth Low Energy. Apple de­vices start their AWDL in­ter­face and AirDrop server only af­ter re­ceiv­ing a cus­tom ad­ver­tise­ment via Bluetooth LE (see USENIX pa­per for de­tails). This means, that Apple AirDrop re­ceivers may not be dis­cov­ered even if they are dis­cov­er­able by every­one.

Sender/Receiver au­then­ti­ca­tion and con­nec­tion state. Currently, there is no peer au­then­ti­ca­tion as in Apple’s AirDrop, in par­tic­u­lar, (1) OpenDrop does not ver­ify that the TLS cer­tifi­cate is signed by Apple’s root and (2) that the Apple ID val­i­da­tion record is cor­rect (see USENIX pa­per for de­tails). In ad­di­tion, OpenDrop au­to­mat­i­cally ac­cepts any file that it re­ceives due to a miss­ing con­nec­tion state.

Sending mul­ti­ple files. Apple AirDrop sup­ports send­ing mul­ti­ple files at once, OpenDrop does not (would re­quire adding more files to the archive, mod­ify HTTP /Ask re­quest, etc.).

* Milan Stute, Sashank Narain, Alex Mariotto, Alexander Heinrich, David Kreitschmann, Guevara Noubir, and Matthias Hollick. A Billion Open Interfaces for Eve and Mallory: MitM, DoS, and Tracking Attacks on iOS and ma­cOS Through Apple Wireless Direct Link. 28th USENIX Security Symposium (USENIX Security ’19), August 14–16, 2019, Santa Clara, CA, USA. Link

OpenDrop is li­censed un­der the GNU General Public License v3.0. We use a mod­i­fied ver­sion of the python-ze­ro­conf pack­age (essentially adding rudi­men­tary IPv6 and AWDL sup­port) which is li­censed un­der the GNU Lesser General Public License v2.1. Both li­censes are found in the LICENSE file.

My mom fainted the first time she set foot in an American su­per­mar­ket. It was 1981 and we were freshly ar­rived in America, and some com­bi­na­tion of the cul­ture shock and smell and sen­sory over­load of a Safeway was too much for her, not nor­mally a faint­ing woman.

I did­n’t faint, but I stood trans­fixed in the ce­real aisle. After six long years on Earth, here was a place that un­der­stood me. These were car­toon char­ac­ters, made of pure sugar, that you could eat as a meal. Every box had a toy in­side. How could I pos­si­bly choose just one?

Houston in that era was not an earthly par­adise. But try telling that to vis­i­tors like us, daz­zled by the sheer abun­dance of American cap­i­tal­ism. There were su­per­high­ways in the cen­ter city! Everyone had a gi­ant car! You could drive that car up to a restau­rant with a yel­low “M” on it, and a teenager would hand you a bucket of pink ice cream through the win­dow! According to the sign on the restau­rant, this had hap­pened bil­lions of times. It was over­whelm­ing.

All that pre­lude is to say, com­ing in to the Hong Kong protests from a less de­vel­oped coun­try like the United States is dis­ori­ent­ing. If you have never vis­ited one of the Zeroth World cities of Asia, like Taipei or Singapore, it can be hard to con­vey their mix of high den­sity, maze­like de­sign, ut­terly re­li­able pub­lic ser­vices, and high so­cial co­he­sion, any more than it was pos­si­ble for me or my par­ents to imag­ine a real American city, no mat­ter how many movies we saw. And then to have to write about protests on top of it!

It’s hard to write ar­tic­u­lately about the Five Demands when one keeps get­ting brought up short by ba­sic things, like the ex­is­tence of clean pub­lic bath­rooms.

The time and lo­ca­tion of protests are set via so­cial me­dia alchemy; once you get no­ti­fied about one, you de­scend through a spot­less mall onto a bright and clean train plat­form, get whisked away by a train that ar­rives al­most im­me­di­ately, step out into an­other mall, then fi­nally walk out­side into over­whelm­ing heat and a gath­er­ing group of demon­stra­tors.

When it’s over, whether the demon­stra­tors have dis­persed of their own will, or are run­ning from rub­ber bul­lets and tear gas, you duck into an­other mall, and an­other train, and within min­utes are back in a land of in­fi­nite hy­per­com­merce, tiny al­leys and posh ho­tels with their lobby on the 40th floor of a sky­scraper.

Not every­one lives in a lux­ury ho­tel, man! I get it. But my eyes are like saucers. I ask for­give­ness of Hong Kongers if at times I am still that six year old kid, daz­zled by what to you is or­di­nary. You live in a kind of city we Americans can only as­pire to, and it’s no won­der you love your home so much you will take any risk to save it.

Word spreads that there will be a protest in Tai Po, a res­i­den­tial dis­trict in the New Territories, close to the bor­der. The pro­test­ers have been cy­cling events through dif­fer­ent neigh­bor­hoods, as a way of build­ing sym­pa­thy with the peo­ple, who can look out from their win­dows and watch the po­lice re­ac­tion first­hand. At this point, the po­lice re­ac­tion al­most in­evitably means tear gas, and peo­ple have been gassed in their own apart­ments, on high floors. This is a par­tic­u­lar hard­ship for the sick and el­derly, al­ready strug­gling in the heat.

One of the deeper causes of the pre­sent cri­sis of le­git­i­macy is the hous­ing cri­sis in Hong Kong, an­other way in which the gov­ern­ment has failed the peo­ple it is meant to rep­re­sent, and you can see it in the ex­tra­or­di­nary den­sity of apart­ment build­ings, each unit pock-marked with an air con­di­tioner, tiny liv­ing spaces with some of the high­est rents in the world.

Tai Po is eas­ily reach­able by MTR, the city’s com­muter train sys­tem. Everywhere ex­cept the is­lands is eas­ily reach­able by MTR. The MTR is the one tech­nol­ogy the Hong Kong protests could not do with­out, an au­tonomous fief­dom that the po­lice mostly stay out of. It is neu­tral ter­ri­tory. The train ride is un­event­ful un­til we get off at Tai Po sta­tion, where there are an un­usual num­ber of peo­ple in black, the color of the protests (lucky is the Hong Konger who started the sum­mer as a goth or metal fan, and has some wardrobe op­tions!)

The ar­riv­ing pro­test­ers stream out of the sta­tion in groups, con­sol­i­dat­ing as they ap­proach the ral­ly­ing point in a lo­cal park. Volunteers along the way pass out fly­ers and hold di­rec­tional signs. There is a mix of ages, though they trend young. The typ­i­cal Hong Kong pro­tester, re­searchers tell us, is a col­lege ed­u­cated pro­fes­sional in their twen­ties. There is a roughly equal gen­der bal­ance.

The streets around the park are al­most free of traf­fic. After a brief false start in the wrong di­rec­tion, the crowd turns it­self around with hand sig­nals and be­gins to march. The at­mos­phere is fes­tive, with lots of chant­ing of “ga yao” (add oil), the id­iomatic phrase that is now find­ing its way into English.

Once every few min­utes a stray ve­hi­cle wan­ders into our path, and demon­stra­tors take pains to let it through, with self-se­lected vol­un­teers part­ing the crowd. If the taxi honks in sup­port, a cheer goes up from the marchers.

The road takes us past lush park­land, where skinny white birds ob­serve us from the tree­tops, and then through a busi­ness dis­trict with no po­lice, few pedes­tri­ans, and al­most no traf­fic. Many stores along the route have been shut­tered in an­tic­i­pa­tion of the march, but the sec­ond-floor restau­rant win­dows are full of cu­ri­ous faces. People are pho­tograph­ing us, and we pho­to­graph them back. When some­one waves or shouts sup­port, whether from the street or from a pass­ing ve­hi­cle, the same cheer goes up.

In the win­dows, we can see cou­ples on dates, cu­ri­ous chil­dren with their hands pressed to the glass, and store keep­ers look­ing out with an ap­prais­ing eye. Up in the high rises, old men in un­der­shirts lean down to watch.

A Thai restau­rant has stayed open. The hand-let­tered sign in its win­dow in­vites demon­stra­tors in for free re­fresh­ments. There is noth­ing you can pay for in a protest - vol­un­teers hand out gas masks, wa­ter, tea, and end­less fly­ers, de­signed and printed with as­ton­ish­ing alacrity in re­sponse to each day’s events. Anything you may need, peo­ple have do­nated.

Across the street, a man is stick­ing post-its to the shut­tered store­front of a 7-11, cre­at­ing an­other one of the post-it walls that are all over Hong Kong. The air­port protest on Friday even had a guy styling him­self Memo Man, dressed in a black body suit you could paste notes to, un­til he looked like a pa­per hedge­hog.

The level of heat and hu­mid­ity is al­most com­i­cal. My slavic body is shut­ting down, in a process so un­set­tling to fel­low marchers that con­cerned peo­ple start of­fer­ing me wa­ter or tiny, sin­gle use tis­sues. These turn into wet con­fetti the sec­ond they touch my face. You might as well try to stop Niagara with a hand towel.

“It’s okay,” I tell them. “This is nor­mal. I’m not dy­ing—I’m Polish.” They edge away.

Our group at this point num­bers in the thou­sands. We pass through an­other neigh­bor­hood of res­i­den­tial high-rises and find our­selves at a large, empty in­ter­sec­tion. In the dis­tance on the left there is a pedes­trian over­pass full of jour­nal­ists (we can tell be­cause they’ve set up an­tenna tripods). Beyond the over­pass stands a line of cops, their plas­tic shields glint­ing in the sun.

With the po­lice vis­i­ble, there is a lit­tle bit of a hush in the crowd. The march con­tin­ues in a di­rec­tion par­al­lel to the po­lice line, to an­other ma­jor in­ter­sec­tion. There, vol­un­teers are yelling to of­fer marchers a choice. We can turn right and walk to a nearby train sta­tion. Or we can go left and con­front the po­lice. Most peo­ple choose to go left, and are handed sur­gi­cal masks (to hide their faces) if they don’t al­ready have them.

The po­lice sta­tion is just ahead, a five-story build­ing with large Eiffel tower-style an­ten­nas on the roof. Another line of riot po­lice has blocked the road lead­ing to it, and jour­nal­ists rush to get pic­tures. The demon­stra­tors stop and con­fer.

I should say a few words here about the cu­ri­ous way the protests are or­ga­nized. The pro­test­ers learned in 2014 that hav­ing lead­ers was a weak­ness. Once the lead­er­ship was ar­rested, the heart went out of the oc­cupy move­ment, and it lost mo­men­tum. So in 2019, there is no lead­er­ship at all. The protests are in­ten­tion­ally de­cen­tral­ized, us­ing a jury-rigged com­bi­na­tion of a pop­u­lar mes­sage board, the group chat app Telegram, and in-per­son hud­dles at the protests.

This sounds like it should­n’t pos­si­bly work, but the pro­test­ers are too young to know that it can’t work, so it works.

The pro­test­ers di­vide them­selves into groups based on how much they can risk be­ing ar­rested. The is­sue is not jail time, but the prospect of los­ing a job or be­ing kicked out of school, now that China has shown it will crack down fe­ro­ciously on com­pa­nies that em­ploy demon­stra­tors.

The front­most group are the peo­ple who ac­tu­ally come into con­tact with the po­lice, and put them­selves at great­est risk of ar­rest. Behind them there is a sup­ply group, who passes wa­ter and other es­sen­tials for­ward, and helps those in front if they are hurt. And be­hind that is the great body of demon­stra­tors. Those who will be up front are given lee­way to make de­ci­sions, in­clud­ing telling the crowd to move back and make room, or de­cid­ing to dis­perse and re­assem­ble else­where.

Now these front­line pro­test­ers have formed a hud­dle to dis­cuss the tac­ti­cal sit­u­a­tion. Protesters around them shield the group from sur­veil­lance with um­brel­las. The po­lice watch, and the rest of us wait.

Journalists are all over these protests. Members of the lo­cal press wear yel­low vests marked PRESS, and put on head­gear if things start to get spicy. Some of the for­eign cor­re­spon­dents elect to dress more elab­o­rately, look­ing like they’re about to ex­plore the lu­nar sur­face rather than in­ter­view a tiny re­tiree. You can spot key events or celebri­ties in the protests by look­ing for the cir­cle of yel­low vests, and pyra­mid of selfie sticks raised above what­ever is hap­pen­ing.

The pro­test­ers, like beavers, have a strong build­ing in­stinct. They want to make bar­ri­cades. The pre­lim­i­nary hud­dles have ex­pressed con­cern that we are not on fa­vor­able ter­rain. The po­lice is dead ahead, the street is bor­dered by a cul­vert and stream, and it would be too easy to cut the pro­test­ers off from be­hind. So a new set of hud­dles forms, screened by um­brel­las, and af­ter a few min­utes we see that they have re­assem­bled steel bar­ri­cades into tri­an­gle shapes, held to­gether by plas­tic ties, which they will as­sem­ble and tie to­gether to block the side roads.

A great hur­rah goes up as a group of masked pro­test­ers runs one of these tri­an­gles down the road, the crowd zip­per­ing open in front of them. As they run, the um­brella hold­ers run along­side to keep them screened. Another tri­an­gle pla­toon runs its bar­ri­cade down to the in­ter­sec­tion.. And then - dis­as­ter! A third tri­an­gle is rushed down the street, but the squad misses their turn, and races off into the dis­tance. The crowd roars for them to stop. Far down the road, they skid to a halt, re-form, and rush back. More cheers.

The rest of us stand and watch this busi­ness un­fold. It is four o’­clock and the heat is cook­ing me from within. A breeze is blow­ing to­wards the po­lice line, and there is spec­u­la­tion that this is why the po­lice have not fired tear gas. The for­eign jour­nal­ists in their body ar­mor are all up at the front of the protest, so there is a dis­ori­ent­ing dy­namic where peo­ple fur­ther back can fol­low a Bloomberg live stream what is hap­pen­ing two hun­dred me­ters to their front. Flummoxed by the wind, the po­lice have in­stead brought out pump tanks of pep­per spray, like gi­ant hot sauce dis­pensers, and are bran­dish­ing them at the front of the crowd.

More time passes. Finally, the de­ci­sion sur­faces that the po­si­tion is too un­fa­vor­able. This has been an­other de­vel­op­ment in the pro­test­ers’ tac­tics since the start of the sum­mer. Rather than stand­ing their ground, they have found it more ef­fec­tive to melt away and re­assem­ble some­where else. The tac­tic is a clas­sic one, but I am im­pressed with the abil­ity of a de­cen­tral­ized group to adopt it so ef­fec­tively.

And so, every­one makes their way back to the train sta­tion, where again things tran­si­tion to nor­mal, as if a street protest with thou­sands of par­tic­i­pants has­n’t just hap­pened. The trains ab­sorb the ex­tra pas­sen­gers eas­ily (the New York sub­way would be in flames), and we re­turn to the heart of the city.

The next day there is an au­tho­rized protest in Victoria Park, where a dour Queen Victoria in the late years of her reign sits swel­ter­ing on a metal throne.

These au­tho­rized protests are be­com­ing rare, even though Hong Kongers are sup­posed to en­joy free­dom of as­sem­bly. In June and July, the po­lice would rou­tinely grant the per­mits that the lead­er­less protests al­ways found a way to ap­ply for. More re­cently, the po­lice have switched tac­tics and are now re­fus­ing per­mits, then tear-gassing the in­evitable il­le­gal as­sem­bly.

But to­day’s rally is of­fi­cial. Demonstrators line the edges of the big open bas­ket­ball courts and soc­cer fields, wher­ever there is a scrap of shade. A first aid sta­tion has been set up by the med­ical vol­un­teers, and free wa­ter and elec­trolyte drinks are avail­able to every­one. The air is still, mak­ing the heat worse, and for hours noth­ing re­ally hap­pens, just a crowd stand­ing and half-lis­ten­ing to speak­ers ral­ly­ing the crowd from the stage. A small group of Buddhists has set up in­cense and per­forms a cer­e­mony in the frame of a soc­cer goal.

Anticipating where the real protest will hap­pen feels just like hop­ing you’re one of the peo­ple cool enough to be told about the af­ter­party. You keep one eye on the cool kids, in this case the fully masked pro­test­ers. As long as they are still around, we know we haven’t missed out on any­thing.

Finally, around six o’­clock, two lines of peo­ple form up and start to move. We are on the march.

The crowd shifts and re­con­fig­ures to start mak­ing its way out of the park. We file past groups of Indonesian women in hi­jab, sit­ting on flat­tened card­board and hav­ing their pic­nic in the park. No amount of pol­i­tics is go­ing to de­prive them of their pre­cious day off. Queen Victoria looks down at us with dis­ap­proval, and then, just like that, we a re an il­le­gal as­sem­bly. Speakers at the edge of the park blare out an aw­ful, sac­cha­rine an­them as we reach the main road. I put on my hard hat.

It is hard to be­lieve this is the tenth week of protests. The en­ergy and num­bers are just as­ton­ish­ing. In spite of the re­lent­less­ness of the po­lice, in spite of the beat­ings from thugs who the au­thor­i­ties have al­lowed to rough up peo­ple with im­punity, every week­end Hong Kongers come out to march.

We move in the di­rec­tion of City Hall, down a thor­ough­fare lined with Times Square-like an­i­mated ad­ver­tis­ing. The crowd boos and shines lasers on a large an­i­mated sign be­long­ing to a main­land Chinese news­pa­per. Then there is a sud­den stop and a sea of hand ges­tures, thumb and pinky out, hands twist­ing rapidly. Someone up in the van­guard needs an Allen wrench! This is pro­cured and passed, and then the ges­ture turns to a “C” shape. They need a mon­key wrench!

Finally, what­ever bar­ri­cade full of hex nuts that is im­ped­ing our progress gets dis­man­tled, and the crowd flows on through.

The march is en­ter­ing the ad­min­is­tra­tive heart of the city. It parts for a while to let through some trapped buses and taxis, and then re-forms again, mov­ing to­ward Central. We are get­ting close to po­lice head­quar­ters, and soon a de­ci­sion will be nec­es­sary. As we get closer, all mo­tion stops, more con­sul­ta­tive hud­dles form, and twenty or so aim­less min­utes go by.

Then, a hand ges­ture. Retreat. The po­lice are too strong here. The crowd heads back in the gen­eral di­rec­tion of the park.

A woman stand­ing on a con­crete planter by the MTR sta­tion is yelling “go to Tsim Sha Tsui!”. People are look­ing at their phones, check­ing the lat­est news. Some of the Telegram groups around the protests have tens of thou­sands of par­tic­i­pants, and in­for­ma­tion gets am­pli­fied quickly. We de­cide to fol­low the wom­an’s ad­vice and take the train to Kowloon.

Down in the MTR, it’s a dif­fer­ent world. Though we have just left a huge protest march, here we are in the midst of fam­i­lies, cou­ples on dates, el­derly peo­ple, women in saris, white ex­pats in busi­ness clothes. The hel­mets come off and we again join the ranks of the law­fully as­sem­bled, the train sys­tem ef­fort­lessly ab­sorb­ing a surg­ing crowd that would turn BART into a mass tomb.

At Tsim Sha Tsui sta­tion we meet an ar­riv­ing train full of demon­stra­tors, some al­ready wear­ing pink-capped res­pi­ra­tors. We fol­low them up and out onto the street, emerg­ing some­what un­ex­pect­edly out­side a mosque, where a South Asian woman on the steps is yelling “no pho­tos!”. She does­n’t mean not to pho­to­graph the mosque. Rather, she’s yelling at peo­ple who are tak­ing pho­tos of the demon­stra­tors from its steps.

We are now in the heart of the tourist dis­trict, with ho­tels and fancy restau­rants all around us. If I came here dur­ing the day, I would be stopped and asked a dozen times if I wanted my clothes tai­lored. Tonight, the tai­lors have stayed home. The street is a sea of black-clad peo­ple in masks and hard hats. Word goes around that tear gas has al­ready been fired two blocks away, and I fum­ble to get my equip­ment on.

The Persian po­ets say the nose is the out­post of the face. I am nor­mally proud of mine. Its great bulk has pre­ceded me into every dif­fi­cult sit­u­a­tion in my life, sniff­ing out both dan­ger and op­por­tu­nity.

But the mask I bought here is de­signed for more del­i­cate faces than mine. When I put it on, it some­how chan­nels the air I ex­hale di­rectly into my gog­gles, which fog up in­stantly. I can only see for a few sec­onds at a time be­fore the world turns into a white mist. But, I rea­son, not be­ing able to see from con­den­sa­tion will be much bet­ter than not be­ing able to see from tear gas. I hang gog­gles and mask around my neck and await de­vel­op­ments.

The crowd has be­gun to move in the di­rec­tion of the po­lice. Up ahead, some­one is wav­ing a big black flag with the Hong Kong em­blem on it. They are sil­hou­et­ted against a pale cloud of smoke, and as I watch I see streams of more smoke falling in arcs around the flag wa­ver. That is the tear gas.

The peo­ple around me are fill­ing bot­tles with wa­ter. Tear gas is kind of a mis­nomer - it’s a solid dis­per­sion that gets de­liverd through a burn­ing smoke bomb. You can ex­tin­guish it by dous­ing it in wa­ter The kids have a well-prac­ticed as­sem­bly line go­ing, de­liv­er­ing wa­ter to the front line, and I try to stay out of every­body’s way.

Supply vol­un­teers are hand­ing out wet wipes (to get the chem­i­cal residue off your skin) and sin­gle-use plas­tic sticks of saline so­lu­tion for an eye rinse. I am just mov­ing up to get a bet­ter view of the flag wa­ver when a tear gas can­is­ter lands at my feet, and I sud­denly re­mem­ber an im­por­tant en­gage­ment else­where.

When you are in a for­eign land with strangers, it is good to have shared in­ter­ests. They bring peo­ple to­gether across cul­tural and lin­guis­tic bar­ri­ers. Right now, the crowd and I are all deeply in­ter­ested in mov­ing back a bit. As we go, med­ical vol­un­teers ap­proach peo­ple who have been af­fected by the tear gas and help them rinse their eyes. “Don’t rub.” Everybody is tended to. Hong Kong protests have bet­ter med­ical care than any place in America, I think, in an­other of those lit­tle cul­ture shock mo­ments that keep lift­ing me out of the sit­u­a­tion.

For a while, the sit­u­a­tion is sta­tic. I no­tice the flag wa­ver has never stopped, de­fi­antly wav­ing right in front of the po­lice line. Word comes that the po­lice have now raised an or­ange warn­ing flag, which means they will use rub­ber bul­lets.

The front line asks for peo­ple to move fur­ther back, and we com­ply. It is dan­ger­ous to look di­rectly back into the crowd be­cause of the dozens and dozens of green lasers be­ing beamed in the di­rec­tion of the po­lice (who have taped foil to their vi­sors as a de­fense).

At one point, I hear a tremen­dous cheer go up. A group of pro­test­ers rushes past with their prize, a tall sec­tion of scaf­fold­ing they have de­tached from a nearby work site. The lasers dance over it in cel­e­bra­tion. It is rushed for­ward for bar­ri­cade duty on the front line. I see other peo­ple form­ing a bucket brigade to pass up wa­ter bot­tles.

Then, for no rea­son I can see, there is panic. People are run­ning flat out, and I worry about be­ing knocked down in the surge. I catch the briefest glimpse of a woman with no pro­tec­tive gear, dressed nor­mally, who is weav­ing her way up­stream through the es­cap­ing demon­stra­tors with a placid smile on her face.

When the run­ning sub­sides, I duck be­hind a tree in the me­dian. I don’t know what’s go­ing on, only that peo­ple ran and now have stopped run­ning. Someone says that the po­lice line has pushed for­ward. Then there is a new sound from up front, the pop-pop-pop of rub­ber bul­lets be­ing fired, and peo­ple start to run again. “When in Rome,” I think to my­self, and our lit­tle group legs it into the first side street we can find. And there we come across an open snack stall.

With tear gas, adren­a­line, and the ad­vanc­ing riot po­lice be­hind us, an ap­pe­tiz­ing line of skew­ers is dis­played in neat rows ahead of us, in front of vats of steam­ing broth. The choice is ob­vi­ous.

I se­lect skew­ers of in­de­ter­mi­nate seafood and wait for them to be heated by the com­pletely un­fazed pro­pri­etor. We are in lit­tle side street full of bou­tiques, stores and restau­rants, many of them still open, the own­ers stand­ing out­side to as­sess the sit­u­a­tion. Other demon­stra­tors are fil­ing past in their head­gear de­cid­ing which way to go to avoid the po­lice.

I put my mask and gog­gles in the back­pack, and re­turn to the role of or­di­nary tourist. In this re­spect, I am far more for­tu­nate than Hong Kongers, who will have to worry about be­ing stopped at ran­dom by po­lice on their way home, and be­ing caught with masks and hel­mets on their per­son.

I can’t get over the odd­ness of the sit­u­a­tion. In one di­rec­tion is bed­lam, in the other com­plete nor­malcy, sep­a­rated by a few hun­dred me­ters. Some ac­tual tourists are weav­ing about, wor­ried, and demon­stra­tors turn them around if they ac­ci­den­tally head to­wards the tear gas.

Skewers eaten, we elect to call it a night, and find our way to the nearby MTR train sta­tion. The es­ca­la­tor at the en­trance is not work­ing, the first time I’ve seen any­thing fail to func­tion in this in­domitable train sys­tem. Underground, the sta­tion is packed with demon­stra­tors, and il­lu­mi­nated signs above our heads apol­o­gize for the slight dis­rup­tion in ser­vice. Trains are now run­ning every seven min­utes, in­stead of every two, and MTR re­grets the in­con­ve­nience.

Sympathetic sub­way work­ers have opened the gates to the plat­form, so peo­ple can get to the plat­form with­out a po­ten­tially track­able swipe of their Octopus card (the magic recharge­able card with which you can buy al­most any­thing in t he city).

And then, just as we are de­scend­ing the es­ca­la­tor to the train tracks, a group of demon­stra­tors rushes in be­hind us and call­ing for every­one to run—the po­lice are com­ing.

This is the scari­est mo­ment of the night, as a quick stam­pede starts in the very con­fined space of the es­ca­la­tor. I am ter­ri­fied that some­one will trip and get tram­pled. On the train, peo­ple are hold­ing the doors open, and yel­low-shirted MTR per­son­nel ap­pear to re­store or­der. Protests are protests, but the MTR must run!

Later that night, we will learn that in an­other sub­way sta­tion, po­lice fired tear gas can­is­ters di­rectly at peo­ple, a ter­ri­ble thing to do in a con­fined space. There is video of po­lice beat­ing un­armed pro­test­ers sav­agely on an MTR es­ca­la­tor. And the whole city sees the pic­tures of a young medic who lost the vi­sion in her eye af­ter po­lice shot her in the face with a bean bag round. The out­rage from those acts of vi­o­lence will pro­voke the mas­sive protests that shut down the air­port on Monday and Tuesday.

But that news is still a few hours away, and again the MTR per­forms its alchemy of tak­ing us into a world apart, the sky­scrap­ers and ho­tels around Central, where the view is of tankers and brightly lit junks drift­ing through the har­bor, and there is no sign at all of the tur­moil we have just wit­nessed.

That is the Hong Kong I saw last week­end. I don’t know - I sus­pect no one knows - what will hap­pen to­mor­row. The only sure thing is that peo­ple will march. There are many Hong Kongers and other smart peo­ple writ­ing on­line who can ex­plain the po­lit­i­cal con­text of the protests, the like­li­hood of in­ter­ven­tion, and what this means in a deeper way. I am just a vis­i­tor who per­haps thinks too much about fish cakes when be­ing tear gassed.

But I hope every­one stays safe, that the in­evitable protests this week­end are al­lowed to pro­ceed peace­fully, and that those in a po­si­tion to es­ca­late the cri­sis in­stead rec­og­nize the fun­da­men­tal rea­son­able­ness of what Hong Kongers are ask­ing for—to be ruled by the agreed laws, ap­plied fairly to all. Above all, I hope no one is hurt.

To the many, many Hong Kongers who have shown kind­ness and gone out of their way to wel­come vis­i­tors to their city even in these dif­fi­cult times, I want to of­fer my deep­est grat­i­tude. What to me is some­thing to ob­serve and write about, to you has be­come a ques­tion of sur­vival.

Thank you for let­ting me join you in your city, and see what you are ex­pe­ri­enc­ing at first hand. I know that in America, all our hearts will re­main with you, and with Hong Kong, what­ever comes next.

A place for red­di­tors/​se­ri­ous peo­ple to dis­cuss quan­ti­ta­tive trad­ing, sta­tis­ti­cal meth­ods, econo­met­rics, pro­gram­ming, im­ple­men­ta­tion, au­to­mated strate­gies and bounce ideas off each other for con­struc­tive crit­i­cism, feel free to sub­mit pa­pers/​links of things you find in­ter­est­ing.