I nearly pulled my developer engagement rant from the publish queue yesterday, since Aral did a much more eloquent job of describing the problems of working with developers. But I'd been working on it for quite some time, basically jotting down frustrations and annoyances after each developer event I went to. A colleague convinced me there were enough points of differentiation to make it worth publishing as well. So it's finally hit the wires.

Still - I highly recommend you go read Aral's post:

Let me use the tools and technologies I already know instead of forcing me to learn a whole new set. Give me some open web technologies to play with and I might just stay the night.

Excellent.

Incidentally, it's not all bad - one event I went to had two highly passionate and entertaining speakers (to quote someone: "their talk was f**king ace"). Another event saw me whipping up a widget using standards-based technologies (XML, JSON, HTML, CSS) and easily deploying over bluetooth. But there's still an uphill struggle most of the time, even though it's not rocket science to get this right.

(This post originally appeared over on the LiMo blog)

1. Call a spade a spade

Before I even get involved, I want to know: what's in it for me, and why should I care. It's amazing how many organisations talk about addressable market or target technologies or available devices. Blah blah blah. I want to know: what's the future of your platform, how quickly can I be productive, and how can I get my apps in the hands of users. Seriously. Cut the fluff, cut the marketing, you're talking to a technical person here. We detect bullshit for a living. So: tell us what we get and when we get it. Clearly. Concisely. It's not difficult! In return, we might buy into your platform, and then you'll have an army of evangelists more useful than a thousand glossy corporate brochures.

2. Captain Awesome

There's a commonly-held myth that everyone develops for the iPhone because of the fantastic tools, or the fantastic documentation, or the promise of becoming an App Store Millionaire, or because the Reality Distortion Field made them do it. Well, they may all play a part, but the number one reason is this: a compelling device that people want to use. Compared to all that came before it, the iPhone was all about usability - even in the early editions of the operating system. If you don't have a compelling, awesome device, please stop asking me to develop for it.

3. Hide and Seek

So you have a compelling device. You want me to invest in your platform. You push me to your website. But then you're not prepared to let me see the details of that platform - technical documentation, wiki pages, forum searches - without forcing me to register. Why should I have to give you all my personal details when I'm not even sure your platform is viable or of interest until I've had a chance to review those materials? How are us developers supposed to share hints, tips, and pointers to useful information if it's all behind a registration wall? What's so top secret about those device APIs that you can't make them public?

4. Please Hold

The rest of the internet has accessibility-crushing CAPTCHAs and automated email verification ("click the link to confirm your account"). But your site is special, and so you give each and every sign-up request that personal bit of attention. You really want developers for your platform, which is why you make me wait 72 hours before I can login and download the material I seek. But honestly, a cooling-off period is good. You don't want me to hastily rush in and adopt your platform and start being productive. I need to take some time to reflect on my decision - time I can spend evaluating your competition. Just don't expect me to be back after those 72 hours, mmmk?

5. No really, who are you?

Please enter your login and password. My login might be my email address. It might be a username you asked me to create. It might be a randomly generated username from your firstname.lastname.integer mashomatic. I will never know, and you will provide no hint. Oh - and as a special bonus, I need a separate username and password for the forums, the download site, and the wiki. Because single sign-on is, like, so last century.

In fairness problems 3-5 are common to all sorts of websites, not just for developers. But you'd think if they got 1-5 nailed, it would be all plain sailing here on in. Dream on! As if that wasn't bad enough …

6. README.txt

I can almost guarantee your developer kit is not available for my chosen developer environment. (Hey, Linus, we'd love you to build cool stuff with our Windows SDK! Steve, old pal, try this Eclipse plugin! Balmer, dude, you'll really dig this XCode tutorial!) And if it is … what are the odds of a simple installation? If I want to develop for three different platforms, all of whom use Eclipse for their SDK? Why yes, I would like to install three personalised copies of Eclipse, thank you very much. That sounds tremendously efficient and much smarter than using a plugin ecosystem.

7. The dotted line

Please read the following license agreement carefully:

Use of this SDK is subject to the terms and conditions of our SDK license agreement. This agreement is between you ("YOU") and big faceless corporation ("THE MAN"), a company incorporated under laws in a country far far away. By accepting these terms you give us all rights to your code, to your firstborn child, to 10% of your annual income in perpetuity and furthermore you acknowledge full responsibility and warranty and fitness for purpose of your application. You will be liable for the sum of one billion dollars ($1000000000) and forfeit any right to talk about THE MAN without express consent for ever and ever, amen. Please indicate your acceptance of this agreement by depositing a litre of blood here: [ x ]

You want me to develop for your platform, and you start the relationship with 35 pages of legalese? Seriously?

8. Goodbye Cruel World

The quickest problem to describe, the hardest to solve. How long does it take from access to the website to being productive and seeing "Hello World" in an emulator? How much documentation do I need to read? Is everything self-evident, following common methodologies and best practices? Does it all fall into a typical developer workflow?

9. Deploy.

Assuming I got my "Hello World" working, how easy can I get it on my real live actual phone? My neighbour's phone? Share it with everyone in my office and gather useful feedback from them? Beware: if your answer is "send them to the app store", my neighbours and colleagues will all demand you give them bundles of cash to spend there.

10. Unconference

So, you told me why I should write for your platform. You have a compelling device. You made all your content readily available and accessible. You had a speedy sign-up, and let me pick sensible login details. Your tools were lightweight and fitted with my normal workflow. Your licensing terms were reasonable. I could become productive quickly, and get my app on several phones without too much pain. Now I want to take the next step, and meet the others who are developing for your platform, to become an active member of the ecosystem. I want meetings, get-togethers, hackathons, and conferences. You've kindly arranged all of these, but … do I get to talk technical, or will I be in a room full of suits? Will it all be glitz, glamour, vapourware roadmap and marketing, or will you concentrate on nuts and bolts and real world problems? Is there all the power and wireless I could ever need? Do you have ALL your developer materials handy (like on a USB stick) to save me waiting a day for the download? Can I run off with one of your devices, or some developer-specific test hardware? Will you have passionate spokespeople who are engaged in what they talk about, or marketing drones wheeling out the corporate message? Will it be Death by PowerPoint, or Death by Pizza?

In the pub last night with a few like-minded computer cognoscenti, the discussion turned to the success of Ubuntu desktop linux, and whether or not it was ready for the server.

Whilst I've generally run Debian on servers with rock-solid performance and stability, on a personal server I've been experimenting with Ubuntu. I thought it was worth reporting that I smoothly upgraded that server tonight not just one release, but two releases, from 8.04 to 8.10 to 9.04. It required a couple of restarts - which generally is not ideal but doesn't matter much in a non-critical context. But that was all - and in less than an hour, I've got an up-to-date machine.

And yes, this is a long-winded way of saying "testing, testing, 1-2-3, is this thing working?"

So, Google have just announced a new operating system for devices like netbooks. From the announcement:

Google Chrome OS is an open source, lightweight operating system that will initially be targeted at netbooks. Later this year we will open-source its code, and netbooks running Google Chrome OS will be available for consumers in the second half of 2010. Because we're already talking to partners about the project, and we'll soon be working with the open source community, we wanted to share our vision now so everyone understands what we are trying to achieve.

Firstly, this is great news. We already have moblin , maemo, and various netbook remixes, but any big company deciding to invest in building open source platforms is likely to stimulate the ecosystem, provide competition that leads to innovation, and bring valuable eyeballs and marketing to the open source world.

Unfortunately, Google have done it again - started down the path to another "throw it over the wall" open source project, missing out on the key benefits of the open development model and skipping that most important step of all - building a community from inception to ensure the community develops and matures in line with the code.

That announcement quote again, with some emphasis added:

Google Chrome OS is an open source, lightweight operating system that will initially be targeted at netbooks. Later this year we will open-source its code, and netbooks running Google Chrome OS will be available for consumers in the second half of 2010. Because we're already talking to partners about the project, and we'll soon be working with the open source community, we wanted to share our vision now so everyone understands what we are trying to achieve.

Now, I know many people at Google, I know they have a lot of smart folk there, and I know that some parts of the organisation really understand what open source is and how it works. But how is it that there is this continuous disconnect at a fundamental level when it comes to new initiatives? We saw it with Android and we saw it with Chrome: Google do the bulk of the work behind closed doors, then dump the code out there and simply expect everyone to pick it up and run with it. If you're moving to open from a proprietary codebase, such as in Symbian's case, this approach is understandable. But if you're starting from scratch, it makes no sense at all.

Here's the thing. Either you believe in the open source model - and the open development that goes with it - or you're a cynical company using it for marketing and to leverage some free bug fixes. Which is it to be, Google? Are you going to start the conversation around code from inception, giving every motivated developer an opportunity to collaborate and contribute, accepting not just the rewards of community development but also the risks? Or are you going to do your own thing yet again, and hope no-one calls you on it?

I tried out the Moblin test drive USB image on my EeePC, but wanted something a little more permanent. Moblin seems like quite an interesting alternative to the hideous Xandros Linux install that comes by default or my not-strictly-legitimate installation of Mac OS X, and I'd like it hanging around so I can keep an eye on the project. Putting it on an SD will allow me to use it without impacting my normal work environment - and I could even have various releases and other operating systems on multiple SD cards.

Unfortunately, there's a few bugs that cause problems when installing to an SD card, and it took a bit of time searching around to find the right solutions. I found some threads on the moblin-dev mailing list, but thought it would be useful to pull everything into one coherent guide. So here's what I did.

Firstly, create a bootable USB image. The detailed moblin live image instructions contain an error for Mac users:

sudo dd if=/path/to/downloaded.img of=/dev/diskN bs=1m

should read:

sudo dd if=/path/to/downloaded.img of=/dev/diskN bs=1024

When you've written the image to the USB key, you need to boot from the USB key. Press ESC as the machine starts up to get the boot device selection menu. When the Moblin menu appears, select the "Boot and Install" option.

When the installer starts, work through to the section for selecting the install location "Select the drive(s) to use for this installation", and select your SD card device. For me, this shows up as "sdd Single Flash Reader". Also select it as the location for the boot sector, in the "What drive you you like to boot this installation from?" option.

When the installation is complete, allow it to reboot, but again select the USB key to boot from as we need to apply some fixes to our install before it will work. At the Moblin boot menu, select "Boot" to run the live image off the USB key.

When Moblin starts, go to applications and select terminal. You now need to mount the recently installed partition and edit a few files there. Firstly, become root by typing su - (the password is moblin), and then type:

mkdir /mnt/sd

mount /dev/sdd1 /mnt/sd

cd /mnt/sd

vim etc/fstab

This will allow you to edit the location of the partitions to mount. Change any references to sdd in this file to sdc (since when we boot without the USB key, the SD card will be in a different location). There should be two entries - one for the / partition and one for the swap partition.

Next, edit the grub boot configuration (vim etc/grub.conf) and again change sdd to sdc, and also add rootdelay=10 to the kernel line.

Finally, a quick hack to make the boot process pause before checking the disks. vim etc/rc.sysinit and search for the fsckoptions section, and just before that (just after the hostname line) add: sleep 2

You should now be ok to reboot, remove the USB stick, and select your SD card as the drive to boot from.

It works, and it's possible to use the system, but beware that the SD card introduces a fair degree of lag as it is not the fastest device to read from and write to (possibly restricted by the port in the EeePC rather than the card itself).

Somehow, time seems to have gotten away from me. Last post, 8th April? Two months? Has it really been so long?

In my defense, it's been a busy time. Lots to do at work, and also lots of rental apartment hunting, followed by moving, followed by sorting out the infrastructure in the new place. On the subject of moving ....

I'm somewhat wary of drawing attention to my previous diatribe on London Estate Agents, as this year I realised I was cheerfully giving out an email address that led them straight to an incentive to screw up my move (london_estate_agents_are_scum@andrewsavory.com? estate_agents_die_die_die@andrewsavory.com?). But some parts of the recent experience I had just beg to be documented. Next year I'll have to register estateagentsaretotallywonderfulandterrificallyspecial.com, or some abbreviation thereof. Suggestions welcomed.

Last year, I saw an awful lot of properties as I narrowed down the area to live in and the exact requirements. Typically, three or four places a night. This year, I was lucky if I saw three or four places a week. The market is very strange at the moment - everyone currently renting seems to be staying put, and there's very few new properties coming on to the rental market as buy-to-let sales collapse almost as fast as the banks' profits. Sadly, any drop in prices due to the recession seems to be as frequently offset by the rise in prices due to lack of supply.

Anyway, from the ones that we did see, some highlights include:

• A "balcony" that was actually a strip of fenced-off roof accessed through a window. It was a new property, and the agent said "they forgot to put doors instead of a window". More likely, they failed to get planning permission, since they "forgot" the doors on two flats side-by-side.
• A property being refurbished that had a bathroom "retiled to a high standard", that came replete with wall-to-wall mould (presumably lovingly regrown in record time after the tiling?)
• My personal favourite estate agent, who when questioned about the large amount of black fur on the floor, swore there were no previous tenants with pets.
• The same agent, when questioned about the large damp patch and water stains in one corner of the ceiling and down one wall, guaranteed there were no problems with the roof and no leaks.
• The property with "rear garden" that was actually astroturf.
• The elegant, space-saving, "kitchen in a corridor" - is it a kitchidor or a corrichen?
• The flat viewed twice, each viewing a month apart (in case it was judged too harshly first time), that was missing a patio door to the balcony both times it was viewed, and the agent that could not guarantee the door would be fitted before a move-in date a few weeks later. When I say missing - this brand new fourth-floor apartment on a windy street had a piece of plywood propped up against it.
• The minimalist art student pad that consisted of a bed, a bar, and unopened packets of condoms all over the floor.
• The property that we put an offer on, only to find that another agent had already let it out.
• The property with the heating cranked to maximum and no visible thermometer (despite three people searching until we had to leave lest we suffer from heat exhaustion)

Anyway. New place found, after much stress, and some more colourful stories of London Agents to discuss over beers.

This just in from the big G: