Werd I/O

A while back, my out-of-warranty Macbook Pro's wireless antenna died. I had the card replaced; no dice. And unfortunately the antenna is in the screen, so to get working wireless back I would have had to get that replaced at a very high cost.

I went another way.

If you walk down the Networking aisle at Best Buy or Staples, which is what happens when you need a new wireless adapter in a hurry, you'll see that all the USB wireless dongles say they're for Windows only. Not a single one ships with a Mac driver, because I guess the Mac hardware is considered to be infallible or something. Maybe the cost-benefit analyses didn't show it to be worthwhile. Who knows.

Luckily, most USB wireless dongles are repackaged chipsets from other manufacturers. In particular, the Linksys AE3000 and a few other wireless-N models by manufacturers like Belkin are based on the Ralink (now Mediatek) RT3573 chip. I bought the Linksys AE3000 because of the build quality and speed capabilities.

Years ago, Ralink released some official drivers for Hackintoshes, which they've kept up-to-date. So after buying my Windows-only Linksys dongle, all I had to do was go grab the appropriate driver from their download page.

Or so I thought. You see, it turns out that the AE3000 didn't exist when the driver was written, so the installer doesn't know anything about it. You plug in your dongle, and nothing happens. What you actually have to do is install the driver and, before the final reboot after installation, go find the Info.plist file in /System/Library/Extensions/RT2870USBWirelessDriver.kext/ and add some information about the manufacturer. (After some adventures with text editors, I found that it was best to do this using sudo nano in a terminal window.)

And this kind of ridiculousness is why open source operating systems are a good idea. Nonetheless, despite the convoluted technical steps, it works: I have a working wireless-N connection via my Windows-only wireless dongle (even after an upgrade to Mavericks). I hope this helps someone else - and that manufacturers start properly supporting Mac OS X.

The BART strike is over: at the time of writing, they're expecting Bay Area Rapid Transit trains to start rolling at 4am, with a full service up and running by sometime in the afternoon. That's great news: the roads have been gridlocked here, and it's felt like the Bay Area has been brought to a standstill.

Nonetheless, I fully supported it.

The base salary for a train operator is $56,000 - a lot in most areas, but when a one-bedroom apartment runs for almost $2,000 a month, it's a salary that doesn't stretch very far. Particularly not if you have a family. And given that BART was running on a budget surplus, and worker wages were frozen for five years, it seems very reasonable to ask for more.

A second issue was safety: workers were asking for better lighting, and better protection against attacks. This request is all the more poignant given that two workers were killed on Friday.

I'm pleased that the union and BART management have reached a deal, not least because it was inconvenient to me: BART is by far the best way to travel around the area. What I'm less pleased about is the amount of anti-union propaganda I've seen from all over Silicon Valley. From tasteless jokes to threatening to replace them all with robots, it's not been pretty.

The purpose of unions is to allow workers to collectively organize and deal in a way that they could not as individuals. A company must negotiate for its best interests, by attempting to get the best value out of workers. It makes sense that the workers should have their own ability to negotiate with similar weight. Without this ability, wages, benefits and working conditions will tend to favor the companies rather than individuals. Here in the US, the labor movement was responsible for establishing the 40-hour workweek and the concept of having the weekend off, which were only ratified in 1940.

Unions have also been responsible for establishing the minimum wage, the concept of sick days, holiday pay, maternal leave, child labor laws and laws eradicating sweatshops in the United States. None of these are at all bad things, and while unions are not always a positive thing - just as company management is not always a positive thing - I'd argue that they're an important part of the fabric of working life. I have been proud to be a member of unions in the past, and if there was an appropriate tech industry union, I'd be proud to be a member of one now.

As Politico points out, a Harvard / University of Washington study showed that between a fifth and a third of the dramatic increase in income inequality in the united states (40%!) is related to the decline in union membership. While it's not the single cause, it's certainly hard to ignore, and points to a larger issue related to the evolution of workers' rights (and the perception of workers) in American society.

In January, Time noted that:

First, the fact is that when unions are stronger the economy as a whole does better. Unions restore demand to an economy by raising wages for their members and putting more purchasing power to work, enabling more hiring. [...] Second, unions lift wages for non-union members too by creating a higher prevailing wage. Even if you aren’t a member your pay is influenced by the strength or weakness of organized labor. The presence of unions sets off a wage race to the top. Their absence sets off a race to the bottom.

A victory for unionized workers, then, is a victory for all of us. Why on earth should a progressive industry like technology be against better conditions and pay for workers? I agree with Michel Hiltzik in the LA Times:

Blaming the workers for the impasse is a peculiarly one-sided interpretation of what's happening. Sure, you could say that 2,400 non-automated, human employees stand in the way of Silicon Valley's determination to "build something." But it's equally true to say that BART's nine board members and its general manager are the real obstacles to a settlement. Maybe Silicon Valley should figure out a way to automate them.

We're supposed to be making things better. As an industry, we may need to rethink what that means.

#bartstrike #labor #unions

One often-seen trope in tech industry commentary is: "the geeks will inherit the earth".

It's a nice idea, which appeals to a lot of people in this ecosystem; there's even a lovely symmetry to the idea that the people who were probably bullied and ostracized in school, at least to some extent, are the same people who go on to change the world in meaningful ways. And in a lot of ways, it's true.

It's not because geeks are in any way better, or more intelligent, people. Instead, my theory is that it relates to being an outsider. People who don't change themselves to fit in are, almost by definition, more likely to think independently. If an effective leader is one who creates stand-out strategies and is able to creatively and intelligently react to circumstances, it makes sense that independent thinkers would fit the role more readily. The popular kids at school are much more suited to be followers - they've essentially taught themselves how to follow fashions rather than create them.

MBAs are not traditionally good at startups for similar reasons. They've been taught cookie cutter business methods, which make much more sense as management tactics in larger businesses than in the do-what-you-have-to context of getting something off the ground. Here in San Francisco, arguably tech startup central, besuited MBAs are often thought of as not bringing much to the table.

But geeks have their own popular kids now. Startup culture has created its own norms; brogrammers swarm San Francisco and cities like it, following the fashions dictated by outlets like TechCrunch and PandoDaily. Not a single one is likely to change the marketplace, let alone the world - and with them comes a pervasive culture of entitlement and even bigotry that isn't a million miles away from the cool kids.

Outliers are always going to be the people who bring about real change: people who can't easily be described, and whose actions can't easily be pattern-matched to an archetype. Often, these are people who don't take direction well. They might come across as weird, or antisocial. But their ideas are like nothing you've ever heard, and given the tools, they will create things you've never thought of.

Someone once said to me, in reference to someone who they thought was weird, "one way of looking at it is that they don't think mainstream culture is good enough for them." Damn straight. Being mainstream shouldn't be good enough for any of us. There's nothing to be gained by trying to be like everybody else, or by fitting yourself into a pre-defined pigeonhole.

Me? I like weird people, and I like working with them. I wish I was weirder myself: it's a sign of creativity, independence, and intelligence. San Francisco has a name for people who follow; they're called "normals" - or, sometimes, "consumers". It's not a label to aspire to.

In fact, none of us need to be normals or consumers. Once upon a time, we were needfully forced into demographic categories, so that products and media could be created that would broadly appeal to us. The Internet has created a world where anyone can connect to anyone else, whether it's to talk, to inform, or to sell. Fashions of all kinds are meaningless in a world where products can be viably created for an audience of one. They're an artifact of the age of broadcasting; one that's long since gone. We're in a post-demographic age, and if you're still trying to follow the crowd, you're a decade behind.

#startups #outliers

When I left Elgg in 2009, I immediately started working on Outmap, a social geodata platform that you could use with any web browser. It never saw the light of day.

Outmap allowed you to collaboratively create map layers, either privately in a group, or in public. Here's two use cases that illustrate what you could do with it:

• Crowdsoucing useful free wifi hotspots Back in 2009, finding free wifi that worked well was a mission. Suddenly, you weren't alone: you could set up an Outmap space, and tell it to watch a hashtag, for example #freewifi. Users could then tweet with an address with that hashtag, or add geo-information to the tweet itself. Outmap would also watch Flickr for that tag, and check for location information either in the Flickr metadata, or in the EXIF data in the photo itself. The data then could be mapped, or simply displayed in a list based on your current location.
• Gathering (or crowdsourcing) scientific data Users could add fields with types. For example, if you were doing wildlife counts, you could take your GPS-equipped smartphone into the field, and as long as it had a web browser that supported the Javascript Geolocation API, that would be all you'd need to record a result. Your Outmap space would tie your numeric recordings of wildlife data to the location where you recorded them. And because it was all social, and tied to individual user accounts, you could examine (or even remove) recordings made by particular individuals for full accountability.

It was based on data tied to individual location points, but further developments would have allowed you to group points into areas, in order to better support some scientific applications. And again, it was all web-based used existing web standards, all social, and (like Elgg) had per-item access permissions.

Outmap couldn't be released for reasons I won't go into here, and were unrelated to the mechanisms of the platform (but were related to the fallout from my decision to leave Elgg). Let it suffice to say, it was out of my hands. I abandoned work on it in 2010, and moved on to work on latakoo.

Geolocation has evolved since 2009, and I think we all now understand that the web is something that we can access from anywhere, and that pages can know about your geographic context. Some other use cases were covered by Google Maps and (particularly) Findery, which is building up a world of memories, found objects and resources on a shared map. Geoloqi, whose founders I really like and respect, supercharges the kinds of use cases Outmap supported (as well as many others). Meanwhile, there are (and were) professional GIS platforms that are extremely powerful and used for many scientific and industrial applications.

I still think there's a place for this kind of functionality in an enterprise social platform. Luckily, I'm now in a position to work on that. Watch this space.

#outmap #idno #elggmistakes #geolocation

I don't think it's saying too much to talk about how we're building latakoo into a cloud media database. Customers from all over the world - a large number of which are television journalists - are using us to send footage, archive it in a searchable way, and synchronize it with their own enterprise infrastructure. Broadcasting and Cable recently discussed one of the things we're doing with NBC News, which leverages our API to distribute archive footage to paying clients. But every day, we're adding more hooks and functionality to allow people to build sophisticated media workflows with latakoo as the back-end.

Here's one example of how it works.

A journalist out in the field shoots some footage, and pulls it straight off the camera into the latakoo desktop app. (For example, we'll take footage from a Panasonic P2 card.) They choose one or more destinations, and hit "start". The app then intelligently compresses the footage, taking note of metadata like timecode, and stitches segmented video files into a single long piece of footage if the user wants it to. It's then rapidly sent over a standard Internet connection (some folks use 4G cards, others go to Starbucks or use sat phones) to our servers. There's an iOS app too, of course, and Android is on the cards. We're also releasing new versions of the desktop app later in the summer, which includes much faster uploads for high-bandwidth environments.

Once the media hits our servers, it might be transcoded into a format of the recipient's choice, and sent to their infrastructure. That's important, because media operations don't want to have to worry about format incompatibilities: they just need to receive the footage quickly, in a predictable, fast way. There's full individual and role-based permissions, so only the people of the recipient's choice can see it on latakoo.com, and of course they have full control over their infrastructure.

They can embed the video on the web, of course, but they can also add extras like automatic transcriptions, or push to a custom-branded video portal. They can also use our API to search, retrieve and manipulate their content (which is designed to make integration simple, unlike the SOAP-based messes a lot of professional media platforms are saddled with).

Internally, our platform has the ability to hook any custom metadata at all off the footage, and we're in the process of releasing that to our customers too. There are also tags, notes, comments, and everything you'd expect from a social platform for business.

We're a very small team, but I'm proud of everything we've put together. We punch above our weight, consistently, and although enterprise software might not be as sexy as the next Snapchat or Instagram, we get to be the delivery backbone for some very high-quality news operations around the US. They depend on us, and we're proud to serve them.

#latakoo #video #delivery

We got a mention in Broadcasting & Cable magazine!

You've got to be a subscriber to read it, so here's a pertinent excerpt:

One notable example of those efforts can be found at NBC News, which in 2011 became the first U.S. broadcaster to set up an online site that allowed clients to buy and download archive material, Fon-Sing says. “It is part of an underlying goal of opening up the archives so our clients have easier access,” she says.

To further improve those systems, NBC News is currently working with video company Latakoo to develop a new content delivery system. On a network level, tech teams are also using a new media asset management system that will improve the capacity and flexibility of the archive system.

You can check out the whole article here.

#latakoo #nbcnews #nbc

This piece was submitted as a position paper for the W3C's Workshop on Social Standards: The Future of Business, due to be held on August 7-8, 2013, in San Francisco.

Really interoperable interoperability

Much has been written about both the power of APIs to connect social applications in powerful ways, and vendor lock-in in the context of those APIs. Rather than usher in a new era of interoperability and open computing, APIs have allowed vendors to create new ways to lock users into their ecosystems.

In many verticals, simply gaining access to a product’s API documentation is enough to require complicated licensing arrangements, vendor evaluation of your business intent for the API, and often, an asymmetric Non-Disclosure Agreement. “Open” is the new closed: too often, the API is a proprietary product in itself. This is as true in social software as it is elsewhere.

This proprietary nature carries multiple business risks. Not only does it require that customers invest heavily in a particular vendor’s products, but should that vendor subsequently decide to discontinue those products – as happened recently in the case of Google Reader and a number of Yahoo! products – the customer must repeat that investment in another platform. Finally, recent surveillance revelations must be food for thought for any business using proprietary services to host sensitive data.

Sophisticated open API standards mitigate these risks, but developing support for these can require a significant expenditure, and the business case may not yet be clear to most vendors. There is no doubt that they occupy an important place in the emerging social landscape, but not all vendors, or their customers, can justify the level of technical expense currently required to “buy in”. Indeed, given a high enough barrier to entry, even ostensibly open APIs may inadvertently have the same ill effects as closed ones.

Proving it

Although there have been significant advances in the field over the last five years, there remains a need to prove the business value of decentralized web technologies. To many of us involved in both the industry and the movement, this seems silly: after all, the business value of other decentralized technologies, like email and the phone system, are hardly questioned. Nonetheless, in a world where centralized data siloes regularly receive multi-billion-dollar valuations, the onus is on those of us who are building more open technologies to demonstrate their worth. Note, it is not enough to argue their worth: we must build, ship, and actively demonstrate a profitable product or service with a business model where the decentralized social web is an inextricable component.

I believe that these compelling business models exist, and that they are most easily discoverable in the enterprise. However, belief is not demonstration: we must continue to test and iterate them. During this exploration phase, this means that, our software and underlying protocols must be easy to write, adapt and change. Ease of development is more important than sophistication; we must not create our own technical lock-in before we even ship.

The IndieWeb

The “IndieWeb” movement was founded by Tantek Çelik, Amber Case and Aaron Parecki, around their annual IndieWebCamp event. Although it was originally created to encourage participants to self-host their own web presences (a laudable goal in itself), over the last year it has also begun to incubate a number of simple social web protocols based around Microformats 2 and Webmention.

At its simplest level, assets on the web are marked up with appropriate Microformats 2 classes, so that any parser may obtain a consistent JSON representation of their content. Linked targets on the page are then pinged using Webmention (or pingbacks), which alerts them to the presence of that content. They may then go back and parse the source of the ping, discovering content like comments, replies, event RSVPs and favorites. Adding more content types would be trivial, and indeed, more are emerging every week. If a content type is not registered, the target page may simply register that the source “mentioned” it.

An obvious further implementation incorporates signed HTTP requests for both parsing and Webmention pings, allowing for lightweight authentication so that protected resources can be selectively revealed.

The protocols and standards under development within the IndieWeb community offer some unique advantages for testing decentralized social models:

1. They piggyback on top of an open, decentralized system that everyone has already bought into: the web itself. Indeed, on the IndieWeb, where possible, the web is the API.
2. They are extremely simple to develop for, allowing you to concentrate on building well-designed tools that meet human use cases instead of building support for social protocols.
3. Social software need not be “monolithic”. Suites can be constructed out of small, compatible pieces, loosely joined.
4. Major search engines support Microformats, so marking pages up to be IndieWeb-compatible may also yield SEO benefits.
5. The IndieWeb community actively embraces participation in existing closed networks through a process called POSSE, minimizing the potential business impact for entities transitioning to a decentralized model.

POSSE - Publish (on your) Own Site, Syndicate Everywhere, as coined by Tantek Çelik – accepts that your friends, contacts or customers are easier to reach on the social platforms they’re already using. Therefore, content on your own, independently-hosted platforms syndicate out to your audience across the networks they already use; links point back to the originals. In the short term, it becomes immediately possible to experiment with decentralized social models without losing your existing audience. Over time, it may be possible to transition those audiences to consume and interact with your web presences in a more decentralized way, ensuring that you can post on your terms, and they can consume on theirs.

While most implementations of POSSE concentrate on consumer social tools like Twitter, Facebook, Flickr and Foursquare, there is no reason why the same principle could not be applied to commercial platforms like Yammer, Avid Interplay, GitHub, Salesforce or SocialText – or any proprietary service used internally inside any enterprise, APIs permitting.

Idno as an experimental testing ground

Idno is one embodiment of an IndieWeb-compatible open source platform that can be installed across many hosting environments. It was originally designed as a replacement for older open source networking platforms, but rapidly evolved into a testbed for many of the ideas the IndieWeb community was proposing.

At the time of writing, decentralized social web activities supported by Idno include:

• POSSE posts to Twitter, Facebook, Flickr and Foursquare, and replies on Twitter
• The ability to comment on, or reply to, a post (or multiple posts) on another IndieWeb-compatible site
• The ability to “like” a post on another IndieWeb-compatible site
• The ability to RSVP to events posted on other IndieWeb-compatible sites
• The ability to post content, including status updates, blog posts, bookmarks, photos, geographic “check-ins” and events that other people with IndieWeb-compatible sites may comment on, reply to, “like” or RSVP as appropriate

Due to its framework origins, Idno allows developers to easily build new post types. Indeed, support for events and RSVPs – at the time unsupported by any other IndieWeb-compatible software – were built in a single evening, with one developer, directly after an IndieWebCamp event. Other software produced by IndieWeb developers began to support events and RSVPs the next day. By the end of the week, at least three separate software platforms supported the content type. There is no doubt that the barrier to entry is low for individuals and businesses alike.

Conclusion

The rapid development that IndieWeb standards make possible is perfect for testing business models relating to the decentralized social web. This does not undermine the technologies and successes of the wider federated social web movement, or of other open social software projects; however, it does allow models to be tested much more quickly.

The relatively low barrier to entry of the IndieWeb also may encourage more developers to take part (as has already been shown), and as such, it seems likely that the standards that community is developing may find themselves in wide use for some time to come. An obvious analogy is RSS, which is not a sophisticated syndication standard, but saw widespread use due to its ease of implementation.

Many of the prevalent models for social software are hostile to the needs of both businesses and individual users. The IndieWeb aligns software developers with their users, while providing simpler tools for development, and encouraging both wider participation and more experimentation. I believe the result will be accelerated innovation in social software, and a much faster path to validating business models for the decentralized social web.

#indieweb #w3c #socialweb #business #idno

Syndicated to IndieNews

This site runs on idno: an open source social publishing platform that I've been working on for the past few months in my own time.

You may know that I co-founded Elgg, the open source social networking engine, which is used by the likes of Oxfam, NASA, the World Bank and several national governments as a social intranet and learning platform. The original thinking around Elgg happened a decade ago. Given that, you shouldn't be surprised to learn that my original thought experiment was: What decisions would I make if I was building Elgg today, in 2013? What would I do the same way, and what would I do differently?

Some technical decisions

I knew that I could make a faster social networking platform, with a better templating engine, and a much smaller codebase - even while sticking to PHP as an underlying scripting language. Partially that's because PHP 5.3+ is a much better development platform than earlier versions. It's also because there are now some well-tested, intelligent back-end frameworks, like Symfony 2, and front-end frameworks, like Bootstrap.

One of the major decisions I made when we built Elgg 1.0 was that not only was it a hassle for plugin developers to write their own database schemas - it was undesirable to the point of being dangerous. We effectively faked a NoSQL schema in MySQL by creating a data model around entities (first-class objects like users and blog posts), metadata, annotations and relationships. People were taken aback, and it was row-intensive, but it worked, and it continues to work today.

Nonetheless, today we have NoSQL, so #idno is based around MongoDB. This means there are far fewer database transactions involved - and adding new data to an object is incredibly easy. Together with a plugin architecture based on lazy loading, and Symfony's excellent observer pattern support, as well as the framework code I've built, I'm able to write a new plugin in an hour or two. That's important for a system I'm building in my spare time!

Meanwhile, all of the things about #Elgg that were great - a plugin architecture, granular access permissions - are intact. And on top of that there's a faster framework, and a responsive front-end that works really well in a mobile browser. Great!

But that's not the end of the story.

The #indieweb community has existed for years as a force to advance the state of the independent web, and to promote ownership of our own spaces. IndieWebCamp is an annual event for creators to discuss their platforms, technologies and ideas.

One of the big concepts to come out of #indieweb has been #POSSE: Publish (on your) Own Site, Share Everywhere. The idea is that your friends or followers shouldn't have to join your site to engage with you; you should be able to post on your own site and be read on Twitter, Facebook, Foursquare, or wherever they happen to be. idno has built-in plugins for status updates, blog posts, images, checkins and events. Correspondingly, it also has plugins to #POSSE this content to Twitter, Facebook, Foursquare and Flickr - and writing more would be trivial.

That's just as well, because I've committed to only post on my own site and copy to third parties (where that's possible).

Reinventing the social web

This year, though, something else happened. Using Microformats 2 (a way to very simply embed meaningful markup into any web page) together with Webmention (a way for any web page to lightly ping the pages it references), the community participants created the first indieweb decentralized comments thread.

Using nothing more than the markup on their own web pages and a very simple protocol, the participants created the basics of a decentralized social community, where each comment is hosted on its owner's own site, but nonetheless forms a coherent, easily-readable narrative.

This is a very big deal.

It's a completely different model to traditional social networking, where content typically doesn't bleed outside the walls of a specific social site. It's also different to previous decentralized social networking efforts, which have been in many ways more sophisticated, but much harder to join in with. Because a simple IndieWeb-compatible social tool can be built in an afternoon, just as a simple RSS-compatible tool can be built in an afternoon, these concepts have a much greater chance of succeeding.

Needless to say, idno is now a first-class participant in the decentralized IndieWeb social community. I've implemented IndieWeb comments, and moved immediately to also implement decentralized events that anyone can RSVP to, as well as decentralized likes. It also integrates with Firefox's brand new Social API.

You can browse the web and reply to any page, on a site that you truly own.

As more sites and platforms implement the IndieWeb social standards, those interactions will become correspondingly more social. For now, though, you can go ahead and interact with the web already.

Beyond that, idno will continue to develop over time as a community platform in itself. I'm using it here on my own site as a single-person publishing platform, but it doesn't have to be that at all, and all those Elgg-style features will continue surface as time goes on. But there's a big, wide web out there, and it's important to embrace that as widely as possible.

idno's homepage is here. Meanwhile, I continue to do work I'm proud of in my actual job, working for latakoo to facilitate media storage and transfer for video professionals and the broadcast news industry. We're talking about using decentralized social networking there too - but more on that another time.

I've been thinking this morning about content types and granular access permissions (which, it turns out, is ground the IndieWeb community has already tread).

Activity Streams is a data syndication format with very granular content types, which is awesome - unless those content types dictate the kinds of content you actually allow people to create with your software.

Why should a content type be strictly a note, or an article, or a place, image, video, application? One of the amazing things about the modern web is that we can combine content types to create experiences that are richer than the sum of their media parts.

At the simplest level, I want to be able to (eg) include a photo with a checkin. But why not construct a post that's a photo followed by some audio followed by some text followed by an interactive widget followed by a non-linear video with an interactive layer on top of it? One of the neat things about the #indieweb is that you control your platform - and that should mean controlling the form of your content too.

Watch this space ...

#indiewebcamp

It shouldn't be surprising. I've been on the web and posting on the Internet since 1994, but posting in the usual way scatters my data all over the place. Short status updates end up on Twitter; longer, more personal ones on Facebook; checkins on Foursquare; photos on Flickr; audio on Soundcloud; etc etc etc.

My site here at werd.io is an attempt to change my posting habits from being silo-first to more of a #POSSE approach: Publish (on your) Own Site, Syndicate Everywhere. Now, all my status updates, posts, photos and checkins are here in one place, on a server that I own running code that I write, and copied to all those other sites.

It's made me think about posting much more deliberately.

A friend of mine often says that you shouldn't publish anything on the web that you wouldn't be happy seeing on a billboard. I don't think that's true on the whole web - for example, at latakoo we're building tools to make sending, storing and sharing private media content (video, audio, images, large data files) easier, including a self-hosted enterprise option that federates with our hosted .com site. But for the free, public, social web, it definitely makes sense.

This morning, I checked into my office, and then I checked into a local BBQ joint for lunch. Do I really need to share that? Possibly; possibly not. It's my choice, but at least having all this content front and center allows me to make it in a more informed way. I'll probably check in a little less often, except perhaps to announce my presence at venues for special events (like IndieWebCamp this weekend) or to "tweet" links to resources I think are interesting.

This is all new, and my thoughts on it are still baking. Having one stream has certainly made me think about my identity online in ways that I haven't for years. Maybe I'll maintain several identities? Run an anonymous site for frivolous checkins or photos of my latté? The jury's still out, but because I'm empowered to run my own platform, the choice is all mine.

#indieweb #indiewebcamp

There's been a lot of news stories lately about how technology companies like Google, Apple, Microsoft and Yahoo! may or may not be giving your data to the #NSA as part of a project called #PRISM. They deny it, news outlets confirm it and it's hard to tell what's real and what isn't real.

Whatever your political views, or whether you think government entities should be able to snoop on your phone and electronic communications, it's hard to argue that the sheen hasn't come off the consumer Internet industry. As the economist Umair Haque said earlier today:

15. There is nothing more lethal to an economy than the idea that people have nothing more to contribute than "information".

— umair haque (@umairh) June 7, 2013

The large online services have created a world where, despite the breadth of software's possibilities, the scope of our communications are limited. On Facebook, you can post status updates, links, photos and videos; on Google+, you can post status updates, links, photos and videos. What if you want to post a game, or an interactive multimedia presentation, or a live graph connected to real-time data?

Those things are hard for centralized services, because they've got to concentrate on common denominator forms of content - like status updates and photos - but they're much easier when you control your own site. If you could install your own publishing app as easily as an app on your phone, and then add new ways of posting stuff to that site just as easily, suddenly you would be able to make your presence on the web your own. And you could let other people in - you could create online communities that fit your needs, rather than bending your communities around the limits of a Facebook group or a mailing list.

That's what inspired me to start working on idno, and these are some of the ideas that inspired other people in a community of developers called the #indieweb to build their own sites and platforms. We don't believe in treating people as data points; we believe in user-centered software for individuals. Software that you control.

#idno will be available to install onto your own site later this month; a turnkey hosted version will follow. In the meantime, if you're a developer, you can check out Idno on GitHub, or some of the other IndieWeb projects out there.

Won't you join us?