I’m at an interesting intersection in my career path. I just concluded eight years at a small, statewide health care reform nonprofit in Massachusetts called Community Partners. I was Technology & Strategy Director there. Like so many orgs around us, we went under a month ago due to the bad economy. Though I am sad to lose my wonderful co-workers, it was coming for a long time, so I was somewhat prepared. A long time ago, other organizations and foundations started asking me lots of technology questions. This has naturally parlayed into consulting.
At this juncture where I have a sense of what it's like to work in a small org and am also looking at and helping larger orgs and foundations to make decisions about tech and use it in smart ways, I’m thinking a lot about something I call "supported open source."
"How do I choose a CMS?" is one of the most frequent questions I get. "Should I go with a closed but well-supported system or should I venture out into the Badlands of Open Source?" There is another way! That is supported open source.
The perception is often that if you choose open source—even if you hire additional expertise to initially build your site—you have to have skills in-house to keep it going after launch. I think the perception that you're on your own with open source is one of the barriers to its adoption for many businesses and nonprofits. But there are companies and consultants that will stick around, long after your site is launched, to give you the help and support you need. And there are different ways of doing this based on your org's budget.
At Community Partners, we ran things on a shoestring. I build web sites, but I don't write custom PHP code. When we wanted to use a profile module to collect contact information from users on our Drupal site and sync it with our Access mailing list database (yes, I know... Old Skool...), I found the module. It didn't work right. This functionality was a priority for us, though. Luckily, we maintained a contractual relationship with a Drupal consultant who would help us out with our site when our budget allowed. We only paid him to help us when something was broken, or when we wanted a new feature we couldn't implement ourselves and we had the funds to do it.
Having someone you can pay to give you support only when you need it is clearly cheapest way to go. If you're rolling in money, however, having a company on-call 24-7 to support you with anything you need is the other end of the spectrum. And everything in between exists. I want to disclose here that at present, I have a paid relationship with a consulting firm called OpenIssue LLC, which offers a spectrum of services for open source CMS platforms. I am working with them because I am becoming increasingly convinced that supported open source is has some serious advantages for our sector.
I am dogmatic about not being dogmatic, and the needs and mission of an org should always determine what technology they choose, not the other way around. You're never married to a piece of software and you should change platforms if and whenever it serves you. But particularly during this time of economic uncertainty, there is something comforting to me about software that's being developed by a worldwide brain trust. Open source software can't be yanked out from under you if funds (temporarily) disappear, or if a contract expires, because we all own it.
Though this community code base can be messy, open source development specialists know how to clean it up for you. So you get that worldwide scope of innovation, plus the focused attention on your org's particular needs. For orgs that want to stay innovative but don't always have cash flow, this can be a great solution. Ongoing support can be stopped and re-started as needed when there are budget troubles.
I know of a few companies out there that explicitly offer ongoing support for open source platforms. My fave among these is PICnet. Non-Profit Soapbox is designed to be an affordable, fully hosted, software-as-a-service (SaaS) way for nonprofits to build sites quickly and easily in the Joomla! CMS. PICnet has been around for a long time, and honestly I don't know why more companies aren't offering open source SaaS for nonprofits. Seems like a great idea to me. Here are a couple more companies that offer ongoing support:
I predict more of these companies will emerge in the coming year, and I think it will be a great leap forward for our sector. Do you know of a company or a consultant that offers ongoing support for open source software platforms? If so, I'd love to know about them. Please add them in the comments.
In an earlier post, I talked about two challenges which fuel cloud computing: the capital and support costs of network infrastructures and desktop anarchy. I want to pick up here where I left off, with more discussion of three cloud computing opportunities.
Software as a Service probably has the most familiarity. The wispy tendrils of Software as a Service reached into my Thanksgiving this year. Usually, we don’t host, and this year we will. To reduce operational costs, frustrated with the support costs involved with email, I put the family invite list, arrival and departure logistics and food contributions up on doodle.com.
It’s off my desktop and phone system into their system--simple, collaborative, low cost, centrally maintained, reliably backed-up, eminently scalable (hopefully won’t need that for our thanksgiving), platform independent, secure (enough for this), environmentally sustainable (carbon offsets for how much we may eat).
Doodle is a light weight alternative to meetingwizard.com or more elaborate reservation systems, and though its light-weightedness caused some other problems, it helped.
Meanwhile, Linda tapped into foodie SaaS epicurious.com to supplement the menu planning. Yes, we also have the 3-ring binders of family recipes and a shelf of cookbooks. Epicurious (OK, I prefer allrecipes.com) brings a world of collaboration, search, on-demand, pay as you go to the meal planning type of project. Print magazine co-sponsor Gourmet magazine is about to close its doors, but no doubt SaaS Epicurious will continue.
Holiday photo-sharing? Facebook, Flickr, Google web albums and not bring-your-own laptop, flash drive or photo album.
At the consumer level, Google has championed this approach more than any other company. Google entices millions to leave the desktop behind and do our daily work with on Gmail, Google Documents, Calendar, YouTube, Maps, Groups and more. Yahoo and others add to the offerings.
Once you get comfortable, you may find yourself surrounding yourself with other services. You may well use a hosted pay as you go service like Basecamp, Zoho or Central Desktop to mange projects. You may use Mozy, Carbonite, Dropbox or other web based services for back-up. You may use webex, adobe connect, or logmein to provide hosted screen sharing or web conferencing services.
Going back ten years, at the corporate level, Salesforce championed the software as a service approach to managing contacts, leads, business relationships, and all things related to the sales process (and now support and other business functions). Instead of network installing Act, Goldmine, Microsoft stuff at the low end or Siebel and other systems at the high end, they invited customers to use their web service. Pay according to what you need month-to-month, and let them take care of security, back-up, support, upgrades and the like.
The SF foundation charitable donation and “starter pack” has extended Salesforce’s appeal to nonprofits as well.
As I suggested earlier, these types of services typically may get justified on cost basis. Specifically, they transform long term capital and human resources costs into operating expenses. Today’s recession favors this calculation. Instead of figuring out the total cost of ownership of a new server, new software, support costs, licensing, periodic version updates, desktop upgrades, back-up, security and other ancillary utility purchases, SaaS lets organizational planners focus on one thing—the monthly usage cost. They also favor collaborative approaches to getting things done that are not as easy or natural on traditional network installed systems.
As critical applications move up to the cloud, the desktop does not matter very much. All that matters is having a standard browser.
Yet, to get to those web software as a services, you still have you to boot up that familiar personal computer and land on your personal desktop. Google hopes to go further, turning its Chrome browser into an entire web-facing operating system. More about that another time.
For now, for most of us, the desktop still matters a lot. Most of us still do our daily work there—word processing, maybe email, maybe other stuff. It matters for installed donor and contact management systems, network accounting software, critical long time installed databases whether Microsoft Access or some giant client server application. It matters when you want to print, scan, archive, share files, and avoid malware all the while. When these issues come up, the costs in time and support in monitoring and managing desktops come into play.
IT as a service (or Infrastructure as a Service) looks at things from this end. If the premise of SAAS is to make the desktop matter less, with IT as a Service, the idea is to tame it.
IT as a service has levels and gradations. It often begins with combining and rationalizing network servers using virtualization. VMWare and other companies have popularized the idea of running mutual virtual machines on the same hardware. Many businesses and organizations today have more than one server. They may have a basic server for sharing files and printing. Another for Exchange email management. Another for their fund-raising software or other special applications. Virtualizing servers takes advantage of increased computing power to reduce the total number of servers, and focus on keeping those few up and running well.
A related trend is to centralize and standardize the user experience. You start up your machine and then connect via Microsoft Terminal Services or Citrix into central server which then gives you a new, fresh, controlled desktop. For larger companies, creating that standardized network infrastructure makes it easier to then have IT infrastructure specialists manage everything from afar using elaborate diagnostic tools such as Kasaya.
The higher level next step is to move the whole infrastructure up to the web. If everything is centralized, virtualized, standardized, why not seek even higher efficiencies of scales by running the whole operation on someone else’s servers, where bunches of other organizations also are getting managed at the same time in the same place.
Ask you local network support organization if they have this kind of offering and compare prices with what you are doing and planning now. I recently got a major taste of this approach at a day-long business summit run by Zumasys, a West Coast infrastructure company which has helped some of our larger clients, and I see other partners heading in this direction.
Of course, like SaaS, IT as a Service come at a cost. Both point in the direction of flexibly supporting organizational expansion, especially in a recessionary era, reducing support costs, and reducing user woes and problems, and also reducing the cost of a desktop computer.
The goal is usually not to reduce on-site IT staff, but to keep that staff from burning out and to keep it focused on strategic support and innovation. By commodifying basic support issues, IT staff can focus on what is critical and distinctive about what you need and do.
I’m trying out Open Atrium. http://openatrium.com/ Now in first beta, Open Atrium from Development Seed consolidates powerful project management features to Drupal in a modern, polished format.
When we first started bearing down on Drupal two years ago, about the first thing we wanted to do manage independent projects on our own www.dbdes.com site. We got reasonably far, with the ability to define clients, projects, tasks and organize blog-like discussion and documents for each. Given the state of the art two years ago in Drupal and our own priorities, we eventually shelved it in favor of a generally positive relationship with Basecamp (http://www.basecamphq.com). Meanwhile, many of our Drupal sites required one or another set of Intranet features, and each one got delivered in customized, one-off ways.
Fast forward to summer 2009, and the Open Atrium project led by the wonderful Development Seed team (http://developmentseed.org/) promises to provide a standard Intranet within a Drupal site. I suspect along the way, it will give Basecamp and its competitors a run for its money. Well, given that Open Atrium is open source, “run for the money” may not be the best way to express the comparison; more about that later.
So what is Open Atrium and what does it have?
Install Open Atrium as easily as Drupal 6 generally, and then get going with it in about 5 minutes. Open Atrium has all the polish now available in Drupal 6-on-the-verge-of-Drupal 7.
Create a group and start adding users to them. If you know Basecamp, a group might correspond to a “project.” As with a Basecamp project, you can have people from more than one company on a project. Drupal fans: Open Atrium groups rely on Drupal’s “Organic Groups” module and start with all that OG power.
From the group dashboard, you see a snapshot of all the recent activity for the group, and each user can customize elements of his/her dashboard.
Each group has its own group blog for discussion with comments and related documents. Anyone who uses project management software these days would probably agree that the blog format works better in a more modern way than older-style web forums or bulletin boards. And it uses the increasing popular "markdown" technique for formatting text. You can assign users with the group to take part in a discussion, with notifications going to the user by email. In the full production release, Open Atrium will also have other familiar forms of messaging.
Each group has its own calendar of events, which aims to exchange in and out with your other calendars. Use the calendar to mark out deadlines and major project events.
Document library, in any upload format, including the ability to compare revisions of documents.
Each group also can have a “shoutbox,” which resembles a private group twitter space. What is a private twitter? We have experimented with Yammer (http://www.yammer.com), which you should check out if you want a cool, free, private twitter for your team. Having a group shoutbox offers the same and part of the whole Open Atrium for that group. This has great potential in itself when it reaches the full release stage.
Case Tracker. In the case tracker, you create projects for your group, which I would say roughly correspond to Basecamp milestones, and then you add cases to them. Cases correspond to to-dos or tasks. The case feature already has the advantage of assigning multiple people to them, having start and end dates associated with each case, setting priority, notification and so on. Basecamp alternatives has features like this, and it’s great to see them in Open Atrium. And each case has full blog like discussion and the ability to attach documents.
This is a very cool start. And I expect Open Atrium to really take off. Within the Drupal community, adding Intranet and collaborative features like these has been part of the big appeal. Open Atrium offers the prospect of being able to do it in a standard way.
Having a complete open source project management alternative is part of the larger discussion about cloud computing and hosted software. We like delegating to 47 Signals (the Basecamp publisher) all the administration of the site for all our concurrent projects. And yes, I do trust having client data secure on Basecamp. Wow, one big thing not to have to worry about!
The Basecamp API allows manipulating of any and all data they store for me. And even without that, I can regularly download all project activity in one XML file. Please note: Not project documents, but everything else. With the help of the wonderful ThickToast add-on from http://www.vb123.com/basecamp/, I can regularly bring Basecamp activity into our internal Access-based billing system.
Yet overall, like our use of any Software-As-A-Service provider, disengaging from Basecamp would be a complicated process. Like moving out of a place you have lived in for a while, lot of stuff to take care of and fit to where you are going. And it does mean counting on some start-up company’s commitment to privacy and security.
Open Atrium allows you to host your stuff wherever you want. All your data is there in accessible MySQL tables, following Drupal standard node format. Like everything else with Drupal, you will have the choice of your own private server; hosting it on any of tons of reliable Internet Service Provider; or -- I suspect -- provided in fully managed SAAS format by Acquia or someone. For Drupal developers, taking part with Development Seed in the development project is a lot more friendly than making suggestions, say, to the Basecamp folks.
What provides more overall peace of mind I will leave as (an interesting) topic for another day.
For sure, Open Atrium is Open Source, downloadable without licensing fees. And those who involved, which I suspect we will, will have a lot of say in how the project evolves. In the first week of release of the beta version of the software, over 10,000 people downloaded it—outstanding for a brand new Open Source project. And the project has close to 2000 twitter followers.
Check it out; I know we will. I am already thinking about which upcoming project to manage from it.
My esteemed colleague Michelle Murrain lobbed the first volley in our debate over whether tis safer to host all of your data at home, or to trust a third party with it. The debate is focused on Software as a Service (SaaS) as a computing option for small to mid-sized nonprofits with little internal IT expertise. This would be a lot more fun if Michelle was dead-on against the SaaS concept, and if I was telling you to damn the torpedos and go full speed ahead with it. But we're all about the rational analysis here at Idealware, so, while I'm a SaaS advocate and Michelle urges caution, there's plenty of give and take on both sides.
Michelle makes a lot of sound points, focusing on the very apt one that a lack of organizational technology expertise will be just as risky a thing in an outsourced arrangement as it is in-house. But I only partially agree.
Security: Certainly, bad security procedures are bad security procedures, and that risk exists in both environments. But beyond the things that could be addressed by IT-informed policies, there are also the security precautions that require money to invest in and staff to support, like encryption and firewalls. I reject the argument that the data is safer on an unsecured, internal network than it is in a properly secured, PCI-Compliant, hosted environment. You're not just paying the SaaS provider to manage the servers that you manage today; you're paying them to do a more thorough and compliant job at it.
Backups: Many tiny nonprofits don't have reliable backup in place; a suitable SaaS provider will have that covered. While you will also want them to provide local backups (either via scheduled download or regular shipment of DVDs), even without that, it's conceivable that the hosted situation will provide you with better redundancy than your own efforts.
Data Access: Finally, data access is key, but I've seen many cases where vendor licensing restricts users from working with their own data on a locally installed server. Being able to access your data, report on it, back it up, and, if you choose, globally update it is the ground floor that you negotiate to for any data management system, be it hosted or not. To counter Michelle, resource-strapped orgs might be better off with a hosted system that comes with data management services than an internal one that requires advanced SQL training to work with.
Where we might really not see eye to eye on this is in our perception of how 'at risk" these small nonprofits are, and I look at things like increasing governmental and industry regulation of internal security around credit cards and donor information as a time bomb for many small orgs, who might soon find themselves facing exorbitant fines or criminal charges for being your typical nonprofit, managing their infrastructure on a shoestring and, by necessity, skimping on some of the best practices. It's simple - the more we invest in administration, the worse we look in our Guidestar ratings. In that scenario, outsourcing this expertise is a more affordable and reliable option than trying to staff to it, or, worse, hope we don't get caught.
But one point of Michelle's that I absolutely agree with is that IT-starved nonprofits lack the internal expertise to properly assess hosting environments. In any outsourcing arrangement, the vendors have to be thoroughly vetted, with complete assurances about your access to data, their ability to protect it, and their plans for your data if their business goes under. Just as you wouldn't delegate your credit card processing needs to some kid in a basement, you can trust your critical systems to some startup with no assurance of next year's funding. So this is where you make the right investments, avail yourself of the type of information that Idealware provides, and hire a consultant.
To me, there are two types of risk: The type you take, and the type you foster by assuming that your current practices will suffice in an ever-changing world (more on this next week). Make no mistake, SaaS is a risky enterprise. But managing your own technology without tech-savvy staff on hand is something worse than taking a risk - it's setting yourself up for disaster. While there are numerous ways to mitigate that, none of them are dollar or risk free, and SaaS could prove to be a real bang for your buck alternative, in the right circumstances.
Peter Campbell and I have had an ongoing conversation/argument about whether or not Software-as-a-Service (hereby known as SaaS) is more secure than in-house facilities in a small, IT resource-poor organization. So we decided to "have it out" so to speak, on the Idealware blog.
First - we are talking here about small or medium-sized nonprofit organizations with no dedicated IT staff. And the question is, basically, "is it more secure for that organization to house their data and services 'in the cloud', instead of in-house?" My answer is "no." Don't get me wrong, I think SaaS is a great thing - my company implements it, and I've been thinking a lot about SaaS using open source tools. And it's not less secure, at all, either. But it is not a security panacea, and it shouldn't be thought of that way.
Why is this? I want to start by asking the questions "what is security?" and "what are they risking?" Security is, in my mind, is their data safe from getting in the wrong hands? And the risks are not only stolen data, but also corrupted and lost data.
People who spend a lot of time thinking about security do get lost in the depths of encryption, blocking ports, protections against attacks, and virus/worm protection and the like. And I think it gets easy to imagine that if someone (a SaaS vendor) does security "right" and a nonprofit, who has little or no access to good IT expertise, will inevitably do it "wrong", then SaaS will be more secure for them.
But lack of access to good IT expertise means a few things:
Yes, it does mean that their in-house network is likely insecure
It also means that they might not know how to understand or choose SaaS products that are known to be stable and secure, with solid business models.
It means they likely won't know how to get their data out when they need to, for whatever reason
It means there is a lack of understanding of the risks of SaaS, especially in organizations, like human rights or activist organizations, with sensitive data.
And the human factor in security doesn't pay attention to where the data lives.
What do I mean by the "human factor?" I mean using "password" for passwords. I mean sharing passwords among staff, some of whom eventually leave the organization. I mean not doing backups (yes, having backups are important for SaaS, too.)
So my opinion is that we can't say definitively which is more "secure," because there are too many factors at play. And the most important thing is education of organizations around security and risk.
If your nonprofit has 40 or more people on staff, it's a likely bet that you use Microsoft Exchange as your email server. There are, of course, many nonprofits that will use the email services that come with your web hosting, and there are some using legacy products like Novell's Groupwise or Lotus Notes/Domino. But the market share for email and groupware has gone to Microsoft, and, at this point, the only compelling up and coming competition comes from Google.
There are reasons why Microsoft has dominated the market. Exchange is a mature and powerful product, that does absolutely everything that an email system has to do, and offers powerful calendaring, contact management and information sharing features on top of it. A quick comparison to Google's GMail offering might look a bit like "Bambi vs. Godzilla". And, as Michelle pointed out the other day, GMail might be a risky proposition, despite it being more affordable, because it puts your entire mail store "in the cloud". But Gmail's approach is so radically different from Microsoft's that I think it deserves a more detailed pro/con comparison.
Before we start, it's important to acknowledge that the major difference is the hosted/cloud versus local installation, and there's a middle ground - services that host Exchange for you - Microsoft even has their own cloud service. If you are evaluating email platforms and including GMail and Exchange, hosted Exchange should be weighed as an additional option. But my goal here is to contrast the new versus the traditional, and traditional Exchange installations are in your server room, not someone else's.
Server Platform
Installing Exchange is not a simple task. Smaller organizations can get away with cheaper hardware, but the instructions say that you'll need a large server for mail storage; a secondary server for web and internet functions, and, most likely, a third server to house your third party anti-spam and anti-virus solutions. Plus, Exchange won't work in a Linux or Novell network - there has to be an additional server running Microsoft's Active Directory in place before you can even install it. It can be a very stable product if you get the installation right, but getting it right means doing a lot of prep and research, because the slim documents that come in the box don't prepare you for the complexity. Once you have it running, you have to run regular maintenance and keep a close watch - along with mailbox limits - to insure that the message bases don't fill up or corrupt.
GMail, on the other hand, is only available as a hosted solution. Setup is a matter of mapping your domain to Google's services (can be tricky, but child's play compared to Exchange) and adding your users.
Win - GMail. It saves you a lot of expense, when you factor in the required IT time and expertise with the hardware and software costs for multiple servers.
EMail Clients
Outlookhas it's weaknesses - slow and obtuse search, poor spam handling, and a tendency toward unexplained crashes and slowdowns on a regular basis. But, as a traditional mail client, it has a feast of features. There isn't much that you can't do with it. One of the most compelling reasons to stick with Outlook is it's extensibility. Via add-ons and integrations, Outlook can serve as a portal to applications, databases, web sites and communications. In a business environment, you might be sacrificing some key functionality without it, much as you often have to use Internet explorer in order to access business-focused web sites.
But where Outlook is a very hefty application, with tons of features and settings buried in it's cavernous array of menus and dialog boxes, Gmail is deceptively uncluttered. The truth is that the web-based GMail client can do a lot of sophisticated tricks, including a few that Outlook can't -- like allowing you to decide that you'd rather "Reply to All" mid-message -- and some that you can only do with Outlook by enabling obscure features and clicking around a lot, like threading conversations and applying multiple "tags" to a single message. Gmail is the first mail client to burst out of the file cabinet metaphor. Once you get used to this, it's liberating. Messages don't get archived to drawers, they get tagged with one or more labels. You can add stars to the important ones. It's not that you can't emulate this workflow in Outlook, it's that it's fast and smooth in GMail, and supported by a very intelligent and blazingly fast search function. Of course, if that doesn't float your boat, you can always use Outlook - or any other standard POP3 or IMAP client - to access GMail.
Win - GMail. It's more innovative and flexible, and I didn't even dig deep.
Availability
Exchange, of course, is not subject to the vagaries of internet availability when you're at the office. Mind you, much of the mail that you're waiting to receive is. And Outlook - if you run in "Cached mode" - has had offline access down for ages. GMail just started experimenting with that this week. If you're not in the office, Exchange supports a variety of ways to get to the mail. Outlook Web Access (OWA) is a sophisticated web-based client that, with Exchange 2007 and IE as the browser, almost replicates the desktop Outlook experience. OMA is a mobile-friendly web interface. And ActiveSync, which is supported on many phones (including the iPhone) is the most powerful, stable and feature-rich synchronization platform available. Exchange can do POP and IMAP as well, and also supports a VPN-like mode called Outlook Anywhere (or HTTPS over RPC).
GMail only supports web, pop and IMAP. There's a mobile GMAIL app which is available on more phones than Activesync is, but it isn't as robust or full featured as Microsoft's offering.
So, oddly, the Win for remote access goes to Microsoft over Google, because Microsoft's offerings are plentiful and mature.
Business Continuity
So, not to belabor this, Exchange is well supported by many powerful backup products. In cached mode, it mirrors your server mailbox to your dektop, which is additional redundancy.
GMail is in the cloud, so backup isn't quite as straightforward. Offline mode does some synchronization, like Exchange's cached mode, but it's not 100% or, at this point, configurable. Prudent GMail users will, even if they don't read mail in it, set up a POP email program to regularly download their mail in order to have a local copy.
Win - Microsoft
Microsoft also Wins the security comparison - Google can, and has, cut off user's email accounts. There seem to have been good reasons, such as chasing out hackers who had commandeered accounts. But keeping your email on your backed-up server behind your firewall will always be more secure than the cloud.
But I'd hedge that award with the consideration that Exchange's complexity is a risk in itself. It's all well and safe if it is running optimally and it's being backed up. But most nonprofits are strapped when it comes to the staffing and cost to support this kind of solution. If you can't provide the proper care and feeding that a system like Exchange requires, you might well be at more risk with an in-house solution. The competence of a vendor like Google managing your servers is a plus.
Finally, cost. GMail wins hands down. The supported Google Apps platform is free for nonprofits. Microsoft offers us deep discounts with their charity pricing, but Dell and HP don't match on the hardware, and certified Microsoft Administrators come in the $60-120k annual range.
So, in terms of ease of management and cost, GMail easily wins. There are some big trade-offs between Microsoft's kitchen sink approach to features and Google's intelligent, progressive functionality, and, in well-resourced environments, Microsoft is the secure choice, but in tightly resourced ones - like nonprofits - GMail is a stable and supported option. The warnings about trusting Google -- or any other Software as a Service vendor -- are prudent, but there are a lot of factors to weigh. And it's going to come down to a lot of give and take, with considerations particular to your environment, to determine what the effective choice is. In a lot of cases, the cloud will weigh heavier on the scale than the colossus.
At this Thanksgiving time of year, we are supposed to reflect on things we take for granted. Don’t worry, I’m not going to start in on Thanksgiving. I just want to acknowledge that I tend to take some of my desktop tools for granted. Case in point this morning: don’t take your browser or you web mail for granted.
I admit that I have a lot going on in both Firefox and Gmail. This morning, trying out a combination of new Google labs settings for Gmail plus the Getting Things Done Firefox add-in, I suddenly and abruptly got logged out of Gmail. I got a polite, but unbelievably firm “locked out” message. For up to 24 hours!
Searching on user groups, I saw that some people once locked out wound up locked out for days at a time. And one person found that once unlocked, all old email was gone. I prepared for the worst—I submitted an email pleading my greediness and asking to be let back in. I looked at my alternatives. And decided to blog about it. I want to say that 3 hours later, I’m back in. In the meantime, I thought about some lessons. Much of this falls under the category of don’t take things for granted.
Not taking things for granted begins with testing add-ins meticulously. I had modified my settings a few days ago, but not restarted Firefox. This morning, I added something else, restarted. Quite possibly the installation of both together into Gmail clashed and triggered the lock-out out. Add things one at a time, restart each time, and make sure the new thing tests in a clear environment.
I often have a lot of Firefox tabs open. And sometimes, not seeing my Gmail or Google Calendar tab, I end up opening another. In the help pages, it says clearly that being logged in multiple places and switching active sessions can trigger a lock-out. I will not take Firefox’s stability for granted and be more careful about my tabs.
Don’t add more add-ins to Firefox than you need. I love my add-ins and I am going to write something at some point about my favorite add-ins, but, hmm, not today.
Have a back-up plan. This is probably the most important lesson. After using Eudora for years, trying out Outlook (I’m sure you have heard of it), I settled in on Thunderbird, which has been fine. In the last while, however, I have been testing Gmail to consider moving our email hosting there. Fortunately, all my webmail could still download to Thunderbird. I was able to confirm that even though I couldn’t open Gmail, Google still was faithfully, if more slowly, receiving and forwarding email to Thunderbird. Nothing wrong with that. If you rely on web mail, it makes sense to still have a POP or IMAP local account somewhere that backs everything up and that you can use in an emergency.
Clear you cache once in a while. I do that in IE and Opera, but not in Firefox. Letting browser cache get all messed up is also mentioned as something that can contribute to triggering a lock-out.
Be careful with beta software. Yes, look closely, almost everything beyond search you use from Google is still marked as beta. Gmail Beta, Documents Beta, Calendar Beta. Can’t a big company like Google get its big stuff out of Beta? And if not, be careful trusting critical organizational stuff there. At least have the alternatives and back-ups in place, as mentioned earlier.
Be careful with software you can’t get support for. As I mentioned, I’m using Gmail a lot as an experiment. If you have a basic Gmail account, you have limited recourse if something goes wrong. Take that into account in your planning. Only with the paid business or free nonprofit apps edition can you get phone support for “critical issues.”
So I’m back where I was, lessons often mentioned as general advice to others, now reinforced in my own case.
I keep being surprised by how frequently I hear clients tell me that a vendor has suggested they "build them a CMS," or by proposals from vendors that include custom building a CMS. I hear people suggesting building their own social networking website. I even occasionally still hear tell of organizations who want custom CRMs.
The web software landscape has changed dramatically over the years. Five years ago, it was full of custom built systems of all sorts - and the "build vs. buy" decision was, I think, more difficult, because the available software to buy was fairly cruddy. (And, for the purposes of this post, I'm using "buy" exceedingly loosely - including purchasing proprietary software, installing open source, or using SaaS.)
But the landscape is different now, and I think that, in some senses, the "build vs. buy" decision is much more straightforward. First, the software available, whether it be open source, SaaS, or proprietary, is much better all round. There are new types of software being developed all the time (like, for instance, the new crop of "Social Network Management Systems" both open source and SaaS, like Ning.)
In addition, the increasing openness of software, whether it be open source, or open platforms like Salesforce.com, means that customizing software to your needs, or integrating different pieces is much more straightforward, meaning it's a lot easier to create exactly what you need by integration or customization, rather than building from scratch.
This is not to say that there is no role for custom built applications. I'm in the process of working with two organizations to create just that. But they are both for quite highly specialized functions. And I've also been involved in projects to create interesting and customized web functionality - but those are being done with adding custom modules to an open source CMS.
From my perspective, exhaust all of the "buy" options: open source/proprietary/SaaS out-of-the-box, customized open source/SaaS, or integration of already existing components, or building modules on top of open source tools, before you take on building something new from the ground up. You'll save money and time, as well as be able to take advantage of an upgrade path as web software changes and improves, meaning you won't have to build whole systems again.
Subscribe through Feedburner