Kevin’s Blog

Unfortunately, I made the decision to upgrade to Word 2007. After 4 painful weeks (and many engineers who are sick of my complaints) and many threats to re-install Word 2003, I woke up with a startling revelation: I need to abandon Word altogether. Now if there was only an alternative to Excel or Powerpoint left on the market - I’d abandon those too. But I’ll explain those ones in a moment. They are an even more painful story. But first things first.

In Alfresco 2.1, we extended document management, task management, collaboration, federated search, blog posting, and web publishing directly into the Office environment. This integration showcased the ability to easily embed Alfresco UI components - powered by our new Web Script technology, which provides a simple, light-weight, scriptable (using either PHP or Javascript) way to reference and include Alfresco content and content services into any application environment (desktop or arbitrary web runtime) using a simple URL (groundbreaking, eh? Wasn’t the whole notion of the Web about easily referencing of data and services via URIs? What goes around comes around).

So, in order to showcase our new Web Script-based Word integration, I took the plunge and upgrade to Office 2007. And that was the day my productivity plunged. Markedly.

I’ve seen the ads for Office 2007. How it is designed to change the way I work and make it easier for me to share information and get more done. Really? Was this targeted for me? With the massive amount of content I generate and distribute, could this make my life better (especially being backed with Alfresco content management?).

After four weeks, I can conclusively say no. Leaving aside Excel and Powerpoint for the moment, I can share that Word 2007 has indeed changed the way I work. I spend much more time worrying about whether or not I saved my documents in the older file format that is compatible with what everyone else can open (the point was sharing information, wasn’t it?) and trying to figure out where all my favorite commands are in the new, improved, easy-to-use ribbons (maybe they are not so easy after all?).

My frustration with Word 2007 really comes down to a few things:

• Who is the product designed for? Word 2007 offers a blizzard of new features. None of which I really need to take advantage of. In this regard Word - along with Excel - seems to be designed for a professional technical documentation writer or, in the case of Excel, a seasoned business analyst. I am neither. I am a regular knowledge workers who spends a significant portion of his time writing documents and creating spreadsheets. But the documents I am creating are not “professional” in the sense that I am not overly concerned with layout and presentation. Yes, I need some generalized mark-up and tabling capabilities, but not much more. I’m not using Word day-in-and-day-out to create glitzy marketing collateral. I need to write clean documents with a minimal amount formatting so that my colleagues can easily read it.Word 2007 - like Word 2003 before it - seems to be trying to target the people who use Adobe Acrobat. I don’t need Acrobat. Never did. If Word is becoming Acrobat, am I leaving Word or is Word leaving me?
• Was there any accounting for the costs of upgrades? Now all software vendors struggle with customer upgrades. Introduce new functionality, or change the UI to improve the user experience, and there are upgrades costs in terms of retraining. But there are ways to ameliorate such costs - for example, in my prior company, when we overhauled our user experience and redesigned from the ground-up, we did not require a forklift upgrade. The upgraded product ran both GUIs, and users were able to choose which one they wanted to use. New users could start on the new GUI, existing users could stay on the old until such a time as they were ready to cut over. And they could go back and forth if they ever did get confused.Word 2007 does not give me choice (in many senses). I am stuck with the new ribbon, lose all access to familiar menus, and have no turning back. I’m generally what you would consider a power user, and so you’d expect that I’d be someone to ramp up quickly with the new interface and get all the benefits of the new productivity enhancements. That’s not the case. I think the ribbon is attractive, yes, but frankly I still after four weeks find myself searching and searching for basic functionality. Seeing lists of available actions in a menu was a convenience for me, not a burden. Now everything is so iconized and hidden in various submenus on icons my discovery costs for functionality have gone through the roof.Perhaps I’m mistaken, but I just can’t see how everyday people who depend on Word but who are not technical power users are going to make the leap. I think the attendant costs in terms of end-user training and lost productivity are going to be huge for any organization.
• Do they really know what makes me productive? If Word and Office more generally is about productivity, do they know what makes me productive?  I’ll tell you (since Microsoft didn’t ask me): my hands not leaving the keyboard.  I type, and I type well. When I want to author a document, I want to quickly bang it out. Anytime my hands leave the keyboard means I lose my train of thought or just simply interrupt my flow of typing. Having to need to format text is not contrary to this. I thought being able to hit Alt-E and either hot-key or cursor my ways through menus was great. Yeah, first time using the system the ribbon may be a nice, attractive way for someone to explore what functions are available. But frankly once I know what I need to do, I really just want to type. Making me use a mouse to do everything really slows me down

Which gets me back to Excel and Powerpoint. Back in the mid-90s, I worked for a consulting company that was standardized on Lotus123 and Freelance. I first realized the productivity costs of forcing my hands from the keyboard and making me use a mouse when I was put on a project for a major entertainment company. That firm mandated that our consulting team use Excel and Powerpoint. For the first time, I had to consistently interrupt my financial modeling to grab the mouse and select various options in different dialogs. It was frustrating … that job was all about knowledge worker productivity - we were on a fixed price contract and had short timelines for a ton of collaborative work. The net result? Instead of my normal 12-14 work day, I wound up working 14, 18, or more. And, when crunch time came, I had to pull multiple all-nighters in a row, mostly because doing everything took so much longer in Excel and Powerpoint than it did in Lotus123 or Freelance (which enabled me to use either the mouse or keyboard - choice).

Though I guess it wasn’t all that bad. I was so burnt out after that assignment and frustrated by my difficulties creating and sharing information quickly with my peers using Excel and Powerpoint that I quit that company and moved to Silicon Valley. There, I got in touch with Peng Ong, and joined a small start-up called Interwoven as product manager when it was just 3 people in June 1996. My goal: find a way to help people more easily publish and share information productively - using this new thing called the World Wide Web.

Funny how things turn out. Maybe Word 2007 will indeed usher in a productivity revolution.  But probably in an equally unexpected way:  by incenting others to invent new tools and technologies to save people from Word’s expensive upgrade path and provide them will a real office worker productivity environment. Namely, Alfresco

Well, since the release of our WCM maintenance release on April 16th, Alfresco has been on a development tear, enhancing both our core ECM platform and WCM services with the release of our latest Community release, Alfresco 2.1 RC1 today.

Coming from 11 years of traditional enterprise software development, I continue to be astounded by the sea-change an open source model brings to enterprise software development and adoption. This past 3 months has been for me a validation that open source will fundamentally break down and eliminate transaction costs for sharing ideas and information to speed product development, and for providing access to and validation of software by potential prospects. Let me explain that first bit; the second bit will be the subject of a subsequent post.
In my prior experience, software development was a lengthy, closed-door process. Despite every best attempt to engage customers, glean requirements, and validate plans, fundamentally the need to safeguard IP and maintain competitive advantage meant that information on what we were building, how it was being built, and when it would be available with what known defects was impossible to disseminate. This ultimately meant:

• Longer release cycles. Because customers did not have access to our UI mock-ups, design docs, source code, and nightly builds - and could not freely discuss
  them on forums and file and track issues in our bug database - we’d need to have lengthy BETA cycles to solicit feedback, rework requirements, and re-engineer
  parts of the product.
• Reduced product quality. Not everyone was a customer; not all customers could participate in a formal BETA (which was often limited anyway, due to the need to rapidly engage and solicit targeted feedback to rework elements of the product); not all customers who might be normally solicited for participation could participate due to the specific timelines and time requirements demanded by the BETA program. And lastly, partners - so critical for successful software deployments - are not treated themselves as customers, meaning that these vanguards of successful deployments - who often best understand a customer’s environment - do not have their valuable insight incorporated in the final release.The open source model changes this: everyone is a customer, whether a paying subscriber, a partner, or a college student with a perverse fascination with all things
  ECM (I love these types; future Alfresco engineers!). More testers mean more dicussions means more feedback means better data. And lots of data. With nightly builds available every day, and the source freely available for download on each check-in, anyone at any time can take a minute, an hour, a day to walk through the pending release and provide a comment - or two. And because feedback occurs real-time, changes can be made real-time - easy fixes get put in that may gone missing in the old model, quick changes to accomodate special environments or scenarios added. Because all feedback doesn’t have to be gathered, processed, prioritized, and assigned for development at the end means out of the gate the software is more robust.

  In the old model, these transaction costs to the free flow of information meant in reality, customers needed to wait until a maintenance release - simply put, even
  after a 3 month BETA, the feedback gleaned couldn’t be incorporated until the one minor release later. This too then means a longer release cycle - but at it’s
  heart, it is about the initial release often not being up to snuff.

• Lack of Customer Preparation and Consequent Slow Adoption. Perhaps the single biggest challenge, however, was customer and partner awareness and planning. Because of the need to safeguard IP and product plans, customers and partners could not themselves plan. How can a customer commit in advance to an upgrade to a new software version, if they don’t know exactly what will be delivered, when, and with what issues? BETAs don’t help; the true known defects still are not exposed and the release date of the maintenance release everyone knows is necessary is guesswork at best. What this means in practice is that investigation and
  planning often wait until the release of a maintenance release … so even after a 3 month BETA, a 3 month maintenance release cycle, customers are looking at
  a 6 month timeframe for upgrade. That’s nearly 12 months after code complete of the base product. At which point technology and business requirements may
  have moved on. This too is about a longer release cycle - but, more fundamentally, it’s about a loss of opportunity to take advantage of new technology to
  wring out more operational efficiences, get better control over your internal data or processes, or get a jump-start on some new business initiatives. Ouch!

In this case of our latest 2.1 Community release, the open source model has opened my eyes to these problems - and mightly so:

• Our entire development cycle was nearly the same as a typical BETA period, which the same amount of significant product enhancement you might find in a traditional enterprise software release with 12 -18 month combined dev and BETA cycle.
• Our product new capabilities out of the gate have a higher quality threshold than what would typically be in an initial major product release (pre-maintenance), since so many users from the customer community, partner community, and internal community have tested various features as they’ve been developed.
• Our entire release targets and timelines and specific tasks have been publically available on our wiki and in our bug database for all to see since project launch on March 14th. Customers already are lining up to adopt 2.1, without the traditional enterprise software mentality of immediately waiting for the first maintenance release to ship before beginning planning. That means these customers can take advantage today of new capabilities to close out 2007 initiatives; in the old model, this new release would be slated for a mid-2008 upgrade AT BEST

So, today we released Alfresco 2.1 Community RC1 … another milestone in the Alfresco product roadmap. This release both introduces new innovations in the ECM market and shows the acceleration possible with an open source business model.

If you haven’t taken a look at Alfresco yet, do take a look at us now. For more on 2.1 RC1, see the announcement on our forums and detail on our release note page.

http://forums.alfresco.com/viewtopic.php?p=23367

Kevin

I had an interesting conversation with a customer yesterday. Like many others, this particular customer was looking to make a significant investment in their website to overhaul look-and-feel, move from a static to dynamic user experience, and include access to new application services and new capabilities for cross-sell and up-sell. This customer labeled this their own “Web 2.0″ intiative … getting a new modern architecture both server-side and client-side and setting themselves up for the next 5 years of growth. So far so good.

Unlike years before, however, this customer was saavy enough to understand that to sucessfully re-launch their site they needed to design in up-front the supporting content management platform and processes. While looking at their new site and architectural requirements, they looked heavily at the features and architecture of various CMSes - both commercial and open source. Kudos to them.

The challenge: no single product seem to meet the needs of their entire team. The customer found this odd; this customer had what they thought was a fairly standard web operation:

1. A team of application developers building the core application logic and web services interfaces to expose new capabilities on the website

2. A team of web developers building the actual website and the supporting CMS templates and workflows

3. A team of web designers and graphics artists designing new sites, pages, and associated images, Flash, video, and more

4. A group of content managers responsible for creating new sites, site sections, or microsites (temporary site sections to support a specific marketing effort) based on approved templates, and responsible managing which users and groups can perform specific roles with specific approval processes on that site

5. A decentralized team of publishers and reviewers responsible for producing the actual site content

What this customer found was that while nearly all CMSes provided good support for the decentralized team of publishers and reviewers, and that while better CMSes provided decent support for content managers needing to quickly spin-up a new site and configure the processes around maintaining that site, no single CMS provided a comprehensive solution for managing their entire site development process. No CMS provided an integrated environment for reviewers, publishers, managers, designers, and developers.

This customer - like many others I’ve talked to - wanted a CMS to manage their website. The entire site. All activities around producing and maintaining that site. And support for all users who played a role in that process. This customer wanted:

1. A single repository of record for staging, versioning, workflowing, and deploying an entire dynamic website. Not just the content, but the code as well.

2. A single system to support development, design, and publishing to eliminate separate systems used by each group to reduce number of servers, reduce integration headaches, reduce integration errors, and improve site QA capability and overall quality.

3. A single system where developers, designers, managers, and publishers could collaborate on new releases (updated designs, new site services, etc.) easily without comprimising the ability to maintain the current site or without adding lots of additional costs for replicating an entirely new CMS infrastructure.

At Alfresco, our focus is to meet these requirements. At Alfresco, we are working to not only provide the services you’ve come to expect in a traditional Web 1.0 CMS, but more importantly working on a new type of CMS that will help support you in your move to more dynamic, interactive, Web 2.0 sites.

The Alfresco approach is a different one: our new WCM capability will support simple, intuitive, wizard-based XML publishing using XForms. We will support robust editorial review with simple email-based preview and approval powered by JBoss’ jBPM engine. We will also support key concepts of parallel development, virtualization, staging, snapshotting, branching, and deployment. And it is these specific capabilties not found in other open source CMSes that so neatly map our customer’s requirements.

Parallel development means that developers, designers, and contributors can work independently from one another on potentially destabilizing changes to the website without affecting one another. An app developer can change some back-end business logic - without breaking anyone else’s ability to preview a functional version of the site. A web developer can change an included Javascript file - without interrupt the developers or publishers. The designer can change a *.css and preview a complete overhaul of all affected web pages - without any reviewer. In Alfresco, parallel development means we support change set isolation, allowing everyone to collaborate without fear of stepping all over one another.

This is closely coupled with the concept of virtualization. Virtualization means that all users will be able to preview a fully-functional version of the site prior to deploying to the run-time environment. Java developers will be able to preview changes to their application code. Web developers will be able to preview changes to scripts and JSP pages.  Not just a static preview of a generated HTML file, Alfresco will support any number of views of an entire web application so that all users have a robust, previewable state of a dynamic website before committing a change, regardless if that is to code or content.

More than that, Alfresco also provides support for staging, snapshotting, branching, and deployment. Need to stage different sets of changes to the website for development, QA, test, or timed deployment? Alfresco provides an unlimited number of virtual staging servers to queue up changes to the site for different purposes - all without requiring replication to different server machines. Need to have a consistent snapshot of your entire website for purposes of deployment, rollback, and recovery in the event of a disaster? Alfresco provides an ability to automatically, an nearly instantaneously, snapshot an entire site - all code, all content, all media. Need to work on a new version of the site to launch a new set of services? Alfresco supports branching to enable a team of users to simulataneous stage, preview, and version today’s site - as well’s as tomorrow’s. And finally, need to deploy an entire site to multiple front-end file server, database servers, and application servers in your run-time? Well, you’re in luck … Alfresco does that too.

There’s a lot of hype around Web 2.0 technologies and a lot of interest in our customer base for leveraging these technologies to support their new web initiatives. Oddly, content management tool seem only to be looking at incorporating these technologies in their products to improve their user experience - and don’t seem to be looking to enhance their core services to better manage a customer’s own Web 2.0-style site.

At Alfresco, we think Web 2.0 technologies demand a corresponding Web 2.0-ready CMS. The traditional CMSes packages for Web 1.0 just don’t cut it.

Last week, I had the opportunity to speak on a panel at the Collaboration Technology Conference in Boston.  The goal was to discuss how enterprises can leverage open source technologies to establish a collaboration platform for the enterprise.

At least that was the stated intent.  We never really got around to talking about collaboration.  The reason?  The audience was more interested in open source, asking a number of questions that I hear over and over that show a general lack of understanding with what’s different about open source these days and why enterprises should feel comfortable - really, compelled - to look at companies like an Alfresco.

Of the many questions fielded, I’ll highlight the Top 3 questions I hear over and over again when I introduce our open source ECM platform to potential customers or partners:

1.  How do you make money? 

2.  How much does it really cost to deploy your software? 

3.  How safe is your software?

Let’s address each of these in turn: 
 

Question #1:  How do you make money?

The real question here is “If I invest in deploying your technology, will you have enough money to support me, fix bugs, and enhance the product over time?  Or are you going to go belly-up and leave me with a migration headache?”

The answer is unequivocally yes:  the new open source enterprise software model means that companies like Alfresco generate a profitable stream of support and maintanence revenue that enables us to fund operations and invest signficant R&D resources into advancing our offering.

Coming from the commercial software world, this was a stunning relevation to me how this works.  But it is really simple.  Let me explain.

In a traditional enterprise software firm, software license revenues may account for 40% or so of total quarterly revenue.   To generate this net new license revenue, a traditional enterprise software firm spends heavily on marketing (seminars, executive dinners, etc.) and sales (commissions, commissions, commissions!  those sales reps love the brand-new BMWs!).  This cost of sales may eat up to 60% or more of quarterly revenue.  Really, what this means is that in the traditional model, net new license revenue is acquired at a cost … each net new customer is unprofitable in year 1.  Why acquire a new customer then?  Support and maintanence.  Customers purchasing software today can be expected to renew maintanence for 3 to 5 years.  Customers become profitable in year 2 because maintanence revenue has exceptionally high margins.  Maintanence is where the real money is.

In the open source model, customers are profitable in year 1.  That’s because we only charge support and maintanence.  We can do this because unlike a traditional firm, we don’t have the same Sales and Marketing spend:  we don’t have to market heavily to customers to get them to engage a sales rep to go through a grueling sales process, and we don’t have to pay sales reps hundreds of thousands of dollars to act as gatekeepers to trialing our software.  We just build general brand awareness and let you download our product and see if it fits.  All we need to do is be there when you’re ready to deploy and need a maintenance contract.  We don’t need license revenue.  And we don’t need lots of Sales and Marketing to get license revenue.  We spend our money on R&D and make the same money or better than the traditional vendors off of support and maintanence.

It’s a sexy model.  And it makes sense.  And it means we’ll be around funding R&D for a long time.
 

Question #2:  How much does it really cost to deploy your software?

The real question here:  “Isn’t open source just a bunch of random code that I need to spend a lot of development resources on to do deploy something functional and usable for my end-users?   Is the software really free is I have to spend more deploying open source than a packaged enterprise application?”

The answer:  a resounding no!  The new open source enterprise software model calls for a new type of open source package.  It’s not a bunch of random code. And it’s not expensive to deploy.

Let me explain.

Because a company like Alfresco doesn’t spend heavily on Sales and Marketing resources (which in a traditional software company use personal skills of persuasion to get a customer to overlook flaws in packaging, usability, extensibility, etc. and deploy an application), the new open source enterprise software model dictates that software is tightly-packaged, well-documented, and easy to install.  Furthermore, because we have a business model built around getting customers to successfully pilot our software and buy a maintanence contract when ready to deploy, the new model also requires that the software out-of-the-box supports most everyday use cases, is friendly and intuitive to end-users, and is readily customizable not via lots of custom code but more easily through a GUI.   Unlike more familiar open source projects, the new enterprise applications coming from a company like Alfresco are targeted at both developers AND business users - we invest just as heavily in UI design and development as we do in architecture. 

Is it expense to deploy?  Actually, the new model dictates that we are LESS expensive to deploy than a traditional enterprise software package.  We can’t afford to not be able to have hundreds of thousands of people download, install, configure, and deploy quickly and easily and with great enough success that they choose to get in touch with us to purchase support and maintanence.  And we can’t afford to help them get through this process.  The traditional software model does not have the same incentives as we do.

Question #3:  How safe is your software?

The real question:  “If I deploy a particular version of your software, can I be assured of having professional support and bug fixes?  Am I going to have to constantly upgrade to new release versions and deal with upgrade issues and new features when what I really want is to avoid the change management costs with upgrades and simply get the current product I’ve deployed stable?”

The answer:  But of course!  That’s the difference between a traditional open source project and the new open source enterprise software model. And it is the one place where the new model is similar to the traditional enterprise software model.

To beat a deadhorse, we are an established company that generates solid money from support and maintanence.   Our support and maintanence practices at least as good (really, better as I’ll explain) to a traditional firm. You can open support cases.  You can track bugs fixes.  You can get maintanence releases.  You can stay on a known, good, stable platform for as long as your internal policies dictate before upgrading to a new feature release.  Just think normal support and maintanence, and realize that the new open source model is as safe as anything offered by a traditional software firm.

Well - really safer.  And why is this?  That’s because not only do we allow you to track your support cases and bugs, but our ENTIRE bug database is available for you to browse.  Really, nothing hidden.  You may like to know what other issues are being found by other customers - whether or not you’ve hit them - just so that you may avoid them yourself before they are fixed.  And when looking beyond simple bug fixes to the next major feature upgrade, our entire roadmap and design specs for new releases are available on the wiki.  You don’t have to interpolate from the tidbits of information given out by a product manager to figure out when is a time to upgrade and how best to plan - you have access to all the information you need to make a safe, effective decision.

And there you have it.  The new open source model works.  We’re a viable company, our software is a fraction of the cost, and it’s superior in terms of quality and usability and supportability than anything offered by a traditional firm.

At the Collaboration Technology Conference, I found that nearly everyone in the audience walked away excited by open source after going through these points - hopefully you’ve got renewed excitement in open source as well.

Yesterday, Oracle made an interesting announcement on its upcoming Oracle Content DB release.  This is Oracle’s new product offering for Enterprise Content Management (ECM) and is billed as ”content management for the masses” and ”basic content management services” for 80%+ of unstructured conetn that isn’t today stored in a relational database.  Oracle’s objective is to provide a management layer atop that underlying RDBMS that exposes content services and serves as a platform for the development of content-centric applications, much like the RDBMS did in a prior generation for client-server applications.  Further, Oracle’s objective is to get all unstructured content under management by supporting easy access to content via a file share.  Sounds compelling.   

Oracle’s focus on providing ECM for the masses is on target - too much information continues to sit outside a content management framework for reasons of deployment costs, ease of use, and scalability.  And Oracle’s objective to provide a platform for content-centric apps that easily supports end-users, their content, and they way they work is laudable.  The only thing Oracle really gets wrong in its announcement is telling its customers to wait for a future release that will only partially accomplish this.  Oracle’s announcement is exciting because what it really offers is confirmation for IT architects looking to build a next generation platform for their content-centric applications that indeed evaluating Alfresco ECM is the right decision.

Why do I say this?  First let’s look at key requirements for an IT architect when building platform like Oracle describes:

1.  JSR 170 support.

Oracle likens its Content DB to a next generation RDBMS for content-centric apps.  But before the database became a key platform for the development of client-server applications, what happened first?  Standardization via SQL of data access, retrieval, and persistance.  Standardization enabled the growth of a pool of developers with a common skillset and eliminated risk of vendor lock-in.  Just as standardization was critical to the establishment of the database as a development platform, so too is standardization critical to the establishment of a content repository (a management layer built atop the RDBMS) as a platform for content-centric applications.

That standard exists today in JSR 170.  Alfresco ECM offers full support for JSR 170 and our support for the standard is a key reason why IT architects evaluate us.  Not only will Oracle’s planned future announcement not offer full support, the accompanying statement of direction is unclear on future timeframes for that support.

2.  Ease-of-use through file-system interface.

Oracle correctly points out that the way most knowledge workers prefer to work with content is via a familiar file-system metaphor.  Being able to easily browse files and folders and launch for editing via Windows Explorer means user resistance melts and learning curves flatten.  But Oracle’s approach offers complications to meeting the following requirements:

a.  No client-side installation.

If users are going to benefit from an Explorer-based file browser, first they have to be able to use it.  And if it’s too costly to rollout and maintain by IT, then the utility is zero.

b.  Normal Explorer-like behavior. 

If users are going to find it intuitive and natural to use, the experience of working with an Oracle folder or file in Explorer can have zero difference from any other file or folder.  That means being able to right-click and create, rename, open, or view properties.  It means being about to drag-and-drop or synchronize with Microsoft Briefcase for offline use.  Any difference, however, small, represents a change that an end-user may find quirky, annoying, or blocking - and over time will occasion user dissatisfaction and preference to avoid the system altogether.

c.  Seamless content management. 

Similar to the above, most end users for most documents don’t want to think about content management - and shouldn’t have to.  If training is to truly be minimized, end users shouldn’t have to know that they have to right-click on a document in order to do things like check-in or check-out.  Users should be able to simply drag-and-drop, edit and save a document and have the content management system automatically trigger the appropriate rules to route the content for review, trigger version control, web publishing, lifecycle management, and more.

At Alfresco, we implement a CIFS projection of our JSR 170-compliant repository for precisely for these reasons.  Zero client footprint - just map a normal network drive.  Zero difference with normal network shares, files, and folders in Windows Explorer - drag-and-drop, see your normal menu items, continue to do offline synchronization with Briefcase.  And zero requirement to train on executing specialized content management controls … with Alfresco, end users simply work as they do today on documents, and behind the scenes our advanced rules-engine will automatically process document updates for version control, workflow, transformation, metadata assignment, web publishing, records management, and more. 

Oracle is right about the simplicity of the file-system interface.  And Alfresco uniquely supports a true file-system interface for precisely this reason.

3.   Compatible with IT architectural stack.

Oracle makes another good point in that content be securely managed in the RDBMS, which is the core building block for any next generation platform critical for reliability, availability, and scalability.  But is Oracle’s RDBMS the only option that IT architects need for the web-based apps?  And, for that matter, aren’t there other components of the stack that may or may not be Oracle?

At Alfresco, we built our entire ECM platform on a next generation IT stack and afford IT architects with the flexibility to use different components within that stack as needed.  Alfresco leverages Hibernate for DB persistance, Spring for our application framework, any J2SE web container for our web app, and Lucene for search and indexing.  While Oracle is right to focus on getting all content into the RBDMS, making certain that the content platform is built on a next generation stack and open and flexible is essential.

At Alfresco, we believe that in the emergence of a next generation content platform upon which content-centric applications will be built.  We believe that that platform should be based on open standards like JSR 170.  We believe all structured and unstructured content in the enterprise should be managed in a secure repository, and that to accomplish that that the content management needs to be as simple to use, simple to deploy, and simple to scale.  We believe in the use of a real file-system interface, support for a next generation open source IT architectural stack, and use of an RBDMS for the underlying physical storage of content to meet these needs.

I encourage anyone who hasn’t read Oracle’s announcement to take a good read.  And then come take a look at Alfresco.