Software Localism, or the Law of Two Peters

What do Pete Seeger and Peter Thiel have in common? If your answer was "nothing," read on, my friend.

A gift of a hand-knitted software app, just for you!

Pete Seeger, the noted folk singer and social activist, wrote a book about how to tell stories. It was really a tale about the virtues of making things for your friends and family, told through a folk music lens. When it came to music, Pete cared about democratization over technical perfection. Pete wanted everyone to sing and to play, and he wanted to make it easy. Pete always asked his audiences to sing along, even if they didn’t know the words. 

In the intro of his storytelling book, he says:

“Four and twenty trained singers caroling in harmony are not so effective as one parent’s voice, however out of tune. 

The world can be full of people with enough carpentry skills to make a table. Or enough sewing skills to piece a quilt. Or vocal skills to sing in a choir. Or gardening skills to grow some vegetables or flowers.

Just because we have cars and buses shouldn’t mean we forget how to walk. And just because we have books and television sets shouldn’t mean we forget how to tell stories. They needn’t be virtuoso stories. And you don’t have to look far. Tell about your family and friends. Tell about the nation’s history or a people’s history. Tell a moral tale or a silly one. Tell stories, even though they’re only the bare plot.

In the past, there was barely any software, and software was costly to build – literally *anything* was better than nothing. But now that there’s a *ton* of competition, including potentially AI-assisted competition, I see the future world as one ruled by the same law as our present world, just with meaningfully more urgency. I call it the Law of the Two Peters: 

1. Just like Peter Thiel says, by building for a small market, you minimize competition and gain a monopoly. 

2. Just like Pete Seeger says, by building a product for your own community, you create something magical. The value of the product is compounded by the value of the social connection. 

In short: build for your community to maximize the power of your social connection with the product. Tailor the product to their needs, minimize competition, gain a monopoly. Magic. 

The Law of the Two Peters has always been true, but it used to be really hard to pull off. Clay Shirky, NYU professor, describes the phenomenon of locally built software being *better* than well-built, scalable software in 2004: 

Making form-fit software for a small group of users has typically been the province of banks and research labs. We've been killing conversations about software with "That won't scale" for so long we've forgotten that scaling problems aren't inherently fatal. The N-squared problem is only a problem if N is large, and in social situations, N is usually not large. A reading group works better with 5 members than 15; a seminar works better with 15 than 25, much less 50, and so on.

This in turn gives software form-fit to a particular group a number of desirable characteristics -- it's cheaper and faster to build, has fewer issues of scalability, and likelier uptake by its target users. It also has several obvious downsides, including less likelihood of use outside its original environment, greater brittleness if it is later called on to handle larger groups, and a potentially shorter lifespan.

In November of 2002, as a project for a class on the feeling of online spaces called Social Weather, [two of my students] created an application called (alarmingly) Teachers on the Run.

Teachers on the Run was essentially HotorNot for ITP professors, to allow students to describe and rate us in advance of spring course registration. Every professor was listed in a database; students could come by anonymously and either enter a comment about a professor or cast a vote agreeing or disagreeing with an earlier comment. The descriptions were sorted in vote total order, so that a +5 description (5 more students had agreed than disagreed) was displayed higher than a +2 or a -3. And that was it -- a list of names, a list of comments, click to vote, and a simple sorting algorithm.

They launched it on a Friday. By Saturday night, another student called me at home to tell me I'd better take a look at it. There are only 200 or so students at ITP, but Teachers on the Run had already accumulated hundreds of comments, most positive, some negative, a few potentially libelous. More importantly, though, there had been over a thousand votes in 24 hours. By Monday morning, I had students telling me they knew what was on the site, not because they'd seen it, but because it had been the only topic of conversation over the weekend.

The curious thing to me about Teachers on the Run was that it worked where the [scalable] version failed. RateMyProfessors.com has been available for years, with a feature set that put the simplistic write/read/vote capabilities of Teachers on the Run to shame. Yet no one at ITP had ever bothered to use RateMyProfessors.com, though the weekend's orgy of rating and voting demonstrated untapped demand.

What (probably) made RateMyProfessors mediocre is that it missed nuanced and specific features that made Teachers on the Run (gulp!) great. Maybe there were little inside jokes that helped, or perhaps the platform had a rating system that was specific to the way professors taught at their school. It could be any number of 100 different things, but it makes the system uniquely successful.

My friend A talks about the homegrown little social networks, dating apps, and mobile games that have taken over Gunn High School in Palo Alto, since everyone in Palo Alto has been programming since birth. Every year, there’s a Gunn-specific game of Assassins using an app that is 100% local to Gunn. It can both be true that 99% of Gunn students use these apps, and that the students at the neighboring Palo Alto High School (who certainly have many, many friends at Gunn and *also* have parents who are Stanford professors and Google execs!) wouldn’t use the same thing. The product is the community. All products, social or not, take on network effects. 

Local software has a number of meaningful benefits, like fewer tradeoffs between divergent user groups and better user/builder incentive alignment. But one of the best ways that local software trumps “scaled software” is its ability to handle issues with real-world solutions. Some of the problems of software are internet anonymity and scale issues. With local software, that’s not a problem. One particularly magical example is the handling of fraud – in Shirky’s class, any bad actor on the platform would have their name and LDAP posted on the department bulletin board. Local software can combine the best of the real world and the Internet. 

What’s prevented more local software from blooming, especially if the Law of the Two Peters is the best way to resist competition? It’s mainly the cost of writing apps. I think we need to make it possible for groups other than Stanford professor’s children and elite university students to have software that feels entirely customized to them. Once more groups are given that option, I think we’ll see it soar to success. 

What needs to be true to make that happen? I think the following: 

1. The cost of the actual “tool building” has to go down, meaningfully. 

   The entire “no code” movement attempts to make building software easier, but it’s still not enough. Software engineering is still incredibly costly. To make this movement possible, you need a few builders in almost every community who have access to low cost and accessible tools.  These builders need minimal constraints: they cannot be limited to making Airtable forms or Notion documents. They should be able to make everything from social games to SaaS apps. Some people believe that AI will make it possible to build average quality apps with natural language instruction – if that’s the case, great, it’ll be useful! 

2. Prime the pump of imagination. 

   The hardest part of software is figuring out what to make (says the PM.) It’s hard to think of great tool ideas from scratch. Most builders need a few recipes or guides to get them going. Perhaps they have a sense for a unique twist on an existing app, but want the template of the existing tool to work from. Perhaps they only can remember a specific edge case or two they want fixed. Pete Seeger often encountered this with stories and songs – his primary suggestion was to make it simple to remix everything. One of his best examples was a popular Japanese folktale about a magic salt cellar. He was able to spread the tale virally throughout the US…by changing the salt cellar to a pot of ‘oatmeal’ or ‘grits.’

3. New funding models that allow for more “mom and pop” software shops 

   VC funding means that companies need to grow like crazy. It doesn’t make sense unless there’s the potential of a 10B+ outcome. But local software doesn’t usually come with a $10B outcome. SMB software will need new types of funding, the same way that the new bookshop on your block probably required a loan. In our ZIRP days of yore, I think we saw a number of potential alternatives like Pipe or Clearbanc flourish. Since interest rates have climbed, the best potential alternative looks like software coops funded by angel investors. Rocicorp is a small software shop that expressly does not aspire for venture scale. The business is self-sustaining, but was initially funded by a set of angels. The business is an LLC with members, aka “partners” with employees acting as junior or senior partners in the firm. Here’s how they explain the firm to potential candidates.

Every Thanksgiving, my mom used to make sweet potato curry, which is exactly the same thing as potato curry, but made FESTIVE. I can imagine a future like that, where little twists on software tools are lovingly gifted to communities. I want a world where my friends send me little apps they make, and I do the same, just like playlists and handknit sweaters. SF residents do buy most of our software from local businesses (lol) – it’d be great if the rest of the world could, too.