When I migrated Enter Content Here off of Blogger, moving the content and comments was really easy - literally just the click of a button. This was a nice surprise because my expectations were based on a typically painful CMS migration. Because I use FeedBurner, my RSS readership experienced little disruption either. I already had moved my Blogger blog to a custom domain and WordPress allows you to format your own permalinks so it was easy to map the old URLs to the new with a simple Apache Rewrite Rule. Within my blog.contenthere.net virtual host of my hosting provider, I created the rule:
RewriteRule .* http://www.contenthere.net%{REQUEST_URI}
The one piece of the move that proved to be an issue was getting Google to update its index and move entries from blog.contenthere.net to www.contenthere.net. This was particularly problematic because I wanted to use the Google Custom Search Plugin for WordPress so I could include product pages and other content in my search results. I submitted a dynamically updated Sitemap (using the Wordpress Sitemap Plugin), Google ignored all of my entries (see image on top).
I learned from the support forum that Google probably thought that these new pages (under www.contenthere.net) were duplicates of the blog.contenthere.net pages and was skipping them. I don’t really understand why that is because there is no way that the rendered pages could be identical. I just had to take it on faith. The only way to get Google to update its index is to configure your rewrite to send down a status code of 301 (permanent redirect). The updated rewrite rule looks like this:
RewriteRule .* http://www.contenthere.net%{REQUEST_URI} [R=301]
While I was at writing rewrite rules, I added a few more to handle the situations where WordPress’s permalink algorithm was different than Blogger’s. The biggest difference is that Blogger omits “The” and “A” from a post title when building a permalink. There were also discrepancies where I changed the title of the post after publishing.
To improve my custom Google search in the short term, I added the site blog.contenthere.net to the list of indexed sites. This way people using the onboard search can still find the pages that have not yet been re-indexed and, when they do, Google should get the 301 code.
As for my old blogger blog (contenthere.blogspot.com), I did everything I could to make it as ugly and unappealing as possible. I wrote messages explaining the move all over the template. What I really wanted to do was have a link from each post to the new URL. However, there is no path variable that would allow me to construct a new link by concatenating the new domain (www.contenthere.net) to the current path. Blogger just has a tag for the full URL (data:post.url) and I couldn’t find syntax for substrings. I could have done it with Javascript but didn’t want to bother. Instead, I inserted a search form for my custom search in each post and preloaded it with the blog post title. This approach has the additional benefits of potentially giving the visitor more recent content and also sending them through Google to give it another chance to update its index. I have a free statcounter collecting traffic statistics on that site. When it gets down to 0, I will probably delete the whole blog.
Since making these changes, my search based traffic is back to its pre-migration levels. Google still doesn’t seem to take an interest in my Sitemap but that doesn’t seem to matter. Through the process, I have learned that originally hosting my blog on Blogger did not lock me into the platform. Instead, it allowed me to focus on the content and quickly establish a voice in the blogosphere without worrying about infrastructure. Blogger’s support of custom URL’s was critical to minimizing lock-in. When I migrated to a custom domain, Blogger helped route traffic from the blogspot URL to the new one. This put me in a good position to move to the blog to any platform I chose.
Evaluating open source and closed source software
December 30th, 2008Gartner has been saying how the current recession favors open source software. Many people in the open source software business are experiencing the same thing. They are finding themselves included in software selections against commercial players that were once considered out of their class (certainly out of their market). I think this is a great new development. There are some very good open source platforms that have been ignored for the simple reason of being open source and not having the same recognition as their closed source competitors.
That said, using licensing cost as a primary decision factor is a bad idea. Licensing is still a relatively small portion of the overall cost of a software solution. When a company looking to save money on licensing also tries to cut costs in other aspects of the solution (implementation, migration, deployment, and training) project risk balloons. In fact, most of the open source horror stories I have heard can be attributed to this same flawed logic. An open source software implementation project will probably cost the same to execute (not less, not more) than an equally suitable commercial product. I predict that 2009 will see many failures from unrealistic technology investments as companies try to unscrupulously cut costs and suspend their disbelief of a free lunch. But there will be an equal number of successes as companies consider leaner (easier to use) technologies and more agile (and pragmatic approaches) to implement them. This is where a trusted and experienced implementation partner can be invaluable by setting realistic budgetary expectations and efficiently expending resources. If you go with an open source solution, be sure not to skimp on the resources that will make the execution of the project a success.
The primary challenge in evaluating open and closed source software at the same time is that they tend to be represented unevenly. Even commercial open source products (which behave very similarly to traditional commercial software companies) usually cannot afford to field a sales team like a commercially licensed product company can. Without the upside of an all-profit license sale, the risk simply isn’t worth it. Even traditional commercial software companies balk at spending money on sales when the potential license deal is too small. Somebody else needs to represent the solution to level the playing field.
The open source product advocate could be your own internal I.T. or it could be a systems integrator that presents a complete solution. Both options come with complications. If it is your internal I.T. organization, things can get emotional and political. They will get attached to their solution. In fact if they don’t feel a personal connection to what they are selling (like a commission-dependent external salesperson is), they won’t be a good advocate. If their solution is not selected, there are bound to be hurt feelings and the last thing you want is someone on the team hoping for an “I told you so” moment when their victorious competitor runs into problems. Another potential issue is that I.T. may not have the resources to support their solution if it is selected. Presumably they have other responsibilities that won’t go away if they “get this deal.” Of course, this is less of a risk with commercial open source software that comes with a support contract that is similar to the other commercial solutions you are considering.
The primary problem with using an external systems integrator is knowing which one to use. Because every open source project is offered by many consultancies, the systems integrator market is even more chaotic and confusing than the software market; and there are fewer resources available to help you figure it out. Furthermore these companies are in constant flux as their staffs turn-over. The secondary issue is that there are big stylistic differences between a consulting sale and a product sale. A consultant sells by consulting. He wants to learn about the problem and work with you to solve it. He is less comfortable just quoting specifications and prices of a pre-defined like a software salesman may. His quote will be appear high because he is unable to ignore or trivialize the implementation effort like commercial software salespeople tend to do. And, because consulting carries a lower margin than software licensing, he is probably less willing to invest as much in a customized demo. The last thing he wants to do is build a big part of the system for you and then have you turn around and have someone else finish it.
Still, I do think that using external systems integrators is the way to go. In fact, I spend a lot of time talking to consultancies to keep track of who is good at what so I can refer my clients to the right integration partner. The best way to normalize the software vs. consulting stylistic differences when you are considering an open solution is to have all the solutions presented by integration partners. This will give you a more realistic comparison of the true cost and scope of the solution. A consultant is less likely to exaggerate “out of the box” capabilities than the software vendor because he will be around when the box is opened. This will also level the playing field on the investment that each candidate is able to make. If you take this approach, you will come out of your selection with a trusted partner that knows your business and is personally invested in your success. With that, how can you go wrong?
Posted in commentary, open source, selection | 2 Comments »