First of all, Happy Mothers’ Day to all the mothers out there. I’m not going to change my language to wish everyone a Happy Birthing Persons’ day (yes, that’s a thing now), because that seems even more exclusionary. In the myopic fighting over gendered language, the new term omits step-parents, adoptive parents, foster parents, and a whole host of other folks who provide necessary guidance and nurturing to all of us who needed it at one point or other. If you’re one of the folks hell-bent on pushing that mutilation of our common tongue, please revise and resubmit next year.

I want to also apologize for the lateness of this week’s Note. I’ve been working hard on getting a number of projects out the door (and in the invoice pipeline) the past couple of weeks and this last week was a busy one. The main issue is that I’ve been putting the finishing touches on some new basic framework technologies, and it’s always nerve-wracking to push something out into production the first time. My brain has been so deep into declarative questionnaire systems and extensible automated dialog systems, that the slice of my mind responsible for creating English prose had been packed up so tightly in the small room under the stairs in my brain that it needed some time to breathe before being expected to do anything not-embarrasing. I think it’s still stretching its legs, but I also need to get this Note out before we start stumbling over into Next Week’s Note territory.

I originally had some thoughts about the fracas going on over at Basecamp, but I’ll save those for a future Note when more time’s passed and we can see how it plays out in the end. For those of you looking for a teaser, Basecamp (née 37 Signals) is a Chicago tech company that makes small business productivity software and invented an open-source web framework called “Ruby on Rails” (you may have heard about it). Like a lot of organizations in the past year, an internal equity and diversity conversation within the company got a little heated and in response, the benevolent dictators (read: founders) of Basecamp decided to make non-work political talk off-limits. This blew up into a major conflict within the company, leading to the suspension and resignation of one of the earliest hires when he refused to engage in a conversation about white supremacy on a impromptu conference call. The remaining founders stood firm on the new policy, and offered employees a generous severance package should they wish to be employed elsewhere. More than a third of the company took them up on their offer, and I expect that more will also leave, if only because their working life is about to become a lot more unpleasant as they’re pulling the additional weight of the third that abandoned ship.

This incident comes at an interesting time for me, as I’m getting a lot of my own HR infrastructure up and running at my company in order to be compliant with the new demands of many of my institutional clients. That means getting contractors to sign off on company security policies, implementing background checks for new hires, and building curriculum for new folks to be able to check off the boxes in contracts that state that people working for me have had training in X, Y, and Z. Given what’s going on over at Basecamp, now may be the time to me also institute some similar policies, before anyone can object to them. More on that in a future Note.

Making a living writing mobile apps is a Fool’s Errand

This has been a consequential year for technology and law. Earlier this year, the Supreme Court of the United States ruled in favor of Google in a decade-long lawsuit when it told Oracle that API definitions are not copyrightable. Contrary to the wishes of ill-informed corporate lawyers, there are obvious and measurably simple ways to structure programs and name functions, and just because someone implements a sine function that takes an angle and returns a floating point number representing the ratio of the sides of the right triangle that angle forms isn’t novel new creative activity. Had Google lost to Epic, it would be like telling carpenters they had to eschew best practices and to build their buildings in new novel ways, or license the best practices from the first mover to avoid lawsuits over door frames. The technology industry (including Oracle who sued, and is currently cloning Amazon’s APIs) dodged a bullet with that ruling.

The next most consequential case is being litigated right now. After Epic Games attempted to provide a method to purchase cosmetic elements for Fortnite avatars, Apple kicked them out of the iOS App Store for violating a contractual clause that stated that any in-app purchases must use Apple’s payment system and Apple gets to skim 30% off the top of those purchases. Epic declared that this behavior demonstrated that Apple was acting as an illegal monopolist and they took the iPhone-maker to court. The case is ongoing and is likely to rival Oracle v. Google when it comes to the shaping our technological ecosystems in the decades ahead. While I’m rooting for Epic in their lawsuit, I fear that Apple will win and that will be bad for innovation in the years ahead. I’m not going to go deeper into the case itself right now, but as a small developer playing in the mobile software schoolyard, I wanted to share some personal history playing in that sandbox.

If you get enough drinks into me, I'll often slip into referring to my company as my “laboratory for failed monetization experiments”. What I mean by that is this: When I first started Audacious Software back at the end of 2008, I took on consulting work to pay the bills while I bootstrapped some products that I hoped would take off and lead to non-linear revenue growth that would allow me to invest in other projects, allowing me to build a small personal empire on clever ideas. The original plan was to spend about half my time doing consulting work, and the other half doing product work. As the products took off, I would be able to dial back the consulting work and focus more on improving and expanding the market for my products. (Note that this is the same bootstrapping approach used by Basecamp/37 Signals a decade ago.)

The first product that I started building was a home automation system called Shion. The basic idea was that the home automation space was ready to go mainstream and the major missing component was a decent user interface for interacting with one’s smarthome. At the time (and this is still true), there was a motley collection of home automation standards (X10, Insteon, Z-Wave, etc.) and the purpose of Shion was to provide a common interface to those devices so that it didn’t matter whether you were commanding an X10 or Insteon device - your light would turn on and off. The second innovation that I wanted to bring to the market drew upon my context-aware computing work in graduate school - a true two-way user interface. Products at the time (and still presently) emphasized the control aspect of the devices - I tell a device to turn on, and it turns on. The only relevant flow was from the user’s wishes to the device’s actions. To me, an equally valuable flow was from devices to the user. As a user, I don’t only want to give commands, I also want to know the state of my house and have it observe the environment to be truly intelligent. For example, if it notices that it’s evening and I just switched the TV on, it should dim the lights in the TV room and save me the step of doing that. When the sun sets, the system should activate the outdoor lights. And I built a system that did exactly that.

The problem with the home automation business is that it’s still a high-touch customer support business, and selling Shion under a traditional software license (high up-front cost, no ongoing costs) wasn’t a viable option. (I would be eaten alive in support calls.) So instead, I gave away the core product, and and once someone got everything configured and running to their satisfaction, I would monetize it by selling an add-on service: monitoring and control from a smartphone, where you’d pay a monthly cost to have access to the network that connected your home and smartphone. This is where I started running into issues with Apple’s iOS business model.

Since the earliest days of the App Store, Apple has not only prohibited the use of third-party payment processors, it’s also prohibited the mention of third-party purchase options. If you want to set up a subscription relationship, you either go through Apple’s In-App Purchases (IAP) or you use intentionally obtuse language to direct someone to a web page (that can’t be opened within your app) where someone can put in their details to subscribe there. This is intentionally user-hostile interaction design, intended to push developers towards using Apple as their payment processor and paying a fee of 30% for the privilege. Furthermore, Apple also includes a most favored nation clause in their development agreement that prohibits developers for charging customers paying through IAP more than customers paying through the website (with a standard 5%-ish processing fee). I thought that $10 per month would be a reasonable subscription fee at the time, so I could make $9.50 per month from my web users or $7.00 a month from the iOS folks. I was contractually-prohibited from charging IAP users $13 a month. Furthermore, there was also language that mandated if I provided an option to sign up outside of Apple’s purview, I also had to provide an IAP sign-up option as well. As recently as last year, Apple was still enforcing that provision as Basecamp (all roads lead back there this week) discovered when they attempted to launch their own e-mail service.

Since language encouraging potential users to sign-up via the web interface would get my app rejected and I was prohibited from raising prices for iOS users that reflected the additional 25% Apple tax was claiming as their due, I eventually decided to cease development on the the new home automation business, as it became clear that the only folks who would be able to sustain a viable subscription-based home automation business would be those who sold it as an add-on to a larger existing business (as we’ve seen with Comcast, AT&T and others getting into the game), and not something that would be allowed to succeed on its own merits. This ended up being a smart move on my part, as Apple’s proven that it is not a neutral marketplace, and is more than willing to deep-six older apps that occupy new markets that would like to enter, a practice developers have called “Sherlocking”. This the App Store equivalent of Amazon using private third-party seller data to bootstrap house brands in successful product markets.

The greatest tragedy in consumer software development over the past decade has been the move away from open and competitive markets of programs to locked-down “walled gardens” where platform vendors exercise excessive control over devices that they sell to narrowly restrict where developers are allowed to innovate. In the pre-iOS days, the Mac software ecosystem was a wonderfully chaotic market where small-time developers (who called themselves “indies”) innovated and invented things like RSS readers, multi-client messaging applications, new web browsers, and other pieces of software that scratched an itch and allowed clever developers to make a few bucks in the process. It was bottom-up innovation at its best.

These days, that interest and enthusiasm is gone. Developers have to work 30% harder to make the same financial returns as before, without Apple providing anywhere near that amount in value. Apple has prohibited third-party app storefronts, and users’ ability to discover new apps has been stunted for more than a decade now as it’s clear that charging developers 30% to be in the App Store is the priority - not the actual App Store itself. Contrary to Apple’s claims that developers benefit from being present on the App Store, developers are still responsible not only for marketing their apps and games, but also distinguishing their offerings from competitors who are using intentionally misleading videos to draw people to their latest “free to play” Skinner boxes looking to trap their next whales. (Apple seems to have no problem with the baits-and-switches.)

So, I’ve largely gotten out of trying to make any reasonable amount of money writing consumer-facing apps on the iOS App Store, or on any of its competitor’s storefronts (such as Google Play) who are aligning their business practices to match Apple’s. If I release consumer-facing software, it’s either a passion project (such as the Pnakotic Atlas), or something that I’ve been able to monetize in an alternative way (such as Fresh Comics’ growing affiliate income over the web). I’m happy to sell my services to others with more faith in the ecosystem than me, and that’s how I’ve been able to make a living over the past decade in this space. As the old adage goes - don’t be the guy panning for gold - be the guy selling the pans and shovels.

One final comment before wrapping up this topic: while I’m annoyed and frustrated at all the greedy stupid stuff Apple is doing and how it’s stunted the mobile market, my biggest frustration with it is how it’s going to retard the emergence of the next generation of developers. I learned to do what I do by tinkering and modifying and experimenting with systems that were open and transparent. One of my favorite ways to give back in the last decade was making the occasional trip back to my high school in New Mexico and teach a two-day course in robotics programming using a kit called the Boe Bot. I could come into a new class of 8th or 9th graders who haven’t programmed a line of code in their life and leave at the end of the next day with several teams competing to race robots that they built and programmed themselves. Their robots raced around obstacles or showed off some cool new tricks that the new programmers invented all on their own.

The bridge between the kids’ ideas and the physical robot that would physically enact those ideas is a piece of software called an integrated development environment (IDE). This software provided a place for the kids to write their robot’s programs in a programming language called PBASIC. The IDE would check the syntax of the new programs and if everything checked out, it would upload the program to the robot’s BASIC Stamp microcontroller. The kids would unplug their robot from the computer, and set it on the floor to see how well their intentions were expressed in the code that they wrote, and as interpreted by the microcontroller.

The last time I visited my old high school, PCs and laptops had been phased out in favor of iPads for educational purposes. In order to do our workshop, we had to borrow teachers’ laptops to have enough machines to run the Boe Bot IDE. Now, someone might ask, “Why didn’t you just download an IDE to the iPads and go from there?” It’s an entirely reasonable question, and the answer is that Apple’s thrown up enough hurdles over the years dissuading general-purpose peripherals and programming on the iPad that the Boe Bot developers (rightly) question whether Apple would allow their IDE on the App Store. In addition to Apple’s antipathy towards general-purpose programming environments, there’s also the issue that Apple also prohibits apps from communicating with hardware devices outside their purview (and hardware licensing fees), even using open standards such as RS-232. So, my Boe Bot class has been put on indefinite hiatus, and is likely a dead relic of the past as schools continue to move to iOS-centric computing environments.

As much as Apple would claim that their actions are intended to improve the state of the iOS and mobile ecosystems, what’s actually happening is that Apple is abusing its position as the iOS platform vendor to skim revenues from iOS developers and users without providing a comparable tangible benefit in return. It’s a rotten situation, and as much as I’m not a Fortnite fan, I’m squarely in Epic’s corner in this fight. To whatever extent Apple can be neutered as the final arbiter of what’s “acceptable” on their platform, the better it will be not only for independent developers, but also for the next generations of developers who are currently ill-served by Apple’s short-term financial ambitions.

Book reports

I’m skipping this week’s book reports on account of the lack of space remaining in this newsletter. (I have quite a few books to review!) I remain on-track for my goal and will have some reviews to share next week.

Interesting reads and watches

The Oldest Productivity Trick Around (New York Times)

Does nuclear secrecy make us secure? New book offers counterargument (Ars Technica)

For Richard Branson, the Romance of Space Tourism Meets Reality (New York Times)

Four astronauts make first nighttime landing in the ocean since 1968 (Ars Technica)

Facebook and Instagram notices in iOS apps tell users tracking helps keep them ‘free of charge’ (The Verge)

Why are game-makers creating new Game Boy games in 2021? (Ars Technica)

A Glimmer Of Normalcy In Chicago As Customers Return To Small Businesses And Massive Venues Alike (CBS Chicago)

Sohrab Ahmari and the Price of “Liberalism” (The Bulwark)

Ben Wheatley’s In The Earth finds horror in fungi (The Verge)

China Is a Paper Dragon (The Atlantic)

I’m giving up my CMDR rank this week to become a lowly cadet once more. That’s right, Boat School is starting on Tuesday!