[jr3] Strategic plan

[Jukka Zitting <ju...@gmail.com>]

Hi,

Based on the various recent and older discussions, here's my very
high-level suggestion on what to target and how to reach it.  Take
this as a proposed strategic plan, which doesn't directly address more
tactical issues of which specific features to implement or how.
Following the Situation-Target-Path model from [1], here's my
proposal:

Situation
---------

In Jackrabbit 2.x we have a solid and feature-rich content repository that
works well especially for the needs of traditional web sites and integrated
content management applications. However, the trends in user expectations
(especially for personalized, interactive and collaborative content),
application architectures (distributed, loosely coupled, multi-platform
solutions with lots of data) and hardware design (horizontal rather than
vertical scaling) have rendered some of the original Jackrabbit design
decisions (that date back almost a decade) obsolete and there's no easy
way to incrementally update the design.

This problem has been a know issue for years (the first proposals to address
it date back to 2008), and over the last year we've been actively prototyping
promising ideas to gather more experience on how they work in practice. Now
is the time to move to the next phase where we take that experience and all
the knowledge we've gathered from working with existing Jackrabbit versions
and use it to build a new repository that better matches today's needs.

Target
------

We want to implement a scalable and performant hierarchical content
repository for use as the foundation of modern world-class web sites and
other demanding content applications. The repository should implement
standards like JCR, WebDAV and CMIS, and be easily accessible from various
platforms, especially from JavaScript clients running in modern browser
environments. The implementation should provide more out-of-the-box
functionality than typical NoSQL databases while achieving comparable
levels of scalability and performance.

By 2013 the new repository should have stabilized its internal architecture
and the implementation should be ready for production use in major deployments
that don't need all the designed features to be ready yet. By 2014 the
repository should have reached comparable level of functionality on all
Jackrabbit 2.x features that we haven't explicitly decided not to support.
It should be possible to migrate existing Jackrabbit applications and
deployments to the new repository implementation with little effort.

Path
----

Since the goals of the new repository implementation are somewhat different
than the traditional goals of Jackrabbit (i.e. to be "a fully conforming JCR
implementation"), we should organize the implementation work as a new
Jackrabbit subproject with its own identity (i.e. not just "Jackrabbit 3").
This subproject shall have it's own dev@ mailing list, source repository,
issue tracker and release cycle. For now the effort will remain a part of
Jackrabbit and fall within the oversight of the Jackrabbit PMC, but down
the line we may want to branch it off to a separate TLP, possibly through
the Incubator.

The new repository shall be implemented in an open, collaborative fashion
based on the Apache principles. The effort shall be open to all contributors
and actively strive to make it easy for new people to get involved. To
achieve this, the new architecture should be designed to be modular and
easily extensible. Extra care shall also be taken to make the new repository
trivially easy to deploy and use for the most common use cases.

To enable a rapid feedback cycle and to make it easy to track our progress,
we shall adopt a "release early, release often" model of making new releases
at least once a month and maintain a growing set of automated integration and
performance tests to maintain release quality. A key design constraint for
all features is to make them easily testable.

To get started on all this, I propose that we select a name for the new
repository and set up the proposed subproject infrastructure over the next
two weeks. Then we'll target at releasing the first 0.1 version of the new
repository by the end of March. The minimum requirements for that release
are only that it's accessible through HTTP and JCR ("Hello, World!" level OK),
come with a runnable jar for easy deployment, and have a basic integration
test suite that verifies that the release meets the above requirements.
We'll build on from there!

[1] http://en.wikibooks.org/wiki/Business_Strategy/Overview_of_Strategic_Planning#Methodologies

BR,

Jukka Zitting

Re: [jr3] Strategic plan

[Stefan Guggisberg <st...@gmail.com>]

On Thu, Feb 23, 2012 at 2:04 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Thu, Feb 23, 2012 at 12:45 PM, Jukka Zitting <ju...@gmail.com> wrote:
>> Based on the various recent and older discussions, here's my very
>> high-level suggestion on what to target and how to reach it.
>
> I put this proposal up on the wiki at [1] so we can iterate it based
> on emerging consensus.
>
> [1] http://wiki.apache.org/jackrabbit/Jackrabbit%203%20Strategic%20Plan

+1, very well put!

thanks, jukka.

cheers
stefan


>
> BR,
>
> Jukka Zitting

Re: [jr3] Strategic plan

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Thu, Feb 23, 2012 at 12:45 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Based on the various recent and older discussions, here's my very
> high-level suggestion on what to target and how to reach it.

I put this proposal up on the wiki at [1] so we can iterate it based
on emerging consensus.

[1] http://wiki.apache.org/jackrabbit/Jackrabbit%203%20Strategic%20Plan

BR,

Jukka Zitting

Re: [jr3] Strategic plan

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Thu, Feb 23, 2012 at 3:50 PM, Michael Dürig <md...@apache.org> wrote:
> I think it is important that we identify and plan for cross cutting concerns
> which are not easily modularizable. We should also mention this in the plan.

Good point. I tried to avoid setting architectural direction (except
general goals like modularity and testability) but a general statement
like this is a good guideline to include in the overall plan.

See the draft roadmap I sent and the resulting discussion for more
specific details on how I think we should go about addressing such
issues.

BR,

Jukka Zitting

Re: [jr3] Strategic plan

[Michael Dürig <md...@apache.org>]

Hi Jukka,

Thanks for making the effort and putting this together! I think after 
much prototyping and experimental work in the past couple of months it 
is very valuable to try to get a clear vision of the big picture.


> Path
> ----
>
[...]

> The new repository shall be implemented in an open, collaborative fashion
> based on the Apache principles. The effort shall be open to all contributors
> and actively strive to make it easy for new people to get involved. To
> achieve this, the new architecture should be designed to be modular and
> easily extensible. Extra care shall also be taken to make the new repository
> trivially easy to deploy and use for the most common use cases.

I think it is important that we identify and plan for cross cutting 
concerns which are not easily modularizable. We should also mention this 
in the plan.

Michael