Officially, Google killed Reader because “over the years usage has declined”.1 I believe that statement, especially if API clients weren’t considered “usage”, but I don’t believe that’s the entire reason.
The most common assumption I’ve seen others cite is that “Google couldn’t figure out how to monetize Reader,” or other variants about direct profitability. I don’t believe this, either. Google Reader’s operational costs likely paled in comparison to many of their other projects that don’t bring in major revenue, and I’ve heard from multiple sources that it effectively had a staff of zero for years. It was just running, quietly serving a vital role for a lot of people.
This is how RSS and Atom have always worked: you put in some effort up front to get the system built,2 and in most instances, you never need to touch it. It just hums along, immune to redesigns, changing APIs, web-development trends, and slash-and-burn executives on “sunsetting” sprees.3
RSS was the original web-service API. The original mashup enabler. And it’s still healthy and going strong.
Mostly.
RSS grew up in a boom time for consumer web services and truly open APIs, but it especially spread like wildfire in the blogging world. Personal blogs and RSS represented true vendor independence: you could host your site anywhere, with any software. You could change those whenever anything started to suck, because there were many similar choices and your readers could always find your site at the domain name you owned.
The free, minimally restricted web-service-API era has come and gone since then. As Jeremy Keith wrote so well a few weeks ago (you should read the whole thing), those days aren’t coming back:
But [Facebook] did grow. And grow. And grow. And suddenly the AOL business model didn’t seem so crazy anymore. It seemed ahead of its time.
Once Facebook had proven that it was possible to be the one-stop-shop for your user’s every need, that became the model to emulate. Startups stopped seeing themselves as just one part of a bigger web. Now they wanted to be the only service that their users would ever need… just like Facebook.
Seen from that perspective, the open flow of information via APIs — allowing data to flow porously between services — no longer seemed like such a good idea.
(He also addresses RSS. Read it. I’ll wait here.)
This isn’t an issue of “openness”, per se — Twitter, for instance, has very good reasons to limit its API. You aren’t entitled to unrestricted access to someone else’s service. Those days are gone for good, and we’ll all be fine. We don’t need big web players to be completely open.
The bigger problem is that they’ve abandoned interoperability. RSS, semantic markup, microformats, and open APIs all enable interoperability, but the big players don’t want that — they want to lock you in, shut out competitors, and make a service so proprietary that even if you could get your data out, it would be either useless (no alternatives to import into) or cripplingly lonely (empty social networks).
Google resisted this trend admirably for a long time and was very geek- and standards-friendly, but not since Facebook got huge enough to effectively redefine the internet and refocus Google’s plans to be all-Google+, all the time.4 The escalating three-way war between Google, Facebook, and Twitter — by far the three most important web players today — is accumulating new casualties every day at our expense.
Google Reader is just the latest casualty of the war that Facebook started, seemingly accidentally: the battle to own everything.5 While Google did technically “own” Reader and could make some use of the huge amount of news and attention data flowing through it, it conflicted with their far more important Google+ strategy: they need everyone reading and sharing everything through Google+ so they can compete with Facebook for ad-targeting data, ad dollars, growth, and relevance.
RSS represents the antithesis of this new world: it’s completely open, decentralized, and owned by nobody, just like the web itself. It allows anyone, large or small, to build something new and disrupt anyone else they’d like because nobody has to fly six salespeople out first to work out a partnership with anyone else’s salespeople.
That world formed the web’s foundations — without that world to build on, Google, Facebook, and Twitter couldn’t exist. But they’ve now grown so large that everything from that web-native world is now a threat to them, and they want to shut it down. “Sunset” it. “Clean it up.” “Retire” it. Get it out of the way so they can get even bigger and build even bigger proprietary barriers to anyone trying to claim their territory.
Well, fuck them, and fuck that.
We need to keep pushing forward without them, and do what we’ve always done before: route around the obstructions and maintain what’s great about the web. Keep building and supporting new tools, technologies, and platforms to empower independence, interoperability, and web property ownership.
Over the years, comma usage after prepositional phrases has also apparently declined. ↩︎
Then you spend twice as much time figuring out how to deal with poorly crafted feeds, ambiguities, and edge cases — especially for Atom, which is a huge, overengineered pain in the ass that, as far as I can tell, exists mostly because people always argue with Dave Winer and do their own contrarian things even when he’s right, because they can’t stand when he’s right. ↩︎
They never hear about it, and don’t know what it is if someone starts explaining it. To most “business” people, RSS might as well be NTP or SMB. “Something the servers do.” ↩︎
This plan is particularly problematic because Google+ is, relatively, a clear failure so far. ↩︎
Apple dragged Google into a similar war for extreme mobile-OS lockdown — that’s why Google had to do Android. ↩︎
Taking pictures is great. Printing pictures can be time consuming, overwhelming, and not all that fun. Fracture was founded around a simple idea: there should be a better way to print and display your photos.
Fracture prints your photos in vivid color directly on glass. It’s picture, frame and mount, all in one, and includes everything you need to get your photo on your wall. Simply upload your photo, choose a size, and we’ll get to work hand-assembling it in our Gainesville, Florida factory.
Prints start at just $12, and you get free shipping on every U.S. order of $100 or more. Check it out.
Thanks to Fracture for sponsoring Marco.org this week. They gave me a free print for one of my photos, and it’s great: very modern-looking, clean, and practical. I’ll be ordering more.
iOS 7 beta 3 came out this morning with a surprisingly major change: as I first saw reported by Sebastiaan de With and later more specificially identified by Neven Mrgan, the system font has allegedly been changed from Helvetica Neue Light to Helvetica Neue (regular).1 Compare:
It’s a subtle change in theory, but it has a huge effect — see for yourself. This paragraph is in Helvetica Neue Light if you’re on a device that has the Helvetica Neue family. (If not, you probably don’t care about fonts, so it will be Comic Sans.)
It’s a subtle change in theory, but it has a huge effect — see for yourself. This paragraph is in Helvetica Neue if you’re on a device that has the Helvetica Neue family. (If not, you probably don’t care about fonts, so it will be Comic Sans.)
See? Light weights look cool (moreso at larger sizes) and work well in advertising and logos, but are generally harder to read. The system font’s most important job is to be legible to as many people as possible in as many conditions as possible, so the previous choice was simply a bad design choice.
It represented one of Apple’s biggest recurring flaws: letting cool come before functional.2 With Ive’s new role leading UI design, I was afraid that we were in for a long series of such failures. And with iOS 7 being unveiled so publicly and confidently, I really didn’t think any decisions as significant as the system font would change before release.
Now, we know otherwise.
Apple’s stated design philosophy of iOS 7 was “clarity, deference, and depth”. They nailed deference and depth, but clarity has suffered in many big and small ways.
While the too-thin font was far from the only design flaw in iOS 7, I’d say it was the biggest. Just as the new APIs in iOS 7 were clearly the result of Apple listening to all of us, we now have a sign that they’re listening on the design front as well.
The best thing for us to do is to continue to make noise about the remaining issues.
Naturally, as an NDA-bound developer, I cannot confirm this. Let’s assume it’s true for this post. ↩︎
We discussed this in ATP 19 at 1:02:45. Start at 57:45 if you have a few more minutes. ↩︎
While the too-thin font was far from the only design flaw in iOS 7, I’d say it was the biggest. Just as the new APIs in iOS 7 were clearly the result of Apple listening to all of us, we now have a sign that they’re listening on the design front as well.
The best thing for us to do is to continue to make noise about the remaining issues.
Do you really think this had anything to do with bloggers bitching?
In short: Absolutely. (Also, “bloggers” doesn’t really mean anything anymore: this had something to do with people writing and talking about it.) To understand why, it helps to understand how Apple works.
Apple isn’t a waterfall dictatorship. It’s a company full of many smart people at all levels, and while those people are generally in agreement on high-level philosophies and priorities, they often have different ideas that need to be resolved through experimentation, debate, or executive order.
From what we can tell from the sidelines, the “executive order” option doesn’t seem to happen as often as the casual observer may think: even Steve Jobs, one of the most qualified people in history to make effective executive orders, was frequently swayed by good arguments. Apple does some things because a higher-up feels like it, but in most cases, they arrive at decisions only through internal debates that we rarely hear about.1
Since Apple is just people, they’re usually trying to figure out the best answer to the same decisions and trade-offs we argue about on the outside: what’s best for the user, what’s best for battery life, what apps should be allowed to do, how multitasking should work, how far sandboxing should go, and so on. Almost any decision that causes controversy on the outside has almost certainly caused just as much on the inside, it’s probably still being argued, and the decision probably isn’t set in stone.
We can’t participate directly in those debates, but we can provide ammo to the side we agree with.
I’ve heard a number of times in the last few years that something I wrote was circulated within Apple or brought up in an internal discussion, usually to support one side of a debate. And it’s very unlikely that Marco.org is the only site that Apple employees read. (Less pointedly, filing bugs or enhancement requests is also used as a sort of voting system that also informs internal debates.)
Obviously, it’s mostly only productive to argue positions that Apple may feasibly take, and only in arguments that they’re actually having. And time is critical: it’s a lot easier to change parts of iOS 7 now than in October. But our opinions definitely matter.
We can effect change if we’re pushing for what’s best for Apple and its customers. Apple doesn’t get everything right every time on its own.
Allowing the best ideas to prevail over initial executive decisions is different from design-by-committee. In design-by-committee, too many people have equal control (or veto power) over the output. Apple doesn’t appear to work that way: a very small number of higher-ups still have the power to make most decisions as they see fit, but they’ll consider valid arguments to the contrary and be willing to change their minds for the sake of making better products.
Steve Jobs had that quality, but I think Tim Cook might be even better at it.
We’ve seen a number of reports that Scott Forstall was “difficult to work with”. If that included being inflexible and unwilling to let the best ideas prevail over his own, Cook’s firing of Forstall to “increase collaboration” looks quite good so far. I believe we’re seeing a clear reduction in capricious or arbitrary decisions making it into the products. ↩︎
Finishing a single leg of the trip requires considerable stamina and concentration in the face of arch boredom: the vehicle constantly lists to the right, so players cannot take their hands off the virtual wheel; swerving from the road will cause the bus’s engine to stall, forcing the player to be towed back to the beginning. The game cannot be paused. The bus carries no virtual passengers to add human interest, and there is no traffic to negotiate. The only scenery is the odd sand-pocked rock or road sign. Players earn a single point for each eight-hour trip completed between the two cities, making a Desert Bus high score perhaps the most costly in gaming.
In the wake of Google Reader’s shutdown, I rewrote my feed-stats script to be more accurate and produce more relevant output formatting.
I was happily surprised to see the top stats for my site:
Subscribers
App/Service
Reporting
45,565
Google Reader
Reported total
16,000+
Feedly
(See below)
8,959
NewsBlur
Reported total
4,164
NetNewsWire
Unique IPs
2,765
Feed Wrangler
Reported total
2,574
Feedbin
(See below)
2,477
The Old Reader
(See below)
1,301
Stringer
Unique IPs
1,227
Reeder (direct)
Unique IPs
1,203
Fever
Unique IPs
Google Reader’s crawlers are still running, but as far as I know, nobody’s seeing the results, so they don’t really count.
Feedly does not yet report subscribers in its User-Agent string, but were receptive to the idea when I suggested it by email. They queried one of the database segments and reported that my current subscriber count is over 16,000. Given that they appear elsewhere to be the most popular new service, and they’re one of the few free options, this number is plausible relative to the paid alternatives.
Feedbin and The Old Reader both plan to add subscriber reporting soon, and gave me my subscriber count by email.
In addition to those, AOL Reader and Digg Reader currently do not report subscribers. Please help me pressure them to add a subscriber count to their User-Agent strings1 — it’s important for publishers to know how many people are invisibly subscribed behind one-to-many crawlers like these.
Anyway, total reported subscribers are split almost equally between Google Reader and non-Google-Reader options:
45,565
Google Reader
48,236
All others
I can’t reliably compare site traffic since I published an extremely popular post just one day after Google Reader’s interface and API were shut down, but so far, it doesn’t appear that site traffic is noticeably down.
Attention to the feed also appears healthy: this week’s sponsorship post generated a strong number of responses and may have been partly responsible for overloading the sponsor’s site shortly after it was published.
It’s still a little early to say for sure, but so far, it looks like most of this site’s former Google Reader subscribers have found alternatives and remained subscribers.
I’d love to hear from others: How have your subscribers fared?
The standard format is simply including “N subscribers” somewhere in the User-Agent. ↩︎
iWatch as identity, Bluetooth Low Energy and Siri in a watch, how regular people use iOS devices, iCloud and the Dropbox Datastore API, and targeting nerds.
What I found absolutely shocked me. “Diagram Touch” was nothing more than a cracked (two year old) version of TouchDraw that had been repackaged with a different splash screen and different icons.
Awful.
I wonder if there’s a good way for Apple to prevent this. If all apps are required to have unique binaries, a lot of those crappy bulk ebook/guide/tips apps may be inadvertently blocked (although that might be a feature, not a bug).
I’ve come to a point in my life where I hesitate before telling people I’m a software developer. Am I, really? The answer is more complicated than I expected.
This really hits home for me. I’m not as far toward “writer” and away from “software developer” as Matt is, but I’m probably halfway there.
I’ve always defined myself as a programmer, but I’ve never been happy just programming. I’d hate to work on a large development team where that was my only role — in fact, the idea of writing code full-time for anyone doesn’t appeal to me anymore.
I love doing it as a means to a larger end, but I’m just not that into it as a profession anymore. In many ways, I always kept my distance a bit, never caring much for advanced methodologies, studying design patterns, proving algorithms, or learning cutting-edge languages before they’re stable and practical. I’ve always written code for the sake of making the product I wanted, not for the code’s own sake.
And for about the last six months, I’ve hardly written any code at all. Between selling Instapaper, running and then selling The Magazine, writing this site, co-hosting a very successful new podcast (and learning how to edit, publish, and monetize it), and trying to spend a healthy amount of time with my family, there hasn’t been much time left for development.
Am I really a programmer anymore?
To borrow from and paraphrase Merlin Mann (hopefully accurately), you are what you actually do, not what you think or wish that you did. So far, in 2013, I’m really a writer and podcaster (and, to an embarrassing degree, a Twitter user) with a programming hobby.
This is why I’ve been so aggressive about trying to get things off my plate: I’ve written and podcasted for years without issues, but for the last six months, I’ve basically replaced software development with paperwork, business and legal overhead, and bullshitting on Twitter.
And I’m going to need to change that if I want to launch anything again.
The immensity of this change can not be understated, nor can the risks. Ultimately, I believe the reorganization will paralyze the company and hasten its decline.
I didn’t really give much thought to their bland corporate announcement the other day, but it’s far more interesting than it sounded.
Bugshot, its omitted and future features, and exploring NAS options: Synology vs. homebrew, NAS backup considerations, and hoarding terabytes of Apple videos.
Interesting data from Flurry, but I think their mobile-advertising business is influencing their conclusion a bit too much:
In light of that, it seems that the conversation about whether apps should have ads is largely over. Developers of some specialized apps may be able to monetize through paid downloads, and game apps sometimes generate significant revenue through in-app purchases, but since consumers are unwilling to pay for most apps, and most app developers need to make money somehow, it seems clear that ads in apps are a sure thing for the foreseeable future.
Compared to traditional web-browser ads, mobile-app ads so far have been much more intrusive to users, less effective for advertisers, and less profitable for developers. And despite ads being the norm for both low- and high-quality websites, apps with ads are perceived as profoundly cheap and low-quality.
I don’t think this “conversation” is over at all. If we had to declare a conclusion today, I wouldn’t bet on mobile ads being the clear “winner” over in-app purchase. And it would be a miserable outcome for all three interested parties — users, developers, and advertisers — if ads do end up being the de facto way for apps to make money.
Getting your app in front of the pack this year will take more than a facelift. It’s going to take marketing, which means understanding where you can acquire users organically and where it makes sense to advertise. You’ll need a tool to show you where your most engaged users come from.
Tapstream, the simple app marketing analytics tool that sheds light on all that, is extending a special offer for Marco’s readers for a very limited time: sign up and activate the SDK within the next 7 days and get the $99/month Pro account completely free for life.
We apologize that maintenance is taking longer than expected.
It’s now been almost three full days. I don’t know anything about their infrastructure, but for a web service to be down this long with so little communication, most “maintenance” or migration theories become very unlikely.
The most likely explanations:
Severe data loss, with trouble restoring from backups. While this can happen to the best of us, I don’t think it’s very likely to have happened here. Also, three days is pretty long even for backup-restoring troubles.
A security breach, followed by cleanup and increased defenses. The longer it goes, especially with no statements to the contrary, the more this becomes the most likely explanation.
Apple IDs have been working normally, so if it was a security breach, it’s more likely specific to one of the roles of the Developer Center: forums (boring), beta downloads (boring), developer identity (creepy but maybe profitable), or device provisioning and certificates (potentially very profitable). If a root certificate somewhere was compromised, this could mean having to immediately generate new certificates for development, or more pressingly, push notifications or iCloud.
Either way, if you’re an iOS or Mac App Store developer, I’d suggest leaving some free time in the schedule this week until we know what happened to the Developer Center.
See also: this comment and this video from security researcher Ibrahim Balic, who may have been the “hacker”. His timing and the data he got match up very well with Apple’s story so far.
Crashlytics addresses a huge hole in mobile app development: providing deep insights into an app’s performance to pinpoint and fix issues quickly and easily.
Built by a hardcore team, Crashlytics is the most powerful yet lightest-weight crash reporting solution. We perform a deep analysis of your stack traces, highlighting the most impactful threads and lines so you can spend more time fixing issues and less time finding them.
Available for iOS and Android, Crashlytics has been installed in many of today’s top applications, including Twitter, Square, Yammer, Yelp, Kayak, Nickelodeon, and Groupon.
A blatant Chrome ad (with some misleading-at-best wording on the iPhone splash page), but it’s damn impressive and a lot of fun.
This is a Google side project at its best: a fun, technically impressive toy for geeks wrapped in a huge ad that’s mostly honest and probably well-intentioned, as long as you don’t think about it too much and you believe that it was created by a few geeks having a great time in a plush workspace full of laptops, free snacks, and colorful toys.
There seems to be a culture developing around designing games and apps that are intended to intentionally mislead and coerce customers into making more and more purchases.
I like both of his suggestions for improvements, but I also don’t think there’s any chance Apple would implement anything like them unless forced.
The system today is making tons of money for the people at the top (including Apple), and any changes like this would almost certainly cause those people to make less. Probably not a lot less, but less. And “less” is an unspeakably bad word in capitalism, even for Apple.
The only likely source of such changes would be regulatory, but most1 governments and regulatory agencies can’t be bothered with something as minor as how much the relatively rich are accidentally spending on casual smartphone games.
Then again, politicians, like “journalists”, are always looking for a reason to attack Apple.
And the E.U. passes a lot of consumer-friendly laws. ↩︎
The Kindle Fire first defined the shitty-7-inch-tablet-for-$200 category. Last year’s Nexus 7 showed the world that it was possible to hit the same price point while shipping something halfway decent, but it hasn’t aged well even after just one year.
Here’s hoping its new successor ages better. The screen sounds great, at least:
The tablet’s specifications are largely in line with recent speculation: its 7-inch screen has an increased resolution of 1920×1200, retaining the previous tablet’s 16:10 aspect ratio.
While I don’t care for such a skinny aspect ratio at that size, I’d love to see a pixel density like that on the iPad Mini.
As we know with the iPad 3 and 4, high-DPI tablets to date have needed to make substantial trade-offs to drive those panels. The results have been mixed at best: the Retina iPads are bulky and (relatively) expensive, and most high-DPI Android tablets have suffered from poor GPU performance or other issues.
Just as the first Nexus 7 showed that a previously terrible category could be done better, I wonder what the new Nexus 7 will tell us about the feasibility of a Retina iPad Mini this year.
I’m curious how Google squares these claims with all the usage share numbers that show Android tablets at far below 50 percent. Either the usage share numbers are wrong, or people just don’t use the Android tablets they buy.
…if you were not entirely committed to tablet computing, wouldn’t you be likely to buy the cheapest tablet available? And when the user experience doesn’t wow you, you tend not to use it. It’s obviously not like that for everyone but I wonder if that doesn’t explain some of this.
Another potential contributing factor: I’ve often heard from people who bought Nexus 7s or Kindle Fires as cheap tablets to give others, usually their children, spouses, parents, or grandparents. Children are less likely to show up in web-browsing and e-commerce marketshare surveys, and giving cheap tablets to adults who didn’t already use tablets on their own — and therefore aren’t necessarily committed to using them — might increase the chances of them being used very lightly or abandoned.
I own two 7” Android tablets — one shitty Kindle Fire and one halfway decent Nexus 7.1 I bought both primarily for Instapaper testing and secondarily “to play around with.” Granted, I’m not the typical user, but they’ve both sat in my closet, unused, since a couple of weeks after getting each. I bet this story is common among geeks like me, at least.
I’d be tempted to get the new Nexus 7 “to play around with”, but last year’s model sitting in my closet2 reminding me I’ll never use it is a very effective deterrent.
I previously owned a shitty Nook Tablet as well, also for Instapaper testing, but have since sold it (lol) for almost nothing.
Still, that’s three Android tablets sold to someone who isn’t even an Android user. Sure, I’m an edge case. But add up enough of these edge cases and you start to explain the huge gap between claimed marketshare and real-world usage. ↩︎
I offered to give my Nexus 7 and Kindle Fire to Betaworks in the Instapaper acquisition, but they had so many of both sitting around already that they declined. Tech companies with mobile apps can practically tile walls with outdated Android devices. They’re the new AOL CDs. ↩︎
This week: iSCSI FU, the Developer Center downtime, Logic X and App Store upgrade pricing, iOS developers acting like the RIAA, and the effects of falling prices for apps and games.
In my tests, it did successfully render some items immune to liquids, but not everything, and not nearly to the degree that you see in the company’s demonstrations. The coating didn’t seem to last long, either. … The coating leaves a frost-colored haze on every surface, and it turns textures rough and faintly gummy. That explains why the shirts and shoes shown in the company’s demos are white; on any other color, NeverWet would look terrible.
Oyster makes it easy to build, test, and use a library of regular expressions. Oyster features code generation in over 11 languages and integration with popular snippet libraries Dash and CodeBox.
Syntax highlighting, dynamic matching and replacement templates, and clipboard or drag-and-drop code generation all work together to help you build, test, and use your regular expressions.
With Oyster, it has never been easier to exploit the power of regular expressions in your projects: just ask Brett Terpstra.
Good article by Elia Freedman, but then it ends with this footnote:
Listening to Marco Arment talk about this problem is frustrating. The guy has an incredible personal brand, like [Loren] Brichter, and the things he touch get instant echo in the iOS chamber. Would The Magazine had been such a success if I had built it? No way. His personal echo chamber made that happen. (Note that I am not complaining in the least about his ability to do this. If anything I’m a little jealous.)
I’ve heard things like this a lot, but I think you’d be surprised at the reality.
A very popular article on this site might get 50,000 hits. Most get more like 20,000. Sponsors have reported getting 1,500–2,500 clickthroughs on sponsored link-posts.
In the App Store, I’m competing with hundreds of thousands of other developers for the attention and money of hundreds of millions of customers, most of whom don’t know or care who I am.
I released a new app a few weeks ago. Here’s its sales graph:
To date, I’ve invested about two weeks of time into Bugshot and it has made a total of $3,531.89. That’s not bad at all, but it’s not going to go very far, especially considering that the average for the last 5 days is just $47 per day, and the trend is clearly falling quickly.
Bugshot got great press, but that’s also most of the press that it’s ever going to get.
You can see the sales bump on July 22 when I invested another few days into it, polishing it more and adding two major features (Blur and “Open In…”). But you can also see that the bump was small and temporary, and further investment in any major features is probably not a responsible use of my time.
My audience gives me an advantage on day one, and that’s certainly significant. But after that, I’m in the same boat as everyone else.1
John Gruber’s comments on The Talk Show #49 about Vesper’s sales suggest that the same is true for them. John’s audience gave them a great launch, but now, they’re in the same App Store dealing with the same challenges and competition as the rest of us. ↩︎
