incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Spicar <>
Subject Re: The future of Clerezza
Date Tue, 06 Nov 2012 09:31:20 GMT
I could imagine there would be enough people that could support the RDF
libraries and data access layers. They are used not onnly in Stanbol and
when they are actually used people might put in the required effort. I
think part of the problem is that to me it didn't seem like the CMS
components are moving anywhere so I preferred to work on other projects in
my free time.

However there are still some projects that use Clerezza CMS components.
>From my experience they did not contribute much to Clerezza because the
effort and time needed to get changes approved and subsequently get a
module released scared them off from even trying. Maybe Clerezza CMS
components might still develop some life on places like GitHub where
collaboration is more informal and people can just fork it and implement
their changes and offer their changes as pull requests. In worst case it
will be a nice archive ;)


On 6 November 2012 09:48, Bertrand Delacretaz <>wrote:

> On Friday, November 2, 2012, Fabian Christ wrote:
> > moving Clerezza libs to Stanbol would be an option but I am wondering
> > if the Stanbol community is strong enough to additionally maintain
> > this code...
> Without having analyzed in detail, my impression was that the parts that
> Stanbol uses are not very complex, so if the move is limited to those parts
> that should be doable? I didn't mean to move the CMS-related parts of
> Clerezza, just the reusable RDF and other libraries that Stanbol is using.
> > ...The people behind the code should be
> > willing to move and keep contributing. Otherwise I see the potential
> > that the Stanbol team decides to switch entirely from Clerezza to
> > other alternatives....
> Agreed, but if we consider the libraries that Stanbol is using, aren't
> those people already Stanbol committers anyway, ?
> -Bertrand

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message