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)
