Tuesday, 24 June 2008

TiddlyWest

One of the things we're trying to figure out at Osmosoft is, generally, how a company should behave when engaging in an open source project. The answer is more complex and interesting than at first it might seem - it depends on many factors, such as the size and maturity of both the company and the project, how many community members are on the payroll, the personalities at work, and so on. Plus these things tend to change over time.

In our case, it's a monster sized Enterprise getting into bed with a young and attractive starlet of an open source project - all the more reason for us to tread carefully and act responsibly.

I've occasionally asked different people what role they would like us to play in the community. Some say they'd like us to put pressure on the core developers to keep the updates coming through. Others say we should clean the figurative toilet, and do the jobs that developers might not enjoy (such as writing unit tests and doing cross browser analysis). On the whole we've tried to behave as though we're unpaid members of the TiddlyWiki community - tinkering with TiddlyWiki and sharing our stuff as we go along - while perhaps doing a little more toilet cleaning and core committer-hassling than the average community member.

We're always striving to improve, by the way, so if you have a view on this do please respond in the comments.

In any event, one piece of feedback we received is that we can help organise events and bring members of the community together in real life. We've already done this twice, at TiddlyAnniversary in September and TiddlyYuletide in December, both of which took place in London, and so, continuing the tradition of ridiculous event names, we were thrilled to co-host the latest event - TiddlyWest - in San Francisco last week.

The most valuable aspect of the event for me was a chance to meet our co-host, Eric Shulman, for the first time. Eric is something of a TiddlyWiki legend, having created more TiddlyWiki plugins than anyone else, and I'm sure everyone present found his presentation fascinating. No-one cared that his ten minute presentation took 40 minutes!

Assembled

We also had a few luminaries from Silicon Valley in the room; Salim Ismail (formerly CEO of Yahoo! Brickhouse, and now working with us to get TiddlyWiki working with his Confabb website), Greg Wolff (President of UnaMesa, which holds the TiddlyWiki code in trust) and Paul Hammant (ThoughtWorks Senior Technical Architect) were all in the house.

Open source fans tend to have a broad set of unusual ideas and interests, and this certainly applied to Rich Shumaker, who demonstrated Contact Juggling at the event:



So when all is said and done, I'm hopeful that we've forged some connections between local TiddlyWiki users and ourselves, as well as helping create a few new fans along the way. And I was thrilled to read the positive feedback in the TiddlyWiki discussion forums.

Thanks are due in no small part to Kevin Werbach and the team at Wharton West, who kindly donated their space and their sandwiches for the event.

There's a full set of minutes, videos, links and photos on the Osmosoft website. And my set of photos can be seen here.

Monday, 23 June 2008

Installing aTV Flash v3.0 on an Apple TV

I've recently installed Apple Core's aTV Flash v3.0 on my Apple TV and, seeing as it's something of a hack, I thought I'd blog about the experience in case others are considering doing likewise.

The aTV Flash v3.0 adds specific functionality to the Apple TV, namely the ability to drag and drop files onto the device from my main computer (any common format), and then have them play via the Apple TV menu. This saves the hassle of converting files into a format that iTunes likes. So this is mainly for video content downloaded via BitTorrent (generally DivX or .avi file extension). It does a bunch of other stuff too, such as adding a browser, but I'm not really interested in the other aTV Flash features.

It all worked pretty well, except for a few minor issues. Here are the details (which I've also just posted to this thread on Mac Rumors: Forums):

Using aTV Flash v3.0, and a 1gb USB thumb drive, I managed to install everything OK. This was with a brand new 160gb Apple TV device.

However I've noticed the performance is a bit patchy. I download most of my content via BitTorrent (so, mostly .avi / DivX files), and so far everything has worked, EXCEPT each time I open a file, it's all a bit strange....the Apple logo comes and goes, and / or it says "please wait" while I can hear the audio has started in the background before it either freezes or the picture comes in, and / or it throws me back to the main menu. When I persevere, it works eventually, often on the 2nd, 3rd or 4th try. This problem still persists. Weird.

Another odd thing...I watched a TV episode where the picture quality was poor (as though it had been badly encoded). But it improved during the show, and then when I watched it again, it was greatly improved, almost as though it had learned how to decode the program better! Obviously this is irregular, I'm just trying to describe the behaviour as it seemed at the time. This only happened the first time I used it.

I used Fugu to SFTP my files over to the Apple TV, and it worked like a charm.

Anyway, on the whole, I'm happy with the aTV Flash v3.0, although I'm hopeful that a future patch will clean up these issues. I gather from the above-linked thread that some users have found they can't get their Apple TV to work at all after installation...it might be just due to it being an earlier version of the software, and in any event it's worth checking for more recent forum threads to see what the latest situation is if you're considering a purchase.

All other main Apple TV functionality (such as music and photos) remains unaffected, and I haven't played around with the other aTV Flash functionality as yet - such as the browser - as I don't really have a need.

Hope this helps.

++UPDATE: 26 June 2008++

I've discovered that the above problems were caused by using the nitoTV plugin which appears on the main menu. To be fair, it's very new technology. But when I used the Sapphire plugin (also via the main menu), I experienced no problems whatsoever - the content loaded automatically every time, and even used the native UI for pausing, fast forwarding and rewinding content. Win!

++UPDATE: 7 July 2008++

Having used the box for a couple of weeks now, all seems to be well. The exception is that a couple of times the box has crashed when half way through a program, and it restarts automatically. When I restart the program using Sapphire, I can use the native Apple TV controls to fast forward to the right moment very quickly, back where I was about 60 seconds after the problem occured. I've got a feeling this is happening when a program is left as paused for too long before being resumed, and some resource is being used up while in this state.

Other than that, still very happy!

++UPDATE: 13 August 2008++

Have experienced a few minor issues over the past month, such as sudden crashes. Also for some reason, on Sapphire, shows which should have been shown as "viewed" simply dropped off the browser, so I couldn't watch something twice.

But I upgraded both the Apple TV firmware (v2.1) and the aTV Flash software (v3.2.2) at the weekend, and this seems to have resolved the problems. Sadly a full factory restore was needed. Have decided this time to just stream iTunes from my main Mac (rather than a full sync) and obviously this has saved me a large chunk of space - more room for TV and films. The performance seems to have improved slightly (no crashes yet). Oh, and in case you're wondering how to upgrade aTV Flash, you need to sign into the site to get at the link.

All in all, this formerly slightly flakey software is now, dare I say it, pretty much ready for primetime...
________________________
Apple TV version 2.0 (bought in the States, activated in the UK)
Connected to TV over HDMI
iMac G5 1.5gb RAM running Mac OS X 10.4.11
Connected to Apple TV over wireless
BT HomeHub

Supernova 2008

I attended Supernova last week, which I have to say was one of the most interesting and challenging conferences I've attended. Kevin Werbach and his team at the Wharton School (University of Pennsylvania) did a great job bringing in a plethora of interesting speakers and panels.

There was a fair chunk of admin for me though; BT were sponsoring the event, there were five of us attending, and so there were stalls and flights and hotels and couriers and all that malarky to arrange. Having gone to all the hassle of arranging a big stall on the first day, I got the impression it repelled rather than attracted this particularly savvy audience.

Reach up

I guess people assume that Big Telco companies don't have much of interest to say. And I guess this is understandable, given that the disruptive projects in this space (Skype, Grand Central, Android, iPhone) have grabbed all the headlines in recent years. We didn't really get a chance to talk to many people, until we ventured out into the room away from the stall - and once we started talking to people, we got a much better reaction.

And it was great to see this perspective being challenged in the Open Flow track on the Tuesday. JP Rangaswami, the MD of BT Design, gave a talk on how important it is for large companies to adapt to these challenging times, and pointed at Osmosoft (for whom I work) as being an example of what BT is trying to do in this space.

JP

We got a much better reaction on Tuesday night as a result. But I digress.

After JP's slot, there were some great panels in the remaining Open Flow track. Tantek Çelik did a great job moderating the 'Whose Social Graph?' panel, pushing Google, Facebook and Plaxo on how difficult it is to get data out of their platforms (particularly Facebook). What made the discussion even more interesting was that the screen behind the panel was used to show the audience's views on the discussion, via Twitter (using Summize). And then the screen was switched to show this blog post by David Recordon, who was in the audience, criticising Facebook for blocking Google's Friend Connect service. Unbeknownest to him, this was on the screen while Dave Morin of Facebook was talking about their supposedly open policy.

Closed

Things got pretty heated, and eventually Morin refused to comment further other than to say Google's people were talking to Facebook's people, leading to this great tweet from @psd! Dan Farber and Nic Cubrilovic covered the argument in more detail.

My view: Facebook's business model depends heavily on keeping their customer's eyeballs on their site. They can't afford to release social graph data because it threatens their business, but likewise they have to be seen doing something when it comes to sharing data. Like good politicians, they have a consistent response to criticism about data portability; they talk up their privacy concerns. This is bullshit. Up until now, this has been sufficient to maintain traffic to their site. My stance continues to be this; I will maintain a presence on Facebook because my job requires it, but I will not put data in until I know I can get it out again, and I will visit the site as infrequently as possible in the meantime. And I encourage others to do likewise. It hurts the web.

Phew, rant over!

Anyway, another great panel which followed later in the same track was the Bottom-up Distributed Openness panel, with the founders of Microformats, OpenID, OAuth and OEmbed. My takeaway from this session was how these guys and one gal had seen how painful it had been to invoke standards in the W3C, and had generally decided to restrict their initial efforts to a small, closed group to get their standards off the ground. With impressive results. Turns out selective closed-ness is the way forward in certain situations.

And Jeremy Keith kept did a good job keeping things light-hearted with buzzword bingo running in the background. Waddayaknow, when Leah Culver mentioned RSS and Wikis in the same sentence, we got a House!

House

There was plenty more going on during the event, much of it outside the sessions, and way too much to record here. But suffice to say it was one of the best conferences I've been too, and I hope very much to be involved next year.

You can see a full set of photos here.

San Francisco

I've just returned from San Francisco, which I hadn't visited since 2000 (If you'd like a laugh, check out the California Journal I created back then...marvel at the background images! Gasp at the photos downgraded for dial-up! Cringe at the hand-coded html! Etc. etc.). It was a brilliant trip, mainly for work reasons - will post about that in a sec - but also I got the chance to soak up the city.

It's a lovely place, and I really wouldn't mind living there one day. The people are friendly, the weather is (mostly) agreeable, and there's plenty going on. Here are a few snaps from the walk around town.

The Farmer's Market by the Ferry Building was one of the nicest, friendliest markets I've ever visited...

Honey

Exchange

Sale

We went for a great walk up to Coit Tower:

Coit Tower

View South

View North

The Mission is a fab neighbourhood for photos, whether it's the Maracas:

Maracas

...the epic burritos...

Burrito

..or the sensational array of murals...

Robot

Face

Guitar man

Everyone's seen the cable cars of course, but what's amazing is that they grab onto cables which are moving below the street. We saw the machinery that pulls them along:

Subterranean Machinery

Fans of Sean Connery might remember him meeting his daughter at the Palace of Fine Arts in The Rock:

Palace of Fine Arts

And of course there's also the Golden Gate Bridge:

Golden Gate Bridge

As if I hadn't put the camera through too much by then, I was also gifted an amazing view of the city on the flight home:

San Francisco - Bridge and City

The all-too-brief visit was just brilliant. I've got a poor memory of anything prior to 2003. It's not a coincidence that this is when digital photography became practical and affordable. These photos will live with me a long time!

The full set of photos can be seen here.

Tuesday, 10 June 2008

How to make money from open source

Every now and again, I poke my head out from the echo chamber that is the open source world, and get bombarded with one question. How do you make money from open source?

Many people have answered that question in the past, so consider this a re-heat of last night's dinner, as it were.

Of course, for some open source developers, the very question is offensive. They create open source software for reasons other than financial ones (as described in my previous post). But for others it's an important question, and I for one would like to finesse my response.

The often used answer is that one makes money because of open source, and not with it. Let's unpack this. There are many examples of this being done successfully, such as;
All decent business models. And making money from open source is also possible at the level of the individual as well.
  • Doc Searls makes money talking about open source at conferences and through writing about open source in Linux Journal. He also gets paid for consultancy services. This is interesting from my perspective, as Doc doesn't write code (I am not a developer either).
  • Jeremy Ruston, my boss, made money selling his one-man open source company to BT. Note he didn't sell the code itself; that is held in trust by a not-for-profit outfit called UnaMesa. Even still, the amount exchanged was sufficient to make him happy.
I'm not sure how much this helps the average salesman, though. They're looking for direct ways to make money, not indirect ways. Open source is a hot topic right now, and its inevitable that those charged with bringing in money will ask how open source can help them do that. And these unfamiliar methods of making money might be unsatisfying for those who are new to the topic.

I think that the best answer is to say that there are two possible approaches.

The first is to use open source as an enabler. Rather than asking how you'd make money with an open source product, look at your existing and upcoming business opportunities and figure out whether open source can play a role in them. The benefits of reduced costs and improved flexibility might make all the difference.

The second is to put open source at the heart of your business model. To attempt this, you'd really need to get under the skin of open source; understand how the community works, understand the unique benefits of open source and how it's changing the world, and then try and identify new business models in the same vein as those listed above. It's not straightforward, but it could be lucrative.

In this day and age, where commoditized open source solutions are leading their respective fields, it's incumbent on the salesmen of large companies to get their heads around open source, so they can understand in turn where the opportunities lie. With their knowledge of the market and commercial acumen, they may just hold the key to the next wildly successful business built using open source.

Photo shared under a Creative Commons licence by WhatKnot.

Wednesday, 4 June 2008

Building a Developer Community

Many companies say they want to build communities, but take completely the wrong approach. They say something like 'If You Build It They Will Come'. This might be true in certain rare instances, but for the rest of us there is much to do to improve the odds of success.

There are numerous books out there that explain how to build communities, but not so many explaining how to build a developer community. These communities are more sensitive and enigmatic than, say, Digg-like communities, and I think they're more interesting too. We're talking about a class of community that can conjure up something completely new from your tools, which represents an intriguing path to innovation.

So here are some guidelines to consider. There's no guarantee they'll work, but I can guarantee that, the better these are implemented, the higher the chance that the community will form with unforeseen benefits. There are several planets you have to push into alignment, and then you have to keep them there. So here goes:

1. Might seem obvious, but figure out why you're building the community in the first place. Is it just to improve adoption? Improve credibility? Improve quality? Develop an ecosystem of support? Whatever it is, figure this out and make sure everyone on your team knows and agrees. Try and hang some rudimentary metrics off the targets, so you can track progress and take course corrections.

2. Get ready to relinquish control of your product. The most successful communities form around things they can influence and help drive. The more control you hand over, the more chance your community will form, and the more chance someone will come up with an idea you haven't thought of. I'll say it again: Give away as much as your business can handle.

3. Consider the motivations of the community. Most developers are driven by some or all of the following: (a) a desire to be creative, (b) a desire to share, (c) a desire to make a living. Let's look at these in more detail.

3a. The desire to be creative. Consider the nature of what you're handing over. Is it obvious what it should be used for? Or has it been designed to be used in all sorts of interesting ways? If you were a creative type, would you rather have access to this:










Or this?










Try to design products that can be used in as many ways as possible. Make it interoperable and extendable, so it can be combined with other products. Open source and open standards are the way forward. Just having an api doesn't count on its own; the quality of the api itself and the supporting documentation can make the difference between success and failure. For webby projects, see REST.

3b. The desire to share. Software is abundant; easy to copy and reuse. In this environment, hoarding just doesn't make sense. The best way to get the respect of your peers is by demonstrating your prowess in your chosen profession. If you're creating a community, make it as easy as possible for developers (and potential users) to share their work and for others to find it. Help developers to find each, and work together, and then get the hell out of the way.

3c. The desire to make a living. By giving people a platform to demonstrate their creativity and skill, you improve their employment prospects. Also, there's the tantalising prospect of acquisition (see 6, below).

4. Learn humility. You need the community much more than they'll ever need you. Someday, if you behave the right way for a long period of time, they will start to trust you and treat you as their moral leader. Even then you'll still need them more than they need you. You are the servant of the community, and thinking this way will drive all sorts of appropriate behaviour. And if you're experiencing friction with the community further down the path, there's a good chance you've forgotten this guideline.

5. Choose your language carefully. Avoid using terminology such as 'managing', 'exploiting' or 'owning' the community. Chastise your colleagues for doing so. You don't 'own' anyone or anything, not even your product (if you've done it right), regardless of what the licence terms say. Respect needs to be ingrained in your corporate culture. Once you've established the community framework, the only thing you can manage is your relationship with the community. Use words like 'influence', 'support' and 'help'.

6. Feedback loops shouldn't just be bootstrapped onto your service or product, they must be built into the core. Resources should be allocated to this, and fiercely protected. They are your ambassadors. Your best people should be involved. It is your top priority, regardless of whether you've hit critical mass or not. If someone has a question, you'll need to be well positioned to immediately jump on the opportunity to give as much help as they'll take. Let your people develop personal relationships with community members. Let them meet in real life, and be ready to pay for the beer. Be ready to relinquish control over your staff as well as your product.

7. Be ready to change your product. The responsiveness outlined above is perhaps the most important responsibility when running a community, especially so in the early days. And if you're a large company, and like many large companies you're struggling to innovate, this relationship puts you in a unique position. From here, you can observe what people are doing with your tools, so you can improve them quickly in response. Build the products with this quick 'reconfigurability' in mind. And from this vaunted position, you can also identify innovative ideas that you can learn from, and possibly swoop in with an acquisition offer before your competitors get wind of it.

Does this sound predatory? Then consider the facts that developers (a) deserve to get paid like everyone else (b) might want to be acquired (c) might need the support to really get their idea off the ground and (d) have the option to turn down the offer. But don't be too surprised if the developer is offended by your overtures; for some developers, money isn't an incentive and their passion for the technology is more akin to a religion than a business.

8. Ship a quality product. If you think the developer community is going to finish your job for you, you're in for an unpleasant shock. Don't use a beta release as a reason to ship a product that's either incomplete or full of bugs. If you do this, you'll lose any credibility you may have with the developer community, and they won't come back a second time. In this day and age, there is no excuse for not building in quality as you go along.

9. Details *really* matter. If you're about to make a change to a product, service or community, no matter how small, make sure the community is cool with this. Without spamming forums, you still need to be sure the important people find out and can respond. If you're lucky, and you've done a good job creating the feedback loops, the community will tell you what they think. Lucky you.

10. When you've made a decision, explain it. Your explanation should stand on it's own; don't just point at a conversation - actually spell out the logic and the feedback that has led to your decision. Again, do so on the same forums as before. You owe the community that much.

11. Give some thought as to the most appropriate tools that the community is familiar with - don't force them to move the conversation over to your shiny new platform. You need to relinquish control over the conversation as well as the product itself. If you've followed the other points, there's nothing to be scared about. There are perfectly adequate tools out there such as getsatisfaction, Google Groups, Twitter, Facebook (which sucks, of course, but your audience might still be there), Soureforge, Trac, blogging software, simple mailing lists and so on. Anything that smells like BigCo might put off potential community members.

12. Be ready to provide financial support. Obviously, this depends on your budget and project, but it needn't be expensive. It could simply involve buying community contributor Bob the latest Nvidia card so he can write drivers, or paying for Manuela to attend a conference so she can talk about the project. Having the feedback loops mentioned above should help you spot these opportunities to develop ambassadors outside your organisation.

So all this should be considered nothing more than a general introduction; if you're charged with building your own community, I'd recommend you conduct some more in-depth studies to improve your chances. I can recommend reading the Cathedral and the Bazaar and Here Comes Everybody, and JP recommends reading Community Building on the Web. If you've got anything to add to this list of guidelines, or the list of the best books, please add them in the comments. Thanks!

Photos shared under a Creative Commons licence by Flickr users baboon and atomicShed.

Sunday, 1 June 2008

Barcamp London 4

So we're camped out here at Barcamp London 4, at GCap's offices overlooking Leicester Square, and it's just fab. So far, today, I have learned how to time travel, make the perfect cup of coffee, break the internet and make a Nabaztag swear.

My talk about the Ten Commandments of Twitter went down well. And, for the first time, I won a game of werewolf (playing as a werewolf, no less). I didn't do so well at Faceball, though.

You can see today's photos here.