Email: dev@concena.com       Twitter: @dbrucegrant
Assessing the Cost of Nuxeo versus Commercial Alternatives

When customers ask about the cost of Nuxeo I always answer in terms of value.  The primary reason for this is simple; I think that the value of an open source approach is by far the more important discussion and will underpin any discussion of cost (or investment). However, understanding cost is critical to making any investment!

The following table outlines the costs associated with Nuxeo versus traditional commercial solutions.  Arguably there are other categories which could be included the list. However, these are, I think, the items with the most cost impact.

 

Nuxeo

Commercial

Comments

License Fees

None

Server and/or user license fees. Adding more users or servers dramatically increases the costs.

Open Source – no initial fees, but more importantly no barriers to implementing more servers or adding additional users (inside or outside your company)

Maintenance Fees

None

Typically 20-25% of license fees. More users and servers increases annual maintenance costs as well

For commercial solutions maintenance fees are required just to get access to new releases of software.

Connect Subscription

Convenience features and access to online Studio development suite

None

The connect subscription is optional, but is required if annual support is required

Annual Support

Per Application irrespective of number of servers or users. Multiple levels of support are available with requisite Service Level commitments.

None in standard maintenance model

Nuxeo annual support is optional. In practice, commercial software often has additional premium support costs as well as those not covered by maintenance.

Development

Required to implement customer’s business requirements. The size and scope of this effort is tied directly to requirements. Simple customizations with Studio, more complex with Nuxeo IDE.

For true off the shelf software there may be no development required (or possible!).

Nuxeo-based solutions are built to suit your business requirements, rather than having to mold your requirements to a commercial solution. It’s typical for some level of integration development (at a minimum) with commercial solutions.

Configuration

Included in development

A separate step in commercial products to configure fields, content types, view, etc.

Configuration allows for some customization of Commercial solutions, but scope and flexibility are limited.

Initial Implementation

Tied to scope

Tied to scope

Assumed neutral in terms of cost, however, this is not always the case.

Server Updates (hot fixes)

With annual support the application of server hot fixes is (almost) trivial. Otherwise, manual updates are still possible, but require additional effort.

Included with annual maintenance, but the effort to install varies based on the vendor and the product.

 

Upgrades

There will be an ongoing cost to maintaining custom developed code.

There will be a cost to maintaining any custom-developed integrations.

Difficult to compare in the abstract, however, Nuxeo is architected in a way that promotes extension and redefinition of function while maintaining ease of upgrade.

 

The bottom line: a Nuxeo-based solution will likely yield a cost savings over a commercial alternative. In the worst case scenario the cost difference may be neutral. However, as I mentioned at the start, I think that the real benefit (value) of Nuxeo comes from its flexibility, extensibility, scalability, performance, standardization, build-to-purpose, rapid pace of development. While estimating cost is necessary, defining the value of Nuxeo to your organization is imperative!

I'm very interested to hear how others feel about this...

Extracting EXIF, IPTC, XMP and more with Drew Noakes metadata-extractor-2.5.0-RC3

Nuxeo already uses an earlier version of the metadata-extractor library. Problem is, this version is somewhat dated (circa 2006/2007) and has very limited support for the broad range of embedded metadata. Well, the new 2.5.0-RC3 version looks to address this limitation by adding support for a much broader array of embedded metadata standards - including XMP! Here's a link to the metadata-extractor project. Thanks Drew!

There are enough structural changes between 2.3.0 and 2.5.0-RC3 that simply replacing the JAR will not work. In the case of Nuxeo that would have meant finding and fixing all the touch points with the metadata-extractor. I opted for a simpler option (that in no way impacts existing code).

1. Downloaded the sources to metadata-extractor-2.5.0-RC3 and the changed the package name from com.noakes.* to com.noakes.custom.* . I then recompiled to create a -RC3.1 jar.

2. Copied the -RC3.1 jar into my nxserver/lib directory (along with xmpcore.jar - comes with RC3 jar download)

3. Overrode and then modified PictureChangedListener to explicitly use -RC3.1. Then added the following code (snippet only). All of this code runs after Nuxeo has processed the blob and set what metadata it can. Obviously this can be made smarter to check to see if (as is the case for JPEGs) Nuxeo found and set the EXIF/IPTC metadata. And of course, longer term it will be best if the newer 2.5.0-RC3 is baked into Nuxeo!

                ImagingService service;
                Map<String, Object> map;
                try {
                    service = Framework.getService(ImagingService.class);
                    BufferedInputStream in = new BufferedInputStream(blob.getStream());
                    Metadata metadata = ImageMetadataReader.readMetadata(in, true);
                    exifDirectory1 = metadata.getDirectory(ExifIFD0Directory.class);
                    // metadata.getDirectory(ExifInteropDirectory.class);
                    exifDirectory3 = metadata.getDirectory(ExifSubIFDDirectory.class);
                    iptcDirectory = metadata.getDirectory(IptcDirectory.class);
                    // metadata.getDirectory(XmpDirectory.class);
                   
                    if (exifDirectory1 != null) {
                        Date dateTimeOriginal = getExif1Date(exifDirectory1.TAG_DATETIME);
                        int width = getExif1Int(exifDirectory1.TAG_X_RESOLUTION);
                    :
                    :

The getExif1xxx functions do the necessary checking to make sure that tag exists and conversion to proper type. For example...

              private int getExif1Int(int tag) {
                  int result;

                  if (exifDirectory1.containsTag(tag)) {
                       try {
                          result = exifDirectory1.getInt(tag);
                       } catch (MetadataException e) {
                          result = 0;
                       }
                   } else {
                       result = 0;
                 }

                 return result;
               }

Five Steps to Success with Enterprise Document Management

Having worked with document management (DM) type solutions for more than 15 years I have seen my share of successes and failures. I'm trying to focus on the positive, so... what makes a DM implementation successful? I've netted the answer down to five points. I should say, that these five points are predicated on the selection of viable DM software, which are innumerable.

One: Follow the KISS principle (at least to start)

While it's nice to dream of an all-encompassing, one size fits all enterprise solution for document management you may be setting yourself up for failure from the outset. So pick a focus area, think about the larger architectural picture, but start with something that has reasonable scope and is entirely manageable. 

Two: Strong Sponsorship

DM projects tend, over time, to have tentacles that touch many parts of an enterprise. From the start it's important to have executive buy-in and active support. Support from the top will give you the leverage you need to be successful in getting your DM solution deployed and (more importantly) used!

Three: Time to Results

Return on Investment, whether for a DM solution or a piece of capital equipment, is an important factor in business decisions. Delivering observable, positive results in the shortest time possible is an important factor in the success deployment of document management. The success of an initial prototype or deployment will in part determine the future life of your DM project.

Four: Deliver what you Promise

Clearly communicate scope, features, and timelines - then stick to it! Enough said.

Five: Solution Simplicity

The solution you buy/build/customize/integrate needs to be able to mold to the business rather than re-engineering all business processes to meet the needs of the software. Furthermore, the user interface/user experience needs to match the needs of the business process. That is, if the business process for an insurance adjuster is taking pictures in the field, tagging them and uploading them into DM, then the UI should be dead simple - no need for a full DM user interface.

From what I have observed, delivering complex, feature-laden user interfaces, and trying to make it fit for everyone, just doesn't work for most companies. The solution gets ignored, underused, or worse, misused. In my opinion, the provisioning of simplified user experience that matches business process holds significant weight in the success/failure curve for DM projects.

Nuxeo - Room for Improvement - Part 4

Has the following happened to you...

Just finished editing a Nuxeo document with about 15 pieces of metadata. Forgot to hit Save and navigated away from the page. Wondered why your changes didn't show up. And then the 'doh' moment - damn, forgot to hit Save. Annoyed I re-type the changes and save the document.

I've had the exact same thing happen when saving local security rights - add the right but forget to hit the Save button just below the newly added rights!

If only there were a way to automatically warn users leaving an edited, but unsaved, page. This time and frustration saving functionality would be a welcome addition to Nuxeo.

For a simple HTML page this is trivial, for an aggregated Nuxeo page it is a little more challenging. I have had this happen to me and several clients have also asked about this functionality so I thought it worthwhile adding to my RFI wish list!

Branding DM and DAM

I really like what's happening with themes and styling in DM. Creating custom look and feel has become much easier in the latest release. With pages, flavors, and CSS styling comes a flexibility that henceforth did not exist in DM. Styling has become another configuration item, rather than a mystical journey into big and ugly XML file requiring a modicum of magic to get the result you wanted.

I was a saddened a bit to see this new approach hadn't propagated through to DAM. When I went to perform a comparatively simple branding task in a Nuxeo deployment with DAM and DM I found the 'flavor' extension point only applied to DM... So the following XML, which I thought would change the logo in all places only showed up in the DM UI.

    <extension target="org.nuxeo.theme.styling.service" point="flavors">
        <flavor name="mybranding" extends="default">
            <logo>
                <path>/img/Custom-Logo-36x36.png</path>
                <previewPath>/img/Custom-Logo-36x36.png</previewPath>
                <width>32</width>
                <height>32</height>
                <title>alt</title>
            </logo>

              ...

To get the logo to change in DAM I had to revert back to pre-5.5 approach. Easy enough change once you realize what's going on, but slightly confusing at first when your logo insists on not changing.

I know this will eventually be rationalized. I just hope it's sooner than later.

Showing 26 - 30 of 48 results.
Items per Page 5
of 10

Recent Entries Recent Entries

RSS (Opens New Window)
Showing 1 - 5 of 15 results.
of 3