Video, slides and transcript of my talk at the Nuxeo DevDay


Mon 08 December 2008 By Stefane Fermigier

My keynote presentation at the Nuxeo DevDay last Monday was called “The Nuxeo Way: using open source to build a world-class open source ECM platform”. It was very enjoyable for me both to introduce the conference and to reflect on the first 8 years of Nuxeo.

The conference itself was for us a real success (the room was packed), and according to the feedback we got from the participants, everyone enjoyed the experience.

You will find below the slides and a transcript of my talk.

Slides

The Nuxeo Way: leveraging open source to build a world-class ECM platform

View SlideShare presentation or Upload your own. (tags: standards scrum)

Transcript

A bit of history


Our company was started eight years ago, in 2000, and from 2002 to 2005 our product line was based on Zope. During that time, we learned quite a lot about ECM, open source, and how to build a proper architecture.

In 2005, we started to introduce Java technologies in our offering. We first did a very interesting project, based on Eclipse RCP. At the same time, we started an hybrid prototype mixing Zope and Java technologies. It actually did work out, but we quickly realized while doing this project that it was even better to switch completely to Java.

So, since 2006, we are fully Java based, and we don’t have plans to switch to another technology in the foreseeable future.

Goals and vision


Our original goal for the Nuxeo projects was to address the full scope of ECM applications.

Since we had to initially focus our resources on a smaller subset of this scope, we decided to start first by focussing on document management.

For these two reasons, we wanted an architecture that would be highly extensible so that we could easily add new modules to implement new functions over the lifetime of the project. We also wanted to make it easy for other people or companies to add their own value on top of the platform, hence enabling and sustaining the creation of a real ecosystem around the Nuxeo platform.

The technical vision to reach these goals was to build the platform on solid existing foundations instead of reinventing the wheel: standards (such as the JCR then, or now JCR2 or CMIS), and open source libraries and frameworks.

This is the real benefit of open source: to reuse what other people have built, and provide your own value, as new frameworks and components, on top of it.

During our journey from Zope to Java, we learned some very important lessons:


  • From the Zope era, we learned the value of component architectures and the basics of the ECM discipline. These are lessons, of course, that we remembered when designing the architecture of Nuxeo EP.

  • From the early RCP project, we learned about OSGi and extension points, which are now the foundation of our component architecture.

  • During the Java era, we experienced the value of standards. They are important, because they make it easier for partners such as systems integrators or ISVs to adopt our technology. We also learned that with the proper tools (such as a good IDE) and architecture, we can be as productive with Java as we were with Python, and provide better quality.

Process and tools


We also wanted to implement a robust software engineering process, with a strong focus on quality, and to make it transparent to our customers and to the community, to make it easier for you to participate in this process.

We also have an internal goal for this process, which is to improve collaboration between teams that are involved in working in custom projects for our clients, and those who work on the generic open source platform.

We started out early in the life on the company by adopting development practices from extreme programming (XP) and test-driven development (TDD). We found over time that it was needed to complement these practices with a discipline for project management that would be simple and easy to use, that would increase team efficiency and productivity, and that would be able to scale up, as our company is growing at a very fast pace (> 50% / year).

So we decided this year to introduce the Scrum development methodology, as it is the most popular and best documented agile methodology now, and that literature shows that it is really helpful in increasing productivity, quality and control over development schedules.

Of course, we are still using TDD with open source tools, such as JUnit for unit tests, Selenium for functional tests, and Hudson for continuous integration, that continuously monitor the quality of our products.

Other tools was are using now are also open source, with a few exceptions: Mercurial, which was introduced this year, for distributed source management (we believe this approach scales much better than the centralized SCM provided by Subversion); Maven, to manage dependencies, build, packaging and releases (it is a bit complex but very powerful and is quickly gaining acceptance in the Java development community); Jira, a non-open source task and issues management system, that helps us implementing the Scrum process.

Where do we go now?


Our work on the platform is driven first by evolving or emerging market needs, such as “enterprise 2.0”-style collaboration, mobility or moving storage and computing infrastructure to the cloud, etc.

We also listen a lot to developers feedback. We conducted a first developer survey last month, and got an overall satisfaction index of 3.8/5, which is already very good.

Here are a few more important facts discovered by this survey:


  • The strongest points of our platform, according to you: ease of installation, a large set of functionalities, and strong standards supports. As you remember, these were some of the main goals for us when designing the platform.

  • There are however areas for improvement, which we are working on now, mostly: usability and design for the default user interface, and documentation.

  • All of you are interested in Document Management and Search, and you also have strong interest in Records Management, Collaboration and Workflow.

  • From the technical side, you think our strongest points are our initial choice of technologies, our conceptual model, our architecture and our API. On the other hand, we need to work a little bit more on ease and speed of development, for instance by providing more tools for this, and, as I already said, on developers documentation.

  • According to the poll, your preferred deployment platforms for the server applications are open source Java EE application server: JBoss (81%) and GlassFish (64%), but also “lightweight” web containers such as Jetty (45%) or Tomcat (40%).

  • Your preferred DBMS are PostgreSQL over MySQL (83% vs. 56%), among open source options, and Oracle over MS-SQL (37% vs. 15%), for proprietary systems.

How can you get more involved?


The open source game goes two ways. We’re working very hard to provide you with the best possible open source ECM platform, but we also need your input on several points.

First of all, you can test the platform, and fill bug reports and requests for enhancements on the Jira.

You can discuss with us new APIs or other improvements to the platform, using the mailing list, the forum, the wiki or the Jira.

You can help us write better documentation, either by writing self-contained pieces of advice in the FAQs and HOWTOs, or by editing the Nuxeo Book or other bits of official documentation.

You can also create new translations. There are already 7 or 8 existing translations, and you can easily create a new one by translating a property file.

Of course, you can get involved in the coding side of the project by becoming a committer to the code base: fixing bugs, improving existing code or adding new functionalities.

The best way for you to become a committer is first to create patches and upload them to the Jira. Of course, these patches need to adhere to the Nuxeo coding standard, and will be reviewed by more senior committers before being actually committed to our code base.

If everything goes well, after a few accepted patches, you will get full access to the source code repository.

You can also work on your own side. Because it’s an open and extensible platform, you can own a bit of functionality and develop it on your own terms.

So, with our plugin architecture, you’ve got the choice: you can either work on your own forge or SVN, or we can host your project on our development environment.

Conclusion


Once again, thank you.

Thank you for coming to this conference, all 60 of you.

Thank you for everything you have contributed so far to the platform.

And thank you for your attention.


Category: Product & Development