[ale] Strategies for OS code in the Enterprise

[Jeff Hubbs]

I can't really help you with your CVS issue but I've turned your larger
problem around in my head as long ago as 2001.  

Basically, if you decide to go forward with some piece of Open Source
(OS) software - especially one that isn't widely used, as opposed to,
oh, Linux - then you've got a choice.  You can do something like what
you're saying, i.e., fork off the project for your own nefarious
purposes, OR you can delegate some manpower toward basically joining the
cause and horning in on the development of the software itself.

Think of it like this:  if you've got a vested interest in something
like Issue-Tracker, Xsane, or what have you, and if you've got the
talent it takes to dig into and fix code, then you are valuable to the
project, just like it's valuable to you.  

When I was cogitating on these issues, my concern at the time was the
completeness and correctness of scanner drivers within sane.  I decided
that, to the extent that the project I was trying to start would be
interested in using sane drivers for whatever make and model of
industrial scanners we were going to use, we owed it to ourselves and
the rest of the world to dive in and fix any problems we encountered.  

I acknowledged that if there were a pre-existing driver, the original
author(s) would not necessarily have had our motivation or as high a
stake in the behavior and quality of the driver.  There is nothing wrong
with that, I must stress!  That is simple human nature.  

This illustrates that Free Software does not necessarily mean Free
Ride.  You have to care, and you have to be willing to do some work.  

So, I would suggest that instead of treating the Issue-Tracker project
as read-only, join the cause.  Now, you may find that what works best
for you is a split approach in which you submit bugfixes and
new/improved features of general interest back to the project and
reserve significant behavior changes that are specific to your needs for
internal consumption only.  That makes perfect sense and IMH-IANAL-O, is
in keeping with the GPL.  

- Jeff

On Mon, 2003-12-22 at 15:19, John Wells wrote:
> Guys,
> 
> In my relatively new management role, I'm doing my best at every turn to
> leverage the power of open source software.
> 
> I have, however, a problem I've never really faced before.  We're
> implementing a issue tracking package (www.issue-tracker.com) and have
> installed the latest "stable" release.  While testing it, we've run across
> a number of bugs.  We've also installed the latest development version
> from CVS which fixes a lot of the bugs, but introduces a lot more.
> 
> So, what I'm left with is a "fork" of issue-tracker...our locally
> maintained and personally fixed version, and the official tree at
> issue-tracker.com.  For the sake of upgrades and to keep the ability of
> taking advantage of enhancements, I need to come up with a strategy of
> "syncing" the trees upon the next major release.
> 
> While I'm guessing this will simply involve me downloading the release and
> updating our local cvs repos with the latest code (handling any merges by
> hand), the idea isn't necessarily pleasant.  I'm still thinking through
> the issue, but would like to hear other input from you guys...ever faced a
> similar situation?  Did you come up with an ingeniuous solution?  Is there
> a feature of CVS I'm missing that makes this easy?
> 
> Thanks for the input!
> 
> John
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
-- 
Jeff Hubbs <hbbs at comcast.net>