In an article from Duct Tape Marketing, by John Jantsch, he talks about the benefits of hosting a blog on your own server.  This is a feature that Compendium Blogware provides for you.  There are many benefits to NOT hosting your own software. 
  1. You do not have to learn how to apply the upgrades to your existing software.
  2. We walk you through any questions that you might have so you fully understand the functionality of your software.
  3. Any problems that you experience with "free" blogs, you are expected to fix.  We take the guessing game out of it by fixing the issues for you.
  4. Our company is open for suggestions that you have for product requests.  Therefore, you get to use a software that you are comfortable with. 
Our blog hosting software is always changing and improving to fit the needs of our clients.  If you are considering utilizing an organizational blogging platform look no further than Compendium.

Another search engine?  Are we really in need?  Maybe if it is drastically better, maybe if it makes my life easier; but in general I am not sitting there wanting a new search engine, but I also have to assume that most marketers aren't sitting wanting for a corporate blogging tool --- it's my job to show them that they need one.  So has Cuil convinced me to switch from Google?  Not quite.  Although Cuil was founded by Google engineers and brags about the increased number of pages that are combed through and the ability to search the so called 'deep web'.  In addition, the search results look more like a magazine than a list, as traditional web searches do.  Not to mention the $33M in venture-capital money.

Interesting concept...but a bit confusing for my first try.  Also, was a bit surprised with the results of a few test searches.  Unfortunately, it looks like this evening that their servers were a bit overloaded and I wasn't able to get results for a few terms.  I like the innovation, pushing every search engine to be better and better.  However, this doesn't seem game changing for Compendium because at the end of the day --- a search engine's success will always be based on its ability to serve up the most relevant results based on the search terms in the quickest and most user friendly way.

What does this mean to our business?  Not much --- we measure some of our client's  success with Google and benchmark search standings there as well; but the topically driven corporate blogs that are created from the Compendium system are search engine neutral.

Yesterday, InfoWorld ran a story on the rise of scripting languages and an interview with Mozilla JavaScript architect Brendan Eich. Both are very worthwhile reads because they provide a nice mix of the state of the art and the historical context of scripting languages.

Prior to hiring with Compendium about six months ago, I had tinkered with scripting languages largely as side tasks.  The mainstay of my work lie in compiled languages like C, C++, and occasionally some Java. 

As I sought out new job opportunities both locally and nationally last year, I began to realize that openings for compiled languages were on the decline.  Indeed, a friend of a friend out in the Bay Area advised me last summer with these words:
In terms of technical skills, C++/Linux is a great foundation, however, there is a caveat. In the SF bay area overall, companies are more likely to use newer technologies for R&D/new development. There is still a lot of support work out there, but I would say the growing trend is to outsource support work, so those jobs are ever decreasing... Also, I would suggest making a larger investment on learning newer technologies, such as Java and other technologies on the LAMP (Linux/Apache/MySQL/PHP, Python, or Perl) stack.
That turned out to be some very solid advice, even though I wound up staying in Indianapolis.  Here at Compendium, scripting languages like PHP, JavaScript, and Perl are the bread and butter of our day-to-day efforts to build user-friendly blog software.  The transition proved to be pretty smooth because PHP's syntax borrows so heavily from C and C++.  I was lucky in the sense that I was learning the language within a disciplined environment that made sure web apps were developed properly. 

One of the quotations from the article that jumped out at me was the remark by Andi Gutmans, co-CTO at Zend Technologies.
"It's very easy to pick up and then it will also scale with your needs," Gutmans explains. "I often call it the Visual Basic of the Web."
The ease with which the language is learned is a double-edge sword.  On one hand, it flattens the learning curve, but on the other, it gives mediocre programmers enough dynamite to be dangerous. 

Jeff Atwood at Coding Horror noted as much about a month ago in his bluntly titled blog post "PHP Sucks, But it Doesn't Matter".  Atwood does a pretty good job of surveying the disdain as well as the widespread usage that PHP has managed to garner, but I don't think he quite closes the loop in his analysis.

Syntactically, PHP is a pretty elegant language.  It steals enough syntax from C++ to be familiar but escapes the hideousness of template meta-programming because a dynamic language doesn't have to worry about how to deal with generics.

From my own experience the bad reputation of PHP has two origins. 

The first lies in its original use as a way to embed server-side executable code within an HTML document.  Web programmers latched onto this in droves and abused it, creating websites that did not separate the business, presentation, and application logic cleanly.

The second sore spot is how PHP has managed to assimilate just about every third party library under the sun.  If you've ever had to install PHP or build it from scratch, you already have a deep appreciation, or at least a healthy fear, of how many optional elements can be integrated into the system.  A lot of times, these APIs are written to parallel the nomenclature of library APIs in C or C++, which makes for inconsistencies.

Ironically enough, both of these things are probably among the factors that helped speed the adoption of the language.

What has helped sustain PHP?  Two things come to mind, based on my limited experience.

For one thing, the PHP development community got Model/View/Controller religion.  Nowadays, there are tens of PHP frameworks designed to help developers employ the MVC design pattern, which helps separate the logics and avoid the ugly code for which PHP became notorious.  Granted, not all of them are of equal quality, and some have already gone dormant.  What's important is that enough developers realized that the old way of doing things was neither sustainable nor scalable.

The second thing was the under-the-hood change of basing PHP on the Zend engine, which has helped it to achieve performance levels that you might not expect from a dynamic language.

For all of the speed of development that one achieves with a dynamic language, there is one thing I could live without.  The incredible syntax flexibility of a scripting language like PHP can allow you to create code that is syntactically correct but semantically crazy.

For example, I recently wrote some code that was intended to build up a string that you could pass on to a logging facility.  It looked something like this:
$logger_string = 'problem with operation foo '  . 
$print_r($some_variable, true) . ' some more text';
The bug in this code was that there should have been no dollar sign in front of print_r. It's a function name, not a variable.  PHP sees this as just fine and dandy, converting $print_r into  function name, provided that the variable name evaluates to a string.  This kind of thing will pass the PHP syntax checker but will cause a fatal error at runtime.  It's similar to the situation where a spell checker won't save you from using mistakenly using a homophone.

In spite of all of that, I'm happy to be coding with PHP.  Errors like those above are pretty rare.  Moreover, I don't miss having to worry about type declarations and memory management.  In spite of numerous sins of programmers past, I firmly believe that PHP is a great language to build a solid blogging platform. We're already doing that!

There are a lot of parallels to compare Corporate Blogging today to where Email Marketing was 5 or 6 years ago.   Back then, Email Marketing was free.  All you had to do was download a ListServ application, configure a server or two, find and manipulate some plug-in applications for registration or bounces or unsubscribes or de-duplication or throttling or opens & clickthrough tracking or analytics.....and the list goes on.

In the end, some geeks might have loved all this tinkering, but from a business or marketing standpoint it was a nightmare.   The solution was all encompassing SaaS tools from companies like ExactTarget, Constant Contact or Responsys...

Superior tools designed for marketers, not IT folks.   In the end, both parties were happier.

The same discussion happens in Corporate Blogging Software.   "WordPress is free...why pay you?"    For the most part we hear this when IT folks are involved.   Natuarally as they understand the Compendium Blogware offering they start to see the feature differences, but the don't really understand that Free isn't Free. 

That is why I was so happy to see this post today from a big Technology focused Blog talking about how overly hard WordPress is:

"Recently I have started chatting to an engineer at Automattic, the mob which employs most of the lead programmers on Wordpress. They also run the Wordpress.com service, which is a big job — millions of blogs, tens of millions of monthly visits."
"I complained to him that one of my annoyances in life is how complex Wordpress actually is. Why? Because you don’t just have to configure Wordpress to get anywhere. To get it to perform acceptably you can either throw powerful hardware at the problem (which is how Club Troppo has done it since our donation drive last year) or you can implement a whole rogue’s gallery of tweaks and adaptations."

When you think about what your goals are with advanced business blogging the focus should be on engagement and traffic through SEO....not constantly tweaking software, messing with plug-ins or installing more powerful servers.   Let the Vendor manage that stuff....



On the very excellent Hacker News, someone recently asked the question, "Yes or no: Should web startups host on Amazon?". There are a couple of recent events which I think force this question to be particularly relevant. First, AWS (Amazon Web Services) recently suffered a massive outage, covered here on O'Reilly Radar. Second, a variety of competitors to EC2 (Mosso and Joyent) as well as S3 (EMC) have recently cropped up. Lastly, I continue to more frequently get questions along the lines of, "What's with this PaaS (Platform as a Service) thing?".

What is Platform as a Service?
Let's start with the basics. Platform as a Service, or PaaS as it is more commonly referred to, can be thought of as being like a utility (such as electricity or water). When you need water, you turn on the faucet and you turn it off when you're done. You're only billed for what you use. Likewise with PaaS, when you need "platform" (storage, compute, etc) you simply "turn it on" until you are done.

This is in contrast to a traditional platform model, where you have a significant investment in hardware such as network infrastructure (such as switches, routers and firewalls), storage (SAN, NAS, Fibre Channel, etc) and servers. Not to mention, in this traditional model you typically need experts to manage each of these.

Enter the "managed hosting" platform, Colo, etc. All of these are variations on the traditional hosted model but with changes to cost. At a Colo, you may not be paying for the hardware you may be leasing it. Many of these colocation providers also have "managed services" which allow you to leverage their experts, reducing costs as you now don't need your own. None of these platforms are "pay per drink"/utility however. In other words, these are different from PaaS.

Traditional hosted models are typically much more expensive than the utility model, since at a minimum they typically require monthly contracts (or a huge up front investment). So if you need one more server, even if it's just for testing for a few hours (or handling some additional load for a few days), you are billed for the entire month (or for a whole server).

When should I use PaaS?
This is where the utility model comes in, and where the original question with regard to startups becomes relevant. At a startup you are typically resource constrained in terms of time and treasure (cash). This makes the PaaS model alluring, seductive even. But, and I seem to keep beating this drum, there is no free lunch.

In the best case, such as with Amazon, you simply have an outage that lasts a few hours. In the worst case, your hosting company goes out of business and you lose everything. There is however, a sweet spot. A place where PaaS and a traditional hosting model complement each other very well.

PaaS is a killer for "edge services"; e.g. a CDN, log processing, content proxies, caches, etc. Things where, if it goes away, you're not going out of business. There is a reason that the tried and tested concept of a CDN always uses an origin server, that is, a server that it fetches data from (a master). You want fast delivery, replication, and to leverage a fairly inexpensive infrastructure. What you don't want, is for the CDN to lose a server and now you are missing data.

I still believe that a hosted model is the appropriate place to keep your primary application though. Your data is too important to simply give over to another company. I believe this will change in the future as these PaaS providers start to provide better SLA's, improve reliability and can be held accountable for hours of downtime. Until that happens though, use PaaS for the things it is well suited for, ephemeral tasks and data.

A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable.
-- Leslie Lamport
The Business Technology blog at the Wall Street Journal has a post about a service outage on Amazon's S3, a web service for online data storage.  Service describers are expressing anger at the three-hour outage because it undermines Amazon's claim of 99.99 percent availability.  Blog author Ben Worthen says that the incident raises questions about the prudence of entrusting your computing operations to a third party.
A two to three hour outage, while not common, is the sort of problem that a corporate information-technology department experiences from time to time. It’s bad for business, but not the end of the world. But when you’re dealing with something that challenges the status quo routine, problems invariably draw attention to shortcomings with the model. In this case, it isn’t your techies that are trying to get your business up and running, but Amazon’s.
Putting aspects of IT operations in the hands of other is not really that new or rare.  Lots of companies do not keep their customer-facing webservers in-house.  Instead, the place them at co-location centers, which have the responsibility of providing reliable network connectivity, power, and security.  There are lots of companies that have outsourced their mail servers, relying on a hosting service to provide e-mail delivery and storage.

I think Amazon's S3's outage more significant for two reasons:
  1. Amazon's web services, like S3 and EC2, are getting more attention in the mainstream press.  Amazon VP of Product Development is quoted indirectly by the Associated Press saying that the goal of their web services is to help entrepreneurs focus on ideas rather than server crashes.
  2. Highly consolidated services produce more severe outages.  This is not only true for hosted services like S3, it's also true for in-house systems where a single machine hosts several servers, each of which runs on a virtual machine.
In order for cloud computing to live up to its full promise, service providers will need to factor in ways to recover quickly from server outages, perhaps through some form of redundancy or clustering.  It will also require customers to rethink how they build their applications around these services to take into account a failure.

As for Amazon, I look for them to recover from this embarrassment.  They are probably one of the most advanced software development teams in the world, having tackled some very challenging system tasks in the past.  They'll figure this one out, too.

Sources are saying that Barack Obama's website is pulling in upwards of $525,000 and HOUR! an HOUR!! This is purely from online donations and traffic. The Obama campaign measures the online donations every 15 minutes - and the evening after the South Carolina debate - supporters were on their computers, with credit cards in hand helping Obama push forward in his quest for President.

So how has Obama created a website with such a draw that his supporters are not only donating - but sharing their own input and ideas? He created a blog! And lets his supporters create their own blogs on his blogging platform. my.barackobama.com  allows you to contribute to a community of topics and issues supporting Obama's campaign. What he has done - is created a very powerful blogging software platform that is generating such tremendous feedback that people are flocking to his site hourly to check on new posts and information. The only blogging problems  are (if you can call this a problem) - is because of his overwhelming support, servers are becoming overwhelmed with all the traffic So visitors are not able to access the information as easily.

Here is a great video that was produced by Will.i.am of The Black Eyed Peas. And was Inspired by Barack Obama's 'Yes We Can' speech. http://www.dipdive.com/
I have seen a lot of emotional PR related to the Presidential election - but this truly moved me.



..


if only he could leverage this content in a way that won search on issues he supported .. and fully leveraged the idea for blogging for search..

I was going through my email inbox this morning and read a great brief from eMarketer on Grabbing Those Valuable Search Minutes.  The brief details how advertisers spend money on paid search relative to the audience on a per ad basis.  Interesting enough, the majority of advertising dollars are still being spend on paid search keywords, while the audience is only spending 5% of their online time in search engines.  The overwhelming majority of the time (50%), the audience is spending, is on content. 

How does this relate to blogging?  Well, consider that blogging is all about content! It is posted in a reverse chronological order and written with a human voice.  Now if the audience is spending the majority of their time on content, how can you leverage a successful corporate blogging strategy to drive conversions and revenues accordingly?  We have spoken with and are working with dozens of publishing companies, newspapers, etc which are all trying to capture and retain internet users via our philosophy of blogging for SEO, while at the same time monetizing those efforts into recognizable revenues.  Several of them are seeing success in either allowing an advertiser the ability to sponsor a particular blog, a network of blogs, or implementing their ad server into the blog template. 

Whatever course of action you may take, now is the time to begin converting those Paid Search advertising dollars to where your audience is spending their time, with the content you have available.  Blogging can produce the audience, when structured correctly and executed properly.

How will you monetize this audience?

As someone who is working for his second startup, I like to read about what kinds of ideas are being pitched by startups at conferences like Demo, which is going on this week.  Computer trade publication InfoWorld is running a story on Demo participants whose ideas revolve around prediction.  One of the featured startups was Hubdub, a company whose website attempts to predict outcomes on future events based on quasi wagers placed by site participants.

Predicting non-sports outcomes via wagers isn't a new idea itself.  The eerie accuracy of such markets motivated the Pentagon to explore the creation of terrorism futures markets in 2003, but that idea got axed after it created a lot of controversy.  The Iowa Electronic Markets website has hosted political prediction markets for many years.  On the commercial side, Intrade operates markets for a wide variety of events, from the serious to the superficial (last year they had markets for American Idol).

From what I can tell, Hubdub distinguishes itself from these other markets in two areas:
  1. The markets are strictly binary outcomes (yes/no, one thing/the other).  Other predictive markets may have as many contracts as there are distinct outcomes.
  2. There is a leader board that ranks top participants.  Other predictive markets are anonymous environments.
The second point is significant because this is what Hubdub is using to draw participation.  Wagers are made in terms of a psuedo currency, which is a measure of the accuracy of the participant.  A good record of accurate predictions raises the visibility of the participant.  Quoting the article (emphasis mine):
The point of the game is to see who comes out right most of the time. If you are one of those folks, according to Hubdub officials, you will obviously gain street cred in your area of expertise -- politics, stock market, or technology, for example. Besides gaining some form of respect from your peers, credibility may also lead to more users coming to your Web site or blog. This, in theory, could be shaped into a business where a person's analytical capabilities are worth paying for.
Hubdub's angle on reputation building is interesting.   When pundits discuss the idea of digitizing reputations, they often invoke the dystopic vision of "reputation servers" as described in Bruce Sterling's novel Distraction.  Hubdub's meritocratic path to distinction offers up a kinder and gentler vision of the future.  It's your actions, not other's words, that determine your rating.

The idea of giving away predictions in exchange for the potential of a better reputation and more inbound traffic reminds me of Eric S. Raymond's discussion of reputation in gift cultures in his essay Homesteading the Noosphere where he writes (emphasis mine):

There are reasons general to every gift culture why peer repute (prestige) is worth playing for:

First and most obviously, good reputation among one's peers is a primary reward. We're wired to experience it that way for evolutionary reasons touched on earlier. (Many people learn to redirect their drive for prestige into various sublimations that have no obvious connection to a visible peer group, such as "honor", "ethical integrity", "piety" etc.; this does not change the underlying mechanism.)

Secondly, prestige is a good way (and in a pure gift economy, the only way) to attract attention and cooperation from others. If one is well known for generosity, intelligence, fair dealing, leadership ability, or other good qualities, it becomes much easier to persuade other people that they will gain by association with you.

Thirdly, if your gift economy is in contact with or intertwined with an exchange economy or a command hierarchy, your reputation may spill over and earn you higher status there.

The context of Raymond's essay is the "hacker culture" of open source development, and I could see where someone might try to argue holds true for Hubdub's predictive markets.  I'm not totally convinced that this is the case.  The basis of my skepticism is drawn from the same passage a few sentences later:
The main 'peculiar condition' is that the artifacts one gives away (or, interpreted another way, are the visible sign of one's gift of energy and time) are very complex.
Casting votes to black-and-white questions doesn't take a lot of energy and time.  One could do as little as flip a coin to choose an outcome.  The most valuable answers -- the kind that people pay for counsel -- usually involve weighing a question that cannot be answered in a yes-or-no form.  The value is in discerning the shades of gray.

I think this issue is of great significance to a bloggers looking to elevate their profile.  Rather than trying to find a shortcut to drive traffic to your blog, consider writing high quality posts that answer the shades-of-gray questions your customers might face.   Why?  Because the substance of these posts are the artifacts of energy and complexity that build a real reputation.

I am excited for a new boost of energy in Compendium's own blogging strategy...we have just started a new blogging initiative within our own company and everyone has the goal of blogging twice a week --- a great place to start! 

With several new employees starting within the last couple of weeks this is also great timing within the organization --- as externally facing blogs are a gold mine when it comes to getting to know others within your company better including their attitudes, thoughts and knowledge about corporate blogging.  So check out a few of the newest Compendium Blogs.