Saturday, 17 October 2009

The Future of Google: GMail and Customer Service

In this last article on Google, I'd like to bring to the fore how Google deals with customer service and discuss what I see as a problem with the company: customer service, or lack thereof.

GMail
I have been using this service for about a year now to host my personal e-mail account. When I first signed up, I had a gmail.com address and, when the facility became available, moved my domain's email to the service so that I could benefit from their brilliant application and maintain my own domain identity. For me, the service is great: it's fast, accessible anywhere (including my mobile phone) and, through their adoption of open standards, I am able to access its combined calendar service almost anywhere, except my mobile phone, for which I have to pay a fee to GooSync in order to be kept up-to-date. So from a consumer perspective, I can't ask for much except for Google to complete their offering and provide a mechanism with which to access calendar data from mobile devices without the use of a third party.

Recently, GMail launched a corporate version of their service which aims to provide businesses with a software-as-a-service delivery of mail, calendar, office and collaboration apps centred around web-based access with additional tools like Microsoft Outlook integration by recognising that, even with it's faults, it's a great application for corporate email and, backed by Microsoft's support is the most heavily adopted application in business for provision of mail services.

However, Google's corporate mail offering falls flat. I recently tried to migrate one of my clients to use the service and found a number of problems which have made me hesitant to use this service. So much so that for my own business, Redwire, I found an alternative provider with whom we now have a reseller account and to whom we intend to migrate all of our existing mail provision to, over time. I'd like to explain my choice of moving away from Google here because the issues it highlights are so important; there are a few issues, as follows.


Background
The client I chose to test GMail with is Urch Publishing, a small publisher of market research in the healthcare field. We share an office with this company so I see their MD, Edwin, on a daily basis and he's always eager to try out new technological ways to improve his business and allow him to work more efficiently. So the two of us sat down and signed him up to GMail's business offering. Switching over his mail servers and activating his account was very simple and he became familiar with the system fairly quickly. There were a number of problems though:

  1. Advertising: he paid for Google Mail upfront, for a year, but still had to manually switch off the contextual advertising that is normally part of the webmail interface. This seems odd to me: one of the things that Google tells people is a benefit of paying for the service is to remove the advertising. Doing so was easy enough - there's a setting in the account preferences which allows you to do this. As a corporate customer, though, I feel that as soon as you're paying for a service, Google should switch off their advertising on your behalf as a thank-you for your investment and notify you of this by email, together with instructions on how to re-enable the adverts should you wish to do so, so that you remain informed as a customer.
  2. Migration: this is where Edwin and I really felt let down. Edwin has a huge amount of email in Outlook: about 6GB of data in all, so we downloaded Google's migration tool and decided to give it a try. We followed the instructions provided and started the migration. From this point on, we had absolutely no feedback from the tool, so had no way to know how far it was progressing except to check Edwin's email to monitor progress. The migration application launches in the system tray and once it's there, all you can do as a user is to terminate it. This application desperately needs to provide status information: it should be possible to retrieve a total number of messages and provide a progress bar of transfer, showing the number of items processed and the path or name of the current folder that is being transferred. There are other migration methods available, including server-to-server transfer of emails but we used their application because Edwin has mail stored both locally and our in-office IMAP server so it appeared to me that there was no other option.
  3. Customer service: as soon as we started the migration service, we ran into a number of problems. Reading through the on-line help for GMail provided no answers and, in one case, the documentation was out of sync with the application. So I sent an e-mail to their support service and waited for a response. And waited. Three days later, I received a response which was unsatisfactory and did not answer my questions; instead, I was pointed to the on-line documentation and back to square one. This is utterly unacceptable: as a business, we require support. Real support and, having been in the business for a decade, I have seen that the only way support can be effective (especially in urgent situations) is via telephone, so that customers can have an agent interactively diagnose their problems. As a business, if my customer's email service stops working, they will phone me up and want to know why. If I were to provide a service on behalf of a third party, I must have the ability to contact that provider when something goes wrong.
  4. Service updates: when something does go wrong, the only information I have to allow me to manage my client's expectations comes from Google's Apps Status Dashboard which shows me whether everything is working or not. This is great when things work, but when things go wrong, the information provided is scant and limited to "something has gone wrong". Having said this though, Google do provide rather good incident reports once they have identified the cause of any problem.
So why am I railing against Google? I support the work they do - they've worked very hard to improve people's access to data but in doing so have become very powerful. They use your data to advertise to you, which is why their services are free. However, to quote Aunt May from Spider-Man: "With great power comes great responsibility". Google have shirked their responsibilities: with GMail, you data is stored unencrypted on their servers, protected only by a password and used to make money and, when things go wrong, there's no-one to call.

I don't have a problem with Google holding my e-mail; I understand the technology behind AdSense and I understand the need to make money, but when a company starts offering services to business (i.e. my clients) and is not able to back up their offering with working, usable technology and good support, I'll back off and switch to someone else, as I have done.

Thursday, 15 October 2009

The Future of Google: Trust

I have been somewhat reticent to release this article into the public domain as it relates to a project I am working on privately at the moment and I think it might be a little precipitous to publish. Nonetheless, as the old adage goes: "publish and be damned"...

In addition to current privacy concerns, Google faces the more general issue of public trust. To make people trust the company, it must become involved in something larger than itself that benefits everyone, not just Google employees or users of its services. It must do something truly for the benefit of the greater good and, to this end, I would like to introduce IBM's World Community Grid project, which seeks to use a distributed processing framework to number-crunch massive amounts research data using the spare processing time of consumer home computers, looking for possible drugs to treat Cancer, HIV and Influenza, and to find clean energy generation mechanisms for the world, together with other benevolent projects the results of which are placed into the public domain.

As part of my private project, I have started discovery work on a campaign to promote the work of the Grid through Internet Service Providers. If that were possible with BT in the United Kingdom, who through their wholesale products Datastream and IPstream, reach around 8 million end users across the country.

Regardless of my private campaign, I would like to hand this project over to Google; to introduce my contacts and to start talks to find out if there is mutual benefit for the companies involved. I believe that Google could generate a large amount of public goodwill from this whilst at the same time helping the project achieve its altruistic goals of "don't be evil".

A little of the usually subtle promotion style used by Google to promote its own products could enable this project to bloom. For example, in the Google search footer a new link could be added:

Google Home - Advertising Programmes - Business Solutions - Privacy - Change the World - About Google

With the high level of public and media interest in Google and anything new that the company produces or gets involved in, this could easily snow-ball into a big success for the project, increasing the 1.3m devices currently contributing to a much greater number. This would shorten the time taken to process the research data, so that analysis can be done to find out which, if any, of the computer-chosen candidates work.

One key point is that Google have to do very little to make this happen: they don't even have to run the software. All they do is publicised it so that you, reader, can become a part of something larger that yourself, for the greater good.

So, what next? Well, if you're Google and you like the idea, contact me and justin [at] ilithium [dot] com and I can make this happen for you.

Tuesday, 13 October 2009

The Future of Google: Monetizing YouTube

Since Google acquired YouTube in 2006, it has continually lost money because of the large bandwidth costs involved in the download and upload of millions of videos on a daily basis. Google has recently started to try to recoup some of this loss by implementing an advertising programme directly within video streams in addition to the AdWords Sponsored Links which appear on search results page. The problem with this is that the main consumer base of 12-17 year olds is becoming media savvy and, because they do not possess credit cards, are unable to buy anything online and so therefore enact themselves to purchase from the companies advertising to them.

My proposal is to take a tried and tested system that has made a profitable business model for others and apply that to YouTube, which I dub the Consumer Competition model. An example of this is lafraise.com, Europe's largest online retailer of limited edition t-shirts. Their model works as a contest: registered users of the site submit their designs and can vote on the designs of others. Those designs with the highest score are made into a limited run of 500 or 1,000 and are bought by other users of the site. Their arrangement with Spreadshirt.net, an online t-shirt printing service means that clothes are printed on-demand and at low cost by using automated printing and dispatch services so that for every shirt that sells, lafraise makes a small profit. What makes this system work well is that each winning designer receives a prize of 1,000 Euro. This means that lafraise only need to make a profit of 2 Euro for each shirt sold (in a full run of 500) in order to break even, meaning that the more popular a design is, the more profitable it is for lafraise as once they cover the prize money there are no other costs except for the fixed cost to Spreadshirt.

This model can be applied to YouTube and could reap considerably more reward for Google than it does for lafraise. There is a vast amount of user-generated content on YouTube, more than anywhere else. I would guess that less than 1% of this content is of broadcast quality, but due to the sheer volume of content, these small pieces of video gold are lost in background noise. So, to highlight these works, I propose that Google sets a competition in a number of categories (for example 'Best Nature Video') with a prize of $1,000 (or another set amount). Then, once entrants have uploaded their content, they are voted on by other users to gain a winner. As Google has demographics data on all of their users, this could be used to find a target age audience and market (as defined by the context of each competition). This user-approved and voted for content could then be sold to mainstream networks (in our example The Discovery Channel) to be shown in a time slot which matches voter demographics. The idea of something user-driven being shown on a large network could excite a lot of audience interest, the networks would gain in advertising revenue and YouTube would gain an entirely new revenue stream that, because of it's voted-for nature, could provide a very high return on investment.

Google's dark fibre network could also be used to reduce Google's cost. If the company is able to terminate its fibre connections at major data hubs (such at London's LINX) and offer open peering (a principle where transfer of data between peers at such exchanges is free) then costs of transfer paid by Internet Service Providers could be dramatically reduced. YouTube accounts for 10% of all Internet traffic, which must currently be paid for by these ISPs. If Google were able to offer open peerage, then these costs would simply disappear. A technique called Traffic Shaping is commonly used by ISPs to limit flow of certain types of traffic (particularly BitTorrent) as its prevalence increases their costs and this may already be happening to YouTube traffic. However, by allowing open peering and having enough network capacity to support it, ISPs would have no reason to restrict flow of traffic to YouTube meaning that performance for end users would increase.

Monday, 12 October 2009

The Future of Google: Dark Fibre Subleasing

Since 2005, Google has been investing in dark fibre, the parts of the vast (and mostly ocean-spanning) fibre optical networks which connect telecoms and Internet traffic across long distances around the globe. Initial comments at the time and after have been that Google was planning to build a telecoms network, something which goes against the ethos of the company and would move them into the direct consumer marketplace, which is costly.

I have had a number of ideas as to what this network could be used for, as it presents the opportunity for limitless and cheap data transfer between geographical nodes of the Google data system. My first idea was that it would provide enough bandwidth to allow for the creation of a massive global databasing using technology like MySQL replication. This idea failed because within most relational database systems, replication has a limit to the number of servers that can be managed and the method of replication would create more resource needs to maintain, outweighing its benefit.

My second idea was to use the network to create a new type of indexing, which I term Swarm Indexing, where geographical nodes within the search system matrix maintain the primary index for their region, with backups elsewhere. Software would then be used to create a meta index, describing the content for that region (for example certain key words or phrases that are geographically contextualised) and this meta index would be transferred to Google's central query-processing hub. As the meta index would be relatively small, this could be transferred using normal data channels, but where the dark fibre comes into play is in the speed of connection – so that when a query is identified as region-contextual, the query could be passed to the relevant geographic node for processing. This node could then process the search and send back a response, caching the query for future use. Using the dark fibre connections (at possible terabits-per-second speeds if wavelength division multiplexing is used) would make Google's global network not just faster and more reliable than most others, but because of its size able to handle massive traffic demands. This could also be extended to reduce costs for YouTube, more details of which are coming up in the next article in this series.

Finally, there is a direct commercial interest in holding dark fibre capacity: secure, cheap, long-distance communications. I propose the development of an automated system where Google's dark fibre extends to major data centres and provides open peering (meaning free transit) to other data networks at the centres. Google could then monitor and provide access to transfer of data across their dark fibre capacity at a price which undercuts other providers when transfer time is critical, such as in the broadcast industry. An automated system could be implemented to monitor the capacity of each fibre trunk and set a price available for a time/bandwidth unit, similar to the way AdWords intelligently prices advertising within Google's search results. In order to instil trust from clients, Google could mandate that connections across their network use an encrypted VPN, like the software OpenVPN client which can connect to most VPN networks.

So, the final question is: with this type of system in place, would you trust and use Google to shift your data?

Sunday, 11 October 2009

The Future of Google: Privacy

One of the key issues surrounding Google at present is consumer perception of the privacy of the data they store within the company's systems: primarily in GMail and Google docs. Over the years since these services were launched, I have seen negative comments from the media (for example the BBC) as they believe that, as the company produces contextualised advertisements from their data, the company is then reading their data and has access to their intellectual property. Having a mission statement which says that the company will not abuse the privacy of consumer's data may not be enough.

To counter this misconception I propose a system where, for a nominal fee, Google implement public-key encryption (secured by each user's Google Account password) where all data stored by that consumer is transparently encrypted by the popular and trusted encryption software GPG. To do so would require explicit on-screen warnings before activation stating that if the user's password were lost, their data would be completely inaccessible and unrecoverable. It is likely that most users may not wish to accept this, so an alternative would be to found in the form of a secondary key, held by a trusted third party, which would allow them to revoke the primary key and re-encrypt the data. There are a number of research papers discussing encryption key escrow systems by such bodies as the Center for Democracy and Technology, which should be considered before this could be implemented commercially.

Regulatory Issues
Once data held by Google becomes encrypted, it is covered by the Regulation of Investigatory Powers Act Act here in the United Kingdom which allows law officers to demand that individuals under investigation surrender their keys or risk prosecution. Google's liability risk is mitigated by this law as it places the liability for encrypted data upon the shoulders of the individual citizens concerned, in a similar manner to the way “Safe Harbors” are implemented within the United States' Digital Millennium Copyright Act.

Consumer and Business Appeal
I believe that this would create a new revenue stream from consumers who are wary of Google's treatment of their mail and would reduce the reservations that businesses have in handing over confidential data to an online-only system. Implementation into Google Gears for offline access, however, may become a problem as Gears is a Javascript-based framework which may not have sufficient processing power to handle the encryption/decryption required to make this work.

Estimated return on investment: with 146m users monthly, at a 0.1% take-up, annual revenue is $29m based on proposed prices.

The Future of Google: Introduction

I am fascinated by developments in technology; I read technology news services daily and follow interesting people on Twitter. If I hear about something interesting, I'll do a little digging and see what I can find. Some time ago, I heard about Google buying up a lot of dark fibre, the unused capacity that comes from laying undersea fibre optic cables. There was a brief flurry of discussion about it at the time, then the news media went quiet and forgot about it, thinking it was part of a telecommunications network. I had another idea, and back in July wrote a series of articles describing how Google could tackle some of their key problems. Now, following encouragement from various sources, I am publishing these as a series with another one or two in the pipeline. Technically, I published the first (Microsoft vs Google) a while ago, but the time has come for the rest to see light. Enjoy, and please feel free to leave comments.

FOWA London 2009: The Future of Print Journalism

Lynne D Johnson, Fastcompany.com

The survival of print is being threatened by the web; we all know this. To allow it to continue, print prices are going to have to go up - printed media will become a luxury of the privileged as printing and distribution costs continue to grow.

People have often blamed Google and other search engines as contributing to the death of print: by providing some of the original content to end users without forcing them to view the source site, then the number of views on advertising presented by the site is reduced, losing the site money. In addition to this, online classified ads have further hit revenue streams of printed media.

So what can be done? Journalists need to embrace new media: become bloggers, video bloggers and curators of information. So that their role becomes more about interpreting the many sources of data regarding a subject than just reporting the data directly. People want the respected opinion of respected people and the reason for this is clear: there is so much data available to people these days that there is a need for human filtration, to make sense of this.

John Snow is a brilliant example of a good journalist: he's been around for decades and his experience allows him to put appropriate, difficult questions to the people he interviews and then adapt his questioning to the responses of his guests. So where this is heading (in this author's opinion) is that end-users want informed opinions. They don't want to be spoon fed, but they want to be able to see a number of opinions in order to form their own.

One of the failures of online advertising is that whilst there are metrics to read how many people view advertisements, the reality is that people just ignore the ads.

So what does print need to do? Lynne speaks of the following points:

  • Engagement: having users join group and networks, where they can share ideas on a common subject (for example, food or travel) where journalists meet users, gather their feedback and the publish it, directly creating user-generated content, which is the Holy Grail of the new information economy.
  • New Revenue Streams: where giving one thing away allows you to hook users into paying for additional content - for example, one article in a series given away for free with later articles chargeable.
  • Content Delivery Models: people have changed how they access media, for example in-game advertising is now becoming a popular source of revenue for game makers, as Burger King and other retail outlets can operate a franchise within games.

But in short, Lynne's speech didn't really give anything away. I was, in fact, a little dissapointed as I was hoping for something really extraordinary but the gems highlighted in this talk are not original - they've been spoken about frequently over the past year and the mystery of what print media can do still remains to be seen. I think they are going to have a tough time, personally, but as for what the future holds? Who knows?

Friday, 2 October 2009

FOWA London 2009: Accessibility

Robin Christopherson - AbilityNet.org.uk
In the US, the disabled commuynity (19.4% of the population) has $1 trillion purchasing power (£120 billion in the UK), meaning that they are an audience worth marketing to and therefore an ordiance of significant size such that they should be catered for.

According to Robin, an accessible site reaches 10-20% larger audience; so the benefit is clear: make your site more accessible and you have a larger customer base. In addition to this, though, the improvements to accessibility required to enable disabled access have SEO benefits too.

I'm watching something rather brilliant: a demonstration of how to use Facebook using JAWS - an eye opening experience of how disabled people use sites like this and the difficulties they suffer.

The solution, according to Robin (who, by the way, is blind) is symantics: to correctly put together the content of a page so that it can be correctly read by applications like JAWS. At Redwire, we did this a few years ago for the first time with ReportBuyer.com - we spent a lot of time looking at how to structure the content for such readers.

So think about how you build templates and content; doing so properly and with thought to accessibility will give you better SEO.

One other point Robin made is about CAPTCHAs, specifically talking about an article which states that when CAPTCHAs are deployed, form completion is reduced by 7.9%. His suggestion is to use anti-spam logic problems like those deployed by PHP.net, where you are asked to answer a simple question, such as "Is fire hot?" or "What is 1 + 2?", with the question changing randomly from a list each time the form is used. This provides a simpler, more accessible way to prevent spam.

Thing to look up: Aria, JAWS, and the Google Chrome frame black hole.

FOWA London 2009: Mobile Widgets

Joel Moss of Codaset is showing off the future of mobile web application development: Widgets. This is a technological approach from Vodafone that's been driven by a reaction to Apple's App Store and is, in many ways, technologically superior. Why? The answer is simple: the Widgets approach uses standard web development languages like HTML, CSS and JavaScript, together with widget/application description information in XML.
On its own, this doesn't sound very exciting: building a mini web app in JS sounds a bit dull, but then add in capabilities to access local storage, specialist hardware such as accelerometers, your call log and networking capability and what you'll end up with is a very powerful development environment. The range of applications that can be deployed with this is quite broad.

There is, however, a problem: Apple have beat them to it. However, with Apple, you need to learn Objective C. I was thinking about writing an iPhone app a little while ago but this completely put me off; maybe instead I should develop a Widget? It doesn't appear that the reach or complexity of this technology is good enough yet, but time will tell and hopefully adoption of this platform will be quite broad.

One thing that would make things very, very cool would be for the Atlas technology, demo'ed yesterday, to be able to create widgets. If that were the case then you'd have a very, very fast way to deploy mobile applications. I have a feeling it would work, but without access to the technology, I won't be able to tell - well, not until November 5th anyway. Watch this space?

FOWA London 2009: Cloud Computing

So, second day of the conference and I'm listening to Simon Wardley give a talk on the future of cloud computing - who's delivering 248 slides together with a very funny narrative. One of the best speakers so far.

He has a point though: there isn't a clear definition of what cloud computing is - a lot of people have a lot of different impressions and, because of this lack of definition, the services that people provide under the heading of cloud computing vary wildly.

Another point is that as technology evolves and becomes more ubiquitous, the need to maintain your own platform diminishes, allowing business to move more swiftly towards the software as a service model. Instead of accumulating assets, you just lease processing and storage for a time and build these ongoing costs into your business model.

This is what we're doing at Redwire. This week, we commissioned EveryCity to provide managed, virtualised hosting for our live platform. For me, this means I have one less thing to worry about at work; for the business, we can scale when we need it and deploy really quickly. A win-win situation. If we'd continued with our own hardware, we'd end up (as we have) with a bunch of legacy kit that's old, slow and worth very little.

A new buzzword I hadn't heard before is Iaas - Infrastructure as a Service; which seems to be what cloud computing is all about.

One important point is about how cloud services are controlled. Each of the cloud services have an API, but each API works differently so if you need to switch between providers it's not so easy. Ubuntu decided to change the game slightly by adopting the Amazon EC2 API and making available a cloud version of their Ubuntu server operating system, deployed using Amazon's cloud computing grid. This allows companies to deploy their own cloud computing environment on someone else's hardware.

What matters though, is who controls the cloud. The answer is that it's not important who controls it, but the software which is used to manage it: if it's open source, then everyone can have control. If not, then you risk losing your freedoms as the cloud grows, its size will enforce standards upon its users, eventually reaching consumer interaction.

Thursday, 1 October 2009

FOWA London 2009: Payment Innovation with PayPal

Osama Bedier spends a considerable amount of time talking about legacies; specifically why the space shuttle's voyage distance is limited by the size of its rockets, the history of railroads and the electric toaster. He's been rambling of for fifteen minutes now, having just flown in from the 'States and I'm wondering quite why. Meanwhile though, I am keeping my mind awake by trying to get onto the ever-useless wifi connection so that I can post these things.

Packets: Sent = 4, Received = 1, Lost = 3 (75% loss)

"Cash is dead, good riddance" is Osama's opening quote (to the part of his speech that's relevant) where he explains that the value of digital payments exceeded cash payments back in 2008.

He notes that you cannot perform instant wire transfers with your bank; this is incorrect. The UK banking industry spent £233 million (not sure on this number) developing the Faster Payments system, which allows transfers below a certain amount to be completed within 5 minutes. I've tested this at various times with a friend's account and have seen some astonishingly quick results.

It appears that PayPal are opening up their APIs to developers, launching on November 3rd in the 'States.

Interesting that they have an open API now; I'm wondering if they can be used for a global project I'm due to start at Redwire soon. However, even with the open APIs, I am put off by my prior experiences with PayPal customer services. But if they're able to offer a way to take multiple currencies without translation and allow us to implement a solution which both looks nice and satisfies PCI-DSS then they may be worth considering.

FOWA London 2009: Francisco Tolmasky: Atlas

FOWA London 2009: Francisco Tolmasky: Atlas

Straight out of college, Francisco is a new kind of maverick: one who sees a problem noone else does and finds a solution. His team developed a framework call Cappucino, which is designed to allow building desktop-style applications on the web.

His demo application is 280 Slides, an online version of a tool similar to Microsoft PowerPoint. Its interface is so like a desktop application, I can see how people can be easily confused and not know when they're accessing a web site.

280atlas.com
His latest project, 280atlas, is an IDE which allows you to develop web-based applications, including custom code, GUI and debugging. Drag and drop controls for sliders, input and rendering are as standard.

Their killer UI tool is the ability to link sliders and other components to input boxes, so that as you drag a slider, the value of the input box changes to reflect the position of the slider. With no need to write the code.

I'm watching Francisco generate and RSS reader application. It's utterly astonishing; I have never seen any development environment work like this and I honestly believe that Atlas will completely change the game for developers.

To make things easier, they've built components for some of the basic tools that people need: RSS feeds, Facebook, Twitter and so on. By using their 'binding' capability, there is no need to write code to retrieve data from, in his example, an RSS feed. You just drag a binding between the RSS feed component and the display component. Done. Within the space of a minute or two, you have a fully functional RSS reader.

To make things even more interesting, Atlas is intended to allow the same application to work natively on the desktop and on the web, using the same code base. The flexibility that this presents is amazing: an entirely new future of portable applications.

If you're wondering how this is different from Gears-powered applications, the answer is that Gears really only acts as a tool to cache data, so that applications that require data cannot access it online.

An astonishing reveal is that what Atlas generates is W3C compliant HTML and Javascript; applications generated using this framework will work anywhere, on any system. Atlas is able to access local files when running natively by implementing a WebDAV server in the local operating environment and communicating with this by REST.

Atlas public beta is available from November 15th for $20 at 280atlas.com.

FOWA London 2009: More Wifi info and Open Source Lessons

According to gossip, in previous years MySpace has sponsored the wireless connectivity. This year, no sponsorship has been arranged which may explain why the Carsonified guys are using domestic wireless access points from Linksys, who're not exactly reknowned for their scalability.

In terms of Open Source, Addison Berry from Lullabot is telling us what lessons can be learned from the adoption of open source development principles: specifically that open source developers are passionate about their work, something which comes from people who do the work they do because they love doing it, as opposed to those who are paid to do it.

In addition to passion, there is a transparency: within the open source world, you can see how everything works from software code to how the organisation in charge of the software product is run. A great example of this is the Mozilla foundation, makers of the Firefox browser. Joining their community is easy and, once in, you can contribute work and time and within a short space of time you may find yourself being a lead maintainer for a part of their project.

"I know everyone here is awesome, and that every one of you has a great idea, but you are not the only one with that idea"

Open source developers are often volunteers, so how does that translate to the real world? Is there a way to earn money by working on open source projects? Addison explains: "it's a lie, a big bad lie". She explains that there are many revenue streams for open source projects: custom coding, support, consultancy services amongst others. What makes a difference, from my perspective, is to adopt and know an open source product to such extent that you are able to charge for your time to implement that project.

Addison has an interesting working environment; she only works 20 hours a week on client work, in a similar way to Google does. This benefits the company massively as it gives staff a great work environment and the ability to explore their passions: something which the company prides itself on. Think about this: if you only had to work on projects for twenty hours, would you not be very, very focussed on the job at hand?

FOWA: Javascript Design Patterns

One of the more interesting talks for me today has been by Dustin Diaz from Twitter, who I'll hopefully be talking to more later this afternoon. His topic has been to introduce DHTML frameworks within Javascript, such as jQuery, Mootools and others so that developers can easily introduce flexibility into the interaction between their applications and end users.
At Redwire, we've been using DHTML in its varying forms for years; we started out doing it ourselves using XMLHttpRequest and over the years have come to discover that jQuery best suits our needs - when we employ cross-interface interaction (which is how I see Web 2.0 technology) we use jQuery because, after an initially difficult learning phase (its notation is a little odd) , you can very quickly deploy interactive components.
Dustin has mentioned a few useful tools, which would help any Javascript developer, so I'm linking a few of them in here, as follows:
  • Date JS: Allows you to easily access date information using a class-based approach
  • Enter Framework: More of a methodology than a framework
  • Dean Edward's 'Base' class for Javascript
  • Dan Webb's Low Pro (for jQuery) - unobtrusive scripting for prototype
He also warns of over-abstraction, in that you can simplify your code into smaller and smaller components and then throw unit tests at those parts, but the end result will end up with something more complicated than it needs to be. There is a fine line between complexity and maintainability, and over-abstraction crosses that line.

FOWA: First Thoughts

Given that this is my first paid conference, ever, for work I'm a bit dissapointed. The initial failure of ticketing I discovered yesterday, when a load of people turned up a day early because the tickets were printed with the wrong start date - yesterday was for workshops, in another location. As I hadn't paid for that, I'd expect my ticket should show only the dates relevent to me. Thankfully, work's not far down the tube so I went there and didn't end up wasting a day.

Today, the first day of the conference, I am somewhat surprised by the lack of good organisation - arriving at the venue, I find that registration is entirely paper based and delegates are required to fill in their own name tags, which involves queueing to hand over your ticket, picking up a schedule, then heading to another desk to find a plastic holder for these and a pen to fill them in. Not enough working pens (only one or two for several hundred people) and no staff. The last conference I went to was really well organised; you turned up with your ticket, which they scanned, printed off your name tag (with a barcode on it) and handed you a complete pack. One queue, one ticket, all very efficient and the barcode on your name tag could be scanned by exhibitors, so that they could get your contact details without you having to do anything.

However, it is a rather nice venue and I'm in a very attractive hall listening to Kevin Rose from digg talking about social networking struggling to connect to the Internet. There are seven wireless access points dedicated to FOWA and so far, it's taken me about 20 minutes to get anything out of any of them. A better solution would be to use hardware dedicated to servicing large wireless communities and apply encryption to the connection, so that users don't feel concerned for their personal data. Apparently, poor wireless is not unusual at events; I read recently that TechCrunch writers see this all the time. It's pretty inexcusable, given the nature of the conference.

One great feature that was talked about by Carsonified was there ability to supply power to delegates in the main conference room; a great idea but again poorly implemented. Their solution is to use 3-5m 4-gang power adapters, connected in series. The problem with this is that if one fuse goes, they all go. Oh, and none of the power adapters have surge protection, so it appears that plugging your laptop in is actually a risk! My suggestion would be to run power cables down the length of the walkways of the hall, or down the middle of the seating, with 4-gangs leading left and right, like the branches of a tree.

Finally, wireless access works! Hurrah :)