I've been having a private conversation from somebody on the list that
'suggested' that we should focus on something and getting it done rather
than dreaming on many things and dilute our effort.
This made me think about the impact of this RT-style open development on
community dynamics.
I strongly believe in open development and open design and I think RT
are some great way of working together without worries of saying
something that turns out a bad idea.
At the same time, I agree that I've been dropping on this list all the
random thoughs that I had during the last 12 months of absence from the
OSS world.
And considering the amount of thinking I normally do everytime I have
some free time (while driving, before going to sleep, walking from one
place to another, talking with geeky friends, etc.) a full year of RT
it's tough to digest without a global vision that explains my
intentions.
So, here I express my visions and my intentions to get them done in a
professional and focused way.
- o -
Stream of Thought #1: community dynamics
----------------------------------------
The Cocoon Community does both research and development. Its dyamics can
be visualized as follows:
+-> research ----> develop ---> produce ----> use --+
| |
+---------------------- report ----------------------+
The difficult thing is placing enough social inertia in the loop to
detach it to the single individuals that make up the community. When
this happens, the community can be said "healthy" and "stable".
Some people (read recent Linus Torvald's comments on the Linux Kernel
dev mail list) make a parallel between this system and a biological
ecosystem, arriving to call the process that creates open source
software as "evolutionary software darwinism".
The first person that I heard using this expression was James Davidson a
couple of years ago. I'm happy to see that Linus now adopts the same
concepts.
Anyway, unlike natural evolution witch is a globally stocastic process,
community dynamics act as "directed evolution", thus performing at a
faster rate.
In this context, I believe that RT-style research can be seen as an
evolutionary catalizer that improves the pace of cross-hybridization of
ideas, thus resulting in faster R&D times.
There is no way for me to prove this, but my very high success as a
community bootstrapper (no OSS project that I started failed to get
enough inertia to continue without me) leads me to think there must be
some truth in this.
At the same time, while a higher mutation frequency in biological
populations might increase diversity and provide faster evolutionary
cycles, a frequency too high might degenerate the population since there
is no time to adapt to the changes.
So, if RT work like mutations and cross-pollination for biological
system, we must be careful to avoid the saturation of resources and
leave time for changes to percolate thru the community and be solidified
into code so that the loop can continue.
Without a fast loop (that is: a fast release cycle!), the process looses
stability and degenerates vitality.
I believe the perfect match is one bugfix release per month (at least!)
and no more than two back incompatible releases per year (hopefully
none).
- o -
Stream of Thought #2: The perfect KMS
-------------------------------------
KMS stands for "knowledge management system". It's a marketing buzzword
that indicates systems (mostly targetted for intranet use) that are
capable of managing and making available 'corporate knowledge', the
company information, in such a way that it's easily created, easily
published and easily accessible.
A typical KMS is composed of:
1) a front-end
2) a back-end
3) a content-editing system
4) a search engine
5) an administration toolkit
the idea is to come up with solid and open software solutions that
implement all the above key pieces, then sell the service to glue them
together for customer needs.
The map between those pieces and existing software is *far* from being
accomplished but we are heading in the right direction. My guesses are
for software mapping are:
1) front-end -> Cocoon
2) back-end -> XIndice or a Cocoon-based CMS layer wrapping XIndice
3) editing system -> ??? (Mozilla based inline editor being my best
guess)
4) search-engine -> ??? (The lucene-based indexing appears a first step
in the right direction)
5) administration toolkit -> cocoon webapp
I will now explain my ideas on each component.
- o -
Stream of Thought #2.1: the front-end
-------------------------------------
Cocoon is a publishing system but many hit a wall by using it and they
understood the hard way that:
"there is no distinction between web publishing and web applications"
So, in order to remove this wall, we have to rethink the Cocoon
architecture in order to make it easier to create web applications with
Cocoon.
The problem has been idenfitied by many as a limitation in functionality
of the sitemap, that was designed for "outward" flow of information and
didn't take 'inward' flow into deep consideration.
One of the proposed solution is to enhance the sitemap semantics to
incorporate concepts from "finite state machines".
Another solution is the incorporation of the concepts of Scheme
'continuations'.
The debate is not over, nor any complete solution has been proposed that
makes everybody happy.
There is no release plan nor time frame for this, even if many believe
it's very important to make Cocoon stand user requirements.
Research on this topic will continue on this list.
- o -
Stream of Thought #2.2: The back-end
------------------------------------
I wanted the dbXML project (now XIndice) to move over to Apache because
I think it could be a wonderful seed to grow a community around this
"back-end" concept of a semi-structured content management system.
This CMS could be XIndice alone or XIndice as the storage core and a
wrapping layer that performs versioning/revisionsing and deals with
metadata.
Of course, the goal is to connect this back-end with the front-end, so
interoperability between Cocoon and XIndice (either direct or thru a CMS
layer)
Now that the Apache XIndice project is starting, I'll move over my
effort on the [EMAIL PROTECTED] mail list and will continue the
R&D there.
- o -
Stream of Thought #2.3: The content-editing system
--------------------------------------------------
Following the SoC patterns, content should be edited and modified by
editors, people that have specific writing and authoring skills but
normally lack technical ones.
For this reason, the editing system should require the little possible
effort and integrate seemlessly with the editing environment the persons
are used to.
At the same time, the software should not give any more editing freedom
than what their concerns require. For this reason, a pure WYSIWYG
solution is considered harmful.
The proposed solution is a constrained-WYSIWYG editing system that
allows visual feedback to help the writer contextualize the edited
content, thus simplifying the editing approach, but limits the editing
capability to those areas where writer is allowed/capable of working on.
The required features are:
1) portability: it should work on any system
2) integration: it should integrate with existing systems
3) full WYSIWIG capacity: it should incorporate a full web rendering
system (HTML,CSS,javascript with native XML/XSLT/SVG/XForm capabilities
as a clear plus, but not necessary)
4) customizable: it should allow easy customization of editing needs
Several software technologies were analyzed but the most proposing seems
to be the Mozilla Project (www.mozilla.org) which is portable and
contains a very modular and highly customizable architecture, along with
the fact that it's an open source project, thus safe ground to invest a
technological effort upon.
On the other hand, given personal lack of time and C++ experience and
lack of sponsoring on this side, this effort put on hold, even if I'll
keep an eye on Mozilla to see if they implement the required
inline-editing components.
Anyway, if others want to push this forward, I'll be happy to join them.
- o -
Stream of Thought #2.4: The search-engine
-----------------------------------------
Unlike many believe, searching and indexing of the content of a KMS
cannot be performed from the backend level since this level doesn't
contain the URI->resource information (which is necessarely contained in
the front end).
For this reason, the indexer must necessary connect to the front of the
system (either simulating user requests, or directly hitting the
publishing engine avoiding the request/response
serialization/deserialization overhead).
Even the search part is clearly to be connected to the front end. For
these reasons, I believe the search engine effort should be performed
between the Cocoon and Lucene projects.
I have some ideas that I presented at some ETH (Zurich Institute of
Technology) folks that I will submit in the short future. Unfortunately,
they require some changes in Lucene, for this reason, I'll subscribe to
that list as well and continue the effort between here and there.
- o -
Stream of Thought #2.5: The administration toolkit
--------------------------------------------------
The administration toolkit should be a front-end application.
Another limitation that has been identified in Cocoon is the lack of
modularity at the application level.
I proposed a solution that follows the WAR concepts and uses the
abstraction that cocoon-specific URL protocols allow (as Mozilla does)
to make componentization possible even at the application level.
I will continue this research within Cocoon-dev because it's not only
useful for an administration toolkit but it's a very interesting concept
that would make it easier to create hot-deployable application-level
cocoon subprojects that encapsulate all necessary parts (along with
webapp-specific components, logicsheets, stylesheets, resources,
sitemaps and what not).
- o -
This is an ambitious plan and won't happen overnight. I'm fully aware of
this.
For the pessimists between you, I can only say that my dream, back in
early 1998, was to turn a single-project virtual host named
java.apache.org in a full backoffice suite for web services.
And the only project we had was Apache JServ version 0.9.11 alpha.
I expect the entire effort to take between 12 and 18 months to complete.
Faster if I find sponsoring or jobs that require this software as the
engine (as I'm currently trying to do).
(if you are capable of providing such sponsoring because you like my
plan and you think it's worth for your own company/effort, please let me
know privately).
I hope this gives you an idea of what my visions for the future of this
project are.
Hope this helps.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
