Italian open source blogger Roberto Galoppini has recently joined in the discussion about open source business models that got started by Eric Barroca and Dirk Riehle. For his post Roberto interviewed Day's CTO David Nuescheler and published parts of it. Please find the complete interview below.

On standard participation costs

It definitely depends on the level of participation in a particular standardization process. Simple participation in an expert group or a technical committee can require only a small effort such as a couple of hours of work per month or week. An active participant in a standardization can easily rack up numerous hours per week ranging up to a couple of FTEs. When we talk about leading a specification effort, like we did in JSR-170 or JSR-283, there are a number of subject matter experts more or less constantly involved.

The burden on editor or specification lead also varies by standardization body. With some standardization bodies there is no requirement to produce a testkit to certify or measure compliance of an implementation with a standard.

However, for example in the JCP the specification lead must provide a testkit (TCK) and even a reference implementation the passes 100% of the testkit to prove that the entire specification does not just look good on paper but is completely implementable. Providing a testkit and a reference implementation certainly makes it much harder to complete a standard but it of course also makes the final result a much more solid specification.

In our specific case we did not really see the standards participation as a cost but much more as a part of a our leading edge research and development efforts that we would incur anyway. The choice that we have is whether to do that research behind closed doors and receive our first input from our customer base once the product is shipped or if we want to discuss these topics with the brightest minds in the industry by leading such a standardization. We very much view the expert group in a specification as our extended R&D-team that we can leverage for architecture discussions that matter to the entire industry.

On symbiotic costs (aka competition costs within Apache projects)

We generally feel that through developing most of our infrastructure code in public there are various benefits for us as a commercial vendor.

To ensure that we gained maximum benefit we chose to collaborate with the Apace Software Foundation. In particular because it is renowned for its clean cut meritocracy and true-spirited open source, from its very liberal licensing to the diversity-oriented community and foundation processes.

Traditionally I think that people view community participation in terms of contributing code patches or feature donations. In our experience the most valuable contributions from the community comes in completely unexpected forms. These include the use of a very public active mailing list as a sounding board and self-help archive, issues reporting, the fact that the community is building the software around-the-clock, having a very agile test harness of the latest features and changes in the form of the community and ultimately the prospect of being able to then hire the brightest minds in the industry having seen their great community work on “our technology”.

Most importantly though I think that learning to develop in the “Apache Way” has greatly improved our internal communication skills and has greatly enhanced the overall quality of our products.

We feel that only on rare occasions do we compete against “our” Apache open source projects and we have definitely been able to keep our open source projects very competitive within the open source world.

On code production tracking costs

The production of code that ends up in our products happens in various ways already. I would argue that every software vendor leverages open source and closed source libraries. Some vendors may rely more on open source libraries than others.

At Day we believe in producing a lot of our code ourselves. If we find ourselves in a position where we need to develop commodity code that is generally applicable and reusable we try to open source as much as possible.

This results in our active participation in a lot open source projects (see e.g. here)

Keeping your code open of course also allows to use public, 3rd party tracking tools and statistics about open source projects and allows to compare with peers (e.g. on Ohloh)

Via @georgwaechter I have come across SimPCoRe which is a content repository for PHP. Judging from the description and this discussion SimPCoRe does not fully implement JSR-170, but only a smaller feature set. It does, however, seem to implement the basic ideas and concepts of a (Java) content repository.

It is great to see the ideas and concepts of the "content repository" spreading - be it standards-based or an adaption/evolution or a minimal feature set. Anything that helps with the implementation of better content management systems is a good trend (see also this previous post). Especially, given the large amount of PHP-based CMSs I am happy to see more PHP developers working on content repository implementations (others are Jackalope and Flow3).

Jackrabbit 1.6 has been released a couple of days ago and it comes with a very cool, but somewhat hidden feature: it is now possible to use the Content Repository through http. There is direct read/write access to the repository even from the browser.

Of course, through Sling this was possible before, but now http-based access is native to the Content Repository itself. However, having Jackrabbit-native http access makes it much easier to use JCR from whichever framework or language you happen to use to write applications. In that sense, I tend to think of this as a game changing feature for Jackrabbit and JCR.

Unfortunately, the name of this access capability is not something one would expect like "RESTful this" or "Web that", but "JCR Remoting". Anyway, to check it out run the Jackrabbit 1.6 standalone server and find the description and some examples at http://localhost:8080/webdav-jcr.jsp

Nodes can be read through a GET request for /path/to/node.json , whole trees can be read in one request through a request to /path/to/node.treedepth.json (which is the format known from Sling). Adding, deleting or moving nodes is possible by sending POSTs in a specific format defined in the tutorials at http://localhost:8080/remoting/write.jsp

When I read the JCR Remoting documentation I got very confused by two concepts: WebDAV extensions and the JCR Remoting Client. Here is what I found out:

The intention of JCR Remoting is to make available the complete JCR functionality. At the moment, not all of that is implemented in the protocol. For this reason WebDAV is used as a fallback (for now). This makes sense, because WebDAV is http-based as well.

The JCR Remoting Client is a set of Java classes that implement the JCR Remoting protocol and provide clients with a Java-based JCR session. Essentially, this is an alternative to an RMI-based connection to a Java Content Repository. It might be of interest to you if you intend to use Java to connect to the repository, but you can safely ignore it if you do not intend to do so.

Are you using Apache Sling for internal projects or commercial software or anything else? Let the world know and add yourself to the wiki page of Sling users that got just started by Sling committer Ian Boston (the wiki page also contains an interesting summary on Sling's impact on the code base of the Sakai project).