“This is it,” a friend said to me as we were walking up Market Street with other developers, late at night as WWDC was winding down several years ago. The iPhone had hit. The conference was getting bigger. Apple was on the verge of becoming a giant in the industry and you could feel it in the air — a coming change that was obvious only from a distance because it disappeared as you reached for it, like San Francisco fog rolling over the bay. “This is the height of the conference and it’s never going to be like this again.”
Looking back it perfectly captured what I think of as the second “era” of WWDC. It was a kind of golden age for Mac and iOS developers, with a new generation of successful Mac indies and before the iOS race to the bottom was much past the starting line.
From my perspective, learning Mac development in the mid 90s, there are three distinct eras of Apple’s WWDC. My first WWDCs were at the San Jose Convention Center. The developer base was small enough that you consistently ran into everyone, companies like Metrowerks and even Adobe seemed to have an influence on the conference, and Apple frequently showed off new APIs that might not actually ship soon or ever. It was an exciting time to be a Mac developer but the rest of the world didn’t care. This was the backdrop for the failed Copland project, for Steve Jobs coming back, for the clash between Carbon and Cocoa, and the acceptance of Mac OS X.
The next era was at the move to San Francisco. The conference was getting bigger but Apple attempted to keep the events and themes that made WWDC the same, even for a while busing attendees to the beer bash in Cupertino. This is the time when the iPhone SDK arrived and the conference exploded. I think most developers will always look back at this time as something amazing. It’s the backdrop for that walk up Market Street and a dozen similar conversations.
Now we’re in the third modern era of WWDC, with one undeniable characteristic: a small percentage of developers can get a ticket to the conference. The community, however, is as strong as ever, and there’s still a desire to have WWDC be that “one place” that developers can meet each year. It’s a need that smaller, regional conferences, no matter how important they are, just can’t fill.
I like this post from James Dempsey because it starts with the assumption that not getting a WWDC ticket is the new normal:
“Once something changes from being dependably available to rarely available, you begin to form alternate plans and take alternate paths.”
He’s right. Since it’s likely that Apple will continue to iterate slowly instead of making major changes to grow the conference, we’re better off adapting. By adapting we can focus on preserving the community aspects of WWDC that are arguably just as important as the technical tracks.
And change comes slowly to WWDC. I realized while watching video from the Tech Talks recently that Apple just doesn’t see a big problem. John Geleynse described a situation where only one person from a team is at WWDC; the rest of the company is back at the office watching videos and sending questions to their coworker at the conference to ask in the labs. Getting videos out the same day makes the conference more useful for both those without a ticket and actual attendees (and their team) too.
(I still have complaints about how WWDC tickets are distributed and why Apple doesn’t attempt to grow the conference a little more, but the lottery is an improvement over last year. See Core Intuition episodes 132 and 133 for a full discussion.)
I’ll be in San Francisco for a few days next week — at AltConf, at the Cartoon Art Museum fundraiser, catching up on session videos, waiting in line for coffee, hiding in my hotel room writing code, and getting some good food and drink with fellow developers. WWDC means something different now, but it matters just as much as it always has. Hope to see you there.
Brent Simmons has another expanded résumé of sorts, following his post about working at NewsGator. I love this write-up because it mirrors a lot of the work I was doing, so it brings back a lot of memories. I was actively using Frontier for client work and crazy side projects; one of my co-workers for a time was Mason Hale, who built an early CGI framework for Frontier; and I loosely worked with Dave Winer to help run the frontier-talk mailing list and hack on a potential WebSTAR plug-in for Frontier. (Though I was still a pretty poor C programmer back then. Someone else ended up shipping it.)
Back when the job description “webmaster” still meant something, I worked for the WebEdge conference which brought together the best web developers for the Mac OS. WebEdge hosted the first meeting of the Macintosh Internet Developer Association (MIDAS), led in part by Dave Winer. And I was always playing with the tools that came out of Userland, from Manilla to Radio Userland. I used Radio to run this blog until 2004.
Some of the developers from that time have faded away, moved on to other projects away from the public spotlight. But not Brent. He just shipped Vesper 2.0 and it’s some of his best work.
I was the guest on 2 podcasts recently. First, on Preservation State with Philip Mozolak and Christopher Radliff, we talked for an hour about App.net, Beats Music, and more. It was fun to do a longer podcast that’s free to kind of meander through different topics, and I think we covered a lot.
Next, on App Stories, Vic Hudson interviewed me about how Sunlit came to be. We talk about App.net, design choices in Sunlit, and the future for the app. There’s a lot in there that I’ve never talked about before. Hope you enjoy these episodes!
I use Feed Wrangler as my RSS service, but I like this quote from Feedbin’s Ben Ubois:
“Twitter and Facebook are often cited as the reason for the decline in RSS usage. Where does content originate though? Right where it always has: on blogs and websites that probably have an RSS feed.”
It’s a great point. If you had to choose between only reading Twitter or only reading weblogs, which would you choose? Losing Twitter would be a bummer for a lot people, but losing weblogs would decimate the web. We should do more to strengthen weblogs and RSS because they are the foundation for so much of the most important writing on the web.
Great post from Brent Simmons, recalling his time at NewsGator. On trying to get Nick Bradbury to join them at Sepia Labs, the spin-off that was building Glassboard:
“I loved working with Nick in the past, and — even though Nick was an iPhone user and Delphi programmer — I wanted him as our Android developer. Nick was not eager to be on the NewsGator payroll again, but he accepted since we were spinning out into a separate company. And he quickly turned into a great Android developer, as we all knew he would.”
There’s plenty more, about the different stages the company went through from Brent’s perspective. I love posts like this. It’s important to capture the history and culture of tech companies, before our memory fades. And it’s not unlike what Brent has done on a bigger scale for his podcast The Record with Chris Parrish.
The last half of this week’s Core Intuition serves as a follow-up to my recent blog post on Twitter. Daniel tries to get at the business problems of not being active on Twitter. On the show I say:
“Me trying to make a statement, even if it’s insignificant, by not posting to Twitter... It wouldn’t mean anything if it didn’t cost me anything. If it didn’t have a cost, it would not matter.”
We also talk about Automattic raising money, blog software, and what that sandwich shop that Daniel avoids has to do with customer service.
John Gruber asks, on the rumor that Apple will acquire Beats:
“The Beats streaming service is interesting, but can’t Apple do that on its own, as an expansion of the iTunes Music Store and iTunes Radio?”
Unfortunately I think the answer is no, Apple can’t easily do anything like what Beats Music has done. Not because they lack the skill, but because they lack the desire to actually do the work and hire the staff to make it happen. Compare iTunes Radio side by side with Beats Music. Beats Music isn’t just a streaming service; it’s more like a platform for curating playlists and discovering music.
I like Beats Music so much that I wrote two posts recently about it. Here’s a snippet from each, first on building something you love:
“iTunes Radio looks like something they felt they had to build, not something they wanted to build. Beats Music is in a completely different league, with a deep set of features and content. It looks like an app that’s had years to mature, not a 1.0.”
And then on ending the top 200 by doubling down on featured apps, just as Beats Music has done for music curation:
“How would this fix the junk problem in the App Store? Simple. No one in their right mind would ever feature one of these ad-filled, ‘re-skinned’ cheap apps. Great recommendations mean less reliance on search, making scam apps more difficult to find by accident.”
However, I agree with Gruber that on the surface this potential acquisition doesn’t really seem Apple-like. It would be unusual for them to acquire a high-profile brand. As much as I’d love to see the Beats Music team join Apple to improve iTunes and the App Store, I’ll be a little surprised if it actually happens. Maybe they have something else in mind that we can’t see yet.
Many people have written about App.net this week, but I think my favorite line is from this essay by Pete Burtis, while talking about how the API and apps are years ahead of other platforms:
“If App.net is to be frozen in time, at least it’s to be frozen in the future.”
Sunlit version 1.2 is now available in the App Store. It includes a few minor improvements and one major change: you can now use the app with only a Flickr account. It no longer requires App.net.
We hope this will allow more people to try the app. At any time, you can always add your App.net account to the app’s settings and it will unlock the more advanced features: syncing, sharing stories to other App.net users, and multi-user collaboration so that anyone can add photos and edit text in a story.
Making App.net optional instead of required meant rethinking what the minimum features were that all users should have. Obviously you have to be able to create stories, add photos, include text descriptions, and use filters. But we also kept coming back to one thing: we could not ship without also supporting web publishing. The bulk of work on Sunlit 1.2 was creating a parallel implementation for publishing that would seamlessly work with exactly the same UI, with or without App.net.
Some people may ask why we chose Flickr instead of creating our own user accounts system, or simply having no registration. To support publishing, it helps to have some unique username for a user, and a secure way to authenticate them on the server. It won’t surprise anyone to hear that a lot of people have Yahoo accounts. With a redesigned web and mobile experience, plus 1 TB of free photo storage, Yahoo’s giving Flickr something of a new resurgence. There’s a lot we could build on the Flickr API.
At the same time, Sunlit’s App.net support is a powerful differentiator and we’ll continue to improve it. It lets you own your data, share it with other apps like Ohai, and sync to multiple users. I still believe in the App.net API and user community; it’s too good a platform to give up on.
Last week, in my post about mirroring content, I said:
“When we get into the groove of using a new service for a few years, it’s easy to forget that web sites don’t have a very good track record.”
Now we find out that Mlkshk is shutting down. They are working with the Internet Archive to make sure the content is preserved, and they might still find a buyer for the whole service, but as things stand it’s likely that every link to Mlkshk-hosted images will break in September.
Mlkshk hasn’t been on my radar lately, but it was widely used enough a couple years ago that I added support for its image thumbnails to Tweet Library. I hope they can at least find a solution to keep mlkshk.com working as a static site.
Marco Arment responds to my comment that developers should have seen the potential of the App.net API as something much bigger than Twitter. I wanted my post to be short, but Marco makes good points that are worth following up on. He writes:
“Building an app on someone else’s API, rather than making your own, is a huge risk: it usually only pays off if the service provides a huge existing userbase and hard-to-duplicate functionality. App.net never offered either. They started out facing the typical social-network chicken-and-egg problem, put a huge paywall in front to prevent any growth, and tried to alleviate that by adding more chicken-and-egg problems to their offerings.”
Building entirely on App.net for Sunlit was indeed a huge risk, and one that we expected would take time to pay off. It was a bet on the future. We are incredibly proud of our app and the response it got in the App.net community, but our goal was always to make an app that appealed to everyone, not just a small niche of tech folks. We’ve actually been working for over a month on a new version of Sunlit that expands the reach of the app beyond App.net, and coincidentally it just went into review at Apple this week.
But I think the chicken-and-egg problem was solvable. The main issue with iOS apps is that they couldn’t sign up a new user directly in the app. This made sense when App.net was a paid-only service, because you’d run into in-app purchase issues with Apple, but it became more technically feasible when the free tier launched.
The App.net founders also seemed receptive to the idea. There just wasn’t time to make it happen. I believe this single roadblock prevented any potentially-mainstream killer apps built on App.net from getting off the ground. If it’s not easy to open a third-party app, create an account, and start using the service, too many people will give up. (Our numbers showed that only 40% of Sunlit downloads actually signed in to use the app for real.)
However, building our own backend for the app would also be very challenging and expensive. We are not syncing small bits of data around. It’s a photo sharing app, so right off the bat you’ve got big files that have to be hosted somewhere. On top of that there’s collaboration features, so you need not just user accounts but private sync channels that have specific read/write access to certain users. Plus all the metadata and formats to support syncing text, photos, and location check-in information. Not to mention publishing HTML, thumbnails, and maps. It’s daunting.
(In fact, it’s so daunting, I don’t think there’s a single app in the App Store that has feature-parity with Sunlit. The app simply could not have been built by a tiny team of 2 part-time developers if building a whole backend infrastructure first was a prerequisite.)
Marco closes with this:
“As much as App.net wanted to be — and eventually was — much more than a Twitter clone, it got the vast majority of its initial funding, enthusiasm, and developer support from people’s anger at Twitter’s dickification. But internet outrage doesn’t last long. Since App.net never became the new primary place where our friends all hung out, most of us never left Twitter — we all just accept that they’re dicks now, and we forgot about App.net.”
There’s an argument to be made that App.net’s core mistake was building the Alpha web interface only far enough to match Twitter’s features and then moving on to other things. Instead, they could have kept improving Alpha until it was significantly better than Twitter, so good that it couldn’t be ignored. By doing so, maybe they would have also more effectively demonstrated the power of the API underneath.
I assume that App.net chose not to do this so they wouldn’t compete with developers. After all, the service was founded on the idea that developers should be respected and given every opportunity to succeed. Finding the right balance to showcase the platform with first-party apps without stepping on developers is not always easy. We can argue about which missteps were the most costly, but the founders never wavered on their original principles and they promoted every app that launched on the platform. That means something.
As for outrage not lasting long on the internet, Marco’s totally right. I just don’t forget that easily.
Justin Williams covers several aspects of this week’s App.net news, comparing it to his own Glassboard service. On finding a profitable niche:
“Finding an audience of people interested in your platform is challenging. This isn’t Field of Dreams where if you build it people will magically appear. Once you find that niche of users, you’ve got to ensure they’re also the type of folks that are willing to pay to support your platform. If they aren’t, you keep looking for a niche that will sustain your product.”
He also hits on the main thing that was probably holding App.net back: the stigma that it was just a Twitter clone. I’m more than a little disappointed that fellow developers didn’t get the power of the App.net API. Does Sunlit look like a Twitter app? Give me a break. App.net is hands down the best API of its kind.
So now we figure out what’s next. In the short term, not much changes. Tomorrow I’ll read my App.net timeline, make a few posts, reply and star as usual. Next week I’ll do the same. At WWDC I’ll use App.net messaging apps to coordinate meeting up with friends.
There’s no shame in shooting for the stars and missing. I’m thankful that even as the founders tried a few things outside micro-blogging over the last year, they never compromised on their original mission for the service. They never sold out users or developers, and the servers hum along in testament to that fact, as if nothing that’s good will ever really change.
Before some of the recent discussion about the future of App.net, Colin Pekruhn asked a question, directed at Ben Brooks and me, about whether we’d go back to Twitter if App.net failed. My answer (and his) was a very clear “no”. Here’s what I said:
“I’m very stubborn and not going to reverse my decision on Twitter. If ADN fails I’ll blog more.”
The stubbornness deserves a little more explanation. Because programmers are pretty opinionated folks. When we feel strongly about an approach — to languages, to UI design, to backend architectures, anything — we’ll plant our feet in the ground and argue with coworkers about the right way to do things. And it’s easy to dig in, start coming up with more justifications for a choice before taking a second look and seeing if it’s actually the right thing, or whether we’re just fighting for something because we want to get our way.
I put a lot of thought into no longer posting to Twitter. I often bring up my low Twitter user ID (#897) because I think it helps underscore that I’ve been on the service a long time. I get the history of it. I was there when it was all done over SMS with my dumb Nokia phone. I had fun with early experiments on the platform, like my sadly abandoned @story140 account, my @wii codes service, the Tweet Marker API, and of course the two products I continue to support to this day: Tweet Library and Watermark.
I stopped posting because at some point the anti-developer attitude at Twitter became too much. The limits on user auth tokens, which have already killed a few popular third-party Twitter apps; the problems with shutting down IFTTT recipes; the guidelines that restricted how you could use your own tweets. This is all fairly well documented and I’ve written about it before. I leave my personal account silent as a small protest.
I knew leaving would be difficult, so I set up a series of posts to discourage my future self from ever joining again. My final tweets were timed to go out on the anniversary of Steve Jobs’s death. They’re a collected moment, a tribute to both Steve and how great Twitter could be. I like that they’re forever pinned at the top of my profile page.
The best programmers aren’t so proud that they won’t admit when they’re wrong. There’s a time to fight for what you believe in — your coworkers don’t agree with how you want to build that feature, but maybe they just don’t see it clearly yet — and there is a time to admit you made the wrong call and move on. Saying “I was wrong, let’s do it your way” is a powerful statement and moves a project forward. I never want to ignore Twitter just because I’m so stubborn I refuse to admit I overreacted and that it’s time to crawl back to Twitter and accept defeat.
But here’s the thing: I wasn’t wrong. Every reason I gave above for leaving Twitter is still valid. I have friends at Twitter doing great work — it’s truly incredible what they’ve built, from scaling the backend to how the iOS app works — but Twitter is too big and successful to change now. We can’t rewind the clock to when Twitter was a tiny company that cared more about developers than advertisers, so I won’t be back.
135 episodes already? Hard to believe. But we’ve been pretty consistently putting out weekly shows for a while now. Funny thing about starting early and just sitting down to do work every day or week: eventually you end up with something big.
On this week’s show, Daniel and I talked about Apple’s stock, rumors of a search engine, and a follow-up on my Twitter ads experiment. I like how this episode turned out.
Right after publishing yesterday’s post on mirroring content, I added a link to IndieWebCamp’s POSSE, a project from Tantek Çelik to provide a framework for mirroring posts to different services. It looks like that group is doing great work to identify microformats that will make this a more open standard.
Noah Read also rolled his own solution for writing posts on his site first and then letting them flow to Twitter, App.net, Flickr, and other services. He calls them Snippets:
“Microblogging and social sharing will survive, whether or not the current players do. So I wanted to take control of the things I publish on these networks, without abandoning the great things only they can provide, the conversations and reactions to what is shared. So Snippets are the way I will post to these services from now on.”
Check out Noah’s snippets feed. I especially like the name. As a programmer I’m used to thinking “code snippet” when I hear it, but with enough use it’d be easy to reclaim its normal non-code definition.
