Symphonious

Here's a really simple golden rule for anyone thinking of adding auto update to their products - never ever include any user identifiable information. There's simply no reason you need to know who is checking for updates, you only need to know what version they have. Given the infrastructure of the internet you will wind up getting their IP address, your policy should be that these aren't stored.

It comes as no surprise to me that the WordPress mob broke this rule with their new auto update - they always seemed shifty to me. Tell me why exactly you need the URL of the blog to determine if a new version is available? Exactly what use to you is blog.ephox.intra going to be? Oh well, I'm already removing all the pointless blog entries they spam the dashboard with and those weird technorati partner parameters so I guess I'll be asking for updates from wordpress.com or something too….

UPDATE: I posted this before the inflammatory and completely wrong slashdot article. I'm aware it only sends your blog URL and I've already patched my version so it doesn't. Of course they can still identify me by the static IP and the replacement string I put in instead of my blog URL but it's the principal of the matter more than anything, at least it's clear that I don't agree with deliberately adding personally identifiable information to an update check.

It's a common question - what's the point of social networks? The most common answer is basically none. Most social networks provide yet another way to get in touch and keep in touch with people which is great but lets face it, there are about a billion different ways to communicate and leaving messages on someone's wall only looks good compared to sending smoke signals. Some people might argue that it lets you map out and visualize your social network but seriously I know who my friends are, why don't you? The address book has been around a long time and it still works seriously well.

I think the best way to highlight how seriously useless plain social networks are is to look at the 10 Best Facebook Applications For Business Professionals:

• Conference Calls
• Voicemail
• Asking Questions
• Posting Video Messages
• Introductions
• Business Cards
• Phonebook
• Recommendations
• Defining other people with a tag cloud
• Business directory

Anyone see anything new in there? Anything remotely likely to change the face of business? Nope. Gimmicks galore and sure you can make yourself look all hip and web 2.0. Yes it's very important to reach out, connect with your clients and be part of the discussion but social networks aren't suddenly making it possible to do that, they add the burden of yet another way you have to do it and most of them put up all kinds of walls to make it difficult to do so.

Now that's not to say that the idea of social software is bad - just the idea of social software with no point. What if instead of just building up communities for the heck of it, we built up communities to achieve a common goal or a series of goals? In other words, what if there was a point to it all? That's what LiveMocha is doing by building a social network of people who want to learn a foreign language. Dan Kaplan put me onto LiveMocha and he nails the key cognitive change between what we'll look back on as the hype of social networking and what actually stands the test of time:

The key is that, unlike so many of the wannabes in the social network game, LiveMocha’s social network is not the central focus of the site but simply a feature.

Social networks are not the point, social networks are the tool and it's about time we started realizing that and start putting it to work. There are two ways for this to unfold, either we'll start seeing really useful Facebook applications being built - I imagine it would have been possible for LiveMocha to be done as a Facebook application, or the explosion of different social networks will expand to the point where users simply demand openness and the ability to move their social network around.

Either way the time is coming where the social network will be a feature and a tool, not the entire system. Frankly, I can't wait.

 My open tabs in NetNewsWire have exploded in the last couple of days with really good articles about driving wiki adoption and generally making wiki's work. First up Making Wikis Work is a pretty good overview of all that is wrong with wikis. It's odd to think that a technology as young as wikis has legacy cruft but they do.

In particular, WikiWords are no longer required or a good idea, use an editor that makes creating links easy or use a simple shortcut for creating links (the square bracket notation was easy for most people to learn, but you need to provide a completely GUI alternative as well).

Wiki syntax is the other big bit of legacy cruft - it's probably the biggest barrier to wiki adoption now and wiki creators are all scrambling to add WYSIWYG editors instead but many are struggling to make it all work because wiki markup is so non-standard. Should have used HTML instead…

There's some good suggestions in there for how to create a good wiki too. Not too sure that everyone would agree that hierarchy is the best way to organize things, but you certainly need to include good organization tools which most wikis lack.

Next up, Steward Mader nails one of the big problems with getting people to try out wikis - fear. It's natural for people to fear new things and to fear criticism or looking stupid. Wiki's have always tried to reduce barriers to entry for contributing but they still struggle with people's fear of looking stupid. I think Stewart is too dismissive of this - we've got to find something that makes people feel safe while they get started and build up their confidence. It's social not technical though so the solution isn't going to be simple.

Nat Torkington talks about O'Reilly's problem with ever growing mailing lists - Ephox has the same problem in both directions, extra people and extra content constantly being added to mailing lists. Our engineering alias has grown to include half the company so noone uses it anymore, they just type in all the actual engineers directly. Wikis are often a great solution to this if you can get people to use them - instead of pushing every message out to everyone you let people self organize around the conversations that interest them. Of course, you have to get people to actually use the wiki and pay attention to what's going on there and it doesn't resolve O'Reilly's problems with NDAs etc. It does create a much more useful archive of information if the conversations are actually creating information (rather than just discussing and inspiring ideas). Probably not the solution for O'Reilly but wikis certainly can reduce the email load in a company and allow people to be more productive and actually get the information they need. Email tends to include a lot of people that don't need to be involved and miss a lot that do, plus anyone who needs to know later has to start the discussion all over again.

Rahul complains about Google Docs rather primitive diffing capabilities. Being able to see what's changed is another of the really obvious features that is rarely done well. Our internal wiki has some pretty awesome diff capabilities now but it still needs more work as quite a few types of changes confuse it. I'll have to investigate how track changes could be used to improve it.

HiveTalk discusses how to hold meetings on a wiki. Good advice here but I'm hesitant to call it a meeting, mostly because noone likes meetings. I'd just call it a discussion. The idea of having a deadline is really important as is following up on actionable items. Of course because this is asynchronous people who don't have good time management skills (most people) will tend to put it off in favor of doing something that feels more urgent so you need to be cautious of that and pester people if you really need their contributions. Often the best way to teach people to get involved is to go ahead and make decisions without them (doing the best you can) and let them live with it - depends how important the decisions and the person involved are as to whether you can get away with this though. Probably best to start with something like where the company picnic will be instead of business critical decisions.

Lots of good stuff in there - hopefully I'll get a chance to look at them in some more depth because there's a lot of overlap with the stuff I'm thinking about at the moment.

I got some really positive feedback on the various community/openness projects that I've been spearheading within Ephox from one of our OEMs today. Apparently they've discovered our early access program and are already trying out our brand new Express Edit functionality1.  It's really nice to actually hear from clients that these elements are useful as we haven't really managed to build up a community, even if we are seeing gradually increasing traffic. For a while now we've had potential new employees commenting on Planet Ephox which is great, but we haven't really heard from clients taking advantage of it, even if we've seen some of the indirect effects via analytics and support cases.

Now getting great feedback from one client is satisfying but it's not the end game - of course we want to impress all our clients like this by whatever means it takes. What I find most exciting about this is that it demonstrates to the sales and marketing teams that our openness and even our engineering practices2 are actually valuable to clients, particularly OEMs where the relationship is more important and long term. The business users and product managers probably don't care about automated tests and early access, but the engineers that have to actually integrate our product do. If we can provide them with tools like the hints and tips on LiveWorks! or early access to new features, they can better integrate our products and get the most out of them for the actual end users. In the end, that's what everyone should be working towards and we can and will help out on multiple levels.

1 - Don't forget to let us know how it goes and how we could improve it btw….↩

2 - continuous integration, TDD and all the other things we do to ensure quality↩

Yesterday afternoon Suneth and I took on a research project to see how feasible it was to keep server caches up to date by using XMPP to notify the other servers in the cluster of a change. Imagine a web server with some latency between it and the resources it's serving (eg: it's using S3), to speed up performance you'd want to cache the recently used or most commonly used resources locally on the server, but if you need to scale up to a cluster of servers and the resources are being changed, that cache becomes a problem.

The simplest solution to this is to set limits on the length of time that resources can be cached but I'd prefer to avoid latency in updates as much as possible.

The other alternative is to have some kind of notification between the server cluster so that all servers rapidly find out when a change has been made - much like database replication. This is what Suneth and I wanted to play around with and we thought XMPP would be a quick way to get such a notification system going.

It's worth noting neither of us really knew anything about XMPP other than that it was the protocol underlying Jabber instant messaging and it was a generic XML messaging system. We figured we could use the generic nature of it to send whatever messages we needed and just take advantage of the existing servers to do the marshalling. Fortunately, our lack of knowledge led us right into a much simpler solution - just use Jabber.

We grabbed the Smack API and started playing with it and quickly discovered that sending and receiving messages was ridiculously easy. It turns out that the absolute simplest way you can minimize stale data in your caches is to simply have all the servers join a preconfigured chat room. Whenever they save a change to a resource they send a message to the room with the unique ID of that resource and whenever they receive a message from the room they assume it's a unique ID and remove any cached versions of that resource.

It also makes testing easy - you simply open a jabber client and join the chat room yourself.