I’m launching a new paid developer plan for Tweet Marker today. It’s $75/month and includes a new admin dashboard with stats on active users, hits, and more. I’ve also expanded the API to support syncing which direct messages have been read.
Why charge developers now, after keeping the service free for 2 years? In part it’s because of something I learned from publishing the Core Intuition podcast with Daniel Jalkut. Because for the first few years of Core Intuition, Daniel and I had trouble getting episodes out very regularly; there was always something more important to work on. Adding sponsors pushed us to stick to a weekly schedule, and it’s worked out even better than I expected.
I hope the same thing will happen for Tweet Marker. Although I’ve put countless hours into maintaining Tweet Marker (and plenty of money on hosting), I couldn’t justify the effort to create new APIs because it wasn’t a revenue-generating product. Now I can dedicate more time to it, even with a modest level of support from developers.
Of course, I’m sensitive to the difficulty of transitioning from a free to paid product. That’s why I’m doing two things to make it easier for everyone.
First, I won’t be turning off any existing developers’ access to the service. The last thing I’d want is to break third-party Twitter apps currently in use. But I do strongly encourage commercial app developers to subscribe if they have the means to.
Second, I’ve created a referral program for app developers to let their customers know about the $1/month user subscription. This is a great way for developers to show their support even if they can’t subscribe to the developer plan. But even better, for developers who do subscribe, their account will be credited for each paid user they refer. This can effectively make the new developer plan free or significantly discounted.
This is a big change for Tweet Marker, but an important one to make Tweet Marker strong. I’m excited to keep working on it, so that Twitter apps can work even better together. Sign in here to learn more about it.
Nate Barham describes iOS 7 as layered glass:
“The best developers will see iOS as an operational model, not a visual one. Imagine a Tapbots app that, instead of removing the cute ‘I’m a twitter robot in your phone!’ aesthetic, doubles down on it. Zooming metal plates, ratcheting gears not shadowed from without but appearing from within the device, only now it isn’t a robot-esque layer over the stock controls, the UI becomes the character that the developer envisions—even more so than it has ever done before.”
I really like this post, but I’m not totally sold on the paragraph quoted above. Done right, it could be brilliant. But this is a very difficult thing to pull off, keeping the playful spirit of Tweetbot with a lighter, minimalist iOS 7 UI.
And related, if you missed Christa Mrgan’s recent Macworld essay, she also covers how iOS 7 will use depth and motion to switch from “faux 3D to real 2.5D”, with an example from Adobe’s After Effects. Makes me wonder if designers will need new prototyping tools.
Ben Brooks makes several good arguments for working from coffee shops:
“Coffee Shops started sprouting up everywhere in the U.S. because of massive demand for the coffee shop — not massive demand for coffee, mind you, but for the seats in the shops. This is evident with the way most shops are setup, but no more evidence needed than to look at the move of Starbucks providing free WiFi, instead of paid WiFi they started with.”
I agree. There’s no sense in fighting this trend, and the coffee shops that do will largely fail. But also, as customers, we should be careful not to abuse the privilege. I try to follow these simple rules when working from a coffee shop:
- I don’t take up more space than I need.
If there’s a line, I usually wait until after I place my order before claiming a chair.
For local small businesses especially, I leave a tip.
After a few hours, I order another coffee or wrap up and leave.
Ben also points to a post from CJ Chilvers about libraries. I worked from my neighborhood library earlier this week — it’s a really nice, quiet environment — but the Austin libraries don’t allow you to bring any drinks inside yet, let alone have an on-site espresso machine. While traveling in Oregon a couple years ago, I remember the Eugene public library having a really nice cafe and I was immediately jealous.
I love this detailed write-up of the Twitter backend as it exists today. Sending a tweet to your followers uses a massive Redis cluster with a couple terabytes of RAM:
“Let’s say you tweet and you have 20K followers. What the fanout daemon will do is look up the location of all 20K users inside the Redis cluster. Then it will start inserting the Tweet ID of the tweet into all those lists throughout the Redis cluster. So for every write of a tweet as many as 20K inserts are occurring across the Redis cluster.”
A listener of Core Intuition asked me today if I had second thoughts about no longer using Twitter, especially since I still maintain a Twitter app. We’ll discuss this on a future episode, but the short answer is: no, I don’t regret it. I have a huge amount of respect for what Twitter has built at a technical level, and for the opportunities it gives people to communicate. I just don’t like their attitude toward developers.
Dave Winer writes about Doug Engelbart and the pace of changing computing systems:
“If you want to get the most out of great developers like Engelbart, who are productive well into their 80s, you have to stop digging up the streets, moving the goalposts, bombing the cities, starting over just for the sake of starting over.”
While there’s certainly a time to burn the forest for new growth and opportunity, I have little patience for those developers who spend more time breaking old code than creating new value. Maybe it’s a sign I’m getting old — that I’ve lost my taste for innovation at a technical low level — but I don’t look forward to rewriting all my working code again and again.
Very little has changed in this regard since I wrote a blog post about deprecation in 2010, which (fittingly) also linked to Dave Winer.
Rene Ritchie has a nice comparison of black and white filters in iOS 7 and third-party apps:
“To create the comparison, I took the screenshots posted on Apple.com, isolated the unfiltered image, loaded it into the other apps, applied their filters, and then took screenshots of the resulting images.”
I’ve been working on an iOS 7 app that’s partly about photos, though not actually a camera app, and I always thought it’d benefit from a single great black and white filter. Not as one of a dozen filters, but as the only filter in the app — something strikingly different that would be noticed. iOS 7’s built-in filters and apps like Camera Noir have made me reconsider. Why reinvent the wheel when so much good work is being done on filters by other developers?
Related, the excellent mobile photo workflow by Rands.