Content Technology CTO Blog

Ten years ago I had a belief that a meta-data approach to managing enterprise information was a valid way to go. The various structures, relationships and complexities of IT systems led to disjointed information. By relating the information elements to each other, rather than synchronizing the information together, we _might_ stand a chance.

At the same time a new set of standards was emerging, standards to describe, relate and query a new information model, based on meta-data, these became know as the Semantic Web, outlined in a Scientific American article (http://www.sciam.com/article.cfm?articleID=00048144-10D2-1C70-84A9809EC588EF21 ) in 2001.

Fast forward to 2008 - where are we with this vision. Some part of me is thrilled, another part disappointed. We have adoption of these standards and this approach at use in everyday information management situations. Major software companies and startup's alike are implementing Semantic Technology in their offerings and products. However, I am disappointed that we still find it hard to communicate what this semantic technology means and how valuable it is. Most technologists I meet glaze over at the mention of the Semantic Web or any of it's standards, yet when asked if they think RSS is significant, praise it's contributions.

Over a series of posts to this blog, I would like to try and explain, share and show some of the value of Semantic Technology and why one should be looking at it.

Let's start with what is Semantic Technology and what are the standards that define it's openness.

Semantic Technology

To quote Wikipedia "In software, semantic technology encodes meanings separately from data and content files, and separately from application code." This abstraction is a core tenant and value provided by a Semantic approach to information management. The idea that our database or programming patterns do no restrict the form or boundaries of our information is a large shift from traditional IT solutions. The idea that our business logic should not be tied to the code that implements it, nor the information that it operates on is all provided through this semantic representation. So firstly ABSTRACTION is a key definition.

The benefit of this is that systems, machines, solutions, whatever term you wish to use can interact with each other - share, understand and reason, without having been explicitly programmed to understand each other.

With this you get to better manage CHANGE. Your content and systems can evole or change with the changes managed through the Semantic Technology layer.

So what makes up Semantic Technology, one sees the word in a number of soltuions or technologies, are they all created equal.

In my view, Semantic Technology can only truly claim to be so, if it is based on and implements the standards laid out through the (W3C) World Wide Web Consortium standards process. http://www.w3.org/2001/sw/

The vision of the Semantic Web and the standards required to support it continue to expand, but the anchor standards have been laid out for a while.

RDF - The model and syntax for describing information. It is important to understand that with the RDF standards there are multiple things defined to create this standard - the model (or data model) , the syntax (how it is written/serialized) and the formal semantics (or logic described by the use of rdf). In 2004, the original RDF specification was revised and published as 6 separate documents, each covering an important area of the standard.

RDF-S - Provides a typing system for RDF and the basic constructs for expressing Ontologies and relationships within the meta data structure.

OWL - To quote the W3C paper, this facilitates greater machine interpretability of Web content than that supported by XML, RDF, and RDF-S by providing additional vocabulary along with a formal semantics.

SPARQL - While anyone with a Semantic Technology solution invented there own query language (why was this never there one in the first place!), SPARQL, pronounced "sparkle" is the w3c standardization of one. It is HUGE for Semantic Technology and makes all the effort with the other three standards worthwhile.

These standards are quite a pile to sift through, understanding the capabilities embodied in them takes significant effort, but it is the role of technologists in this arena to remove that need for you to understand them. It is our job to provide tools, solutions and capabilities that leverage the these standards bringing semantic technology to life and deliver the power defined within them.

But that is the subject of another post. So what does this all mean in real life? In my next post I will layout a concrete example using product information as an example.

Comparing relational vs. object-oriented database use in content management is highly subjective, and can’t be generalized. That would be like saying that the movie is always better than the book it is based on. Take the Harry Potter series. While the books have been phenomenally successful, the movies are doing equally well at the box office.

There’s not a one-size fits all approach for technology either. Comparing relational and object-oriented databases needs to be done from several perspectives – notably business rationale for the end user as well as technological advantage – not just one.

On the business end, documentation is mission critical, and must be available 24x7. Relational databases like Oracle support application clustering and high availability out of the box. Customers can count on Oracle always being available, and in a global working environment, everyone can get their job done.

Many businesses need to migrate from some form of binary documentation to XML, but it doesn't happen instantly. Using a relational database, these businesses can store their binary documentation and take full advantage of a CMS while they undertake the process of converting to XML. A relational database can also act as a single repository that stores both XML and binary content, eliminating the need for a separate file system and creates a more homogenous environment for IT.

When business demands and technology realities meet, an argument can be made that a mission critical database application like Oracle requires an amount of care and feeding to be properly maintained. There is, however, also a misunderstanding that with an XML database, an end user can simply let it run and everything is fine.

In reality, many companies like to have control over their “family jewels,” and may want the option of feeding other applications that have canned integrations to relational databases. XQuery may be great, but businesses need to search for content that can be in many forms, XML, PDF, Word, etc. Using a relational database and other technologies, it is possible to support a very robust search mechanism across over 295 different formats.

In both cases, scalability is always a concern. The user must be able to scale and manage both vertically (larger machines) and horizontally (additional machines) while maintaining the integrity of the data and 24x7 access to the system.

Relational databases provide out-of-the-box horizontal scalability, as well as the ability to acutely control how system resources are used. This is crucial in serious business applications. Relational databases can stuff entire areas of XML into a single row (such as a

Have you ever waded through a massive technical manual, desperately searching for the section that actually applied to you? Or have you found yourself performing one search after another, collecting one-by-one the pieces of the answer you need from a mass of documents and web pages? These are all examples of the limitations of static publishing; that is, the limitations of publishing to a wide audience when people’s needs and wants are not all the same. Unfortunately, this classic “one size fits all” approach can end up fitting no one at all.

In the days when print publishing was our only option, and we thought only in terms of producing books, we really had no choice but to mass-distribute information and hope it met most people’s needs. But today, with Web-based technology and new XML standards like DITA, we have other choices.

DITA (Darwin Information Typing Architecture) is the hottest thing to have hit the technical publishing world in a long time. With its topic-based approach to authoring, DITA frees us from the need to think in terms of “books”, and lets us focus on the underlying information. With DITA’s modular, reusable information elements, we can not only publish across different formats and media – but also flexibly recombine information in almost any way we like.

Initial DITA implementations have focused primarily on publishing to pre-defined PDF, HTML and Help formats – that is, on static publishing. But the real promise of DITA lies in supporting dynamic, personalized content delivery. This alternative publishing model – which I’ll call dynamic content delivery – involves “pulling” rather than “pushing” content, based on the needs of each individual user.

In this self-service approach to publishing, end users can assemble their own “books” using two kinds of interfaces (or a hybrid of the two):

Information Shopping Cart – in which the user browses or searches to choose the content (DITA Topics) that she considers relevant, and then places this information in a shopping cart. When done “shopping”, she can organize her document’s table of contents, select a stylesheet, and automatically publish the result to HTML or PDF.

This approach is appropriate when users are relatively knowledgeable about the content, and where the structure of their output documents can be safely left up to them. Examples include engineering research, e-learning systems, and customer self-service applications.

Personalization Wizard – in which the user answers a number of pre-set questions in a wizard-like interface, and the appropriate content is automatically extracted to produce a final document in HTML or PDF.

This approach is appropriate for applications that need to produce a personalized but highly standard manual, such as a product installation guide or regulated policy manual. In this scenario, the document structure and stylesheet are typically preset.

In a hybrid interface, we could use a personalization wizard to dynamically assemble required material in a fixed table of contents – but then use the information shopping cart approach to allow the user to add supplementary material. Or, depending on the application, we might do the same thing but assemble the initial table of contents as a suggestion or starting point only. The first method might be appropriate for a user manual; the second might be better for custom textbooks.

Dynamic content delivery is made possible by the kind of topic-based authoring embraced by DITA. A topic is a piece of content that covers a specific subject, has an identifiable purpose, and can stand on its own (i.e., does not require a specific context in order to make sense). Topics don’t start with “as stated above” or end with “as further described below,” and they don’t implicitly refer to other information that isn’t contained within them. In a word, topics are fully reusable, in the sense that they can be used in any context where the information provided by the topic is needed.

The extraction and assembly of relevant topics is made possible by another relatively new standard called XQuery, which is able to both find the right information based on user profiles, filter the results accordingly, and automatically transform results into output formats like HTML or PDF. Of course, this approach is only feasible if the XQuery engine is extremely fast – which led us to build our own dynamic content delivery solution offering around Mark Logic, an XQuery-based content delivery platform optimized for real-time search and transformation.

The dynamic content delivery approach is an answer to the hunger for relevant, personalized information that pervades today’s organizations. Avoiding the pitfalls of the classic “one size fits all” publishing of the past, it instead allows a highly personalized and relevant interaction with “an audience of one.” I invite you to read more about this in a whitepaper I wrote that is available on our website (www.FlatironsSolutions.com).

WIth Carl's recent post on SaaS, and John Newton's "Content Management 2.0" discussion, I thought I'd throw this into the mix... recently there has also been a flurry of activity around a concept called “Office 2.0” – another offshoot of the term “Web 2.0” – in which all traditional office applications can be replaced by online services accessible through a generic web browser.

What’s making this possible is a set of new technologies including AJAX, RSS and web services, a set of actual applications such as Google’s gmail and ZOHO’s “online” word processor, and a great deal of unbridled enthusiasm.

Since Office 2.0 is particularly aimed at applications that affect business and larger enterprises, I’d like to take a quick look at how well it fits the needs of such enterprises, and then suggest how it might be extended to better meet these needs.

But first, I’d like to point out that it’s easy to get caught up in the details of technologies like AJAX and RSS, and miss the bigger picture. I would propose that the real excitement is in the vision enabled by the technology, as opposed to the technology itself. To not see this leads to the inevitable “religious wars” around specific tools, which we of course want to avoid...

To put this in perspective, Office 2.0 reminds me of what happened with CD-ROM twenty years ago. I still vividly recall a colleague of mine proudly announcing that he was going to the world’s first international CD-ROM conference, which he described as the “Woodstock” of the computer industry. He simply couldn’t contain his excitement about this pivotal event. But then, I remember him suddenly changing his facial expression, looking at me wryly and saying, “well of course, CD-ROM is actually only a storage medium…can you imagine me being excited about going to a floppy disk conference?”

Twenty years later, we might well ask the same thing. CD-ROM has become about as mundane as floppy disks were then. But at the time, CD-ROM represented much more than a new storage medium. Instead, it symbolized the sudden freedom to access and search information – right from your own desktop – that would otherwise be virtually inaccessible. It was in fact, the first glimpse of the kind of mass interconnectivity that the World Wide Web would later provide.

Office 2.0 is much like that – it represents freedom from the tyranny of desktop applications and proprietary data locked up on individual computers. It heralds a new age of unfettered collaboration and information sharing within enterprises.

So what are the key things that are exciting about Office 2.0, and do its maxims and rules actually fit larger enterprises? I think the answer is a tentative “yes” - at least at a conceptual level. And at least so long as the Office 2.0 folks are willing to make a few compromises and entertain some crucial extensions.

To explore this further, let’s go through the official Office 2.0 rules one by one…

#1 - No client application other than a web browser. Actually, this the holy grail of nearly all corporate IT departments, because one of the biggest headaches in IT is trying to keep all the client applications up to-date on individual computers. In practice, we’d have to accommodate situations where a high-speed Internet connection is not available, but I would grant that this is increasingly the exception.

#2 - No files on your personal computer. In principle, this is the entire thrust of enterprise content management initiatives, taking information that’s buried on people’s “C:” drives and getting into a managed and accessible central repository. So far, so good.

#3 - No dependence on any particular vendor.This is another mantra of corporate IT, expressing itself in the current fervor over Software as a Service and Service-Oriented Architectures, ideally with plug-and-play vendor apps encapsulated in generic web services interfaces.

#4 - Collaboration through document sharing and publishing. Again, this a winner with big enterprises. In fact, this is most of what my company, Flatirons Solutions, does for a living. And from the overall perspective of Web 2.0, I might add that wikis and blogs are an increasingly popular way to share ideas and knowledge within larger organizations, supplementing the sharing and publishing of documents.

#5 - Syndication in addition to peer-to-peer collaboration. This is another focus of enterprise content management, allowing people to subscribe to documents or content that has changed or is newly-published. And RSS syndication is increasingly one of the key channels to which we find ourselves publishing content.

#6 - Seamless data import/export across services. This is a fundamental objective of all enterprise content management initiatives, but now comes the rub. The current Office 2.0 vision thinks of sharing in terms of “interchangeable” formats like .DOC, HTML and PDF. But .DOC is a common but still proprietary vendor format, and HTML and PDF are really only sharable at the visible level. In other words, HTML and PDF let you display and print each other’s information, but not actually interchange the underlying source data and information in a way a computer can process and transform.

Proprietary word processing seems less proprietary when it’s on the Web, but if you really want interchangeability between services, you need to be using a vendor, format and media-neutral standard like XML. XML does not assume a particular vendor, nor does it assume web or print as the output medium. Instead, it encodes the information itself in a completely neutral form, from which media-specific formats like HTML and PDF can be derived.

In the work we do with large enterprises, XML also provides the key to sharing information at a much deeper level than “documents.” When we look at the set of documents that people need to share and publish, we see that there is often a tremendous amount of redundancy. If this overlapping information is authored and maintained independently, there are huge problems with inconsistency, and a lot of unnecessary time and cost maintaining and reconciling the multiple versions.

XML allows source information to be “chunked up” into the underlying building blocks, and from there flexibly mixed-and-matched to create the full array of print and Web-based documents. Individuals can collaborate on the source building blocks – without needing to assume a particular assembled document or output medium – and then combine the building blocks of interest into the documents they produce. Furthermore, if these reusable building blocks are structured as standalone “topics”, they can be directly published and syndicated outside the context of a higher-level document or web page. We call this “single source” publishing – because underlying content is maintained once, and then reused many times.

So, is Office 2.0 the right idea for larger enterprises? Perhaps, in principle…but to make it really work we need to merge its vision with the significant work already going on in single-source XML-based publishing. Then we’d have the potential for a real winner.

I’m not at the conference this week (we do have several people from our shop there), but to answer a question posed by Frank Gilbane:

What is the future of software as a service, and is it appropriate for enterprise content applications like content management, authoring, etc.?

The SaaS model seems to have been proven to the point where it’s hard to imagine that it won’t keep growing. We recently posted a whitepaper on SaaS myths, which debunks most of the common arguments against SaaS. In addition to that discussion, I’d offer the following four points:

1) SaaS is a proven technology. It arguably extends to the early days of the web with software ASPs. I guess you could even argue the lineage goes all the way back to mainframe apps! :-) Certainly, though, the existing SaaS companies have been working successfully with this business model for more than six years now.

2) Web technologies have reached a point where SaaS is an out of the box solution. You can now count on fast network connections for users both in the office and home. Security systems are complete from SSL with web browsers up through terminal services like Citrix which allow even HIPAA compliance. For web apps, browser technologies like IFRAMES and AJAX allow apps to be easily integrated on a page (mashups).

3) SaaS provides much more robust server management and security, especially for small and medium sized businesses. As web applications grow more complex, SaaS allows much more convenient, rigorous and cost-effective control over hosting. By centralizing and focusing, the best resources can be brought to bear on fewer hosting environments.

4) This one is a bit of a prediction, and is specific to web sites. Currently, you have a couple options when adding components like blogs, rss, ecommerce, polls, surveys, and search to web sites. You can install apps for those services, which allows you to control ad placement and design. The alternative is to use free hosted apps where the ad revenue goes to the SaaS company. So, the logical next step is for high quality hosted apps where the ad revenue is shared with the web site. This is already appearing with sites like MetaCafe. For an advanced CMS, though, I am not sure this will happen since the CMS tends to be the hub for all the other web apps, but it is certainly possible for a basic CMS.

DITA (which stands for “Darwin Information Typing Architecture”) is the hottest new technology in the technical publishing market. While still early in its adoption cycle, it has the potential to become the future de facto standard for not only technical publishing, but for all serious content management and dynamic publishing applications. Whether this happens, however, will depend on the vision and creativity of the DITA standards committee, DITA vendors and DITA consultants.

While IBM originally designed DITA for technical documentation, its benefits are potentially transferable to encyclopedias, journal articles, mutual fund prospectuses, insurance policies, retail catalogs, and many, many other applications. But will it really be flexible enough to meet these other needs?

At Flatirons Solutions we’ve been testing the boundaries of DITA’s extensibility, taking DITA out of its comfort zone and thereby creating some interesting proof points for its flexibility. So far, the results are very positive. Four specific applications illustrate this:

* User personalized documentation – designed to support a variety of enterprise content libraries out of a single set of specializations, this application involved the use of 15 conditional processing attributes to drive dynamic production of personalized documents. An initial DocBook-based prototype was later re-designed for DITA.

* Scholarly research database – this solution involved marrying DITA with the venerable Text Encoding Initiative (TEI), a nearly 20 year old scholarly markup standard originally written in SGML. DITA was used to split the historical material into searchable topics; TEI provided the rigorous scholarly markup and annotations.

* Dynamic web publishing – designed for a large brokerage and business services firm, this application combines a single-source DITA-based authoring environment with an optimized dynamic processing pipeline that produces highly-personalized Web pages.

* Commercial publishing – we are currently exploring the use of DITA for encyclopedia, journal, and textbook publishing, for clients who have traditionally focused on print, but who are now also moving to increasingly sophisticated electronic products.

Of course, in pushing the boundaries we’ve also found issues. A classic example is the restriction in DITA’s “task” specialization that each step in a procedure must begin with a simple declarative statement. To make it as readable as possible, the procedure cannot begin with a statement that includes a list or multiple paragraphs or a table or a note. But what do you do if your content breaks these rules? DITA’s answer is that you rewrite your content.

Rewriting content is not unreasonable if you accept that you’re moving to DITA in order to adopt industry best practices. However, what if you don’t agree that DITA’s built-in “best practices” are the only way to write good content? Or what if you have 500,000 pages of legacy content, all of which need to be rewritten before they can conform to DITA? Would you still consider it practical?

You can solve this by making up your own “task” specialization, bypassing the constraints of the built-in “task” model. That’s an advantage of DITA. But if you do that, you’re taking a risk that you won’t be able to leverage future vendor product features based on the standard “task” specialization. And in other cases, such as limitations in handling print publishing, workarounds can be harder to find.

DITA 1.1 has made great progress toward resolving some of these issues. To be truly extensible, however, I believe that future versions of DITA will need to:

* Add more “out-of-the-box” specialization types which DITA vendors can build into their tools (for example, generic types for commercial publishing).
* Further generalize the existing “out-of-the-box” specialization types (for example, allowing more flexibility in procedure steps).
* Better handle packaging of content into published books, rather than focusing primarily on Web and Help output, and adapting this model for books.
* Simplify the means to incorporate reusable content, handle “variables” within text, and link to related content.

At conferences I’ve heard it suggested that if people don’t want to obey DITA’s particular set of rules, they should consider using another standard. I’ve even heard people say that DITA doesn’t need to focus on book publishing because print is “old school.” In my opinion, this kind of parochial thinking needs to be seriously reconsidered.

Today, DITA stands at the crossroads. If it can be aggressively generalized and extended to meet the needs of commercial publishers, catalog and promotional content, and financial services and other vertical industry applications, then it has the chance to be “the” standard in XML-based dynamic publishing. If this doesn’t happen, DITA runs the risk of being relegated to a relatively elite technical publishing standard that’s only useful if you meet its particular set of assumptions and rules.

As an industry, which way will we go?

The Content Management market today seems to be moving in two contradictory directions at once. On the one hand, we see ever larger software players, such as IBM, Oracle, and Microsoft building or acquiring content management, driving it "down" into infrastructure. To IBM and Oracle, content is just an extension of their dominance in the data center. ECM to them is thus an extension of the database. Microsoft's push, with both Windows SharePoint Services, and eventually WinFS (no longer part of Vista) is similar, but treats content more as the extension of the file system - the "back end of Office" as it were. While based on Microsoft’s very different perspective of working from the desktop inward to IT, it is still fundamentally an infrastructure play. Content management in this world is still fundamentally way down in the IT technology "stack."

Yet on the other hand, we see customers increasingly funding content management from line-of-business budgets, and purchasing content management based on its ability to solve line-of-business problems. Performance, scalability, reliability are not to be ignored, but other questions dominate selection, such as: "Will we get more returns from our internet marketing efforts with this system?" or "Will our department be able to move up deadlines with this system?" In short, these buyers are positioning the content management system far "up the stack" as one or more different content-driven applications used to produce measurable line-of-business returns.

How can buyers be moving up the stack while the major vendors move down? The answer is part semantics, and part market shift. The term "content management," including all of its current acronyms ECM, WCM or just CMS, is too generic. This is largely due to the fact that managing content itself is so new to both applications and infrastructure, that there it belongs in both places. Secondly, there is a real bifurcation going on in the market. The true infrastructure aspects of content management, such as optimal storage and retrieval, indexing, and library services are increasingly becoming commoditized and absorbed into the infrastructure software stack. But as these content services precipitate downward, they become too generic to solve any particular line of business problem on their own. This means that another layer of content-driven applications must emerge at the top of the stack, to provide the horizontal and vertical applications, such as internet and multi-channel marketing, something I blog about quite a bit. All of these very different offerings are today called "content management" with vendors for each moving down and up the stack respectively.

While technologists love the simplicity of block diagrams showing "the content management goes here," the reality is that content management goes in a lot of places. For the foreseeable future, we're going to have many systems, all of which do very different things, and yet all called Content Management of one kind or another. If you can better understand the specific initiative driving each new system or solution, you can better understand how your current systems do or do not apply, and whether you need to add more "content management" to achieve your goals.

If you haven’t heard of Web 2.0, where have you been? If you actually know what Web 2.0 is, then congratulations. I believe the best definition of Web 2.0 is given by Tim O’Reilly who arguably created the term. Web 2.0 has generally referred to the new breed of start-up who provides a new level of user service, but it also applies to a new wave in technology supporting that user service.

Web 2.0 is radically changing the experience in which end users interact with enterprises and types of user experiences that we now expect from on-line systems. Going hand in hand with Web 2.0 are the raised expectations users have of the interactivity of content, how content is managed and how personal that content is. Providing a self-service experience and to automatically deliver necessary content to new and interactive contexts has put a burden on the existing infrastructure of current generation content management systems. A new generation of enterprise content management is needed to meet the challenges of Web 2.0.

Content Management 2.0 is my term for this new generation of content management. Given everyone is starting to talk about Security 2.0, Virtualization 2.0, etc., I thought I would stake out the term after a brief search on Google seemed to indicate no one has talked about it before. (If you are aware of someone using it, please let me know. I'll give them credit.) IBM has talked about next generation content management, but the term Content Management 2.0 seems to go along with the phenomenon that is finally injecting innovation back into the content management market. These new technologies provide greater interactivity through AJAX, new collaborative styles of classification and tagging, and user driven configuration are being led more by open source than the traditional engines of enterprise content management expansion.

I recently gave a presentation at the University of Oxford where I discussed the concept to the people concerned with the various web sites and content services in the university. The concept originated after an internal discussion about where content management is going. It became clear to us that many new things were happening to content management with blogs, wikis, syndication and new styles of user interface affecting how people build web sites, content, and new web frameworks.

The presentation explained the challenges that existing enterprise content management has in addressing Web 2.0, what needs are not currently being met for end users, what technology changes are required, and how do these technologies “mash-up” to be able to glue systems together through web services and other web-oriented protocols. It also discussed the role that open source will play in this next generation of enterprise content management.

It will be interesting to see how the ECM vendors and specialist WCM vendors react to Web 2.0 and whether they aim for a new Content Management 2.0.

What is the CTO Blog?
The content technology CTO Blog is hosted by the Gilbane Group as a service to the content and information technology community. The purpose of the blog is to facilitate ongoing discussion and debate on technologies, approaches and architectures relevant to enterprise content applications. (Note: Obviously the blog is live, but it won't be officially launched until late August or Early September.)

Why have we created it?
CTOs have a wealth of critical information about technologies that is not always accessible to enterprise customers. When it is, it is often filtered through marketing or PR staff. CTOs also have demanding jobs, and have limited time available to meet with each other with customers, or with other industry influencers. Some CTOs have their own blogs, but in many cases these are not widely read. This blog is intended to encourage communication both between vendor CTOs and between enterprise customer CTOs and vendor CTOs. We have been asked by multiple CTOs to provide this channel.

Who can contribute?
Any CTO is welcome, and anyone who has an equivalent role. If you are not sure whether it makes sense for you, ask us at: ctoblog@gilbane.com. We understand that small companies might have a founding CEO who acts as the CTO (me, for example), and large companies may have multiple senior technology strategists that in effect act as CTOs for divisions. We invite all vendors, enterprise customers, system integrators, and analyst and consulting firms to participate. Anyone may comment on blog postings.

What topics will be covered?
Any topics relevant to enterprise applications and content technologies are welcome. We have set up a starter list of categories at http://gilbane.com/ctoblog/ that suggests the range. Our contributors will help us expand this list. This is a business/technical blog and not intended for personal, political or other types of content.

How can you become an author?
Send an email to ctoblog@gilbane.com if you would like to contribute to the blog, or if you have questions about doing so. If you meet our CTO or equivalent criteria you will be set-up as an author and listed as such on the blog. Each author has full posting and commenting permissions, and also will have a direct link to all their own posts (of the form "http://gilbane.com/ctoblog/firstname_lastname.html). If you don't have a blog, this might be all you need.

What if I already have a blog?
Chances are there will be content that makes sense for your own blog that might not make sense here, and possibly vice versa. In any case, relevant cross-posting is OK.

Are there minimum contribution requirements?
No. Nor are there maximum limits. You can post just once or every day.

What other rules are there?
* Submissions by anyone "representing" approved contributors (for example, PR folks) are not allowed. Anyone is able to comment.
* There will be very little moderating. However no personal attacks, "flaming", or uncivilized posting will be allowed.
* No pure marketing or sales content is allowed, but it is fine to talk about products and their existing and planned functionality, and even to argue for a particular approach, strategy, or philosophy.
* The CTO Blog has a creative Commons license associated with it that only restricts commercial use, so, for example, re-posting to or from your own or other blogs is fine.

Is this a Gilbane Group platform?
Only physically, in that we host it and moderate it. Our own opinions may be found in comments or on our analyst blog at http://gilbane.com/blog/.