Hi Bruce,

I am glad to answer to your questions. Before that, I think it is interesting to briefly remind how Nuxeo project lives. Nuxeo platform is developped in a transparent way (public Jira, public github repository, public jenkins) under LGPL license. Most of the evolutions of the core part are done by developers from Nuxeo company, but there are also more and more accepted pull requests coming from "the community", which is made, aside Nuxeo company developers, of enterprise developers for their own enterprise use, system integrators developers and software vendors developers, that embed Nuxeo, or develop around it their own solution(s). Among all those people that do pull requests, some are direct Nuxeo company customers or work for some of our customers, benefiting from hot fixes, productivity tools (such as Nuxeo Studio), and SLA based technical support, while some just use what is made available freely (you are in this case I guess). Github really simplified the contribution process.
As I said, those contributions are most of the time very specific to one technical part of the platform, but can sometime be much bigger (like Open Social Container). How the roadmap of the product is decided ? We are driven by three main factors, all equally important: the platform vision we have in mind, Evolution requests from our customers and contributions from the community. Furthermore, the plugin and extensibility model of Nuxeo platform allows to experiment first on custom deployments some features before deciding to go for a core integration so as to encourage ground experience before implementing evolutions.


1/ Nuxeo spends time updating the libraries: when we find blocking bugs for our customers, or security problem, or when we need features not present in the current version of the library, so as to implement an evolution on the platform. For instance we upgraded the jod library so as to be able to generate PDF/A compliant pdf. For some stability reasons, we would not want to automatize updates. But library upgrade perfectly fits with the contribution process ! If for your own requirements you expect a library evolution, why don't you check all Nuxeo unit-test and functional (Selenium) tests are ok and then submit a pull request, so that the upgrade is taken into account ?
Your blog post here
http://concena.com/blogged-down/-/blogs/extracting-exif-iptc-xmp-and-more-with-drew-noakes-metadata-extractor-2-5-0-rc3?_33_redirect=http%3A%2F%2Fconcena.com%2Fblogged-down%3Fp_p_id%3D115%26p_p_lifecycle%3D0%26p_p_state%3Dnormal%26p_p_mode%3Dview%26p_p_col_id%3Dcolumn-2%26p_p_col_count%3D1%26_115_advancedSearch%3Dfalse%26_115_keywords%3D%26_115_delta%3D30%26_115_struts_action%3D%252Fblogs_aggregator%252Fview%26_115_andOperator%3Dtrue would maybe deserve such an effort (but the fact that the dependency is a release candidate, I don't know Nuxeo developers policy regarding that).

2/ There may have been some confusion (or I misunderstood your point), there is no plan for two-ways engineering between Studio and Eclipse. For people who would not know Nuxeo Studio, it is an online service provided by Nuxeo to its customers for managing the customization of their Nuxeo instances: implementing the configuration, and getting the resulting plugin, with 100 %insurance of compatibility with future versions of Nuxeo.
What you can expect is a continuous progression in the extension of the scope of what can be configured from Studio, so that you would not have any reasons to want to dig into the generated XML. For instance, the 2.6 version (recently released), added tens of options on the content view configuration, that are indeed present in the low level XML configuration. Nuxeo Studio brings a lot of value in lowering implementation and maintenance costs, and is key part of the commercial activity of Nuxeo, meeting great success among our customers, so that you can expect a lively roadmap on it !

3/ Performance here is a bit too wide (can be file upload, transformation speed, …) but I had read an other blogpost of yours on that topic. Nuxeo philosophy is to implement an open source ECM platform that offers integration of best-of-the-breed lower level open-source components and libraries so as to provide a great and normalized experience all around the platform, while letting the possibility to integrate Proprietary components for capabilities extension. Your blog post on that topic is very interesting for a tuning approach of the existing integration, but the good news is that, if a project requires it, there are still other approaches and options to go further, like pooling the converters by tweaking a little bit the way they are called (and by adding the notion of remote converter). This is the kind of service we are able to provide to our supported customers. And this is the kind of ground experience that then improves the product for the community, once the next version is released, after the improvement. It can also be possible to integrate a third-party proprietary library that would be optimized for the very use case you need. And Nuxeo can publish the integration on the marketplace, so as to make it easily accessible for others, after that.

4/ and 5/ Regarding the Error catching policy and the NoSQL I am not skilled enough to get into interesting details, joker ! But maybe it would be interesting to share why, beside the general buzz on this persistence approach, you would ask for it, what are your uses cases. And that actually leads me to the last part of my reaction to your blog post, and your blog more generally: above your expectations on improvements, new features, performance, etc.. which are always an interesting feedback for Nuxeo company, the community would be really interested in knowing more of what you do with the platform: your customers use cases, generic modules you have developed, do you plan to reverse some to the community… (like, from what I see on your website, Lotus client would certainly meet a big success ! )

Cheers !

Posted on 6/7/12 7:46 PM.

Thanks for the great feedback on the post. My follow-up (on a few parts at least)
1. Now that I'm getting more comfortable with the whole contribution process I will again try this out. Switching form Mercurial to Git was the first step, learning and getting comfortable with Git the second, and now starting to understand expectations and process for contributions. I (and a customer) have funded additional development on the Drew Noakes library to improve the speed at which it processes metadata on huge TIF files (so I am putting money where my mouth is :-) as well as rudimentary processing for PSD files. For those interested have a look at the latest 2.6.x version - the improvements are phenomenal - of course there is some work to getting it to work with Nuxeo 5.5 (it's not just plug and play with the existing library because method signatures have changed).
2. Maybe the confusion is mine - I will review the webinar again.
3. Performance is a wide subject BUT absolutely critical to the success of Nuxeo given the volumes of data and size of objects. Most of this is premised on DAM and core image management where handling of huge files in an efficient manner is absolutely critical.
4. Error handling is a very general topic as well but user perception is negatively skewed with every unexpected error page. I will take time moving forward to start recording instances where I get unexpected errors and at some point follow-up on this.
5. This was more just me wondering if it was even on the long term radar. I think this technology will eventually take hold and I like to be able to field customer questions on topics such as this. Good point on what I have been doing with Nuxeo - would make for good fodder.

Cheers,
Bruce.

Posted on 6/8/12 9:45 AM in reply to .