Nov 11, 2009
Nadav Schreibman just commented on my post "Is Drupal the right platform for whitehouse.gov?" to say that Recovery.gov is now running on Sharepoint. I was pretty shocked when I read the article and had to check the source on the site. Sure enough, I am seeing Sharepoint HTML in all of its postback glory.
The referenced article from Oh My Gov talks about how the Recovery.gov needed a more portal-like framework. Both Drupal and Sharepoint can be described as development frameworks. Drupal leans more towards being a CMS product (with strong capabilities for developing content) while Sharepoint is more of a portal (with strong capabilities for pulling content and data from other sources). It seems like Recovery.gov, with it's mandate to expose where recovery money is being spent, needed more portal and less CMS. This was an expensive change — the redesign project cost $18 Million, which may not be a lot of money in government spending terms but is more than most of my clients have lying around. Thanks Nadav for the tip!
Nov 11, 2009
I am beginning to see hints at serious changes happening within Alfresco. Historically the company has essentially operated as a commercial software company with a closed development model (that is, an internal opaque development team) and an open source version that was treated like shareware ("start using it and, if you like it, pay for the real product."). Gradually, Alfresco has been opening up to be more transparent and developer friendly. For example, now you can get the source of the Enterprise Edition. You just need to pay an annual subscription to use the compiled version if you want to get support.
Recent blog posts by Matt Asay (Alfresco's VP of Business Development) and John Newton (CTO) make me think there is more change to come. First, in April Matt wrote this post on how the (very permissive) Apache Software License is better than the GPL. That had me scratching my head because Alfresco uses the GPL license which is very strong at protecting IP. Alfresco had already loosened up a bit by providing a "FLOSS Exception" where a developer working on another project with another OSI approved license can incorporate Alfresco under that license. But the full Apache Software License goes much further. If Alfresco was Apache licensed, Oracle could embed Alfresco in one of their commercial software products for free.
Then John Newton wrote a post talking about the virtues of professional open source and described Alfresco as a company that made money entirely from support. At the time, I didn't really believe him because the terms felt like you needed to pay to use supportable software rather than pay for the support itself. I know this is a minor distinction but a support contract seems easier to walk away from than an annual subscription to use software. Still, I guess it would be possible to downgrade to a version of the Enterprise Edition that you compiled yourself.
More recently, Matt comes up with this article that is critical of "fauxpen source:" products that come out of a closed development process but are distributed under an open source license. He writes:
In the future, I think we'll see this "fauxpen-ness" fade as companies clearly separate their open-source efforts from their revenue models. Open source can provide a platform for monetization, but it isn't the best way to actually generate cash. Not for most companies, anyway.
I take this to mean that software companies will start to leverage the open source development model and get their revenue from sources other than renting out the IP of the software. Matt doesn't mention Day Software but that is clearly what Day is doing. Day sells commercial software products (CQ5 and the CRX) but heavily invests in components (JackRabbit and Sling) that they have donated to the Apache Software foundation for open development. They use these Apache components in their products and encourage their competitors to do so too. Similarly, IBM invests in lots of Apache projects and Eclipse. Ex-Alfrescan Kevin Cochrane now works at Day and I am wondering if he is convincing his former co-workers on this strategy. I wonder if, now that there is a sufficient developer community, Alfresco will start to put development of some of their components (like their CIFS implementation or their Surf framework) out in the open where more people can contribute to it.
If this is what is happening, (and now I am really speculating) it could mean one of two things. One, Alfresco has reached a size and level of profitability that it can afford to let go of some immediate revenue to fuel some longer term growth. Two, Alfresco is less focused on creating a company with a tight grip on IP that it can quickly sell. Either way, I am very interested in how this plays out and will be watching for Alfresco components being released into an active development community.
Disclosure I do not have any inside information on Alfresco and am speculating based on what I read on the web. I may be (and probably am) totally wrong.
Nov 10, 2009
Often times by the time a client gets to finding me, they have reached a point where they are ready to throw away their entire web infrastructure: both their corporate website and their intranet. They hope that one well executed product selection can solve both problems. When approached by this kind of prospective client I am careful to set the expectation that this hope is probably not realistic — not impossible, just not realistic. That said, there are a few conditions where putting your intranet and external website on one stack does work. Here are the criteria that I use.
-
The intranet is informational rather than collaborative. Different people mean different things when they say the word "intranet." For some, an intranet is just a collection of web pages that only employees can see. Others think of tools and workspaces that allow employees to collaborate and get things done. If you had the latter in mind, chances are you will be looking for a document management, ECM, or portal system like Sharepoint for knowledge worker collaboration. These systems are technically capable of pure web publishing but that is not their strength. Your website management team will feel constrained by a platform that treats web publishing as an afterthought. If you think of your employees and customers/prospects simply as different audiences that you need to publish to, a single platform may work just fine.
-
The company has other platforms on which to build specialized, dynamic web applications. Sooner or later (or probably already) your company is going to need to develop content-oriented web applications and your WCMS is a logical place to start. However, these web applications are likely to introduce the most demanding and specialized requirements. It is quite possible that the union of your intranet and external website application requirements filter out every viable CMS — or at least force some painful compromises. If you have an alternative stack on which to build your fancy custom applications (possibly pulling content from your WCMS) and can let your WCMS focus on simple web publishing, you greatly increase the chance that you can comfortably support both internal and external publishing.
-
The corporate website and intranet are owned by one communications group. Today you may be able to align your intranet and external publishing needs; but will they stay aligned? How will you arbitrate between the competing priorities of the intranet and marketing website? What if those priorities don't just compete for resources but actually conflict with each other? Things can get ugly when two different departments with different goals argue over what feature needs to be added next. These decisions get a lot easier if both the intranet and external website are owned by one communications group. Companies that are structured this way are usually small and can benefit the most from sharing the infrastructure cost between the intranet and extranet. Having the intranet owned by a communications group also pretty much ensures that criterion 1 is satisfied.
If your company meets these criteria, there is a good possibility that one instance of one CMS platform could serve you quite well. Otherwise, I would recommend doing one of your two projects and then putting the product that you used on the short list of products to consider for the other. If it turns out that the one platform supports the requirements of the second project, buy another instance of the software (hopefully at a discount) and start a new project to implement it. Take advantage of code and idea re-use but don't let that constrain the flexibility and agility that you need to achieve your goals.
Nov 04, 2009
I just read Philippe "@proops" Parker's tweet:
there's no "best" wcm, says @jarrodgingras, but is there a worst one? #fixwcm
My 140 character or less answer is "No" but I have more to say so I will elaborate here....
There is no worst WCMS. In fact, I would go so far as to say that every WCMS is (or at least was) the best WCMS for someone. The reason is this: every WCMS product was built to someone's specifications. Some WCMS development projects fail in their mission but we rarely see the products of those projects in the marketplace. What we do see are the products that delivered so well on their specification that somebody had the bright idea to get into the business of repeating that success for other organizations.
So every WCMS, at least at one point in its lifetime, was someone's best WCMS. But software is not static. It changes over time (at least it should) and it is quite possible that poor product management can make software worse. I see that as a very real problem for many of the software products in the marketplace. It takes discipline to avoid feature bloat that clutters the application and makes it less suitable for its best use. Software companies that look to competitors and potential customers for guidance are more vulnerable than companies that listen to their customers who are already using the software.
There is a great philosophy in software product management called "Make it suck less." The idea is that, rather than add new features to draw in new kinds of customers, make life better for people who already use your software. That is, don't ruin the software by trying to please everyone.
Sadly few companies take this approach and, as a result, the race to make worse software has a bigger, more competitive field than the race to make better software. Therefore, nobody is going to win the dubious distinction of the developer of the worst WCMS - its going to be a big tie.
Nov 03, 2009
Edit: I wrote a follow-up post describing how I was doing with these action items. Enjoy!
A couple of weeks ago I attended Jacob Kaplan-Moss's Django Master Class in Springfield, Virginia. It was a great class and I walked out with a bunch of ideas for making better use of Django. What follows is a set of action items that I created for myself. Jacob was not this prescriptive in his presentation. These are just my personal decisions based on how he explained things.
-
Use South for database migrations (complete). Unlike Rails, Django has no native system for synchronizing the database schema with code changes. Django will create your initial database schema for you but you need to modify the tables with SQL whenever your models change. South gives Django Rails-like migrations which consists of methods to alter the database and also roll-back changes. I ported a new application I am working on over to use South and am very impressed. Jacob gave some great advice to keep your schema migrations from your data migrations. For example, if you are renaming a field: you would create one migration to add the field; a second migration to move the data to the new field; and a third migration to delete the old field. Doing this will make your migrations safer and easier to roll-back.
-
Use PostgreSQL rather than MySQL (complete). Jacob didn't talk disparagingly about MySQL but it was clear to me that PostgreSQL is what the cool kids are using. That is not to say there are not disagreements over what DB is best. I have been using MySQL for years but two things won me over. In the class, I learned that table alterations in MySQL are not transactional so if your South database migration fails, you can't roll-back so easily. The second factor came after the class when I was reading all these blog posts panicking about what will come of MySQL now that Oracle owns it. I agree with most pundits that Oracle doesn't have a great reason to invest in MySQL. My comfort level working with PostgreSQL is growing but its going to take a while to get as comfortable with the commands and syntax as I am with MySQL.
-
Use VirtualEnv (complete). One thing about Python that always seemed hackey to me was the whole "site-packages" thing. I don't like how all your Python projects tend to share the same libraries. In Java, you are much more deliberate with your CLASSPATH. The class introduced me to virtualenv and its sister project virtualenvwrapper. This creates a virtual sandbox where you can manage libraries separately from your main Python installation. It is brilliant.
-
Use PIP (complete). I was pretty haphazard about what tools I used to install Python packages. I admit that I didn't really know the difference between setuptools and easy_install. The Master Class nicely explained the different options and it seems like PIP is emerging as the Python package manager of choice.
-
Break up functionality into lots of small re-usable applications (in process). Much of the advice from the class is summarized in James Bennett's DjangoCon 2008 talk: Reusable Apps. Watch the video and be convinced.
-
Use Fabric for deployments (not started). My normal m.o. for deploying code has been to shell over to a server and svn export from my Subversion server. In multiple server environments, I would usually have some kind of rsync setup. However, in my one of my client projects (using Java), I started using AntHill Pro (plus Ant) for both continuous integration and deployment. From that experience I saw light on the automated deployments. Fabric is primitive compared to AntHill Pro (it doesn't have cool web-based UI) but it does allow you to run scripts remotely on other hosts. It's like Capistrano for Python. In the next phase of development, I will definitely be using this.
-
Use Django Fixtures (not started). I am really embarrassed to say that I have avoided using Fixtures for loading lookup and test data. Instead, I have been doing horrid things with SQL and objects.create(). I am looking forward to reforming my errant ways. Fixtures allow you to create a data file that Django will load for you. It offers three format options: JSON, YAML, or XML. Jacob recommends YAML if you can be assured that you have access to PyYAML, otherwise go with JSON which is nearly as readable.
-
Look into the Python Fixture module (not started). This straight Python module seems to be an alternative to the Django fixtures system. It is more oriented towards test data and looks a little like using mock objects. I need to dig in a little more before I make up my mind about it.
-
Use django.test.TestCase more for unit testing (not started). I need to do more with unit tests. I have had some good experiences with writing DocTests but I should use the Django unit test framework more. This will allow me to use fixtures more too! Plus with Django 1.1, startapp even creates a tests.py for you. How can I resist an empty .py file?
-
Use the highest version of Python that you can get away with (in progress). In the class, Jacob made the good point that every version of Python gets feature and performance improvements. Why not go with the latest stable version like 2.6? Snow Leopard did it for me. I will try to upgrade my server as soon as I can get away with it.
If you can make it to the next Django Master Class, I highly recommend you go. Otherwise, you should look into these resources and make your own educated decisions about whether to use them.
Nov 02, 2009
I just read Matt Asay's article "Time to upgrade upgrade open source perceptions of Gartner" where he gives Gartner credit for finally getting open source. His point is that Gartner has stopped steadfastly arguing that open source's impact was negligible. On that point, I have to agree. Gartner has jumped onto the open source bandwagon just as it was accelerating out of Gartner's reach. But what does that really mean? It means that Gartner's readership (predominantly technology vendors) have forced Gartner to cover a market segment that they are no longer able to ignore. It also means that some of the open core software vendors have gotten big enough that they now represent a decent market for Gartner reports and services.
From a technology customer's perspective, the value of Gartner's (and most of the other major analysts, for that matter) opinion is pretty much the same. Main stream technology analysts focus on the business of technology (market share/cap/potential) — not the design or suitability of the products. Market analysts don't work with the technology. They don't talk to users or developers. Half of the people they talk to are CIOs who couldn't identify the user interface of the software they are discussing.
So, if you are a software company or an investor trying to figure out where to spend your money, Gartner's reports just got a little bit more useful. If you are in the market to buy technology, Gartner won't help you understand your requirements and what product is the best fit for your organization.
Oct 28, 2009
By now, most people have heard that whitehouse.gov has been migrated over to Drupal. Apparently, the administration has built a level of comfort with the platform with its experience using it for recovery.gov. While the Drupal community is doing high fives all around and equating this with being the most powerful CMS in the free world, I wouldn't go that far. I would say that Drupal is a very good choice for powering the kind of website that the Obama administration is trying to foster: content rich, news oriented, faceted, and populist.
Apparently, Slate Magazine's Chris Wilson wasn't so generous with his critique of the choice. I discovered the Slate article by reading Conor McNamara's excellent post
"Drupal misrepresented by Chris Wilson of slate.com." In my opinion, Conor's responses to Wilson's points are spot-on. Some of Wilson's criticisms reflect configuration choices, not limitations of the platform (like not being able to add Javascript to a content objects. It's a bad idea to allow this by the way.). Slate.fr uses Drupal and the Today's Pictures section of Slate.com is Drupal powered. It seems like Chris has just enough knowledge to sound ignorant. Readers of my reports know that I can get critical of technologies. But whenever I criticize, I make sure to do my research because I know that I am going to get attacked by defenders of that technology. Chris is about to learn this lesson. If Slate.com's commenting system wasn't so bad, he would learn even faster.
Oct 28, 2009
The CMS Myth presents nice strategy for training CMS users: drop-in labs. The idea is similar to a college professor's "office hours" where the professor schedules time in his office to field questions from students. In this case, it is a computer lab that an expert on the system staffs on a pre-set schedule. Like office hours, this is a complement, not a substitute, to traditional classroom training. A contributor attends a class, goes through classroom exercises there, and then comes back later to practice what he learns on his own work.
This seems like an effective strategy for large CMS rollouts where it is impractical to distribute expertly trained power users across the office. Small companies could benefit as well. I can see an advantage of allowing users to learn from each other as they passively listen to the instructor solving their co-workers problem as they do they their own work in the drop-in lab. As any CMS user knows, each piece of content has its own little nuances and there are so many different ways to use a CMS. Working with an expert nearby shortens period of learning the most effective strategies for achieving the desired result. For example, "should I associate this image directly with this asset or put the image in a central image library and then reference it?"
Back in my in-house I.T. days, we used to make a point of "walking the halls" answering questions for weeks after a big system rollout. Drop-in labs seem much more efficient but you don't get quite the same amount exercise.
Oct 15, 2009
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.
Oct 14, 2009
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.