Category Archives: Technology

on the difference between communication, news, and entertainment

Recently it’s become plain that Twitter plans to add Facebook-style filtering to the Twitter timeline. In other words, Twitter would reserve the right to add or remove tweets from your timeline, rather than sending through every tweet from every account you follow (and none from those you don’t).

Twitter’s stated goal is to make your timeline more engaging, which makes sense based on how they’re monetizing the service. Twitter charges advertisers to promote content, which like any other advertising requires a big block of people constantly paying attention to be worth anything.

For some users, filtering like this means nothing less than the end of Twitter. That may seem overblown, but I think it’s a fair assessment. To be specific: filtering the timeline changes Twitter from a communications service into a news or entertainment service, which is inherently less valuable to me as a Twitter user.

I’ll step back and define some categories:

Communications services involve connecting to a network, then sending or receiving over that network with any other member, as a peer. Examples include mail, phone, ham radio, text messaging, email, IM, and Skype. Connecting to the network may involve cost (like phone service) or registration (like ham radio), but once connected you can send and receive to and from anyone. Communications services are often judged by the completeness and availability of the network (vs. dropped calls or missed emails).

News services involve curated content made by producers and received by consumers. They might use their own network (like newspapers or television) or piggyback on communications networks (like email newsletters or sports updates by text), but the content itself is their primary concern. News services are often judged by the accuracy and timeliness of their information. Choosing whether to cover a particular story is considered an editorial decision, but news services can get in trouble for presenting edited content as truth. (Thus “recorded earlier” notices, or “this interview has been condensed”.)

Entertainment services are like news services, but go a step further; they curate content to be engaging, without the requirement to be true or accurate. Entertainment services often go hand-in-hand with news services, delivered by the same network (like television) or even sharing the same packaging (like newspapers).

The lines between these are fuzzy, but one yardstick to use is the kind of complaints you’d find reasonable in each case. We complain to the phone company when we can’t make a call, but we don’t complain to them about getting 20 tech support calls from family each day. We complain to ESPN when they don’t cover enough soccer, but not that a broadcast game didn’t feature enough goals. Conversely, if the phone company blocked your aunt’s tech-support calls or ESPN added CG goals to the game, that would be unacceptable. You wouldn’t see it as “more engaging content”; it would make the service inherently less valuable to you.

At its core, Twitter is (and has always been) a communications network. It’s a broadcast network, like ham radio, but if I’m sending and you’re listening you expect to get my message. It’s a free service, like IM, but you’d rebel if you started receiving IMs from advertisers or found companies on your buddy lists without adding them. It delivers news and entertainment content, like the mail, but you’d be shocked if the post office rearranged your newspaper or tucked another DVD in the Netflix sleeve.

The justification Twitter gives for adding tweets to your timeline – hey, these are still real tweets, not ads! – misjudge the category they’re in. If CNN swaps news stories with other news, that’s an editorial decision we expect them to make. If AT&T connects my call to a random neighbor because my wife didn’t pick up, that’s bizarre and unexpected.

Considering it this way, I’m not surprised at all that Twitter users are threatening to leave if filtering is added. I’ll probably leave myself, and look for a social communications service that knows what kind of network it is.

Patreon and the future of free software

Crowdfunding is big, and Patreon makes it useful to frequent makers of free art. The model works so well that I think it might revolutionize the way free software is made and paid for.

Paying for software sucks

Ever try applying a mod to Minecraft? They’re free to download, and they can add immensely to the gameplay. The trouble is that to pay for them, the developers put the files behind the nastiest advertising-based paywalls I’ve ever seen.

Finding ways to fund free software is broken. Part of it is the broad and fuzzy meaning of “free” here; it might be crucial open-source software like Linux produced by thousands of developers, or a freeware game made in an afternoon. It might be “free” and supported by ads (like those mods), or “free” and funded by a deep-pocketed patron who benefits from it (like Google Chrome).

Paid software isn’t much better. Despite the revolution brought by app stores (Steam and iOS in particular), the pay-up-front model still encourages developers to concentrate on a flashy big release with lots of features. Bug fixes and UX improvements are appreciated by users, but those users aren’t paying anything extra to get them.

In general, though, there’s a developer who has to choose between building your app and working on something else. Whether you’re waiting for a bug fix that keeps Kafka from paging you at 3am, or an update that adds reentry heating to Kerbal Space Program, you might find yourself wanting to shovel a little extra money in that developer’s direction to help them choose.

From the developer’s side, the ideal business model would be to give away the software to as many people as possible, then pick out the ones who can’t live without it and charge them as much as they’re willing to pay, monthly if they’ll put up with it.

Enter Patreon

Patreon was created in 2013 by Jack Conte, a musician who wanted to get his videos in front of as many people as possible. Jack didn’t like the two choices available to pay for them: YouTube advertising and iTunes. He was tempted to try crowdfunding, but couldn’t imagine running a new Kickstarter campaign for every new video just to cover a few hundred dollars.

Patreon works a lot like Kickstarter, but it’s progressive and recurring: Someone who loves Jack’s videos and wants him to make more can go to his Patreon page and pledge $1 toward the next video, which carries over to each video after that. Jack can then see how much patrons have pledged for the next video, whether $3 or $3000, and budget accordingly. When the video is done, Jack distributes it for free (to everyone, not just backers) and finds new people who love the video enough to kick in another dollar.

Patreon is new, but it’s already working well for both big and small projects. It provides recurring income to the artist, and a direct connection to the patrons. The patrons are paying a small amount for each release ($1 isn’t uncommon), but they can easily see how their pledges add up to give the project a decent budget. In some cases, artists have already dropped advertising because it annoys patrons who are kicking in enough to offset the income.

The key to Patreon’s model is that it encourages frequent releases of art made with the patrons in mind. When Jack is deciding whether a new video is worth doing, he has two natural questions to ask: “Will my patrons think this is worth the $1 they pledged?” and  ”Am I willing to give up that patron money if I don’t do this?” The result is a regular cadence of good art.

Patreon is ready for free software as-is

If you’ve worked with an open-source software project, this might sound familiar to you. There might be lots of people waiting on new releases that fix bugs or add crucial features, but there are only so many spare hours in the day to work on them. A steady stream of patron dollars might encourage developers to work on their free software projects rather than take a contract job or start a new app for the App Store.

Patreon is neutral about the kinds of projects it accepts, so a developer could theoretically set up a Patreon page and start accepting backers right now. Each time an update is released, instead of linking to Youtube the developer would link to the update on GitHub or RubyGems or wherever they normally would.

Links back to Patreon could be added to the project’s README or changelog, or better yet mentioned on feature requests and when closing bugs. After a while, I imagine the relationship between backers and good releases would become plain in both directions: If you want better software, pledge more. If you want us to give more, make real improvements more often.

Frequent updates make better software

As a side benefit, the Patreon model would support the agile software development model. Each iteration (a short development cycle, usually with a fixed time) is judged on whether a notable improvement was shipped to customers, and patrons would be more likely to pledge based on the same metric. Bug fixes can be as valuable to existing users as new features, so there would be a strong business case for fixing bugs and making UX improvements each sprint that otherwise wouldn’t get on the roadmap.

Semantic versioning might see a surge in use, too. Rather than bundling flashy new features into big releases that justify re-purchasing software, the Patreon model would reward regular, repeated progress. Without a monetary reason to treat a point release as a major version (cough Twitterbot 3 cough), the field might be clear to set version numbers based on API compatibility.

Build funding into project sites

The obvious next step would be to create a patron-funding site specifically for software projects. GitHub is already a great community for describing, delivering, and collaborating on open-source software. Integrating patron funding would probably be straightforward. The same could be said of RubyGems or any other site that keeps track of version releases, too.

The tricky part, though, is getting the balance right; Patreon and Kickstarter have both done a great job (and put in some serious UX and community work) distinguishing “backers” and “pledges” from “donors” and “tips”, which seems to make all the difference. Software-patronage sites would have to work to connect the money pledged to real and regularly-delivered improvements to the software.

Still, I hope this model gets adopted by software projects sooner rather than later. I’d love to pay for updates to an amazing Minecraft mod by kicking in a dollar instead of dodging sketchy ads. Wouldn’t you?

how to ruin a Kickstarter

As Kickstarter gets more popular, I’m seeing more lousy Kickstarters. Most of them get ruined because they break the fundamental rules implied by any Kickstarter project:

1. If you don’t meet the backing goal, this project will not happen.
2. If you do meet the backing goal, this project will happen.

In case they’re not obvious enough, an example:

The Furry Pink Car Example

Let’s say I built an absurdist art car, and I want to add furry pink seats in time for the next Burning Man. I have a good reason to want the new seats: riding in the car without them is uncomfortable enough that people complain loudly. However, I don’t have the funds to add them myself.

I have some rewards in mind: an exclusive video of the seats being installed, a ride in the car itself, and for top backers, your name painted on the passenger door.

I know there are plenty of people who would back my project, so I’m ready to go. How could I screw it up?

Remember: If the goal isn’t met, the project won’t happen.

Easy. I could state my project in broader terms than I’m actually funding. “Absurdist Art Car at Burning Man 2013!” My project video could talk all about the car, with a quick mention of how pink fluffy seats would be nice.

When potential backers read that title and watch that video, they’re left with a big question: “You already have this car. Why do you need more money?” From the project page (which is all they have to go on!) it sounds like the project will happen whether they back it or not.

I had this feeling about a recent space company that went the crowdfunding route. The rewards were the usual space-company merchandise, and the project boiled down to “Help us do what we’re already doing!” My contribution wasn’t going to make a difference, so I didn’t bother.

How could I fix it? Change my title to “Pink Fuzzy Seats: The Only Way To Travel” and describe the benefits (and unreasonable expense!) of the all-important seats. If the money doesn’t come through, the art car will be as uncomfortable as it was last year, so no rides for anyone!

Great! How could I screw that up, then?

Remember: If the goal is met, this project will happen.

Messing this up is more subtle, but a lot more common. There’s an assumption underlying my whole project, something I might completely miss by (correctly) stating the goal narrowly. Take a look: can you spot it?

That’s right: I need a working, drivable art car. The rewards require it, the seats are useless without it. If something happens to that car so that I can’t take it to Burning Man, then I’m on the hook to fix it.

WITHOUT asking for more money. That’s the really tough part. Going back to those fluffy-seat backers with a second Kickstarter (or IndieGoGo, or anything like it) seems natural, but it’s dead wrong. By asking for new funds to make an old project possible, I’m casting doubt on my ability to complete that project at all. Why would my backers throw good money after bad?

I often see this problem with films and other art projects, the kind that have lots of steps. (Writing, shooting, editing, post-production, distribution, aigh!) It’s natural to make the film the project, with backer rewards to match, but if you’re just funding the first steps you should only provide rewards from those steps. (A rough cut of the film, for example.) Don’t offer the whole film if you’re only funding part of it.

In my case, I’m resolving to keep the car running and get it to Burning Man, no matter what. It’s something I would have had to do anyway, but now my backers are relying on me to get the furry pink seats on the road.

Note that I’m not going to list “car breaking down” as one of the “risks” or “uncertainties” on the project page, either. If Burning Man is canceled, that’s an uncertainty. If faux pink fur melts in the Black Rock sun, that’s a risk. However, I’m pledging to do everything I can to get the car there, and it’s reasonable to expect me to deliver on that promise.

the documentation lied: publish_stream vs. publish_actions

It may surprise you to discover I still work with Facebook on a daily basis. I did leave Facebook as a user over three years ago, but wrangling the Graph API is still a core part of my job. (For the web developers among you: It’s like your relationship with Internet Explorer.)

Last week I was updating Measured Voice to match changes in the Facebook permissions dialog, and I noticed that the documentation said one of my permissions was now out of date:

“Facebook used to have a permission called publish_streampublish_actions replaces it.”

– from the Facebook API’s Extended Permissions documentation

In a fit of eagerness, I broke the first rule of API usage* and switched out publish_stream for publish_actions. However, it soon became obvious that the two weren’t equal. The auth tokens produced before and after my update were markedly different:

with publish_stream

Requested Granted
manage_pages ? manage_pages
read_insights ? read_insights
user_about_me ? user_about_me
user_status ? user_status
publish_stream ? publish_stream
? publish_actions
? video_upload
? create_note
? photo_upload
? share_item
? status_update

with publish_actions

Requested Granted
manage_pages ? manage_pages
read_insights ? read_insights
user_about_me ? user_about_me
user_status ? user_status
publish_actions ? publish_actions

Requesting publish_stream gave me publish_actions anyway, which makes sense if the two are being treated as equals, but it also gave me a whole passel of other permissions I hadn’t asked for. As it turns out, at least one of those permissions is still necessary to do what I need: post status updates and photos to a Facebook Page.

But which one? I checked the documentation again, and… well, none of them are documented at all. Not listed anywhere, not mentioned as deprecated, not anything. Huh. Some of them do sound like permissions I’d need (photo_upload and status_update, for example), but without documentation it’s just a guess.

It sounds like the documentation is ahead of the actual API development, and reflects some design goal instead. Or maybe this is (yet another) API bug. Either way, I’m going back to requesting publish_stream until they get their facts straight. It still works. (For now.)

* “If it ain’t broke, don’t upgrade to the new revision.”

a note about passwords

Passwords bug me. Specifically, password management on most websites is maddening. Here are a few things to keep in mind when designing yours:

List your password-format rules up front. All too often, sites ask for a password with no indication of their format rules, then scream “ERROR!” when you don’t guess correctly. Yell at your users less by telling them what you want first.

Don’t limit the size of a password unless you absolutely have to. Honestly, it’s 2012. Databases can store unlimited-length strings, and the security of a password is improved by length. If your user wants to use the Gettysburg Address as a password, let them go for it.

Ditto for the content. If the user wants ancient Greek poetry for their password, then don’t freak out about the character set or complain that it doesn’t contain any numbers. Honestly, I once had a health-care provider prevent me from using spaces and punctuation in a password. “Alphanumeric characters only”. Way to be secure, guys.

Don’t limit the password format at all unless a compromised account will damage your service as a whole. No minimum length, no “special characters” requirement, no “at least one number”. I know, this is a tough one to swallow. Take an honest look at the worst a malicious user could do; if the only harmful effects are to the user choosing the password, then let them choose whatever they want.

Rate the strength of a password as the user types, and give hints on how to improve it. If you do this, though, get it right. It’s annoying to type in “correct horse battery staple” and have some out-of-date algorithm tell me it’s “Weak“. It’s worse if the system rejects it outright, but even the knowledge that your algorithm sucks makes me doubt the overall security of your system.

Check that your login fields are friendly to automatic login. I’m more likely to choose a unique password for a site when I can hand off the job of remembering it to my browser or keychain. Each time I have to click “forgot password”, though, my choice is going to be easier to remember (and probably less secure).