"Peter B. West" <[EMAIL PROTECTED]> wrote on 18.05.2004 05:59:20:

> project.  The situation with FOray is more complicated.  I don't know 
> whether it is Victor's intention to fork from HEAD and continue the 
> development along the lines he has previously discussed, or to attempt 
> to integrate HEAD and the maintenance branch in some way.  In any case, 
> what Victor is doing will closely parallel the HEAD development, and 
> this, combined with the possibility of some financial support, has a 
> great potential to de-stabilise FOP.  I'm not saying this as a criticism 

> of Victor, but as a bald statement of the reality.

Some elaborations on this from my side. Please feel free to ignore it
entirely.

About 18 months ago, I was in a situation similar to Victor's.

I wanted to get a few things done in FOP and did some patches. Like
all of you here I realized that FOPs (maintenance) internal structure
wasn't all that great. However, unlike the committers here I thought
that refactoring the maintenance branch would have been the way to go.
My gut feeling was that, given the time available to the committers
and the non-existence of a strong "head developer", the
re-implementation would either take extremely long or fail.

Since this was really a gut feeling based on the discussions here and
my professional experience, I didn't really speak up, because I didn't
really have anything in my hands to prove my point and I also wasn't
a stakeholder - so to speak. Maybe that was wrong, maybe not. Well,
I discussed a little with Nicola as another interested bystander at
that time. Here's an excerpt from my mail that I think still applies:

> Truth to tell, my greatest fear concerning FOP right now is not the 
license
> but that the people involved in the redesign take too long because they 
don't
> have enough time. In commercial projects, I've seen the following happen 
many times:
>
>1. Project A starts and is moderately successful
>2. Implementation learnings from A and new requirements toggle
>   the decision for a complete redesign.
>3. Project B is kicked off as a result, but progresses slowly (for 
whatever reasons)
>4. A is still in use but needs fixes and some small enhancements, 
yielding A'
>5. Time goes on, A' and B progress further.
>6. Someone comes up with a carefully refactored version of A' and B is 
stopped.
>
>I truly hope this doesn't happen with the seemingly long ongoing FOP 
redesign.

This was two years ago, but I think I can still subscribe to it.

About 18 months ago, my options were:

1. Get into the hot-headed discussions an try a turn-around to refactoring
2. Fork off an 0.20.3 branch (at that time) on SourceForge (like Victor 
did now)
3. Write my own XSL formatter.

I pretty soon discarded 1. and toyed with 2. However, since sometimes I 
still
have a "let's storm that hill" attitude and were also pretty familiar with 
writing
text formatters and PS and PDF emitters, I opted to do 3, but to do it as 
a
fun project with an open goal since I didn't have all that much spare time 
beside
my business. Kind of a "let's just see what happens" project.

So what happened was: I now have an XSL formatter that is in my estimation 
further
along than the FOP redesign and that does most things that 0.20.5 does and 
a lot of
things that 0.20.5 does not. I confess that so far, I did borrow the 
TrueType font
reader from FOP. What am I going to do with it? Well, it's not really 
decided yet.
The most likely scenario is to make it a commercial product. BTW: why was 
I fast?
I'm good (like you), I had experience in many of the areas involved, and - 
very
important - I didn't need to discuss my architectural decisions because I 
did it
alone. I had fun.

So why am I writing this?

First, I very much wish the FOP team and the project to succeed. Even I my 
pet
project is ultimately successful and even if it's a commercial success I 
firmly
believe that "we" need an open source XSL formatter under the Apache 
license.

Second, maybe to give you second thoughts about what you and Victor are 
doing.
My personal impression and also my recommendation is to:

Model A: Let one strong developer with resonable time on his hands drive 
the
development of the redesign until it has so far progressed that it's 
usable
for people currently using 0.20.5.

Model B: Refactor the maintenance branch. This keeps more users and 
therefore
more possible contributors on the bandwagon. Refactoring is tedious and 
needs
experience, but you get that experience quickly and the motivation stays 
over
time. Also, the maintenance branch source code is not *that* bad. Yes, it
badly needs refactoring in most places, but it's not beyond repair.

Since I don't see Model A for FOP currently (no strong developer WITH 
enough
time on the horizon), I believe Model B is what would work best. Your 
existing
development model for FOP 1.0 is taking too long IMO. This is not a 
criticism
of any of you, but a personal assessment of what I think can be achieved 
with
the time available to you. It's also still more a gut feeling that an 
analysis.
If you can draft a realistic project plan with people assigned and that 
gives a
reasonable estimate on when you will be done, you can probably do it.
If you can't or the result is too disappointing, please reconsider 
refactoring
the maintenance branch.

What Victor did was going to happen some day or other. Like me, probably a
number of others have their own local 0.20.5 branch with some enhancements
(yes, for some customers I still use my hacked-up version of 0.20.5).
I think his project is good for FOP as long as both projects manage to 
share
at least some things.

Like two years ago, I still don't feel all that comfortable about speaking
up on this. After all, it's *your* project, and what the f*** do I have to
say about it. Ok, this time I decided to do it. Please don't be offended
- it's really meant as a personal opinion from an interested bystander.
I hope you can accept it as such.

Thanks for listening,

Arnd Beissner
-- 
Arnd Bei▀ner
Cappelino Informationstechnologie GmbH

Reply via email to