<!-- Content Here -->

Shortened URLs and spam filters

One of the more frustrating things about email these days is spam filtering. It stinks to miss important messages that your spam filter thought you shouldn't see. It is even worse when your message gets caught by someone else's spam filter. The latter case makes you paranoid whenever someone doesn't get back to you. You start thinking "did he get my message? Should I send it again?"

Just this morning, a spam filter rejected and sent back one of my emails with the following text:

Heuristic analysis has classified your e-Mail as spam and delivery has been refused. We apologize if your message was misinterpreted. Please check your entire message for any restricted content and then attempt a resend. You may also request addition to our list of pre-approved senders.
"Heuristic analysis" was probably an overstatement. It was probably just looking for keywords. But what could I have written in my email about scheduling a business meeting that would have triggered the rejection? Well, I am relatively certain that the issue is this.... In my email signature (and, in this case, the body too) I have a shortened link (is.gd) to my Google calendar so that the recipient can see when I am free. Personally, I thought this was a great idea because I work with clients who use Exchange or other groupware to schedule meetings when everyone is free. This technique allows the meeting organizer visibility into my calendar without my needing to join their calendaring system. I used a shortener because the link is really long. I use plain text emails so the length of the URL matters to me.

I still think exposing my calendar is a good idea so I figured out a work around. Google allows you to embed a calendar in another page so I just embedded it in page on http://www.contenthere.net that can easily be linked in an email. I am hoping this will lead to a drastic reduction in spam accusations.

Open Core

In case you have not been following the open source blogosphere, there is an interesting discussion happening around a new term called "open core." Open core describes the strategy of building a business on selling commercially licensed software with open source licensed components or companion products. Open core companies tend to use third party open source components and distribute some of their own components (not the complete solution) under an open source license (typically the GPL because that is the most protective). Matthew Aslett has a nice breakdown of what is and what isn't open core; although I disagree that the subscription model is open core when the vendor requires a subscription fee to use the software.

This strategy is in contrast to software companies that primarily offer a free open source version of their product and make their revenue entirely from support services (such as technical support, maintenance, training, implementation). eZ Publish and Hippo are pretty good examples of pure open source companies. The term "open core" was coined by Andrew Lampitt and all the chatter around it shows how much it is needed. The market needed something to distinguish the two types of companies: open source and open core. Nicholas Goodman makes the observation that it doesn't make sense for a company that only sells proprietary software to call itself an open source software company. Now each type of company gets its own descriptive classification.

Many of the "household name" open source software companies follow the open core model: Alfresco, SugarCRM, Pentaho, Magnolia... to name a few. The viability of the open source version varies from company to company. Magnolia Community, for example, is full featured enough for most typical uses and is as well maintained as the Enterprise Edition. In other cases, the Community Edition is deliberately hobbled to encourage an up-sell. In other cases, the licensing is just confusing. For example, Alfresco's Enterprise Edition is officially GPL licensed but you need to pay an annual subscription fee to use the copy that was compiled and tested by Alfresco, Inc. — and they won't sell you support or allow their partners help you unless you are using the version they compiled.

From a market perspective, the "open" companies that were established with venture capital tend to be open core. This makes sense because venture capitalists make big investments and are looking for big returns — bigger than what a pure services company can hope for. To get VC money, a start-up would have to position itself as a software company that needed to build product with scalable sales and decent margins downstream. Services companies don't work that way. A services company can make money from day one but shouldn't expect hockey stick growth and low variable costs. A successful service-based software company may also need huge market penetration to create a big enough market to sell services into. It is a matter of multiples. If for every 100 users you get 1 paying customer, you better have millions of users. Many software categories do not have that market potential. For every 1 CRM instance, a large company will probably have 3 CMS instances, 30 database instances, 60 web server instances, and 100 operating system instances. This is why RedHat can be more open to unpaid use than SugarCRM.

So, what does this all mean to the buyer? As I mentioned in the Open Source Web Content Management in Java Report, it is important to understand the vendor's business model to judge the viability of the company and the total cost of the software that you will bear. Differentiating between open source and open core will add some clarity to a confusing marketplace with complicated licensing models.

Daniel Jacobson on de-coupled publishing systems

Daniel Jacobson, NPR's Director of Application Development, has an excellent article on the philosophy of de-coupling the content management tier from the delivery tier. He calls this strategy COPE: Create Once Publish Everywhere. In particular, the diagram is particularly useful in showing how all the pieces fit together.

If you are in the content publishing business (like NPR is), this is absolutely how you need to think about your content technology stack. Your content repository, editorial systems, and distribution channels can get sophisticated and highly specialized so compromise and lock-in can be costly. The delivery tier that came with your content management system may not scale or may not allow you to push the cutting edge if an opportunity to innovate should arise. All of my big name publishing clients have adopted this strategy for their core publishing platform.

However, as I have warned in earlier posts, the flexibility may not be worth the cost for all publishers. Unless your business model depends on aggressively leveraging your content and you can afford to play on the cutting edge, a lighter weight "website in a box" style architecture may give you the flexibility you need without the additional complexity and cost of building and integrating these de-coupled systems. As an example, Drupal is rapidly becoming a popular platform for small to medium publishers and also for smaller initiatives in larger publishers. And you cannot get a tighter coupling of management and delivery tier than Drupal. One strategy that has been used by early Drupal adopters (that have grown out of their forked versions of the platforms) is to use Drupal to publish into a custom delivery tier.

As an architect, I love the COPE model and I think that most successful, large scale content businesses will eventually converge on that strategy. However, as a pragmatist who also serves publishers in the lower and middle tiers of the industry, I know that the resources and expertise may not be available to go straight to that architecture. Still, at the very least, every publisher needs to start thinking on this level: creating and storing content in presentation neutral way to keep options open.

Attending Django Master Class

I am looking forward to attending a Django Master Class, taught by Jacob Kaplan-Moss, on October 16th in Springfield, Virginia. I have been building a prototype application for a client in Django over the last couple of months and have been very impressed with the framework. It looks like the application will be going to Beta soon so it will be great to pick up some expert tricks that will take me to the next level.

Another flower war

Not quite the War of the Roses, there is a little skirmish happening between Magnolia International (as in the CMS company) and Ma.gnolia (the off-again, on-again social bookmarking site). The squabble began shortly after Ma.noglia's recent resurrection (it had shut down in February 2009) when Magnolia International issued what appears to be a Cease and Desist order. It is a little unclear because it was written by Magnolia's CEO, Pascal Mangold (not an attorney) and it seems to be more of a request than a demand.

I am no trademark attorney but, since that hasn't stopped anyone else, I figured I would weigh in from a common sense perspective. I understand how Magnolia International would want ma.gnolia.com to be out of the picture. They probably also want ExxonMobile to stop using magnolia.com. ExxonMobile probably wasn't paying attention when, then Obinary International, Magnolia registered magnolia.info to market their new open source CMS.

Does Ma.gnolia have the right to use their domain? I don't know. There are very specific legal distinctions to determine legal and illegal trademark infringement but I don't think it really matters. In the real world, it happens all the time. This is why you try to grab all the variations of your domain (.net, .org, and .biz as well as -sucks.com, -sucks.net, and -sucks.biz) when you are branding your company. You do your best to claim your little spot on the web and you work with what you've got. Getting lawyers involved is an expensive distraction.

I am sure that Pascal knows all this and that is why he wrote his own letter. Hey, it was worth a try. Maybe this will lead to a negotiation for Magnolia to purchase gnolia.com. Who knows how serious Ma.gnolia is about their business. Personally, I don't think I would use a bookmarking service that had a track record of closing down and opening up again.

This is not a particularly interesting story. What would be more interesting is if Magnolia International went after ExxonMobile. What the heck is ExxonMobile doing with that domain anyway?

Feature Request: Audience-Inspired Keywords

In order to maintain my vendor neutrality, I refrain from advising software companies about their products. But that doesn't stop me from having ideas and opinions so I am starting a series of features that I would like to see. Please feel free to use them and, if you do, tell me about it! If you don't like an idea, let me know why.

Today's feature request can probably be implemented (at least primitively) as a minor customization on most content management systems.

Audience-Inspired Keywords

When a visitor searches for content on the site (or arrives at the site from an external search result), the presentation tier records the keywords that he used. These keywords are then listed as options that content contributors can use to tag their content. This would allow contributors to tag content in the language of their audience. To keep things manageable, there should be a mechanism for filtering out typos and organizing the keywords. There may be some system that would allow you to group synonyms so if people search equally for "bike" and "bicycle," the contributor only has to use one of those terms and the asset is returned on both "bicycle" and "bike" searches.

The original seed for this idea occurred way back when Arjé Cahn, from Hippo, told me of an experimental feature that used the terms a contributor used to search for related images and links as keyword suggestions for the asset he was working on. This feature idea takes it one step further by using the language of the audience, rather than the contributor. Another part of the inspiration comes from the "Best Bets" strategy where you train a search engine to recommend a certain set of assets when a specific keyword is used.

Paul Graham on Post Medium Publishing

Paul Graham, has an interesting essay on Post Medium Publishing. The general gist of is that publishers have never really been in the "content business." They have been in the business of selling paper (the embodiment of the content). Digital publishing, with its ease of replication, devalues paper as the embodiment of content and exposes the weakness of a pure content business. Publishers can either give content away and look for ad revenues or they can come up with some new embodiment that is both desirable and defensible. Personally, I think that publishers are in the audience business. They command an audience that advertisers are willing to reach. But the audience business has become more difficult with the increased competition from all sorts of information sources. Many people, like Graham, are looking for that new embodiment or channel that will bring back the exclusive audience attention that was so profitable back in the golden years of publishing.

Graham also invalidates some of the successful content market examples publishers are looking to emulate. For example, Graham says that iTunes (held as the gold standard for a successful content business) is not really a content store. Rather, it is a "toll-booth" that charges people to access the most direct path to their listening devices. Apple controls the path, it gets to charge a fee. If you don't control the device or the channel, you are back in the unprofitable content business. It appears that Time, Inc. has a strategy here but who knows if they will be able to create that market.

New Alfresco Review

I am pleased to announce an updated version of my Open Source Web Content Management in Alfresco report. The report evaluates Alfresco Enterprise 3.1's WCM capabilities for both traditional web publishing and as a framework for building dynamic web applications. Like all Content Here reports, Open Source Web Content Management in Alfresco is highly technical and gets into details that a potential buyer should know. In writing the update, I interviewed systems integrators and technology managers from customer companies for their candid opinions of the product and the software vendor. I have also personally evaluated Alfresco, supporting documentation, and third party books. I can safely say that you are not going to get a more thorough and unbiased evaluation of Alfresco anywhere — not even if you pay several times the $200 price.

Long time readers know that Open Source Web Content Management Alfresco was originally published in February 2008 as part of a larger report called Open Source Web Content Management in Java. Because all of the products reviewed in that report have undergone significant upgrades, I have been selling it at a deep discount. The front matter that explains the marketplace and significant portions of the evaluations are still accurate and relevant so I have decided to offer a bundled product consisting of the original report plus the updated Alfresco review for $400 — that is still 50% off of the original list price. As I complete updates to the different reviews, I will add them to the bundle and incrementally raise the price to the original full price.

If you are evaluating Alfresco for web content management, save yourself time and reduce your risk buy purchasing Open Source Web Content Management in Alfresco. If you work for a Java shop and are starting to consider open source alternatives to commercially licensed web content management software, consider the Open Source Web Content Management in Java bundle.

Snow Leopard Issues

For some reason, I upgraded to Snow Leopard at my first opportunity. To tell the truth, the end-user improvements are pretty modest and it is difficult to perceive Snow Leopard's slight speed improvements. That is not to say that the upgrade did not have impact. Some software that I regularly use stopped working. I am all up and working now and here is now.

Looking back, it would have made more sense to wait on the upgrade and see what other people on the mailing lists said about their experiences. But, since I figure I would share what I learned.

Ingredients for a good software development project

While nearly all of my consulting work is in software selection and technical strategy, I try to have at least one implementation project in the works so that I can stay relevant as a technologist. For my current project, I am building the technology infrastructure for a new web based startup. The project is going really well and I thought I would share some reasons why.

• Great Client. My client is totally non technical and this is his first startup. He found me through a mutual friend that we both think very highly of. His lack of technology experience means he has not picked up any of the bad habits of technology owners. He didn't force a detailed Gantt chart with a bunch of imaginary dates and tasks. His trust in me helped us to collaboratively prioritize and plan work around his schedule. I have followed through on all of my commitments so the trust has only gotten stronger.

• Fluid Design. The concept has evolved substantially since its original inception. A critical part of the design process involves going through the application with prospective customers and then talking through how to incorporate their feedback. We have done a really good job of keeping things flexible without adding complexity. Some of the more speculative ideas are faked a bit until we get an indication of their viability. The underlying machinery is only reworked when we are really onto something. We have plans to do a holistic refactoring once the design is frozen and we are ready to start preparing the application for beta customers.

• Strong Frameworks. Building the application on top of the Django web application framework makes development incredibly fast. Python has a great unit test system where the tests are written in the comments of the code. This makes them easy to maintain. All of the data administration interfaces are provided for free and, because everything is data driven, the client has a lot of control over what he shows potential investors.

• Simple Tools. All of the work is planned using tickets and milestones in a service called Unfuddle (looks a lot like Trac). The information is very accessible and email notifications keep everyone up to date. I am probably going to bring another developer on board to help with the beta and I think that setting him or her up with a development environment is going to be really easy. Just pull everything down from Subversion and launch the text editor of choice.

I am not fooling myself into thinking all projects can be like this. You don't always get to choose your clients or your tools. Often other constraints are forced upon you. But you can make some adjustments to achieve incremental improvements. For example, on another project for a very large, established client, I used to say "we are going over a waterfall in an agile barrel" meaning that the upper management saw a waterfall model project plan but internally, we were being as agile as possible. We tried to be vague rather than guess and commit. We made decisions that didn't preclude other options. We made opportunities to refactor code. So, rather than throwing up your hands and accepting a recipe for failure, think of how you can get the ingredients for success.