[ale] Strategies for OS code in the Enterprise

[Greg]

Very well written and a commendable attitude.

Greg

> -----Original Message-----
> From: ale-bounces at ale.org [mailto:ale-bounces at ale.org]On Behalf Of Jeff
> Hubbs
> Sent: Monday, December 22, 2003 10:33 PM
> To: Atlanta Linux Enthusiasts
> Subject: Re: [ale] Strategies for OS code in the Enterprise
>
>
> 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>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
>