RE: Linux/Mozilla related Short-Term Contract

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Jonathan" == Jonathan Shore <jshore@example.com> writes:

    Jonathan> That's not very constructive.

True.  But then, this isn't sourceXchange.  (Have you considered that?
Also Cosource.COM.)

    Jonathan> I can't wait for the respective open-source projects to
    Jonathan> provide exactly what I need,

I don't think anybody, not even wileyc or rms, contests that.

    Jonathan> nor am I requesting that the proposed work be folded
    Jonathan> back into any public distribution.

But all of us would have to take issue with this statement.  That is
_exactly_ what you should be aiming at.  Of course, you have a
business to run, but how expensive would it be to

    (1) add the condition that the changes be submitted to the
        relevant project for _consideration_ for integration;
    (2) specify that as much as possible the additions will be done
        based on a _stock_ binary, only changes to configuration files
	and plug-ins; where possible as a "skin" or "theme";
    (3) provide Web space for distribution of the above, and request
        the upstream organization to post a courtesy link if they do
        not decide to integrate the changes?

One could argue that if you plan to update the package as Mozilla
continues to develop, (2) will come at _negative_ cost because you
only have to worry about API changes, and not internals as well.  (Not
that API changes are likely to be trivial, despite what they say on
mozilla.org.)

    Jonathan> Which reminds me: why is it so *damn* hard to get some
    Jonathan> things working on Linux -- there is so much chaos.

Dancing bear, you know.

    Jonathan> Frankly, multimedia capabilities on linux are still
    Jonathan> quite primitive and fragmented functionality-wise IMHO.

Bitflicking always comes high, and the hardware people are slow to get
the concept of "open".

    Jonathan> I'll do my part to strengthen this in time (will be
    Jonathan> starting an open-source project related to some
    Jonathan> multimedia capabilities soon).  In the mean time I'll
    Jonathan> accomplish objectives with a more expedient approach.

Don't forget sourceXchange and Cosource.  Even if you decide not to
use them, they can help as examples for writing specs and contracts.
(Not that your spec had problems that I can see, still, seeing how
somebody who specializes in these things does it can't hurt.)

    Jonathan> So please lend something constructive next time.

I thought that was a bid.  Eh, Chris?  If he does (1), (2), and (3),
and you can subcontract the distasteful parts (ie, building---bletch---
RPMs), what would you say.  ;-)  Oops, I see I'm wrong.  :-( Before
you ask, nope, I won't touch this one either.  (I may be around for
the input manager stuff, though.  Hmm....)

More seriously, I think he was referring to the Japanese parts.  I've
already seen Japmogrifications to GTK+ (mostly backed out).  But it's
always a battle to get Japan localization done in a fashion that is
acceptable to Japanese programmers and upstream maintainers both.

Watch out for that; word your contract carefully with respect to
future upgrades to the stuff you are funding, or you may find yourself
stuck with M17 indefinitely.  Ask anybody who's still using Pine 3.9x.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."