The hiatus is over with a short entry about Google Chrome, the new browser from Google that I learned about on the twitterverse while I was stopped at one rest stop or another.
I can’t test it, because my Mac that has a Windows virtual machine is packed. But I will say this: that doesn’t matter. I won’t be downloading it, or trying it, even when they release Mac or Linux versions.
Why so curmudgeonly you ask? It is open source, after all. And it has some cool features.
Yes, it is open source, and I applaud Google for releasing open source software. However, there was an initial brou-haha about the EULA, which initially suggested that everything you type into the browser belongs to Google (talk about All Your Base Belong to Us!) Yes, they changed it, but it made me realize that it is a Bad Idea to put all of my eggs in one basket. Google already knows enough about me (it reads my mail, my feeds, my search history, and a few shared documents, to boot,) I’m certainly not going to add virtually everything else I do (the percent of things I do using a protocol other than http(s) is dwindling by the second.)
If someone releases a “Chrome minus Google” – that is, a version of Chrome with all of the “phone home” code completely eliminated, then I’ll think about using that version, just to see what it’s like. Otherwise, fuggetaboutit.
You’ve likely heard a lot about “cloud computing“. And what’s true is that the sales-talk about computing in the cloud certainly makes the conceptual issues behind it, honestly, well, cloudy. So I’m going to try and lay out the details of what cloud computing is, and how it’s useful for nonprofit organizations.
Quick definition
Cloud computing is basically running applications on the web via “Software as a Service (SaaS)”. That includes applications from Google Documents, to Salesforce.com, to Gliffy.com, (the service I used to create that graphic.) It also includes applications that you might develop (or have developed) that are hosted outside your network. That’s really all it is – there isn’t anything fancy about it. It still requires the hardware and operating systems, and databases that more traditional applications that are inside your network require, but, generally, you hand off that responsibility to the folks that host your application, and access the application through the internet.
Advantages to cloud computing
The basic advantages are that you don’t have to maintain infrastructure for applications, saving you labor costs, as well as electricity costs. Also, you can access the applications anywhere you go.
Disadvantages to cloud computing
Depending on the vendor and the application, you are dependent on them to keep the application up and your data intact. Changes in the application happen without your knowledge or consent. Your data is not directly in your hands, but in the hands of a third party. You are dependent on your internet connection – which could be a problem for mission-critical applications.
What makes it possible
Cloud computing is made possible and easier by two trends, two that have happened closely in parallel, one that is relatively recent: High bandwidth to the curb and massive data centers.
High bandwidth to your home or office is a necessary requirement to cloud computing. Cloud computing just doesn’t make any sense, or work in any reasonable way without it (have you ever tried to use Gmail on dial up?) As the bandwidth available increases (via FiOS, and other methods) cloud computing will get even more attractive to organizations and people.
Huge data centers are being thrown up everywhere, and more and more companies are getting into the business of providing hosting for SaaS developers. Companies such as Amazon are creating massive grid storage and computing services for applications in the cloud.
What makes it usable
Newer applications are using AJAX and Flash, to give the kinds of functionalities we’ve come to expect with desktop applications – so it’s just like having a desktop application with our data – except it’s “in the cloud” not on our desk. As the limitations of both AJAX and Flash are overcome (and as both develop further) expect even more usability for online applications. And, further, efforts like Adobe AIR, and Microsoft Silverlight, are bringing full-fledged desktop application functionality to applications in the cloud.
What you should do
- Make an assessment – will using this online tool really save money or time, or facilitate collaboration in ways that is not possible with local apps?
- Always read the privacy policy – if you have sensitive data, this might be a deal-breaker
- Always maintain your own backups. If the provider goes belly up with your data, you’re toast.
- Make sure access is secure. Read up on the security of the application
This week, it is my pleasure to host the Carnival of Nonprofit Consultants. This week, I asked the question: What is the biggest mistake a nonprofit can make with their website. I got some interesting answers:
- Ken, at the Nonprofit Consulting Blog, talks about transparency, and how it’s a big mistake not to be transparent. He has some good ideas and suggestions about how to be transparent as an organization through the website.
- Kivi in her Nonprofit Communication’s blog suggests that a website needs to be about the visitor and not about the organization: “The biggest mistake that a nonprofit can make with its website is to use it as an old-fashioned brochure, where you immediately hit the visitor with your long, jargon-filled mission statement, right at the top or smack in the middle of the home page, followed by bulleted lists of ‘projects’ or ’services.’” She gives some great suggestions and examples
- Joanne Fritz talks about three big mistakes – outdated information, insufficient contact information, and outdated design. She makes some great points, and gives good tips to make changes.
- The Hack Artist suggests that it’s important to marry direct mail efforts and a web presence.
- James Young, on the Connection Cafe, suggests that we think about constituent empowerment when we think about organizational websites.
- And, since I’m the host, I get to add a couple of bonus mistakes. I think one of the biggest mistakes that an organization can make with its website is to promise more than it can deliver – make sure that the resources to create that blog, or podcast, or photo gallery, or whatever bells and whistles that you promise on your website, are there when the website goes live.
- I do think the biggest mistake an organization can make in the re/creation of its website is to go with the vendor with the lowest bid. It’s a lot more than price – it’s quality of work, whether you like their previous work, their overall reputation, as well as their fit with you as an organization.
This is a rant. And it is a rant on behalf of the hundreds (thousands?) of nonprofit organizations whose website is stuck behind a custom CMS – one that was written by some web development shop or another, and migration off of that custom CMS is going to be a nightmare.
As the author of a custom CMS (it did have the advantage that it was released as open source, but it never caught on, so it still counts as custom) I know what it is like to put my heart and soul (and time) into a CMS, and want my clients to get what they want. I wrote that CMS back before there were any really good open source ones, like most of the custom CMS out there.
But, that was then, and this is now. There are quite a number of really good CMS systems (both open source and proprietary – I’d say there are a good solid dozen) that have large user bases, many developers and vendors who implement them, and their are lots of new modules and functionality being added every day. There is absolutely no way that one single web development shop can provide a CMS solution that is better in quality or functionality than what is available out there right now. In fact, even if you just focus on the “big three” open source CMS – Drupal, Joomla and Plone, 85% of nonprofits will likely have their needs fully met. The other 15% might want or need a more specialized CMS (like OpenACS, or a proprietary one,) or might need some modules developed for them.
Most custom CMS that I’ve seen lately are sorely lacking in features and/or usability, in comparison to what’s out there, and available. Of course, one could argue that migration off of one of the more popular CMS to another one is difficult – as difficult as migration off of a custom CMS. This isn’t the case for a couple of reasons: 1) The more popular these CMS get, the more people need migration help, and the more resources are available for them (just google “joomla drupal migration“.) 2) More people than just the person who set the CMS up can help do the migration. Unfortunately, relationships with vendors go bad, and being stuck with data in a custom CMS makes migration away from a bad relationship that much harder.
This is the moment for nonprofits to stop accepting proposals with custom CMS, and to make it clear in the RFP that a custom CMS will not be acceptable. It’s also the time for web developers to let their babies go, and start building their business on a well-developed CMS. (Hint: I hear there is way more Drupal demand than supply of expertise.)
Back in December, I had planned to talk first about document format standards before I plunged into XDI. But, a couple of things intervened. First, I decided to write a full blown whitepaper on document standards. So it will be a bit before it comes out. I think people (especially in the nonprofit sector) take document formats far too much for granted, and I think they deserve more treatment than just a blog entry.
I also had a chat with Andy Dale, of ooTao, and it provided lots of great fodder for an informational blog entry. So, here it is. I won’t go nearly into as much detail as he went with me – at some point I’ll write something much more substantial. But this is a good start.
What is XDI, anyway? XDI stands for XRI Data Interchange. It’s all about standards for sharing data over the net via XML and XRIs (eXtensible Resource Identifiers – URIs on steroids.)
If you look at the basic problem – how does data source “A” talk with data source “B”? We’ve done a lot of that via APIs – but that’s a set of idiosyncratic solutions to individual problems (solving the Convio <-> GoogleMaps problem is different than solving the Joomla <-> Salesforce problem, for instance – lots easier than it used to be, but still atomized.) How can this be standardized?
It’s important to understand that this problem has many layers. The first is the identifier layer. Who are you, anyway? Then – authentication – how do I know that you are who you say you are? Then there is authorization/trust – what are you allowed to do, what data can you see? And, finally, there comes the data sharing layer. That’s where this is all leading, of course, but what if when you finally get down to that layer, I say “tomayto” and you say “tomaato”?
Each of the technologies implemented at these layers have to be optimized for different things – you wouldn’t want your data sharing layer to have strong crypto, and be optimized for figuring out who you are, would you? That would be inefficient. So these layers are separate, and, in most situations, pluggable. For instance, you could plug OpenID into the authentication layer for internet transactions, and use Kerberos for internal organizational purposes.
So, to the bottom layer of XDI is optimized for figuring out how the data should be shared. For example – think of a lexicon for all the ways that “First Name” exists out there (“given name”, “First”, “nombre”, etc.) – so it would be possible to share that data. Also, one idea that is a part of XDI is that some data is persistent, and some data is simply a link to persistent data – so the data doesn’t hold my address, for instance, but it does hold exactly where (the XRI) to get my current address.
Andy and I talked a bit about his work in the nonprofit sector. He sees the sector as a great place to try these ideas out – because, for the most part, there is a much more open and flexible ethos around data sharing. I think that probably is mostly true, but as I pointed out to him, the sector is often years behind the for-profit sector in terms of technology. There is a pilot project with Kintera to expose a subset of one nonprofit’s data to an XDI interface. There are others lined up to try it, and the hope is it will spread. I certainly hope it does, and I will be keeping track of this effort, for sure.
I think the idea of this kind of standard – moving data sharing beyond what we (barely) have now, which are these very atomized sets of solutions (even though they are solutions we badly need.) If every data-centric application (ooh, that’s redundant) that a nonprofit implemented had a standard interface for data sharing – think about the possibilities there. Right now, it’s still basically impossible to look at big pictures across a wide range of data domains. This kind of standard would make those kinds of analyses a lot easier.
So this is the next jump beyond open APIs: imagine SQL-like queries on any data, anywhere you were trusted, and across those sources. And I thought open APIs were the holy grail!
Technorati Tags: nptech, openAPI, openstandards, xdi
I hate spam. I always have. But lately, I don’t have to deal with much, which is true for most people. Between server-side bayesian filtering, and client-side filtering, only two or three spam messages gets into my actual inbox everyday. Very nice.
But now, it appears that spam is making it’s horrible way to the web. The first I heard of this was the blogs (on blogger, mostly) designed only to be created to manipulate search engines.
Now, there is a trend in domain name hosting. People will register a domain, test it for traffic, and use it only to deliver Google or Yahoo ads. If that domain can generate one or two dollars more than the cost of the registration, then they keep the domain. If you do this for thousands of domains, this can generate thousands of dollars in revenue.
I imagine that, like bayesian spam filtering, tools like del.icio.us and other collaborative bookmarking tools will mean that people will come across those blogs and domains less and less (and thus not make them cost-effective,) but in the meantime, we have spam to deal with.
