diff --git a/content/blog/growth-as-a-function-of-social-utility.md b/content/blog/growth-as-a-function-of-social-utility.md
new file mode 100644
index 0000000..6261153
--- /dev/null
+++ b/content/blog/growth-as-a-function-of-social-utility.md
@@ -0,0 +1,48 @@
+---
+title: Free software grows as a function of social utility
+date: '2022-08-06'
+---
+
+A frequent complaint I see from users and inexperienced contributors
+concerning free software projects is that they are allegedly not doing
+enough to grow the userbase, sometimes even asserting that a fork is
+necessary to right the course of the project.
+
+Are these complaints missing the point, or do they have merit?
+How do free software projects grow their userbase into thriving
+communities?
+
+In general, these complaints go something like this:
+
+> [PROJECT] developers have explicitly said they do not want the
+> project to grow.  The [PROJECT] is its own worst enemy, and this
+> is just the latest example of it I've seen.  I don't trust the
+> direction of [PROJECT], and neither should you.
+
+The experienced maintainer understands that we must play the long game,
+not the short game.  Tactics such as *embrace, extend, extinguish*
+are largely only effective when maintainers are looking at the short
+term picture.  This is because organic growth in the use of a free
+software package is a function of that package's social utility: a
+software package which provides utility to its community will experience
+growth in adoption because its users will recommend that others try
+the software package and join the project's community.
+
+The social utility of a given software package is not necessarily
+tied to mass-market adoption.  It is possible for a software package
+to be extremely popular in a tight-knit community, while holding
+very little social utility for the mass-market, and this is totally
+fine.  In fact, this is the case for most software packages which
+exist in the world.
+
+Likewise, it is possible to pursue new feature development as a
+gamble on obtaining mass-market adoption, and destroy the social
+utility of the product for its current userbase.  An experienced
+maintainer will recognize that such gambles rarely pay off, and
+usually wind up damaging the project rather than growing it.
+
+Unfortunately, society teaches us that we should grow at any cost,
+which means that inexperienced maintainers can be swayed by such
+arguments to make harmful decisions to their project.  But if we
+recognize that these types of arguments are inherently defective,
+we can help maintainers to avoid taking them seriously.