On 09/04/2008, Guillaume Laurent <[EMAIL PROTECTED]> wrote:
>  I've discussed this with Chris, and unfortunately we're in
>  disagreement

You don't say!

There are so many reasons why I think this is a hopeless idea that I'm
reluctant to start listing them, because it'll take all day and I'm
sure to overlook some.

Also, I agree with Michael that if you want to do this because it's
fun, it seems churlish to object.  There's no point in having a hobby
unless it's fun.

Unfortunately, I don't think I can just not object: after all, this
directly affects my hobby as well.

So here we go.  I'll break down the Reasons Why This Is The Worst
Software Engineering Proposal Of 2008 into three categories,
approximately in order from most rational to most emotional.  I'll
call the categories "business reasons", "community and free software
reasons", and "personal reasons".


A. Business Reasons

These are the reasons why "hey, let's do a Cocoa version of
Rosegarden" would not go down well in the hypothetical Rosegarden Inc
boardroom.  This is the utilitarian category.

1. It's a rewrite.

Rosegarden is a complex application -- several years in the making,
170K lines of code (according to Ohloh), a great many very subtle bug
fixes, years of documentation effort.

Rewriting an application of this size and complexity using a different
language and/or toolkit is very seldom a successful business choice
(see many good reasons at
e.g. http://www.joelonsoftware.com/articles/fog0000000069.html,
http://onstartups.com/home/tabid/3339/bid/2596/Why-You-Should-Almost-Never-Rewrite-Your-Software.aspx).
Also, the fact that all of the reasons you've given for preferring
Cocoa are technical/developer-centred reasons should ring alarm bells
immediately around the boardroom table.  And I think you're seriously
underestimating the amount of work that has gone into the existing
Rosegarden, and overestimating the amount of that work that might be
recycled into a Cocoa version.

2. It's much harder and higher-risk than other ways to achieve the
same result.

We already have this application, and it already uses a cross-platform
toolkit!  Bringing it up to date with Qt4 and adding an OS/X
audio/MIDI driver layer would result in a native OS/X application and
would be easier than rewriting it.  More importantly in a business
context, it would also be much lower risk, because it is essentially a
predictable series of refactoring operations.

(The insight of refactoring is that you can make enormous changes
incrementally, by applying a series of individually very low-risk
transformations.  Rewriting using a different language or a
substantially differently structured toolkit prevents you from taking
advantage of that possibility.  Even if things go well and you quickly
get the skeleton in place, you are always left to do the "last 80%" of
work -- the bug fixes and corner cases -- all over again.)

Note that although Qt4 currently builds as a native Carbon application
on OS/X, a Cocoa version is also under development (with a recent
alpha release).  We're in the hugely fortunate position of being able
to leave much of the risk and effort to the developers of the toolkit
we use.  We should take advantage of that.

3. It's a dead end.

Cocoa on OS/X is the most proprietary development environment in
mainstream use today.  It is unique in being tied to a single hardware
vendor, and it is unique in having no viable migration path away again
for anyone who wants to take advantage of other platforms in the
future.  The only platform it will ever run on is, and is likely to
remain, a minority one.

In particular, a port to Cocoa would completely rule out any
possibility of ever porting to the world's most popular and successful
operating system platform, i.e. Windows.  (Now I personally don't care
about Windows, but then I don't care about OS/X either: we've had just
as many user requests for a Windows port as we have for OS/X.)  Going
to Cocoa would be switching from a potentially portable implementation
on a niche platform, to a totally non-portable implementation on
another niche platform.  Great move!

I may like Linux now, but I know that if I ever change my mind, I can
take my code with me.  You will never again be able to do that, and
one day you will regret it.

4. It's both a stupid waste of time and a sad division of labour.

In the time it's taken you to develop a program with approximately 0%
of Rosegarden's functionality, we could have ported almost the whole
damn thing to OS/X via Qt4 -- if we'd worked together on it.  Without
your help, that effort is going nowhere.  Without our help, you will
find your Rosegarden on OS/X much harder to complete.


B. Community and Free Software Reasons

5. It would hurt our users and make our support task harder.

Whatever you may like to imagine, we already have thousands of users
on the Linux platform.  Either we tell them to move to OS/X if they
want to continue using Rosegarden (tough on them, and hardly a great
PR move for us) or we continue to support both platforms.  The former
is impractical as well as rude; it's not like we can just make the
existing program disappear.  The only reasonable choice is the latter,
so having the two platforms use totally incompatible codebases and
have dissimilar user interfaces and feature sets would make support
harder, not easier as you suggest.

6. If you can afford OS/X...

OS/X is a proprietary platform that costs money and runs only on
premium equipment.  If you can afford OS/X, you can afford commercial
audio software.  Why should I work hard to provide software for
nothing, to people who have chosen a proprietary platform and so for
whom the only "ideological" attraction of the software is likely to be
the fact that you don't have to pay me for it?

Indeed, arguably you have a responsibility to maintain the viability
of your platform by supporting proprietary software companies, who are
struggling because of piracy and competition from "free stuff".  OS/X
currently manages a somewhat higher payment rate for proprietary
companies than Windows, presumably because the OS/X user has less of
an expectation of "free".  Why encourage that to change?  I personally
don't want to see a world in which Apple and Microsoft make money out
of consumer software while nobody else can.  Come back when you have a
business plan, in other words.

7. You're being too negative about Linux.

I don't really want to waste too much time arguing about the merits of
the platforms.  I have much stronger objections to rewriting using
Cocoa than I do to porting to OS/X, and I don't want to give in to the
lure of mixing up those two things, outside of the personal reasons
section and ideological digression in the previous point.

But I do want to note how ironic it is that you've put up with all
those hopeless Linux distros for so many years, only to get fed up
with it just as most users are finally beginning to settle on a single
distro (Ubuntu) that is actually nice to use.  Also, we do in fact
have a fairly complete plan for successful sound configuration out of
the box in Rosegarden on our wiki -- it's really down to developer
effort.


C. Personal Reasons

8. I don't like OS/X very much.

Because Cocoa code is useless on any other platform than OS/X, I and
other developers would have to run OS/X to work on it.  I don't want
to do that, because I enjoy using Linux more.  OS/X makes me want to
smash the screen in just that bit too often for my liking.

9. It would cost me money.

All my computers run Linux, so I would actually be spending money in
order to replace them so I could work my arse off to provide other
people who have plenty of money (otherwise they wouldn't be using
OS/X) with my software for nothing.  Hooray!

10. It's such an enormous amount of work.

How long has it taken us to get to the point where we have a
Rosegarden that does nearly all of what we wanted it to?  Isn't this a
great time to throw it away and start again?

11. It hurts the project that I care about.

Even if nothing happens with this fork, it has already damaged this
project.  With two reasonably committed experienced part-time
developers (you and me) we could have done some interesting things
over the last few months -- or we could do some during the next few.
We could have made good headway with a port to Qt4 and a portable
audio I/O layer.  We could have applied for Google Summer of Code (in
which I'm actually mentoring for another project this year).  Your
absence makes a big difference.  There's probably a deep question for
the amateur psychologist about whether you were subliminally keen to
get out of this project rather than just into a new one, but I guess I
won't go into that.

There is a fair chance that this fork would attract developers.
People tend to be more excited about starting something new than
finishing it.  If that happens, and the momentum moves away from the
only Rosegarden project I'm ever likely to work on, then I'll be in
the position of having put years of work into something that was then
taken and remoulded in such a way as to exclude me.  That would hurt.

12. It's just stupid.

You want to run Rosegarden on OS/X.  Rosegarden uses Qt3 and KDE3, and
they're getting a bit old.  Qt4 is the logical next step from Qt3.
Qt4 runs on OS/X, gets to keep you on Linux, and gets you Windows as
well.  So, let's update our code to Qt4.  Or... no... hang on, I'm
having a better idea here... we could just REWRITE the WHOLE DAMN
THING in a DIFFERENT LANGUAGE using a DIFFERENT TOOLKIT that DOESN'T
RUN on our EXISTING platform!

I know, that's just a restatement of a couple of those "business
reasons".  It's here in the "personal" list because this is the one
thing that really gets me thinking "but this is SO STUPID!" rather
than just "oh well, whatever".


To summarise: I will not work on a Cocoa version of Rosegarden,
because (a) I think it is rationally a bad idea; (b) I don't want to
waste another six years on another rewrite; (c) the result of the work
would be a net loss for me.

There would be one good reply to all of this: I enjoy doing it, it's
fun, I don't care about reproducing everything that's in Rosegarden, I
just thought I'd make a program that loads some of the same files and
see where it goes.  Like Michael, I could totally understand that.
But that isn't what you're saying, is it?  You're saying that this
would be a good thing for the project as a whole.  You're trying to
rationalise it, and I don't think any of the rational reasons to do
this stand up for a single moment.


Chris

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

Reply via email to