Boris Mann

I imagine what Rackspace gets out of this is, that if successful, they will at least have some sort of leverage with Amazon. Amazon is a machine. Amazon executes to perfection and they release new features at a relentless pace with no signs of slowing down. They don't leave much of a door open for others to get into the game. With a real open cloud alternative it might allow a lot of people to play in the cloud space that would have been squeezed out before.

What Amazon can't match is the open cloud's capability of simultaneous supporting applications that can run seamlessly in a private cloud hosted in a corporate datacenter, in local development and test clouds, and in a full featured public cloud.

OpenStack is the first development in the cloud space that hints at a future where there actually are more than half a dozen big platform / cloud providers (aka Hosting Apocalypse).

What does Rackspace get out of it? Well, they don't get obliterated and/or don't have to try and be a VAR on top of someone else's stack. This open source approach allows them a chance at controlling their own destiny.

What are other large hosting / data center providers doing? Nothing much - riding out the end of shared hosting and getting sold to by VMWare, from what I can see.

Let's get straight to the meat of this post: I accepted an offer letter earlier this week, and as of September 1st, I'll be joining the team at iQmetrix.

Now, most of you won't have heard of iQmetrix. I think they're going to be known as a great Canadian success story. Here's a bit of background about the organization.

The company is privately held, around 10 years old, and started in Regina, Saskatchewan. They scratched their own itch at Jump.ca – a wireless retailer AKA store that sells cellphones / mobile plans / accessories etc. – and wrote their own software for CRM, point-of-sale, and so on. The productized version of this became iQmetrix, and they went on to grow until today, there are wireless retailers using the software in every major mall in North America.

So the entire executive team packed their bags back in Saskatchewan, pulled up stakes, and moved out to Vancouver with their families to found the corporate head office here. And now it's time for iQmetrix to kick into growth mode.

We're seeing the first non-phone devices like the iPad coming into wireless retailers, and the app store model for software sales is going crazy. There will only be more devices, more accessories, and more things that your wireless retailer will be selling, and that Main Street America will want to know more about.

Is the wireless retailer going to become like the local computer store? Perhaps - that didn't exactly turn out well. And the story is different in Europe of course, where many countries already have many more wireless retailers or SIM card vendors than we do here.

The other angle that iQmetrix has is around interactive retail. This is another new term to me, and as I've been digesting what it means and how to explain it, the analogy I've come up with is this:

Right now, advertising in the offline world is on a continuum somewhere between billboards and Minority Report.

That is, a range of technologies and products from physical billboards and signage in malls and along highways at one end, to the future of personalized, digital, local offers as seen in Minority Report (touch interfaces included, of course) at the other end.

At the billboard end, there is relatively boring evolutionary technology like digital billboards that aren't interactive and are still broadcast. 

Closer to the MR, revolutionary end of things, we have personalized, direct offers, with the recent news of the Shopkick install into Best Buy stores perhaps being one example. Sites like Foursquare and Twitter might be something that we include on the right hand side of the continuum - there is lots of revolutionary change & experimentation happening here (the Foundry Group's HCI Theme fits in this space).

I think that the current buzz-tag "O2O" (Online 2 Offline) is related - Groupon is held up as one example in a recent Techcrunch article, but I actually believe this is just a (rising) trend of small businesses adopting technology / advertising solutions that are web-based, and so we are seeing a shift of dollars.

In any case, it should be obvious that I'm excited about the opportunity. I have a lot to learn about this new space, but it feels like an area that is starting a decade long change that mirrors the growth of the web in the mid-90s. I will be bringing some startup, web native, and community experience to the table, and to continue to tell the iQmetrix story.

Thanks to Kerem Karatal for reaching out to me while I was sitting on the bench after Bootup, and thanks to the exec team at iQmetrix for hiring "title TBD". I'm looking forward to what we can all accomplish together, and I'm happy to be keeping the Vancouver community as my home base. 

I've played with PostRank in the past (probably back when they were called Aide RSS). They're a Canadian company, based out of Waterloo, founded back in 2007 (CrunchBase entry). They're best known for their "PR" - ranking on blog posts to see if it is important. Since this is similar to what Summify is doing with their social news reader, I'm hoping there might be a connection here.

I dived back into it in the last couple of days because I got notification about PostRank Connect, which is a brand / influencer connector / tracker (as near as I can tell - it's not really "turned on" at the moment).

But PostRank analytics is what is live now, and it's great. Here's a screenshot of the front page of this blog, the default "Overview" tab in PostRank:

The top is the engagement value as tracked by PostRank - comments, tweets, delicious bookmarks, and so on that that post has generated. The bottom are page views from Google Analytics - you click a button, do the OAuth dance, and then connect in your existing Google Analytics account.

Most of the traffic to my blog is organic search from being around for 10 years, so you don't see massive spikes of pageviews correlated to engagement.

Here's another screen shot from the "analyze" tab, which shows you a compact view of posts to your blog, with engagement events and engagement points to give you an overview of how impactful each post is:

If you look carefully, you can see that the Twitter and Delicious links are underlined - you can click through and see more info about who has tweeted / bookmarked your posts. I'd like to see click throughs and info for all of them.

You can see more details about the PostRank Analytics service on the tour page, where you'll also find that it is $9 / month or $99 / year, although I've been told that with a "Connect" account, you'll get a free Analytics account.

Jason Santa Maria wrote a long post called A Real Web Design Application, where he talks about searching for a tool that has the creativity of Photoshop with more of a native understanding of the web. It's a good read, and the comments are over 250 and counting.

I remember talking about how Dreamweaver is dead as part of my 3 Stages of Dynamic Systems talk at Web Directions North 2008. And yet, just the other day I met with someone that was doing a content-based startup and had built hundreds of pages with Dreamweaver templates.

Today, I tend to still reach for OmniGraffle for prototyping, site maps, and so on. On the other end of things, I'm still using a basic text editor for coding (Smultron). I love the team at Balsamiq, but I just haven't been able to get over my distaste for AIR apps. I don't use Photoshop, because I'm design-disabled :P

In any case, I found two interesting tools in the comment thread that might at the very least be Dreamweaver killers.

Steve Parks wrote an article over at Drupal Radar about "elephants" (aka large global IT / services / consulting) shops like Capgemini starting to adopt Drupal and what that means for smaller shops.

Jo Wouters from Krimson left a comment that made a couple of good points. The first part of his comment was that adopting Drupal is a strategic choice, where community was part of the value of adopting Drupal in the first place. I'm quoting the last bit of his comment directly:

Some anecdotal evidence: we are working on a proof of concept for one of the elephants. The spreadsheet they provide us to calculate budgets, has fields for all traditional costs (debugging, project management, contingency, …) and for this project they added an extra field with the label “Community 10%”.

via drupalradar.com by Jo Wouters, Krimson

(emphasis mine)

Budgeting for "community" is absolutely the right thing to do. I've spoken for years about the concept of "Community ROI" (return on investment).

It's very much the language of business - that investing in the community will see a return. Many from the community side find the language of business problematic - we do this because we love it. I've tried to be more pragmatic: having a sustainable business means that you can be funded to continue to do the things you love. In any case, it's clear that these strategic decisions see the value of the community, and see the return in investing in it.

There are, of course, many shops that don't contribute to Drupal. Sorry, writing case studies doesn't cut it - I'm looking for links to patches, module maintainership, contributing handbook documentation, and so on. That, and as I just wrote, actively contributing patches back as part of the client development process. I honestly believe that any shop that doesn't follow community practices as part of developing a site is doing their client a disservice.

Of course, if you don't have experience doing this, it can be hard to get started. Especially, it can be hard to "sell" to clients. One concept I've been tossing around is a line item labeled "Platform Maintenance". If your shop absolutely can't get past the mental hurdle of selling community involvement, then explain to clients that you add (some percentage / some hours) in order to keep their website future proof, secure, more maintainable, etc. Take this time and follow best practices for patching / features for contrib as part of development. Take the time and bundle a module or feature and post it to Drupal.org (the client gets a sponsored by link on the page -- Drupal being a high traffic website, this counts for a lot).

Back to the elephants. We've been lucky to build a critical mass of community before larger players arrived. The Drupal community has always been an ecosystem. There are larger players and smaller players, but we all orbit around the Drupal.org community space. The actions of Capgemini and others are showing that they are stepping up to be part of the ecosystem, which is fantastic. It means, for smaller players, that they need to step up their game when it comes to business planning and other aspects that many have just "grown into".

I'm interested in how you / your shop "sell" Drupal community and/or open source. Many shops have a standard "what is Drupal / why is it awesome", but it tends to focus on features or perhaps low cost. What are the specific open source points that you sell? How do you budget it - do you just work it into your cost, or show line items to clients?

Patches that we write for drupal.org modules are submitted to the issue queue, and we refer to the patch’s location on drupal.org in the make file. This has made us much better contributors to other people projects as it makes being involved in the issue queue a normal part of development, and it encourages us to only patch contrib modules where it’s likely that the patch will be accepted. When a patch gets a review, we make changes, upload a newer version of the patch to drupal.org, and update our make file.

via developmentseed.org

This is actually a quote from Jeff in the comments on the article Drush Make Files for Production Drupal sites, but I thought it was definitely worth highlighting on its own.

In this particular case, using make files actually codifies the decision to integrate closely with contrib modules and actively improve them / add features as needed for a particular project.

I've followed this practice for years, albeit without make files. Patches go in a "patches" directory in version control, with the patch file named with both the name of the module and the node number of the issue on Drupal.org.

An additional process is that if a patch is needed, you run it in the issue queue on Drupal.org, but you also have an internal ticket that links to that issue. You don't close the issue until the patch has been accepted into the mainline of the module. Then you can remove the patch, update the version of the module you're using, and your clients' website is one step closer to easier long term maintenance and updates.

And yes, being involved in the issue queue SHOULD be a normal part of developing Drupal websites.

One more before we go - Boris Mann is joining Drupal Radar as a contributor. He’ll be writing articles and helping to grow our Radar Database feature and make it more useful for other sites via RDF or an API. Watch out for his byline soon!

via DrupalRadar.com

That's the quote buried at the end of On The Radar: 17th July 2010.

I talked to Steve Parks, founder of Drupal Radar, on Friday morning. He's based out of the UK where he runs Pilot Internet, and comes from a journalistic background. Steve started out as a BBC Radio Journalist and started way back in the Drupal 4.6 days.

Steve says:

"it got to the stage where I wanted to give something back to the community, and I thought I could this in two ways:

1. Documentation
2. Helping the community stay cohesive, even as it gets really large, by having a good trade publication to keep everyone up to date, with independent but informed journalism. That's the aim for Drupal Radar".

I was planning my own Drupal information related project, and when I saw what Steve had already put together, I reached out to see if we could work together.

This is very much Steve's baby (perhaps we'll call him a Benevolent Editor rather than Dictator), but he's hoping to build DR in an open collaborative way, much like the Drupal community itself. This means CC licensed comment, including the "Radar Database" which will be information about the people and companies in the Drupal ecosystem. Sort of a Crunchbase for Drupal.

I've spoken out in support of Matt Mullenweg, WordPress, the GPL, and general open source community principles before. It seems like we keep having this discussion, and that it often degenerates into a battle of personalities.

Here's what I continue to believe about licensing and the GPL, which started as a comment on Why the GPL does not apply to Premium WordPress themes, which is part of the #thesiswp running battle. For context, you may also want to watch the Chris Pearson / Matt Mullenweg interview.

Bottom line: Themes and modules are derivatives and should be licensed under the GPL. You can use trademark and other non-code protections that will let you sell them and limit distribution if that is your chosen business model.

The rest of this is the comment I posted.

The way that PHP is executed means that everything runs together in the same space, with no separation (this is a simplification, but essentially correct). So, not the same as the red herring about software apps and operating systems (this comes up all the time).

The Drupal community generally agrees with WordPress in that all themes and modules are derivatives and thus must be licensed as GPL *if* you distribute.

For many years, I've settled on Unfuddle as my hosted tool of choice for development-focused project management and version control repo hosting. It's a great tool if you want all in one development ticketing / bug tracking (which is what I mean when I say "dev focused" PM) plus your code repository all in one place.

However, I've been moving away from using Unfuddle for this type of project management, or been called into other projects where an existing PM tool is already in place -- most notable, either Basecamp or Open Atrium, with the Drupal-based Atrium being something I'm very keen on supporting (interested in seeing more hosted tools integrated with Open Atrium? contact me).

In cases like this, I really ONLY need a (private) hosted code repository*. I saw an article recently comparing various options for private DVCS hosting (DVCS = distributed version control systems like Git or Mercurial) which nicely complimented some of the research/experimentation that I've been doing.

The review states its goals very clearly: lowest cost-per-repository, with storage used as a secondary consideration. Everyone will have their own needs to rank providers across.

For me, I'm interested in a mix between features and pricing, especially using it on a consulting basis with lots of clients, and different kinds of clients (from those that don't use version control at all, to those that have in house developers already).

RepositoryHosting.com is clearly the lowest price-per-repository: it's $6 / month for unlimited repos with a bundled 2GB of storage, plus $1 per additional GB of storage. No "cost per project" means I can generate a project per client / idea / whatever and not have to worry about it. There is bundled ticketing in the form of Trac, and it's likely OK / has evolved since I got sick of it when we used it at Bryght -- I'm not giving points in this review for PM tools in any case. The WebDAV shares is a very cool feature, especially for integrating clients, designers, and other folks into the mix that will find it hard to adopt the version control system directly.

On the features side of things, my pick goes to Beanstalk. It starts with a free plan so you can check it out right away with 1 private repo. The first paid plan is $15 per month, and I'm fine with their 10 repository limit, but I'm always annoyed at limited user counts. Regardless, it is a super clean interface that people will find very easy to use and it integrates with a ton of different tools (Twitter, Basecamp, Harvest, etc.). But the main reason it is a choice that I'm going to be using more and more is that it offers direct FTP / SFTP deployment. I think this makes it a perfect tool for design-centric shops -- they can continue to use FTP-based hosting services and workflows, while starting to adopt best practices version control.

Bottom line: Unfuddle is a great all in one solution and one that I recommend to clients over and over again if they have no PM or development management tools in place, but for just repo hosting, you should consider RepositoryHosting.com and Beanstalk.

I start a lot of my posts these days with a reblog using Posterous. Thus, a lot of permalinks end up over on my "asides" blog, because a lot of the "comment" activity ends up either over there, or on Twitter.

My particular dual website problem might not be solved by this, but it's clear that keeping track of the discussion around blog posts is very much a distributed issue. Don't even get me started on the "Share with Note" in Google Reader that leaves comments stranded over in Reader where post authors are unlikely to to see them :P

The three big systems that I'm aware of at the moment are Disqus, Echo, and IntenseDebate.

On the Bootup Labs and Bootup Entrepreneurial Society WordPress blogs, I went with IntenseDebate. It's my favourite system mainly because I know the Automattic team and I trust them to do what's right for the web long term. Being part of Automattic also removes the (immediate) need to monetize heavily, so they can focus on features and support.

Disqus is very similar to IntenseDebate. In fact, I think it's great that they were being developed at around the same time, because I think the teams competing against each other spurred development and features. Disqus is VC funded, and so is trying a number of different monetization strategies. They have a paid VIP program, although pricing isn't disclosed.

I found a great compare and contrast blog post between Disqus and IntenseDebate that goes feature by feature. At the time (May 2009), IntenseDebate didn't support Facebook or Twitter logins, although they added them both. I have a hard time telling the two systems apart - any passionate users of either system want to point out killer features (or missing ones)?

Echo is the only system without a free option: you can get a 30 day free trial and then switch to either a $10 or $100 month version. Of course, it is fundamentally a very different system. While they do have "JS Kit" (their former name) accounts, this is very much de-emphasized in favour of only using distributed logins from other systems. As well, it aggregates "comments" from elsewhere - whether the comment is a link on Delicious, Friendfeed, Facebook, etc. etc. This has more in common with Trackbacks, but in the Echo system, it is highly integrated and seems more natural than the other two that are "comments first". Finally, Echo doesn't currently write back to the native comment system, using only a JavaScript plugin. This has implications for SEO, and implications for me really wanting to have my own copy of the comment should the service in the sky "go away" :P

On the Drupal side of things, only Disqus and Echo have plugins available, at http://drupal.org/project/disqus and http://drupal.org/project/jskitcomments respectively. From a technology perspective, I like the real time nature of Echo and the general direction that it is heading -- it's almost like having Friendfeed embedded under each post. But, the JavaScript only plugin and the lack of free option for personal bloggers makes it a no go. Since there currently isn't an IntenseDebate plugin for Drupal, I'm going to go with Disqus for now, even though I would rather support the Automattic team.

UPDATE: I just realized after re-reading the Disqus module description, that it will *import* comments from Drupal, but it does not then write those comments back to the native comment system. So, in Drupal, we have zero options for a distributed comment system that writes back / syncs with native comments.