Y Combinator has apparently decided not to. President Sam Altman defended this position in a blog post, framed as a Clinton endorsement, that begins with a partial overview of how reprehensible and dangerous Trump is, but ends with a defense of continuing Thiel’s involvement in Y Combinator that’s effectively framed as a free-speech or tolerance issue:
Some have said that YC should terminate its relationship with Peter over this. But as repugnant as Trump is to many of us, we are not going to fire someone over his or her support of a political candidate. […]
The way we got into a situation with Trump as a major party nominee in the first place was by not talking to people who are very different than we are. […]
That kind of diversity is painful and unpopular, but it is critical to health of a democratic and pluralistic society. We shouldn’t start purging people for supporting the wrong political candidate. That’s not how things are done in this country.
Altman’s framing of Thiel’s Trump support as a diversity issue isn’t just incorrect — it’s a harmful distortion that reveals a deep misunderstanding of the tech industry’s actual diversity issues. (I don’t and can’t fully understand our diversity problem, but I at least won’t pretend to.)
To help illustrate why, here are some of Altman’s own words from the first half of that same post:
This election is exceptional. Donald Trump represents an unprecedented threat to America…
He represents a real threat to the safety of women, minorities, and immigrants…
Trump shows little respect for the Constitution, the Republic, or for human decency…
I do not understand how one continues to support someone who brags about sexual assault, calls for a total and complete shutdown of Muslims entering the US, or any number or other disqualifying statements.
Wrapping reprehensible statements or actions as “political beliefs” doesn’t protect them or exempt their supporters from consequences. Racism is racism. Sexual assault is sexual assault. Labeling reprehensible positions as “political beliefs” is a cowardly, meaningless shield.
But even if such protection existed (it still doesn’t), this isn’t calling for someone to lose their job because they merely voted Republican — the scale of Thiel’s support and the conditions of this particular candidate matter.
Thiel, a non-employee (a “part-time partner”), is directly supporting Donald Trump at a massive scale — over a million dollars! — after we’ve learned even more of Trump’s horrendous statements, positions, and past actions than we could’ve ever imagined.
This isn’t voting for an economic or social policy — this is literally paying a huge amount of money to directly support a racist, sexist bigot with rapidly mounting allegations of multiple sexual assaults.
One more quote from Altman:
If Peter said some of the things Trump says himself, he would no longer be part of Y Combinator.
Funding Trump, especially at this scale, represents general support of what Trump has said and done. If saying what Trump said would be enough to override Altman’s “diversity” argument and sever ties with Thiel, giving over a million dollars to Trump’s campaign should qualify as well.
Y Combinator should be especially sensitive to diversity and inclusion issues due to its public presence and large influence in the technology business. We have so many diversity and hostility problems (that the industry is finally working to fix) that Y Combinator should be leading the way toward inclusive, progressive solutions.
Instead, they’re defending the large-scale support of racism, bigotry, and sexual assault by an influential partner and advisor to their startups as its own form of “diversity”.
Last week, Apple terminated the developer account of one of my favorite Mac apps, the Dash documentation viewer for programmers, for alleged App Store review manipulation.
Dash is a great app that many Mac and iOS programmers use (and that needs no help getting positive reviews), and developer Bogdan Popescu insisted he’d never engaged in such fraud. Since Apple has a history of controversial App Store decisions that often get reversed after public scrutiny, many developers (including me) came to his defense last week, assuming that someone at Apple had made a mistake, and yelled on Twitter for Apple to reconsider or provide more concrete justification. Michael Tsai has a good overview with more links.
Almost 1,000 fraudulent reviews were detected across two accounts and 25 apps for this developer so we removed their apps and accounts from the App Store. Warning was given in advance of the termination and attempts were made to resolve the issue with the developer but they were unsuccessful. We will terminate developer accounts for ratings and review fraud, including actions designed to hurt other developers. This is a responsibility that we take very seriously, on behalf of all of our customers and developers.
This isn’t enough proof for some, but it’s enough for me. (Some quicksearches support Apple’s position, if you’re still unconvinced.)
Like any controversial decision involving people’s livelihoods, Apple probably needs to be careful to avoid potential legal issues, and it would be in poor taste for a huge company to sling more mud than necessary in public against a tiny opponent.
I’m glad our community assumed the best of another developer and pressured Apple to justify this severe action. We should now accept that they have.
The public often doesn’t get the full story behind decisions and changes they see, but it’s usually not for sinister reasons — it’s often just someone taking the high road and letting another party save face.
Bogdan Popescu responded with his side of the story and a recording of a phone call from Apple (without their consent, which is illegal in California, but apparently not in Romania). In summary, he bought another developer account for a relative with his credit card and using his old test devices, which made Apple’s fraud team consider them the same entity (seems reasonable), and that account engaged in the fraud.
His post makes Apple sound pretty bad. But if you listen to the call (which I was torn about whether to do), it’s clear that Apple was being incredibly reasonable and going above and beyond to help him get reinstated and clarify what happened in a public statement, but Popescu didn’t seem to agree with Apple regarding the wording of key facts.
We don’t know what happened between that call and Apple’s statements tonight. I’m guessing Popescu and Apple couldn’t reach an agreement over the wording of the public story, but I think what Apple asked for in that phone call was extremely reasonable.
It’s also notable that Apple investigated this and tried to resolve it as well as they did. If it were any other company — say, Google for a suspended AdSense or YouTube account — I suspect the amount of effort devoted to it would be much lower.
Year one: Free up front, but with many limits and missing features unless you bought the $4.99 (one-time) in-app purchase to unlock them.
This brought in good money up front, but income slowly declined, as all paid-once purchases do, and it restricted the app’s best and most compelling features to the very small percentage of people who paid. Everyone else got a sub-par app.
Year two: Free for all features that were previously locked behind the purchase, with an optional $1/month patronage, to deliver the best app to the most people and hopefully change the direction of the downward revenue curve by replacing one-time purchases with recurring income.
This simply hasn’t brought in enough money, which I’ll get into below.
Starting today, I’m trying a third:
Year three: Free for almost everything, with simple ads on some screens, and everyone now gets the dark theme. Patronage is now Overcast Premium, now just $9.99 per year, for ad-free use, file uploads, and some future features.
Existing patrons become Premium accounts of the same duration, with all Premium benefits. At the end of your patronage, you’ll be asked to renew as Premium.
Buyers of the old $4.99 unlock from year one: Restore Purchases from the Premium screen, and you won’t see the normal ads, but you may see occasional promos for Premium to support further development.
How patronage performed
Patronage was a big risk, both in finance and reputation. I took a lot of heat for it, and it initially made much less money than the previous model. But I knew that if I could convince 5—10% of the userbase to pay, I’d come out ahead.
Here’s how that went:
Patronage initially brought no new exclusive features, based solely on goodwill, which only convinced about 1.9% of people to pay. This wouldn’t be sustainable, so I had to add perks to patronage that some people would want enough to pay for. But to prevent the year-one problem of most people using an inferior or annoying app by not paying, the absence of the patron-only features needed to be inconsequential or unnecessary for typical usage.
In March, I added the two new features only for patrons: a niche file-upload feature that required ongoing hosting costs, and a dark theme that was highly demanded but purely cosmetic.
It worked fantastically at first. The patronage rate jumped from 1.9% to 2.6% in one week, and slowly rose to just under 3%. But growth has stalled there, and it’s clear that I’m not going to reach my 5–10% goal.
And keeping the dark theme behind a subscription has been extremely unpopular, even among those generous enough to pay. People really don’t want to pay a monthly fee for what seems like a basic app feature, even if it’s purely cosmetic, and many patrons have been getting very angry when they stop paying and the dark theme goes away.
Faced with these problems, I came up with a few solutions, all of which were terrible:
No change: The status quo brings in enough money to keep the service running and fund basic maintenance and occasional updates, but I want to do more: more frequent updates, more cool features, more server capacity, more users, and higher quality.
Lock existing free features behind patronage: This would anger pretty much everyone, and once it settled down, I’d be stuck with the same problem as year one: most users never get the best parts of the app.
Add new patron-only features: If any new patron-only features are widely demanded, I’ll be stuck with the year-one problem again. If not, they won’t bring in enough money. The latter is more likely: what most people want (and will pay for) is pretty well covered by Overcast’s current features.
Change to pure subscription pricing for the entire app: This may work for other types of apps, but probably not general consumer entertainment apps in highly competitive environments full of free alternatives, one of which comes installed on the phone. This would severely harm Overcast’s ability to get new users, hurting my political goal of protecting the awesome, open, decentralized world of podcasting with app diversity.
Change to a paid-up-front app, or year one’s one-time unlock: A smooth transition from the status quo to this would be impossible, and I’ve been down this road enough times to know that pay-once revenue curves only go downward. The App Store never made this easy, and the market is only getting more challenging over time.
It felt hopeless, but my initial thinking was restricted by trying to wedge traditional software business models into the realities of today’s App Store. It’s hard to make older revenue models work today because the market is completely different.
Charging money only works in scarcity, but most kinds of software are no longer scarce, especially on iPhone. Whatever I charge money for, someone else can give away, and vice versa. For instance, most of my competitors now offer a dark theme at no additional charge, but if I give mine away without any other changes, I’ll go out of business.
There’s still money in some software, especially if it helps people get their work done, but the market for most consumer apps is much more like music, video, news, opinion, and web services than traditional indie software: an overwhelming supply of free choices, many of which are great or good enough, making it hard for anyone with a paywall to succeed.
The content industries figured out the solution a long time ago. If 97% of my users can’t or would rather not pay, but they spend substantial time in the app every day, the solution is probably ads.
Ads are the great compromise: money needs to come from somewhere, and the vast majority of people choose free-with-ads over direct payment. Ads need not be a bad thing: when implemented respectfully, all parties can get what they want.
Most podcasts played in Overcast are funded by ads for this reason, and as a podcaster and (occasional) blogger myself, I already make most of my income from ads.
So I’m trying ads in Overcast: simple, non-animated, mostly-text banners on the main list screens that unobtrusively scroll with the content.
In exchange for ads, I’m giving everyone dark mode for free. If you’d rather not see ads, a Premium subscription (or restoring the old 1.0 unlock if you bought it) will hide them.
In today’s app environment, for a daily-use consumer app like this, ads make a lot of sense for both users and developers. Ads align incentives toward making a high-quality app that you’ll actually want to use long-term, rather than just struggling to get your money up front or toying with psychology so you’ll buy more gems.
A lot of indie developers struggle to make sustainable income in the App Store. I’ve experimented with many models over the years, and I’ll be happy to share the results of this change to hopefully be useful to other developers.
I honestly don’t know if this will work long-term, but I think it probably will. If it does, it will solve a lot of problems and let me do quite a bit more, better and faster than before, and truly make the best app for everyone, rather than only 3% of my customers.
Filed as Apple bug (Radar) 27848317. The problem, in short:
AVFoundation, the low-level audio/video framework in iOS and macOS, does not accurately seek within VBR MP3s, making VBR impractical to use for long files such as podcasts. Jumping to a timestamp in an hour-long VBR podcast can result in an error of over a minute, without the listener even knowing because the displayed timecode shows the expected time.
VBR encoding is far more space-efficient and better-sounding than constant-bitrate (CBR) encoding. It’s especially pronounced in podcasts, where VBR makes most podcasts 20–50% smaller AND better-sounding than the 64 kbps CBR encoding that most podcasters are forced to use today.
VBR could save podcast listeners massive amounts of data transfer over time. (And therefore money, and battery life, and precious storage space on phones.)
Without accurate seeking, streaming and web audio players don’t work properly, including share-at-timestamp links that are becoming key drivers of the sharing and spreading of podcasts.
Why can’t podcasters use it?
I explained how MP3s work, and why this is a problem, on Accidental Tech Podcast last week — see that? That’s a share-at-timestamp link, and if that file was VBR, it wouldn’t seek to the correct time.
See for yourself: here’s that same podcast in VBR. Note that the file is 25% smaller and the theme song (at 1:22:47 in the original file) sounds way nicer in the VBR version. But if you seek to the same timestamp as the above share link — 1:24:30 — you’ll hear the wrong audio. The player will say 1:24:30, but you’re actually hearing the audio at 1:25:16.
That’s 46 seconds off, and that’s enough to break timestamp sharing, and that’s enough to ensure that nobody ever uses VBR files, and podcasts keep transferring more bytes to sound worse for the foreseeable future.
We fixed this in the same year the Backstreet Boys released “I Want It That Way”
Three simple solutions to accurate VBR stream-seeking have existed for almost twenty years to embed seek-offset tables at the start of VBR MP3s for precise seeking:
But AVFoundation supports none of them. VBRI and legacy Xing frames are read, but only the duration is used from each, not the seek table. MLLT tags are seemingly ignored.
It appears that AVFoundation simply estimates byte offsets with the simple ratio of (timestamp / duration) × totalBytes, but that assumes a constant average bitrate over the file, which is incorrect and an unsafe assumption for VBR encoding. (ABR maintains an average bitrate over the whole file, but doesn’t achieve a better enough size-to-quality ratio than CBR for most podcasts.)
Supporting either MLLT or VBRI at the AVFoundation level (therefore affecting Safari, HTML5 <audio>, Apple’s Podcasts app, and more) would instantly make VBR podcasts practical, allowing much smaller files and better sound without sacrificing shareability and stream-seeking.
I’ll be adding MLLT support to Overcast, but without a way to embed podcasts in the web player to preserve share-at-timestamp links, VBR files will continue to be practically unusable for podcasters.
Know anyone in engineering at Apple? I’d appreciate any attention you can draw to this issue, which I’ve filed as bug 27848317.
This week: why ARM Macs aren’t imminent, a huge rant on the ancient Mac lineup (especially the neglect of the Mac Pro and Mac Mini), dog rental, and my algorithm for syncing audio tracks and correcting drift.
Government guidelines for LED manufacturers require these control circuits to operate on frequencies between 30 and 300 MHz. By coincidence, most garage door opener remotes have been assigned frequencies between 288 and 360 MHz.
I was using a mediocre, no-name LED light bulb in my (very old) garage-door opener, so I switched it to an incandescent I had stashed in my Drawer Of Light, which promptly and poetically burned out later that same day.1
But that was weeks ago, and the problem hasn’t occurred since. It’s been 100% reliable since I removed the LED bulb, and even catches the signal from greater distance now.
I still haven’t gotten around to replacing it. It turned out not to be essential, and I’m a terrible home-repair slacker, which is why I tried to put LED bulbs everywhere in the first place so half of our light bulbs wouldn’t be burned out constantly. ↩︎
Apple has, for a while now, offered two separate additional security measures to protect your Macs, iOS devices, and iCloud account, but thanks to some inexpert nomenclature, it can be a little difficult to tell them apart
I’m glad Dan Moren figured this out and wrote it up, because Apple sure didn’t make it easy to even know that there was a newer, better option than the original two-… uh, factor? Step? I already forgot which is the old one and which is the new one. Whichever it is, switch to the new one.
A few Tesla vehicles have had accidents with Autopilot enabled recently, and I’ve gotten countless questions about these incidents and the nature of Autopilot from people who aren’t Tesla owners. Tesla and the media haven’t clearly communicated what these features do (and don’t do) to the public, so I’ll try to help in whatever small way I can as a Model S owner for a few months so far.
I apologize in advance if I get any technical details wrong about these features. Authoritative information is hard to find, and these features change and evolve often.
Tesla’s autonomous features today, all somewhat grouped under or involved in “Autopilot”:
Automatic emergency braking: This always-on feature will sense if you’re approaching another car or obstacle too quickly and loudly alert you. If you don’t apply the brakes yourself, the car will automatically brake to somedegree. This is a common feature in luxury cars today and seems to be a clear safety win.
Autopark: Reverses into parking spots on demand. This is also becoming a common feature on other cars, and seems reasonably safe as long as you watch out for pedestrians. I use it regularly for parallel parking and it works well.
Summon:This feature lets you command the car, from outside of it, to very slowly drive itself into or out of a garage or parking space. It’s disabled by default and requires multiple steps to enable and engage (nobody could do this accidentally). The potential damage from failures is likely limited to car body or garage damage, not major bodily harm, due to the very slow movement and ultrasonic parking sensors. I haven’t used it yet — I don’t think the small benefit is worth the risk.
Adaptive cruise control: Like normal cruise control, but with a forward radar (augmented by the camera) to maintain a safe distance from the car ahead of you, automatically slowing down or even stopping as necessary. It’s almost like automated driving, but you still steer, and you’re responsible for obeying signs and signals. This feature is also available on many luxury cars today, and Tesla’s is the best one I’ve used yet, so I use it all the time. It bears most of the same risks as any cruise control, but the chances of rear-ending the car ahead of you are greatly reduced, and it may even be safer than manual driving in low-speed stop-and-go traffic. I’m a huge fan of this feature.
Autosteer, which people probably mean by “Autopilot”: Really just one significant addition to adaptive cruise control: the car also steers itself, using the camera to detect lane markings painted on roads (a feature offered by many other cars on its own) and automatically steer to keep you roughly centered in the lane.
Autosteer is a strange feeling in practice. It literally turns the steering wheel for you, but if you take your hands off for more than a few minutes, it slows down and yells at you until you put your hands back on the wheel. It’s an odd sensation: You’ve given up control of the vehicle, but you can’t stop mimicking control, and while your attention is barely needed, you can’t safely stop paying attention.
It’s automated enough that people will stop paying attention, but it’s not good enough that they can. You could say the same about cruise control, but cruise control feels like an acceptable balance to me, whereas Autosteer feels like it’s just over the line. History will probably prove me wrong on that, but it feels a bit wrong today.
Tesla, Elon Musk, and a lot of media coverage have set expectations too high for these features. People expect Autosteer to be fully autonomous, but today’s Tesla vehicles simply don’t have the hardware or software to safely and reliably self-drive on all roads, and such an advance doesn’t feel imminent.
There’s a huge gap between Autosteer and what most people expect from a “self-driving car”. For instance, Autosteer doesn’t see signs or traffic signals, so it will happily drive through red lights or stop signs if you let it.
Most critically, Autosteer has simply not been reliable enough yet for me on anything but wide-laned, gently turning, intersection-free highways with clearly painted lines in dry weather. In my experience, using it on any other type of road — even New York’s highway-like parkways — is dangerous and unsettling, often requiring manual corrections to avoid crossing center lines or getting dangerously close to lane edges and concrete barriers.
The most reliable, useful, and defensible parts of Tesla’s “Autopilot” features today are emergency braking, Autopark, and adaptive cruise control. I’d be just as happy with my Model S if it only had those, without Summon or Autosteer.
While I like using Autosteer on long highway trips, frankly, I’m amazed that it’s legal. I don’t think it’s a big enough advance over adaptive cruise control to be worth the risks in its current implementation. I’m scared for what will happen to Tesla and the progress of autonomous driving as more people use Autosteer in situations it’s not good at, or as a complete replacement for paying attention.
If Tesla updates the software to restrict Autosteer only to interstate highways, the yelling (and possible lawsuits) from existing owners would cause short-term pain, but I think it may save a lot of reputation damage — and possibly even people’s lives — in the long run.
The San Francisco Chronicle, in a very rare front-page editorial:
On one point we must all agree: The level and pervasiveness of homelessness in San Francisco is a disgrace. It is simply not acceptable to allow people to stay in the squalor of tent encampments or sleep in doorways, parks and freeway underpasses without attention to the underlying issues that prevent them from attaining shelter and stability in their lives. It’s bad for public safety, bad for public health, and bad as a matter of basic humanity.
Its reduction to the extent humanly possible should be this city’s No. 1 priority.
I only spend one week a year in San Francisco, and I’ve seen relatively little of the city. But every year, I’m increasingly struck by the widening class divide and disturbing contrast I see as tech workers (including myself) briskly walk past a lot of people for whom society has completely failed, pretending not to notice them, on our way to offices and events of some of the richest companies in the world.
We can’t continue boasting our industry’s “innovation” and how much we’re “changing the world” when we can’t even take care of people’s basic needs literally right outside these companies’ front doors.
This isn’t just a San Francisco or tech-industry problem, but there isn’t another place in America that illustrates the problem quite as clearly, sadly, and disturbingly.
Governments should be fixing this problem, but they have mostly failed due to public ignorance, judgment, and apathy. If you really want to be “disruptive” and have a meaningful impact on the world, disrupt the way our cities and citizens treat those less fortunate than the rich young people ordering overpriced burritos from their phones to avoid going outside.
This fall’s new iPhone is strongly rumored to have nearly the same physical design as the iPhone 6 and 6S, but with the headphone jack removed. Many have guessed the possible justifications for such a move:
In short: There may be a great reason why the headphone jack must be removed on an iPhone that isn’t getting a noteworthy size change or battery-life increase, but we haven’t heard one yet.
There are clear benefits to Apple — minor savings in parts and internal complexity, some profit from adapters and Lightning licensing, and driving a big Beats upgrade cycle — but nobody has come up with any compelling benefits for customers that require removing the headphone jack and can’t already be done in today’s iPhones.
People already think Apple changes ports capriciously and slows down their phone with OS updates just to force upgrades and make more money, even when they actually have good reasons that benefit their products and customers. I suspect that the reaction to removing the headphone jack will be even more severe in this way than the Dock-to-Lightning transition.
Apple better have very good benefits for this that customers will want, but none of the reports so far indicate any.
Combined with the disappointment sure to result from the same physical iPhone design for three years in a row — a mediocre one, at that — I fear for the public perception of this fall’s iPhone and Apple as a result.
It’s too late to change anything about this year’s iPhone hardware, but if this is true, I hope Apple at least reduces the perception damage by including a Lightning-to-3.5mm adapter in the box along with the new Lightning EarPods, and also selling the adapter separately for just $9.99. That would go a long way toward alleviating the problem.