Wednesday, July 08, 2009

Organised volunteerism

As part of a longer discussion on a private mailing list[1] Sam Ruby wrote a succinct description of the Apache volunteerism ethos. He wrote:

"The prevailing attitude within Apache is that releases will be done when they are ready, and that such releases will contain only the functions for which there exists volunteers who have an interest in doing the work. At times, there are people who would prefer a more predictable schedule and specific function. There are organizations which provide such assurances. This isn't one of them."
This resonated with me as a participant in the Apache Harmony project which is undertaking a full implementation of the Java SE specification. There are some modules that attract lots of attention in completeness and performance (such as the core LUNI, beans, security, and so on) and others that don't attract so much effort (such as Swing, print, and RMI).

I'm totally fine with that situation since it represents the technological equivalent of the adaptive market hypothesis of financial markets. In our world, people will tend and care for code that is important to them, and the other code by definition is not so important to people.

I've been a contributor to numerous open source foundations and working groups with different styles of working, and there is no "one true way" -- having a variety of organizations with different styles of working ensures that there is going to be a place for a wide variety of people to be comfortable innovating in the advancement of Java technology.

I'm comfortable with those who want to make some code open, and keep other code to themselves. I object to those who claim there is only one way to behave, and try to enforce that on others through restrictive licensing or organizational rules.

[1] Sam kindly gave me permission to take that quote and make it public.

1 comment:

Daniel said...

I think that not implementing something is not a bad thing, when it can open doors closed by strict compatibility.
Nota Bene: A roadmap can be useful (something clearly lacking in Harmony web site: From external point of view Harmony does not give understanding of his objectives.

Forgetting strict compatibility can even be very good for Java ecosystem, if Harmony can create improvements that Sun does not create (possibly stopped by current JDK compatibility state).

By example, the Harmony Select anticipated seems quite similar to others subsets of JDK:
Google AppEngine (OpenJDK-based):
By not including UI and not allowing JNI, it remove parts of JDK problematic for managing simultaneously multiple untrusted code.
Google Android (Harmony-based):
By allowing JNI, they have probably secured these calls or forked another instance of Dalvik interpreter for each application.

But, even if Apache Harmony has possible objective of defining a future "Cloud/Hosted profile" of Java (, I think a small bibliography can not be uninteresting.

Sun has already given a list of advantages and drawbacks and solutions of MVM (for reviving an old buzzword):

These experiments with Multitasking VM has already given the JSR 121 (creation and management of multiple applications in the same JVM) and JSR 284 (Resource Consumption API).

Isolation of applications is clearly important in embedded space, specifically mobile phones: it is already in the final specification of MIDP 3.0 (JSR 271), section "5.2.1 Data Isolation" (cf. Files at
I understand that it can be very useful to expand Java ecosystem to the web hosting services (where the JNI drawbacks does not need to be managed if UI API are not included and JNI not to be offered) or the embedded space (same problem for creating complex services called by a declarative/Web UI integrated with the browser).

As a programmer, I think it can be useful for solving current problems with development of UI (and possibly future performances with easier parallelism in declarative UI toolkits), then I hope for an evolution to this target: services + declarative UI.

Then, if Harmony has this objective of SOA/cloud services, I think a small up-to-date roadmap can be useful and it is important to not forget to have code and API for Isolation and Resource Comsumption (like these JSR), because untrusted code need to be managed (externally and internally).

Thanks for reading,