The key idea here is that Twitter could monetize better using their existing functionality and popularity of using their API. I really think there are a few potential great ideas here. First, twitter could syndicate ads, and rev share. Or even inject ads in tweetstreams if they don’t get adoption. Mildly dickbar, but hey, ya gotta make money. Then offer either clients or users to have a pay (non-ad) version. This could be paid for by the user, app, or a mix. Since most non-official twitter clients tend to already do this, it seems like a no-brainer.
The other revenue stream could be charging for bots. Allow developers to create “bot" accounts and identify them as such, then rate-limit how many tweets they can make, score them for quality, etc. You could charge either per tweet, or a flat monthly fee. Either way, developers would pay since it lets them use a platform they normally wouldn’t to communicate with other users.
I don’t think the “promoted tweets" are all that bad, but if users don’t really use trends, then forcing them to is just unnatural and awkward. There’s definitely going to be friction as twitter tries to figure out a method of monetizing, but I think they could do a better job of listening to their users (including developers), and figuring out what they would be willing to pay for.
gbb:
There was a quiet fury over the weekend (quiet because the spark was set EOD Friday while all the tech mavens were drunk at SxSW) when Twitter—in its second DickMove-Toward-Monetization™ (the first being the much discussed #dickbar)—announced that 3rd-party client developers could go ahead and fuck off. This infuriated be, as a user, since I hate using Twitter’s site (and Mac app), but adore using their service by means of 3rd-party apps. What’s worse is I’ve been trying to figure out how they’d make money since long before most people had heard of retweets.
When Twitter’s clout began to grow, and non-tech-nerds began to flock to the service to complain about the hoagie they just ate and declare every annoyance FML-worthy, I recall many conversations with fellow start-up tech types that followed the same pattern:
Me: So, Twitter’s getting pretty big…
Them: Yeah, they’re really rockin’ it!
Me: Uh, yeah. But, um, what exactly is their business plan?
Them: Nah, dude, you don’t get it. They’re gonna be huge!
Me: Exactly. I don’t get it. They’ll be huge, but how does that translate into money?
Them: They’ll get so big that, you know… companies will be throwing money at them to be part of the buzz! Plus they have TONS of VC money.
Me: But how? And buzz always dies… how do they plan to survive? Ads? I mean, ads don’t work well with off-site apps feeding off the info.
Them: Nah, man… its… you just don’t get it. It’s all about size and buzz. It works out in the end.
Essentially, that’s about as much sense as anyone ever relayed to me. For a while, I thought I was just stupid—a designer in a tech biz world. I’m not amazing with numbers, but something was missing from the equation.
Read More
twiiter
monetization
developers
Yes, writing code can be hard. It can be frustrating, and difficult at times. But you have it easy.
Just look at the original pacman source code.
Also beautifully illustrated as a distmap below…
programming
pac-man
I had a simple goal. I wanted to find the absolute worst 100 movies on netflix. You see, I’m a bad movie fan. I’m not talking a little bad. I’m talking the worst of the worst. The unwatchable. The unthinkable. I’ve found the humor of them and they totally crack me up (much much thanks to Jane). I was also very much inspired by IMDB’s Bottom 100.
So, I set forth on this task. First, I looked at Netflix’s APIs. I started down the path of using their REST API, which wasn’t bad, but had a few drawbacks.
First, you can only search movies by terms. This makes this a bit difficult for searching their catalog by rating or by pretty much anything else. They do have a full index, so I set off in fetching that. It took a bit to download the full catalog (around 300M), and it was a bit of a pain because it was behind their oauth APIs. After that, with grep and sed I was able to extract out the 76k or so titles from the catalog that were movies (not TV Series or People or Genres). Here is the simple client I wrote with oauth & crack. But the catalog didn’t have user ratings, so I had to go fetch and store all of them, then find the worst.
This was a great chance to play around with redis - it supports sets with scores and it’s wicked simple and fast. So, I whiped up this code so that I could run this code and determine the worst movies. I was all set.
Except one problem. Netflix’s API limits are 5,000 requests a day. If I run this every day, that will be 15 days until I can finish my app. That’s no fun. So, I went back to the drawing board, and looked over at Netflix’s OData APIs. I had never really heard of OData before, but it looked to provide a way of search and filtering on the data that I wanted. After finding the ruby odata gem, this gave me the start of what I needed.
I ended up whipping up this bit of code, which allowed me to not only search and sort by average rating, but I could also filter by DVDs available and Netflix Instant.
From there, it was a matter of throwing it together in a rails app and deploying to heroku. Heroku is simple and easy for hosting rails apps, and free for smaller usage.
So, I finished up and deployed it. I then realized it was a bit slow (from looking at newrelic), and decided to add some caching. Heroku provides a free memcached plugin (up to 5M), so I plugged that in and fragment cached the views. Since this data doesn’t seem to change often, seems like a pretty good compromise.
Challenges, Issues, Final Thoughts
All in all, pretty simple and fun. And not bad for a small weekend project. There are some take-aways. First, I still can’t get this 100% right. Netflix exposes average ratings, but not number of ratings. So, if there are ties, then I can’t sort by number of votes next (which is really more fair and accurate - it’s much harder to maintain a low rating the more votes that come in). Second, I’m still having issues with the ruby odata client filtering by Genre. I know it can be done, but I haven’t been able to get it to work yet with the gem. Ideally, I want the worst for each Genre as well. Overall, Netflix has done an okay job with providing some APIs, but they could really use some love. They last updated the Odata “preview api" about 10 months ago, they last updated the REST API 2 years ago. They were hiring 7 months ago, so I’m hoping they got their new devs and will be making some changes soon.
So, now it’s off to the movies (if you dare).
ruby
netflix
weekend project
worst movies
I’ve always though that xmarks (formerly foxmarks) solves a great problem, and provides value to it’s users. But, a few days ago, xmarks announced they are shutting down. They do give a great history on what lead up to this decision and why, and having known people that work there, I can both understand what went wrong, and why.
Here’s something even more interesting. After a few days and outcry from it’s users, xmarks is now considering staying alive by charging it’s users. I’m sure this seems blindingly obvious to outsiders (charge your customers), but there are a number of reasons why didn’t ever charge.
My take is they should have started charging long ago, and in fact the $10/year is way too cheap. They could get away with $3-10/month. Yes, converting from free-to-pay is a difficult process, but it can be done, and it is worth it. At TeachStreet Dave has written and talked about how we made the transition.
No, it won’t give them a crazy 10-100x return. In fact, they still likely need to find a different way to grow their business and pivot until they find it. But charging for their service allows them to cover their costs and keep their business running while they can grow.
teachstreet
xmarks
free-to-pay
I’ve been a rapid Getting Real, Rework, Ruby On Rails, and overall 37 Signals fanboy for a long time. But I’ll tell you something — I’ve never used their products (other than rails) until now.
Recently, I’ve been working with a project with a couple of overseas teams, and the project manager uses Basecamp. There are a number of things it does well: it organizes for you, handles email updates to tasks, handles attachments well. But there are a shocking number of things that it doesn’t do, or does poorly. Maybe the product is better suited for designers or a design shop (me being a developer and all), but it just seems like there are holes here. I understand the 37-signals philosophy (and trust me, if you work in my office, you’ve heard me spout it enough), but these are a few things that I just don’t get.
No time estimates
There is no place for adding a time estimate for a task, only a due date. This doesn’t work at all for any complex project - dates are meaningless, especially since stuff is always late, and the dates are always shifting. Time estimates (or points or jelly beans or whatever in the SCRUM world) are also going to be wrong, but at least they allow you to communicate that this work is more expensive (will take longer) than this other work. Pretty important communication point for Task-owners and Task-definers.
Tasks have no correlation to Milestones
Maybe I’m missing something here, but if tasks can’t be assigned to a Milestone, then how do you know your progress on reaching that Milestone. I might just be missing how to do this, but I’m not sure.
You can’t change To-Do details on the Comment page
This is more of an interface miss to be, but I find that after discussing that item, I sometimes need to change the details. Not having a way to change the details on this page (or even a direct link), means I have to go back and visually search the To-do list. This can take a bit of time, and get frustrating if you do this a lot.
Too much Drag & Drop
This is a bit more of a usability nit, but I find that drag and drop can sometimes be difficult to use. If you start re-ordering items you have to drag and hold and it can be time consuming. It’s good in some cases, but it would be easier in many cases to have “Move up/Move down" arrows (since those tend to be common use cases). Also, the entire bar should be draggable (rather than just a “handle"). The hover-handle usually means a bunch of extra mouse movements to make it show up, then you have to move back to get it to move, then drag. That’s a lot of work for a quick change.
Why 6 categories of messages?
The six categories of messages are “Assets", “Copywriting", “Design", “Development", “Miscellaneous", and “Transcripts". This might be because I’m not an admin, but why these six? What if I was a construction company? Or a lawyer? Or an accountant? I’m not saying that you should let users go hog wild and create 100 categories, but at least letting them rename them or customize them, they might be more useful to non-design shop (or even different design-shops).
37siganals
basecamp
tech