[rt-devel] Code fork

[Tobias Brox]

I don't know if it has been noticeable at the mailing lists, but
anyway there have been some friction between Jesse and me.  We have a
bit different coding style and different ways of seeing things.  I've
always considered this to be an advantage, because the compromises we
land at often seems like better solutions than either of the
suggestions.  Anyway, I guess Jesse is tired of arguing with me, and
it has eventually comen so far that a code fork is inevitable.  I
really hadn't believed this just a week ago...  To quote Jesse:

      Your goals are fundamentally in conflict with the project's
      goals. Because of your short-term goals, the longterm
      maintainability and extensability of the codebase is suffering.
      I appreciate all the hard work you've put into RT over the past
      year or two, however, this has become an unresolvable conflict.

My first pri short term goal is to serve Funcom Support Department by
putting in whatever features they want to see in our local RT2 version
(or eventually telling them why the wanted feature is a bad idea).  I
can understand that Jesse want to release a RT 2.0 without too much
"jingle&bells", and that much of what we see as essential here at
Funcom doesn't fit everywhere.  However, most of those "doubious
features" are in the web templates, and can easily be removed.

My priority two "short term goal" is to get RT out to the people.  I'd
really like to see a working beta before the 14th of August.  Jesse
thinks that RT2 is absolutely not ready for production.  Well, I can
agree to some extent - most users out there will probably either have
problems with the installation, or they will find that it lacks some
key features.  BUT I have to stress that we actually do use it
extensively in the local production, and that we are quite satisfied
with it.  I'm intending to move the last queues from RT1 during the
day!  We've had no significant problems with RT2 so far - knock on
wood!

I'm deeply concerned with the slow development of RT2.  All time
estimates have been successfully broken.  I don't know what plans
Jesse has for RT2, but it seems more and more to me like a one man
cathedral project than a baazar project, ref. Eric Raymond at
http://www.tuxedo.org/~esr/writings/cathedral-bazaar/ - I don't blame
Jesse for beeing busy with other things than developing RT2, but it is
indeed slowing down the RT2 development considerably.

In my opinion there has been a crying demand for a successor/upgrade
of RT1 already since before the 1.0 release.  RT2 is long overdue. Our
local RT1 version is very feature-rich compared to the official RT1
release - there is tons of enhancements.  I'm not touching it unless I
really have to, not only because it's an ugly hack collection, but
also because it has been a dead development path all since Jesse
suddently decided to skip the development of RT 1.1...

So, I have now set up a project at sourceforge for TwoRT¹ - The
Working Request Tracker.  I guess it will be available during the day,
I will move all sources over to the CVS there.  I also want to set up
a working demo instance somewhere; I'd appreciate it deeply if anybody
can assist me in finding a location outside a firewall where I can run
either fcgi (that's just normal cgi, except that the perl binary has
to be statically linked with the fcgi-libraries) or mod_perl.  I want
TwoRT to be self-hosting, all user requests and bug reports should be
stored in TwoRT.

Here is the major things that are missing from TwoRT (and also RT2):

1 Access control.  Actually I can manage without for the moment.  I
  have no clue about how far Jesse has gotten with it.  In the worst
  case, I think I can handle that in two weeks if I work hard on it.

2 Keyword handling, a system that is to replace the areas.  I'll steal
  a bit from Knowledge Base, a system Jesse has hacked together.  It
  will take me four days of intensive working to fix this.

3 Admin tools.  Administration can be done in SQL, eventually it will
  take me four days to hack together some simple web interface.

4 Ports to different database systems.  That will hopefully be an easy
  task, and I think the interessted parties can manage to do this
  themselves.

5 Converting / Linking tool between RT1 and TwoRT.

Anything else?

RT2 and TwoRT will probably develop in a bit different directions.  My
version will be more feature-rich, and probably the code will be a bit
more "hacky".  This will probably lead to higher complexity, more
bugs, slower code, less maintainability - anyway, I think the code is
so modular by now that those disadvantages can be kept to a minimum.
Just as a sidenote, our full-featured RT1-branch has never had
problems, except when my disk has been overflowing, and eventually
when my old version of mysql decided to do a lot of random things.  I
will try to satisfy everybody, and if somebody have made some features
that there is some demand for, and which might be better to have in
the codebase than as add-on modules, then I will probably incorporate
that.  I will give anyone that seems fit for it developer status in
the CVS.

Another thing, my experiences are geared towards support towards
external "clueless" "customers" rather than in-house technical
support.  Naturally, I think my TwoRT will be more geared towards this
usage; while in-house technically aware requestors usually preffers to
get as much insight into RT and their request as possible, the average
external requestor should have a pleasant, warm feeling that he is
communicating directly and personally with the support personell.

RT is frequently beeing used for monitoring worktasks.  I think it
sucks at it.  I have started setting up a Project Management Tool
built on the top of RT ... hem, TwoRT that is .. :) It's of course
_not_ a full-blooded Project Management Tool, but to say it this way
... the few features I've putted into it until now does indeed work,
and I am using them locally.  I'm considering it to be a prototype
experiment, experience from this can be taken over to the fields of
Asset Tracking, Bug tracking, etc.

So, to be short:

- If you're completely happy with RT1, you shouldn't care at all as
  for now.

- If you'd like to wait until next year² for a perfect, stable RT2 that
  runs right out of the box, but might miss some of the fancy the
  features you want, you should definitively hang around for RT2.

- If you'd like a feature-rich, easy customizable, easy hackable
  request tracker, and if you have the patience of setting up a system
  that most probably won't run at the first try, you should
  definitively go for TwoRT.

- If you would like any of those related products (Asset Tracker,
  Project Manager, etc), you should also have a look at TwoRT.

I will of course continue to monitor the development of RT2 and steal
whatever I find interessting from this project.  I also think the
database schemas will be fairly compatible - if there will be changes,
I will probably provide a converting tool.  I will also allow for
inter-instance linking between RT2 instances and TwoRT instances - as
far as it is in my power.  I hate code forks, and I will eventually be
open for a merging in the future.  Actually I think neither me nor
Jesse have what it takes to make the perfect RT2 alone.

¹ Just a suggestion.  I don't like it very well myself - I'm open for
better suggestions.  I'll also change it if Jesse finds it too
offensive :)

² I hope I'm incorrect about this, but I do have a slight feeling it's
going that way.

-- 
Tobias Brox, +47 22 925 871