But, is this really true?

I often recite this quote when the subject of seat belts comes up:

“Seat belts don’t save lives, they just make the bodies easier to find.”

Let’s start by looking at some data. Here’s the motor vehicle deaths in U.S. by year according to Wikipedia. I’ve created a Google sheet with the data, in order to visualize it. Here’s the graph:

I’ve called out 3 important dates in the graph, with colored symbols.

The left-most marker, the purple triangle, is the year 1958. This was the first year when Saab included seat belts as standard in its vehicles — prior to this, they were available as an option by Ford and others.

The middle marker, the orange square, is the year 1968. This was the year the law requiring safety belts in all vehicles signed by President Johnson.

The right-most marker, the red star, is the year 1984, when New York signed mandatory seat belt use into law. There is no federal law requiring seat belt use, and even today, there is no primary or secondary law in New Hampshire requiring adults wear seat belts in any seat.

These dates are interesting because they are pivotal points in time where we would naturally expect inflections in the graph that correlate to seat belts, if seat belts have a causative effect on motor vehicle fatalities. But, as you can see from the graph, there do not appear to be any. Are seat belts really saving lives?

Maybe the effect of seat belts is so subtle, it wouldn’t be easily detectable in a coarse graph of fatalities by year. What if we take a really close look at the data?

According to the NHTSA, they report:

“Of the 37,133 people killed in motor vehicle crashes in 2017, 47% were not wearing seat belts. In 2017 alone, seat belts saved an estimated 14,955 lives and could have saved an additional 2,549 people if they had been wearing seat belts.”

What? How do you go from “47% were not wearing seat belts” to “[… seat belts] could have saved an additional 2,549 people […]”?

Just think about this for a moment: if 47% were not wearing seat belts, that means 53% were — and still died. Looking at this simply, for every 100 people who died in a car accident, 47 were unrestrained while 53 were wearing seat belts. More people who died were wearing seat belts than not. Period.

How do you make the leap from the fact that more people die while wearing seat belts to “more lives could have been saved if more people wore seat belts”? I don’t think that’s how it works.

Perhaps the decline in overall deaths by motor vehicles over the years isn’t attributable to seat belt use. Maybe it’s largely driven by safer motor vehicle designs, advances in safety technology, more reliable manufacturing processes, etc., that simply result in safer motor vehicles. But, the data doesn’t seem to support the statement that “seat belts save lives” when more deaths involve people wearing seat belts than not.

Of course, I’m going to continue wearing my seat belt: in New Jersey, it’s the law. But, I’m not doing it because it’s actually safer, at least not according to the data.

May 2025 Update: I’m honestly surprised that I didn’t get completely dog-piled telling me all the ways I was wrong, as per usual on the Internet.

As an experiment, I asked ChatGPT o3 to tell me why I was wrong, and it did a fantastic job:

ChatGPT - Seat Belt Effectiveness Analysis

Bottom line

Your headline question has a clear empirical answer: seat belts do save lives, cutting a belted person’s chance of dying in a crash roughly in half.

The apparent contradiction you spotted (more belted than unbelted deaths) vanishes once you account for the fact that almost everyone now wears a belt, so they dominate the pool of crash victims. The statistical frame — not the seat belts — was the issue.

Since I couldn’t find a good list of EX raid eligible gyms in northern NJ, I decided to start one, especially since it seems like Niantic sent out EX raid invites today, August 17th, and people are posting their invites.

The list:

• Vander Sande Field (Rochelle Park)
  + August 25 @ 4:30 PM — 5:15 PM
• Nutley Memorial Parkway (Nutley)
  + August 18 @ 1:00 PM — 1:45 PM
• Tennis Court (Ridgefield Park)
  + August 25 @ 4:00 PM — 4:45 PM
• Find shiny deals at Sprint (Union City)
  + August 25 @ 1:00 PM — 1:45 PM
• Rotary Memorial Gazebo (Rockaway)
  + August 25 @ 3:30 PM — 4:15 PM
• Parsippany Veteran’s Memorial Park (Parsippany)
  + August 25 @ 5:30 PM — 6:15 PM
• Eternal Flame War Memorial (Roxbury Township)
  + August 18 @ 1:30 PM — 2:15 PM
• Morristown World War I Memoria (Morristown)
  + August 18 @ 12:00 PM — 1:15 PM
• Michael O’Brien Memorial (Morris Plains)
  + August 25 @ 3:00 PM — 3:45 PM
• Jared Percevault Well (Succasunna)
  + August 25 @ 3:00 PM — 3:45 PM
• Edward J. Macksoud Memorial Entrance (Ridgewood)
  + August 25 @ 1:00 PM — 1:45 PM
• Rotary Park Playground (Park Ridge)
  + August 25 @ 12:00 PM — 12:45 PM
• Westwood Town Gazebo (Westwood)
  + August 25 @ 3:00 PM — 3:45 PM
• Historic New Bridge Landing (River Edge)
  + August 25 @ 1:00 PM — 1:45 PM
• Edreich Family Memorial Bench (Rochelle Park)
  + August 25 @ 1:00 PM — 1:45 PM
• The Longo Family Memorial Bench (Rochelle Park)
  + August 25 @ 1:30 PM — 2:15 PM
• The Wall of Harmony (River Edge)
  + August 25 @ 1:00 PM — 1:45 PM
• Tree of Peace (River Edge)
  + August 25 @ 4:30 PM — 5:15 PM
• To Honor the Men and Women of Maywood Who Served Our Country during World War Two Memorial (Maywood)
  + August 25 @ 5:30 PM — 6:15 PM
• The Campbell Christie House (River Edge)
  + August 18 @ 6:00 PM — 6:45 PM
• In Loving Memory of Doris Messmer Jay Dederick (Leonia)
  + August 25 @ 11:30–12:15 PM
• Tennis Court (Ridgefield Park)
  + August 25 @ 4:00 PM — 4:45 PM

If you’re not sure what an EX raid is, or want to learn more about them, iMore.com has a thorough write-up on what they are, strategies for doing them, and other useful information about them.

If you got an EX raid invite that isn’t on this list, leave a comment with a screenshot of the invite and I’ll update the list. Thanks!

There’s a few very good reasons why we may want to build PHP’s curl module using OpenSSL and not Apple’s Secure Transport, such as needing to use PEM format client certificates or wanting to use HTTP/2, for example.

Up until March 2018, this was pretty straightforward to do: you would brew install curl --with-openssl and brew install php72 --with-homebrew-curl and that was it. Slightly inconvenient, but easy. 👍

In their quest to “improve” things by rendering inconvenient but easy things into the downright impossible, the Homebrew maintainers moved the PHP formula from the homebrew-php tap to the homebrew-core tap.

“Sounds harmless,” you might think? Sure, except they didn’t simply move the formula as-is. They changed it in significant ways, including removing the ability to control how PHP’s modules are built. 😡 This means you no longer have the ability to control whether PHP’s curl module is built against the system-provided libcurl library which uses Apple’s Secure Transport, or Homebrew’s libcurl library built against OpenSSL, depending on your preference or needs.

This effectively prevented me from being able to upgrade to a newer PHP using Homebrew’s PHP formula. 😢

Checking StackOverflow, I’m apparently not alone. Since I had a personal need to get PHP 7 installed using this new version of the Homebrew PHP formula on my dev environment, I needed to solve this problem for myself.

Good news: I have a working solution. Let me tell you the story of my people …

I’ve modified the php.rb formula to build PHP against the Homebrew-installed libcurl which you’ll still need to install with brew install curl --with-openssl after installing Homebrew’s OpenSSL with brew install openssl.

build against homebrew curl, openssl · dossy/homebrew-core@b75fe28

To apply it, do this:

$ cd /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core
$ curl -s https://github.com/dossy/homebrew-core/commit/b75fe286f79e2b89548c5ed1bbe1958313c5c103.patch | patch -p1

Depending on what changes the Homebrew folks make to the php.rb formula between now and when you go to apply this change, it may or may not apply cleanly. I may update the patch periodically, if my change doesn’t make it into the upstream official repository.

Updated 2018–11–07: I’ve created an updated patch against Homebrew’s current php.rb which is for PHP 7.2.11. Use this instead:

$ curl -s https://github.com/dossy/homebrew-core/commit/d0681b61.patch | patch -p1

Once you’ve applied the patch, you’ll need to force an install from source rather than using the precompiled “bottled” binary:

$ brew install php --build-from-source

Depending on your system, this could take a while. But, it should work. When it’s done, you can confirm whether it’s using the correct libcurl and openssl with this command:

$ /usr/local/bin/php -r "var_dump(phpversion(), curl_version()['ssl_version']);"
string(5) "7.2.6"
string(14) "OpenSSL/1.0.2o"

If it didn’t work, instead of OpenSSL/X.Y.Zn you’ll see SecureTransport or LibreSSL. If that happens, something went wrong. Crying at this point wouldn’t be inappropriate nor a terrible idea. Once you’ve regained your composure, double-check your work and if you still can’t get it to work, let me know and maybe I can help you.

For those of you who experienced success, congratulations! I hope this was helpful and saves you a bunch of time and aggravation. I know I sure would have appreciated it …

Installing PHP 7.2 using Homebrew on OSX using OpenSSL and not Apple's Secure Transport was originally published in This Old Code on Medium, where people are continuing the conversation by highlighting and responding to this story.

The site was experiencing some pretty bad page execution times, often upwards of 11 seconds, which was most noticeable in the WordPress admin area. With the help of the WP Super Cache plugin, once pages were rendered and cached, requests were pretty reasonable, although still a bit on the slow side, a full page load taking around 2.7 seconds. Here’s a GTMetrix performance report before I started:

Right away, I noticed that the SmugMug Embed plugin he was using was trying to embed some files that didn’t exist, resulting in HTTP 404 responses. Unfortunately, these requests won’t get cached, and given the slow page execution times, would take up to a few seconds to generate the 404 page and respond to the requests. I modified the plugin to no longer reference these missing files. This cut down on the overall amount of time the server spent executing code to serve the page.

Another source of unnecessary page execution time came from his use of the Quick Page/Post Redirect Plugin to redirect a few canonical URLs to their desired locations. Again, each of these requests required the entire WordPress machinery to execute, just to return a 301 or 302 HTTP redirect — that’s a lot of overhead for something extremely simple. Since Andy’s a programmer, editing a text file is something he’s very comfortable doing, so we moved the redirects into his .htaccess file, eliminating all that unnecessary processing time.

WordPress provides a task scheduling mechanism called WP-Cron, which by default uses a slice of the page execution time to determine if there’s a task that needs to be executed, and kicks it off by making an HTTP request back to itself to run the task in a separate execution thread. For lightweight sites with a simple theme and only a few plugins, this is perfectly fine. For a site that’s already heavy, this can be considerable overhead. Fortunately, WordPress provides an alternative: disable this behavior and use an alternate scheduling mechanism, such as the operating system’s task scheduler, to kick off the same HTTP request. We went ahead and did that.

Andy’s site also the Jetpack by WordPress.com plugin, which offers a bunch of different and useful functionality, but it’s a take-it-or-leave-it kind of proposition, all of its functionality is bundled together. While you can turn parts of it on or off through its settings, all of its code still gets read in, even if you’re not using it all. Unfortunately, Jetpack Sync is part of that kitchen sink, and it’s not obvious to me how to disable it or turn it off. This was an issue for us because it, too, makes outbound XML-RPC API requests during the page execution to https://jetpack.wordpress.com, even though it should be using the WP-Cron machinery. I didn’t dig too deeply into this, since deactivating the plugin wasn’t an option, so we just have to live with this, but it’s something to be aware of if doing a performance optimization of a WordPress site that doesn’t really need to use the Jetpack plugin.

Speaking of having all that code to read in and parse, there’s another kind of cache that we can leverage to reduce the amount of time we have to spend reading and parsing the same code: the Zend OPcache. This extension is now bundled with PHP as of 5.5, but Andy’s hosting setup is still on 5.4, so I went ahead and installed the extension. I went with the default settings because they’re a good place to start, and can be tuned if and as needed later on. Using the OPcache should significantly improve the page requests that aren’t cached by WP Super Cache, as well as the WordPress admin interface.

Moving onto the actual page size, we can see it’s clocking in at a whopping 2.06 MB across 153 requests. Here, we were able to leverage Google’s PageSpeed Module, specifically, mod_pagespeed for Apache 2.4, to do a bunch of rewriting and optimization of the WordPress-generated HTML, JavaScript and CSS. It took a fair amount of experimentation to come up with the set of filters that yielded the results I wanted, but eventually I was able to achieve a 59.9% reduction in page size, reducing it down to 826 KB, a savings of 1,223 KB from 2,060 KB, with 18.3% fewer requests, 125 instead of 153.

In addition to all of this optimization work, we took the opportunity to reconfigure the site from HTTP to HTTPS, since Google has leveraged its considerable marketshare of its Chrome browser to encourage folks to make the change through clever social engineering: Beginning in July 2018 with the release of Chrome 68, Chrome will mark all HTTP sites as “not secure”. We decided to use a free SSL certificate from LetsEncrypt. Unfortunately, there were a few plugins that needed to be adjusted to embed their resources via HTTPS URLs to avoid the “mixed content” security warnings, so that we could get the green “Secure” padlock to display in the browser.

After all this work, here is what the GTMetrix report looks like:

You’ll immediately notice the improvement in the Performance Scores, from what were previously F grades for both PageSpeed and YSlow, to now C and D, respectively. While it would be great to get both of those up to an A, it’s unfortunately not possible, since the remaining significant contributors to the score are external resources which we have no control over, such as display ads and social sharing widgets.

What you might notice is that our Time-to-First-Byte (TTFB) has actually gotten “worse,” increasing from 190 milliseconds to 449 ms. That’s to be expected since the PageSpeed Module is doing a bunch of work, parsing the response and rewriting it. Despite the slightly longer TTFB, you’ll see that our paint times are around 100 ms faster, our DOM phase is around 300 ms faster, and the onload event fires a full 1.1 second sooner. While the report shows the Fully Loaded Time difference as only 0.5 seconds, from 2.7 sec to 2.2 sec, this 44% improvement in the onload time has a significant impact on a user’s perception of the page load, since the user can now interact with the page a full 1.1 sec sooner.

Granted, these kinds of results aren’t exactly typical, since every site’s needs are different and the mix of theme, plugins and hosting environment can have a significant impact on the overall page execution time and user experience. However, the process and approach to optimizing a WordPress website is repeatable and when you know what you’re looking for, you can achieve great results.

Are you struggling with performance issues with your WordPress website? Have you or others tried to optimize your site and left you wondering if it could be even better? Get in touch with me and I’ll perform an initial evaluation of your WordPress website for free and let you know what I can do to help.

First, let’s start with a quick quiz. Given the following SQL and pseudocode, how many rows do you expect will be affected?

/* Using MySQL 5.6.23 */

CREATE TABLE t (
    x VARCHAR(32),
    y INT
);

INSERT INTO t (x, y)
VALUES ('a', 1), ('b', 2), ('c', 3);

$value = 'b';

$statement = $db->prepare('UPDATE t SET y = 123 WHERE x = :value')
$statement->bind(':value', $value)
$statement->execute()

If you answered 1, then congratulations: you’re right. Easy, right?

So, what’s the issue with using boolean values?

Using the same SQL, but with this slight change in the pseudocode, how many rows do you expect will be affected?

$value = false;

$statement = $db->prepare('UPDATE t SET y = 123 WHERE x = :value')
$statement->bind(':value', $value)
$statement->execute()

If you answered 0, then you, like me, are wrong.

“But, no row in the table has a value for x that equals false, so how can this be,” you ask?

Here is where you, and I, learn how wrong we are.

The answer is: type coercion (aka “implicit type conversion”).

More specifically, it has to do with MySQL’s BOOLEAN type, and how it’s implemented:

BOOL, BOOLEAN

These types are synonyms for TINYINT(1). A value of zero is considered false. Nonzero values are considered true:

Are you thoroughly confused now? Good, you should be. That was a mouthful of gibberish.

While the documentation is perfectly clear and succinctly explains the situation, it might be non-obvious as to why we observed what we saw.

(Oh, and don’t get me started about how “gibberish” is spelled wrong based on how it’s commonly pronounced: it should be spelled “jibberish.” But, anyway…)

Under the hood, MySQL implements BOOLEAN types as TINYINT(1) values, and more specifically, where TRUE is 1 and FALSE is 0. Okay, fine, but still, no value of x in our table was equal to 0 … or, were they? 😈

This is where type coercion comes into play: when comparing a string, in this case, our x which is defined as VARCHAR(32), with a BOOLEAN value, in other words, a TINYINT(1) value of 0, exactly what happens? Let’s see:

mysql> SELECT CAST('a' AS UNSIGNED) AS a,
              CAST('b' AS UNSIGNED) AS b,
              CAST('c' AS UNSIGNED) AS c;
+---+---+---+
| a | b | c |
+---+---+---+
| 0 | 0 | 0 |
+---+---+---+
1 row in set, 3 warnings (0.04 sec)

mysql> show warnings;
+---------+------+----------------------------------------+
| Level   | Code | Message                                |
+---------+------+----------------------------------------+
| Warning | 1292 | Truncated incorrect INTEGER value: 'a' |
| Warning | 1292 | Truncated incorrect INTEGER value: 'b' |
| Warning | 1292 | Truncated incorrect INTEGER value: 'c' |
+---------+------+----------------------------------------+
3 rows in set (0.04 sec)

Oh, damn. MySQL, in its effort to be helpful and “user friendly,” will quietly, but not silently, as evidenced by the warnings, transform our string values into integer 0 values. So, how many rows would be affected? All 3 of them!

mysql> UPDATE t SET y = 123 WHERE x = FALSE;
Query OK, 3 rows affected, 3 warnings (0.00 sec)
Rows matched: 3  Changed: 3  Warnings: 3

Interestingly enough, if we had made a similar “mistake” and used NULL instead of FALSE, the outcome would have been more in line with our expectations:

mysql> INSERT INTO t (x, y) VALUES (NULL, 4);
Query OK, 1 row affected (0.00 sec)

mysql> UPDATE t SET y = 123 WHERE x = NULL;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0

This is because, in SQL, nothing “equals” NULL. Values can be NULL, but NULL is never equal to anything, even NULL. To compare values to NULL, SQL provides the IS NULL and IS NOT NULL operators for this very purpose:

mysql> UPDATE t SET y = 123 WHERE x IS NULL;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> UPDATE t SET y = 123 WHERE x IS NOT NULL;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 3  Changed: 0  Warnings: 0

Conclusion

Even in strongly typed languages like SQL, conveniences like type coercion can create dangerous pitfalls. Imagine if that was a DELETE statement instead of an UPDATE statement — poof, there go all your rows where the key’s resulting type conversion results in a 0 value.

Have you been hurt by accidentally using a boolean value in a MySQL query and affected more rows than you intended? Share your stories in the comments below. It’s okay, you’re not alone.

Did you learn something from this post? Share it with your friends and colleagues who might benefit from it, too!

How using boolean values in SQL can lead to unintended results was originally published in This Old Code on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve been examining different unit testing framework options, and I decided to do a basic weigh-in: see how much each one “weighs” in bytes with all their dependencies. I chose five of the more popular options out there today: Jasmine, Jest, Karma, Mocha, TAP.

Here’s how I weighed them:

$ mkdir weigh-in
$ cd weigh-in/

$ npm_config_prefix=$(pwd) npm ls -g
/Users/dossy/Desktop/weigh-in/lib
└── (empty)

$ npm init -y
Wrote to /Users/dossy/Desktop/weigh-in/package.json:

{
  "name": "weigh-in",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "description": ""
}

$ for i in jasmine jest karma mocha tap; do npm_config_prefix=$(pwd) npm i $i --no-save --no-package-lock; mv node_modules node_modules.$i; done
npm WARN weigh-in@1.0.0 No description
npm WARN weigh-in@1.0.0 No repository field.

+ jasmine@2.8.0
added 14 packages in 1.057s

> fsevents@1.1.2 install /Users/dossy/Desktop/weigh-in/node_modules/fsevents
> node install

[fsevents] Success: "/Users/dossy/Desktop/weigh-in/node_modules/fsevents/lib/binding/Release/node-v57-darwin-x64/fse.node" already installed
Pass --update-binary to reinstall or --build-from-source to recompile
npm WARN weigh-in@1.0.0 No description
npm WARN weigh-in@1.0.0 No repository field.

+ jest@21.2.1
added 486 packages in 40.777s

> fsevents@1.1.2 install /Users/dossy/Desktop/weigh-in/node_modules/fsevents
> node install

[fsevents] Success: "/Users/dossy/Desktop/weigh-in/node_modules/fsevents/lib/binding/Release/node-v57-darwin-x64/fse.node" already installed
Pass --update-binary to reinstall or --build-from-source to recompile
npm WARN weigh-in@1.0.0 No description
npm WARN weigh-in@1.0.0 No repository field.

+ karma@1.7.1
added 296 packages in 16.364s
npm WARN weigh-in@1.0.0 No description
npm WARN weigh-in@1.0.0 No repository field.

+ mocha@4.0.1
added 24 packages in 1.99s
npm WARN weigh-in@1.0.0 No description
npm WARN weigh-in@1.0.0 No repository field.

+ tap@10.7.2
added 338 packages in 17.905s

Any guesses as to how much each of these packages weigh? See if your guesses line up with their actual weights:

$ paste -d '#' <(du -s node_modules.*) <(du -sh node_modules.*) | sort -nk 1,1 | cut -d'#' -f2
856K node_modules.jasmine
2.2M node_modules.mocha
 34M node_modules.tap
 35M node_modules.karma
 54M node_modules.jest

Jasmine’s the lightest at 856 KB followed by Mocha at 2.2 MB, and Jest is the heaviest at 54 MB, with TAP and Karma a close second at 34 MB and 35 MB.

Obviously, weight is only one dimension to consider. But, I hope more people start making it part of their selection process. I know choosing between packages that provide similar functionality and capability, I will certainly favor the one that’s lighter.

JavaScript unit test framework weigh-in was originally published in This Old Code on Medium, where people are continuing the conversation by highlighting and responding to this story.

So, earlier this evening I said I was going to start streaming, and rather than let procrastination get in the way, I decided to just pull the trigger before I changed my mind: I did my first live stream tonight.

I didn’t know what I was going to do, or even if I had everything set up right — the stream starts with me figuring out how to get my earbud’s mic audio working — but I think I managed to get it all working!

I was also incredibly lucky that someone decided to come check out the stream: thank you so much, will_50, for joining me this evening. You made it an incredibly rewarding experience for me, and I’m really looking forward to doing this again!

It’s late, I’m tired, but I wanted to get this out there to memorialize this event. I’m really looking forward to learning how to improve, both as a streamer and as a developer, through this process.

Come follow me on Twitch and watch me stream. I’d love to hear from you!

There’s a first time for everything was originally published in This Old Code on Medium, where people are continuing the conversation by highlighting and responding to this story.

I still think it was a good idea, but 2007 was definitely not the right time. Fast forward to today, 10 years later, and people are live-streaming all kinds of things, here on Facebook, on YouTube, and especially Twitch.

I think it’s finally time. I’m going to start live-streaming myself working on open source projects and basically any non-private/non-client work, and have a go at it. If you’re interested, head on over to my Twitch channel follow it to get notifications of when I’m streaming.

https://twitch.tv/dossy

Obviously, it’s going to be really rough in the beginning, but I’m really excited about being able to finally do this. Hope to see some of you there!

ThisOldCode.tv was originally published in This Old Code on Medium, where people are continuing the conversation by highlighting and responding to this story.

Yes, the “New from your network” view has ONE post, and of course it’s a Benjamin P. Hardy post, natch. Where’s all the rest of the content? Why can’t I just scroll down to see the older stuff, like in my old feed? If I click on the “People” or “Publications” tabs, I do get more content, but I don’t want to have to click back and forth between tabs just to see newly posted stuff — isn’t that what “All” means, in English?

Medium has apparently pivoted from what could have been an amazing LiveJournal 2.0, where I could follow a river-style timeline of quality posts that I can curate by controlling who I follow … to … I don’t even have words to describe it. All I know is that in this new Medium 2.0, “All” means Benjamin P. Hardy, and that’s it.

Medium just took away the old newsfeed functionality from all of us and have forced us into this new one. I was hoping that they were split testing the old vs. new, and the data would prove out that engagement and daily uniques on the new feed would show it was a mistake, but I guess I was wrong, or they are just ignoring the data and are moving forward with this new approach regardless?

Am I alone in feeling this way about the new feed? Was I the only user who opted to keep the old feed when given the choice, and now I’m the only one who finds the new feed a horrible user experience?

If this were a members-only post, this is where you’d stop reading… unless you were lucky enough to be part of the limited members program AND were willing to pay whatever the fee is.

But, lots of content providers monetize content with a paywall successfully, right?

I suppose. AOL made millions with their “walled garden” approach to access to content. But, that was the 1990s, where you could still make money simply selling access. In modern times, however, even one of the bastions of Old Media, the New York Times, who has traditionally employed a paywall, has abandoned that outdated practice.

Well, people love Medium and its content enough to pay, so why not?

Because there are better ways to monetize the value that Medium has built in ways that benefits everyone involved: the readers AND the writers.

Generally, when you believe your value is your content, monetizing that value means restricting access to it: paywalls. But, what if I told you that Medium’s actual value isn’t the content at all?

Medium built an excellent platform to enable writers to create beautiful content easily, and for readers to discover, follow and consume that content enjoyably. They’ve successfully displaced many contenders (I wouldn’t go so far as to say “disrupted”) in the space occupied by classic content management systems and web publishing platforms like WordPress and Drupal and Joomla, simply by building a better mousetrap. That beautiful relationship that Medium was able to create between writers and readers has enabled them to accumulate a wealth of content. Some of it is even pretty good… ;-)

To stop here and see the content as value is so short-sighted, though. The value is that relationship that Medium has been able to facilitate and grow. Monetizing the content means putting an obstacle between the reader and the writer, interfering with that relationship. Monetizing the relationship, giving the writer more options for creating and distributing their content and ways for them to monetize their content, and giving the reader more options for consuming and enjoying that content, is win-win-win for Medium, their writers, and their readers.

In short: Medium should look to displace (or, even disrupt) the classic publisher model.

Medium has elegantly solved the problem of building a platform for writers and readers in the web space. But, there’s lots of other channels for content that content creators want to reach and audiences want to consume: e-books, physical books, audiobooks. These are channels that traditional publishers, agents, and commerce marketplaces (Amazon, Barnes & Nobles, Audible, etc.) control, and for content creators to get their content into those channels means leaving Medium for those things. Medium can change that, and I think they should.

Medium could build the necessary platform for its existing writers to be able to create or modify their content and publish them to those other channels. Instead of charging writers for that privilege, Medium could establish a revenue-sharing model, which is again win-win, aligning Medium and content creators goals instead of orienting Medium in a position of trying to extract the most money from the subset of writers who would be willing to pay for such a service. In a revenue-sharing model, writers and Medium benefit when more content is consumed by the audience — and, not ads, but the content.

Medium could then focus on helping writers by increasing their distribution, figuring out ways to get their content in front of the right consumers in the audience, and facilitating the valuable relationship they’ve already built between the two.

Medium could build even better experiences for audiences looking to discover, access and consume content across those various channels, with all of the great features that the platform provides for web content: highlighting, annotations, sharing, commenting, etc. They could even create new ways for consumers to interact with the content and their authors, furthering that valuable relationship.

The possibilities are really endless when you take an approach that looks to continue to improve the real value that Medium has accumulated, instead of putting obstacles in the way, like a paywall.

Look, I know I’m just some nobody on the Internet with wild ideas and no real successes to my name, so maybe I’m wrong about all of this. But, it’d really make my day if Ev Williams saw this, and replaced Medium’s membership paywall approach with what I’ve suggested. It’s not like I could really take credit for being the catalyst for that change — after all, he’s the successful one, and if this is the direction Medium does eventually go in, he probably had the idea before I did — but in my mind, I’d like to pretend like it was because of me and this post… ;-)