Mobile devices as keys to your personal cloud

April 30, 2013 | 1 comment

Jotting down some quick notes for something to consider: mobile devices as proxies that redirect content types to services as required, cacheing data on its way to / from the Internet.

Some properties and use cases:

  • I take a picture, and my mobile device knows about the services I use that accept photos, and can upload to them automatically when I get a connection. My mobile device has a camera built in, but I can also push from my professional camera to it.
  • I place my mobile device onto a PC to log into it (I may have to authenticate on both devices). My preferences are downloaded from the Internet if I have a connection, or retrieved from the cache if I don’t. I can then save my documents to my mobile device seamlessly, which in turn will push to the Internet when I have a connection.
  • I can install new services as easily as installing an app on my device.
  • I can configure my services as easily as the settings on my device.
  • The interfaces between my device and the outside world are standard. So, for example, to push a photo, my external camera just needs to know about the “pushing data” API; it doesn’t need or want to know that my photos are being synchronized with Dropbox and my home server.
  • Services like identity and storage are interacted with through abstract interfaces. However, my mobile device is not required: one of my Internet services can speak to another one of my Internet services through the same interface standard, even if my device is off. Feeds of data are also provided through those interfaces.
  • My most recently-used data is always stored on my device for easy access.
  • My mobile device is actually an interface to a proxy for all my cloud services, and I get to control everything I do on the Internet through that proxy. Different devices have different networking capabilities, like NFC and Bluetooth, but the API interfaces remain standard.
  • Because that proxy also exists on the Internet, I can buy a new device and connect it to my identity at any time. I can maintain multiple devices. And I can reconfigure my services to point to a different proxy if I want to change providers.

Mobile devices become your gateway to personal computing, and help blur the lines between local and cloud. Everything is accessed through the same interface; your mobile device has enough storage and intelligence to understand how to deal with the different contexts in which it is used.

Just a thought.

Software factories vs software universities

April 29, 2013 | Leave a comment

I’ve worked in startups for almost my entire career – sometimes my own, sometimes companies started by other people. I’m good at what I do, and I love it: I get to create tools that empower people to do things they previously couldn’t, or that were substantial obstacles. Usually that involves some kind of democratization; a righting of an inequality of access. I love creating these platforms, I love watching people use them, and I love evolving them in partnership with the people who use them.

I’ve become more aware that some of my friends in technology startups aren’t having the same experience. We all love technology, but while I find working on it liberating, they find it soul-destroying. They complain about disconnects with management, and that their opinions aren’t listened to. (It makes me feel lucky to work in the environment I do.)

I’m contacted by a lot of recruiters and IT consultants (spoiler: I don’t think I’ve ever used any of them), and over time I’ve become aware that the way in which they talk about technologists is another side of the same coin. They complain about – or often solutions that address – the same disconnects, but from a management perspective.

It’s a mistake to create a them-and-us divide, and it’s impossible to say “this is what developers need; this is what management needs”. Nonetheless, a little empathy goes a long way, and with very little thought about the requirements of the different positions, it’s easy to see why these disconnects occur, and mitigate them.

Great developers are experts in discrete logic. They sit and write logical expressions that represent a desired experience, and don’t just have to think about how that logic resolves, but also about every single thing that could possibly go wrong. It’s not a million miles away from being a lawyer, and computer programs aren’t a million miles away from contracts. Both need to be logically watertight even given contextual circumstances that the author hasn’t thought of; both need to be usable; making a complicated program/contract simple to understand and use is not a simple challenge. Both professions have a reputation for being difficult to get along with.

Finally and most importantly, writing both software and contracts is a creative act. If you want a high quality product, you don’t just do it by numbers. Great developers and great lawyers are artists who are constantly learning and building on their skills. (The distinction blurs even further with user experience developers, whose job is, in part, to translate discrete logic into an emotional response.) They are not simply back-room technicians, and their ideal workplace is something akin to a well-paid university, where they can learn, create and innovate in a nurturing environment.

Startup founders and managers are, in my experience, significantly more financially motivated than developers. (You need to pay everyone competitively, but founders want to sell, whereas developers are often happy finding new, interesting ways to make something work.) This is important. While, depending on their background, they may not have the same grounding in logic as a developer, this isn’t to diminish them: they’ve probably got lots of other skills that the developer might not have, not least an ability to market and sell, and hopefully, a strong sense of vision. (Indeed, if your founders don’t possess these properties, you’re probably in trouble.) Nonetheless, often their ideal workplace is more like a factory, where a decision is made and everybody falls in line.

It’s silly, in a way, because everyone should be – and should feel like they are – all working on the products and services they’re trying to create together. The problems lie in how these two perspectives collide. Inexperienced managers, particularly in smaller startups, micromanage. They want to know every little thing, and want approval on every decision, which in turn means that developers will need to explain the logical underpinning behind their decisions. Worse, they may have to explain why a proposed solution won’t work. Unless these situations are handled delicately, the former has a high chance of making the developer feel undervalued, while the latter may make the manager feel like his or her authority is being undermined.

This is one of the reasons that so much startup literature focuses on hiring correctly. It’s not that some people are wrong and shouldn’t be hired; it’s that you, as a manager, need to feel like you trust them to make the right decision. A hands-off approach (combined with both clear communication and discussion about goals) for a creative, skilled knowledge worker will empower them to make stronger decisions, and make better software. Your main jobs as a manager are hiring correctly and maintaining infrastructure and an environment where your employees can be productive.

Meanwhile, on the other side of the spectrum, a professional developer needs to understand that everyone is a part of the business, and keeping the company afloat is something everyone needs to be concerned with. It’s important to bear those management motivations in mind – they have a fiscal responsibility to the company and its employees – and not think of business considerations as somebody else’s problem.

Given the right environment, that shouldn’t be a problem. If a developer feels like they are trusted to be creative, and to make the right decisions to create software of a very high standard; if their skills are a correct fit for the job that needs to be done; and the environment is such that they can ask questions and provide feedback without fear, and comfortably get work done; if you promote a culture of empathy and try to make sure everybody is valued; then you’re already a long way down the road of reducing that friction and making sure that people love to make great software with you.

It’s a tall order. But nobody said running a startup would be easy.

The Progressive (Profitable) Web

April 2, 2013 | 2 comments

Ryan Holiday laments the loss of Google Reader and RSS in general in Our Regressive Web, arguing that if someone came up with them today, we’d think they were brilliant ideas:

Nothing better has risen up to replace them. The underlying needs of a fairly large user base (that these services meet) still exist.

We’re just regressing.

[...] RSS is impervious to blogging’s worst, but most profitable traits. [...] No wonder nobody ever pushed for widespread adoption. Of course it died a slow death—along with Google Alerts and Delicious. Their mission is antithetical to the ethos of our new media age. Where noise, chatter and pushing—not pulling—rule the day.

Our Regressive Web by Ryan Holiday, on Medium

He’s right. Aggregated content – content on the reader’s terms – has a huge potential userbase, but it wasn’t profitable for either the bloggers or the aggregators, so it languished. Sure, you could tack some Google Ads onto the end of each post in a feed, but control over the form that the content is presented in is granted fully to the user. Where’s the opportunity to upsell? Where are the branding opportunities or the baked-in communities, carefully designed to maximize ongoing engagement?

The irony is that blogs have actually downgraded their on-page advertising over time. If you visit TechCrunch today, you’ll only see two ads above the fold. Check out io9, and you’ll see none at all. The redesigned ReadWrite has a few more: a giant banner above the fold, and then four small squares with another ad in the stream of content itself.

Wouldn’t it be nice if you could have your cake and eat it, too? Allow the user to consume content on his or her terms, while also allowing the content producer to make money?

Here’s an idea I’ve been working on in my own time. It’s a little technical, but bear with me:

  1. Add a simple social layer to the web. I still like the idea of the HTTP header I described in httpID. Your site may connect to my site with a mechanism like OpenID Connect and get an authentication token automatically. Think of it like a one-way friend request. Of course, I can then reciprocate by connecting to your site to create a two-way relationship.
  2. Add authentication to feeds. Each feed has just one URL. An aggregator may sign the request for a feed with an OAuth-like signature. (We’re sidestepping HTTP digest auth for obvious reasons.) The software producing the feed may choose to acknowledge the signature, or not; by default, you get all the public posts you’d normally get when accessing a feed.
  3. Manage connections and restrict access to content. I see everyone who’s connected to me from a control panel, and can reciprocate from there. More importantly, I can add any of my connections to access groups. So if I add you to a group and publish a piece of content so that it is only accessible by that group, when your site requests my feed using a signed request, you’ll see that content.
  4. Optionally: sell access to premium content. Once you can selectively broadcast content to a finite group of people, you can sell access to that group. (And of course, you can have more than one paid-access group.) For example, I’m a subscriber to NSFW, a paid publication with an online presence. They could push all their articles to me as a subscriber, while making a handful of taster articles available to everyone. You could even include a pointer to a subscription URL within that social handshake from part 1. If you decentralize the financial transactions (and why not?), you could even give a small cut to the platform owner.

All of the above is complementary to feed standards like RSS and Activity Streams, as well as to federated social web protocols and methodologies like OStatus. It’s super simple to both use and implement – but could add a layer of commerce to the content web, while also decreasing our dependence on large content silos whose interests are not in line with their customers.