"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
