Working in Public and the Economics of Free

Plus! Delevering, Alternative Lending, Time To Build in Britain, Pinduoduo, Executive Orders, More...

This is the once-a-week free edition of The Diff, the newsletter about inflections in finance and technology. The free edition goes out to 10,366 subscribers, up 977 week-over-week. This week’s subscribers-only posts:

In this issue:

  • Working in Public and the Economics of Free

  • Household Delevering

  • More Alternative Lending

  • It’s Time to Build in Britain

  • Pinduoduo

  • Industrial Espionage in Taiwan

  • Executive Orders (pts 1, 2, and 3)

Programming note: The Diff is relocating to Austin. I still like New York, at least New York circa 2019, so think Elba, not St. Helena. I don’t expect any disruption to the usual publication schedule.

Working in Public and the Economics of Free

It’s the fate of every essential part of the economy to become ubiquitous, then invisible, then superficially boring. You don’t think about plumbing, electricity, gasoline, or staple food products (mostly) because a handful of specialists work very hard to make them available all the time. As software eats the economy, both in terms of market capitalization and in terms of how much behavior it mediates, open-source software increasingly fits into that category.

But we don’t actually know how to pay for it. We don’t know how to ensure that it exists. Sometimes, chunks of it disappear in a fit of pique, albeit for a brief period.

That’s an important problem. We’re in a strange in-between state where software is increasingly essential, the most important bits of it are built by dedicated volunteers, and there’s no great way to encourage them to a) keep doing this, and b) stay motivated as the work gets less and less fun. That was my main takeaway from Nadia Eghbal’s Working in Public, published this week.

The book is a tour of the open source phenomenon: who builds projects, how they get made and updated, and why. This is an important topic! Almost all of the software I use to write this newsletter is either built from open source products or relies on them: the text is composed in Emacs, on a computer running Linux; I browse the web using Chrome, which mostly consists of open-source Chromium code; my various i-devices run Unix-based OSes (iOS is not open-source, but there are as many open-source implementations of Unix as you want); etc.[1] All of this software Just Works, and I don’t directly pay for any of it. Clearly there are some incentives at work, or it wouldn’t exist in the first place, but generally the more complex an activity is, the harder it is to coordinate without pricing signals. Somehow, open-source projects don’t fall victim to this.

As Working in Public shows, they do face a demoralizing lifecycle. When a project starts, it’s one coder trying to solve a problem they face, and trying to solve it their way. Sometimes, there’s a good reason their preferred solution doesn’t exist yet, and the project languishes. Sometimes, the project catches on, acquiring new users, new contributors, and new bug reports and feature requests.

The book points out that a project is not just the literal code:

There’s a reason why open source projects are called “projects,” rather than just code. While code is the final output of a project, the term “project” refers to the entire bundle of community, code, and communication and developer tools that support its underlying production.

That’s an important point: a software project is a loop for determining what changes to make, making them, and then double-checking to make sure they were the right call. Over time, a project moves like an amoeba, extending a single-feature pseudopod and then squelching in the direction of highest user demand.

And, over time, the outside requests soak up most developers' time. Maybe you write a nice library for doing interesting things with text, which is great, until someone who uses it points out that it can’t handle Cyrillic or Hangul characters. You create a way to do something fancy in browsers, and it turns out to be broken in Internet Explorer. Your library is great for analyzing what you think of as “big data,” but somebody else’s idea of “big data” is orders of magnitude bigger, and they’re asking you for help.

Basically every successful software project runs through the classic story of economic development, at warp speed. The cycle many countries go through is that early in their economic growth is driven by manufacturing, and workers' output per hour rises fast (a country that builds its first few factories can soon justify building a bigger port, better roads, and more power plants, all of which boost workers' output. Meanwhile, those workers are getting better at their jobs). As a country grows, more of its internal consumption takes the form of services, rather than goods, and it’s very hard to raise productivity in services. And since the service sector of the economy is bidding for workers against the manufacturing sector, higher manufacturing productivity drives up service worker wages, even if those workers aren’t producing any more. As Baumol famously observed, it takes just as many musician-hours to perform a string quartet as it did in the 17th century, but since the other things those musicians could do have gotten more lucrative, the price of their time has risen. Moore’s Law makes computers faster, which gives programmers higher output per hour, so if your fellow musicians aren’t going to put away their instruments and enroll in Lambda School, their wages have to rise.

Software projects go through this exact cycle: at first, they’re mostly producing and building on “software capital,” code that executes the underlying logic of the process. Over time, more of the work involves integration and compatibility, and as all the easy edge cases get identified, the remaining bugs are a) disproportionately rare (or they would have been spotted by now) and b) disproportionately hard to fix (because they have to be the result of a rare and thus complicated confluence of circumstances). So, over time, a software project falls into the Baumol Trap, where high productivity in the fun stuff produces more and more un-fun work where productivity gains are hard to come by.

This is depressing for project creators. Early on, they have the triumphant experience of building exactly what they want, and solving their nagging problem. And the result is that they’re cleaning up after a bunch of requests from people who are either annoyed that it doesn’t work for them or have unsolicited feedback on how it ought to work. No wonder Linus Torvalds gets so mad. Running a successful open source project is just Good Will Hunting in reverse, where you start out as a respected genius and end up being a janitor who gets into fights.

Somehow, though, the important open source projects keep on going. The book suggests a few reasons for this:

  • Charity: some projects are supported by donations from grateful users. This is nice, and prosocial: programmers have high incomes, so they can afford to back the Patreons of products they like. But charity tends to miss the products that are so indispensable that nobody even considers the fact that someone needs to keep an eye on them. OpenSSL had an absolutely showstopping bug a few years ago. It’s used everywhere. It has 500,000 lines of code. Before the bug, its maintainers got about $2,000 a year in donations.

  • Autocratic stubbornness: This is perhaps the most sustainable model, simply because stubborn people are too stubborn to stop being stubborn. In this model, maintainers of a project filter out the vast majority of feedback and just do what they want. Since doing what they want got the project to where it was, it tends to lead to more of the same. But this doesn’t scale; the autocrats don’t play nicely with others, sometimes they make bad decisions, and they still need some kind of day job to pay the rent.

  • Auditions: One model, which was very popular in the 90s writing on open source, was that contributing to open projects was a way to advertise one’s skills and get a job. That is absolutely true—but perhaps not ideal. It’s like living in a world where every road, bridge, and tunnel is built entirely by volunteers, who do it so they can get a gig building mansions for private buyers. That world would have public infrastructure, just of uneven quality, and the most impressive bits of it would be unmaintained because the creators would have the highest opportunity cost.

  • Sponsorship: Some companies pay employees to work on open-source projects, or make large donations to such projects. They have a variety of motivations: a company that uses an obscure programming language might be limited by the number of devs who know it, so paying for things like multilingual documentation or bugfixes could have a high ROI. In other cases, the subsidy is a way to weaken a competitor: hardware companies subsidized Linux and Gnome to hurt Microsoft’s pricing power for Windows and make the hardware itself the most valuable part of the bundle.

In the end, it’s a mystery that this system works at all. The best explanation is that we’re still very early in the software story: there’s so much low-hanging fruit that we can tolerate vast economic inefficiencies as long as the work being done is on approximately the right projects. The “sponsorship” model is the one that most closely matches the underlying economics, because a sponsor will pay more to back a project if it’s more essential. On the other hand, the sponsor’s economic interest is not in building the best software for the world, but the best software for their purposes; it’s all about commoditizing the complement. So this isn’t a great option, but it’s a least-bad one.

Disclosure: I know Nadia, I got a free copy of the book from Stripe press, and I was delighted to discover—midway through reading the book and quoting the review—that the book quotes my modest proposal about COBOL.

[1] I also use Excel, which is definitely not open-source, but for heavier data analysis I prefer pandas.

Share

A Word From Our Sponsors

Here’s a dirty secret: part of equity research consists of being one of the world’s best-paid data-entry professionals. It’s a pain—and a rite of passage—to build a financial model by painstakingly transcribing information from 10-Qs, 10-Ks, presentations, and transcripts. Or, at least, it was: Daloopa uses machine learning and human validation to automatically parse financial statements and other disclosures, creating a continuously-updated, detailed, and accurate model.

If you’ve ever fired up Excel at 8pm and realized you’ll be doing ctrl-c alt-tab alt-e-es-v until well past midnight, you owe it to yourself to check this out.

Elsewhere

Household Delevering

The Fed’s quarterly report on household debt and credit is out, and debt has declined for the first time since 2014. Delinquencies are also down. The combination of large transfer payments and limited spending opportunities has basically forced households to either pay down debt (if they have any) or save more (if they don’t). So this is evidence that the recovery in consumption will be fierce when it arrives.

More Alternative Lending

A few days ago I linked to this interview with the CEO of Pipe, on turning SaaS cash flows into a financial product. There’s more competition ($), from a surprising source:

Japan’s MUFG Bank will use artificial intelligence to screen Asian startups for financing, looking beyond balance sheets to forge relationships with promising businesses who otherwise may not yet qualify for bank loans… The fund will finance e-commerce, education and health care startups. Using AI, the fund will analyze companies' bank accounts, subscription numbers, accounting data and other information to screen them for loans.

This thesis has a long way to run: interest rates are low, and subscription products turn one-time expenses into an asset with longer duration. Getting that asset off startups' balance sheets and onto the balance sheets of traditional lenders is a vast arbitrage, and as it gets more common we should see even more new subscription-based startups, especially selling to mid-sized and larger companies.

It’s Time to Build in Britain

The UK is reducing regulatory barriers to new housing. At a small scale, this is a policy tweak in a country that doesn’t build much housing (as Boris Johnson put it: “In 2018 we built 2.25 homes per 1000 people. Germany managed 3.6, the Netherlands 3.8, France 6.8. I tell you why—because time is money, and the newt-counting delays in our system are a massive drag on the productivity and the prosperity of this country.” I don’t know what “newt-counting” is, but I’m opposed.) At a larger scale, the big story is that populists usually side with current homeowners over future homeowners (i.e. they try to drive housing prices up rather than make new homes more affordable). There’s increasing evidence in the UK and US that this is changing.

Pinduoduo

I’ve been planning to write about Pinduoduo for a few weeks, but this Turner Novak post says all that needs to be said. The company has built an amazing user acquisition machine, and it’s worth $100bn five years after founding.

One thing that stands out is how well Pinduoduo uses existing companies' infrastructure to market itself. Their first big growth channel was WeChat, and it uses WeChat Pay for transactions. I’ve pointed out a few times that the fastest growth stories are not from the best companies, but from companies that have a temporary cost advantage selling a commodity adjacent to a company with a durable advantage. In any given year in the 2000s, a new SEO-driven e-commerce site would grow faster than Google did; early Zynga put up better growth numbers than early Facebook; Compaq grew faster than Microsoft. Pinduoduo actually seems to be aware of this, and is moving more of its business to its own channels, but the growth model is more fragile than it looks.

Industrial Espionage in Taiwan

A long-running hacking campaign stole “source code, software development kits, and chip designs” from Taiwanese companies, probably on behalf of China. China has gone to great lengths to develop a national chip industry, and has stepped up its efforts in the last few years in light of US sanctions. So far, it hasn’t succeeded. Chip fabrication benefits from the same “geoepistemological advantage” that Shenzehn does: the right people, with the right relationships, colocated with a huge amount of capital equipment. Some of that is easy to copy, but since all the components are complementary copying half means getting less than half the benefit. And the half-life of this knowledge is short, since chip companies keep rolling out newer processes. Still, this underscores how aggressive competition in this space is.

In what may or may not be related news, SMIC, China’s largest competitor to Taiwan’s semi fab industry, has raised its capital expenditures plans for the year.

Executive Orders

Donald Trump has signed an executive order mandating domestic sourcing for some pharmaceuticals. This is a backwards-looking plan, but prudent: one of the drawbacks to complex global supply chains is that a disruption anywhere becomes a disruption everywhere. China and India have a comparative advantage compared to the US in producing many low-priced inputs for drugs, so making them in the United States is not economically rational—unless the plan is to have a stockpile and the ability to scale up production in case imports get disrupted.

Domestic sourcing has another advantage: quality control for cheap drugs is important. The low margins mean an increased incentive to cut corners. There was a long-running scandal at Ranbaxy a few years ago, and what stood out about that scandal was not so much the quality control issues themselves as the fact that the problems—and fines—went on for years. A domestic supply chain is easier to monitor, and at least makes it possible that bad actors in pharma eventually have to stop.

Executive Orders, Con’t.

The plan to extend unemployment benefits by executive order relies on some tricky accounting games: essentially, some money has been allocated for aid to states, but not technically spent, and the executive order plans to spend it on unemployment instead. Timing matters: if Trump acts and then gets sued to reverse his actions, the money still gets spent and Congress has to deal with the consequences. It’s a very politically savvy move, since a) it’s a vast overreach of Congress' traditional role, which Congress doesn’t like at all, but b) the only way to stop it is for House Democrats to sue the President to stop him from cutting large checks to the unemployed at a time when the unemployment rate is above 10% and the election is 87 days away.

Executive Orders, Pt. 3

Yet another set of executive orders, this time banning any transaction with Bytedance or WeChat after 45 days. The WeChat addition is interesting. As Jordan Schneider has pointed out, WeChat is a much less important issue because a) it’s smaller (3m users), b) it’s mostly used to keep in touch with friends and family back in China, and c) because it’s so dominant in China, a US ban wouldn’t hurt the app much, although it would inconvenience millions of people.

In the words of one constitutional law lecturer, “[The executive branch is] not just going to be waiting for legislation. [The President has] a pen and… a phone, and [whoever is President at any particular moment] can use that pen to sign executive orders and take executive actions and administrative actions.”