Re: ticket tracking (off-topic reply)

[Avleen Vig <lists-nanog () silverwraith com>]

On Mon, 8 Jul 2002, gg wrote:

>     I am just writing to just voice a suggestion, not looking for an
> argument or make it sound like a negative critique.  You should re-consider
> your choices for not providing the Source-Code, as not one single individual
> posseses all of the intuition or capabilities in this world.  This is why
> Open-Source is a great thing, individuals begin to take an active step in
> the development process.  What might be a good application can be developed
> into an awesome application.  I am a true and firm believer in open source,
> and although I do not expect everyone in this world to agree with this set
> mentality, I always try to at least share my view.

A discussion is the exchange of knowledge. And arguement is the exchange
of ignorance. Let's discuss.
I suppose I could release the source code. It wouldn't do any harm,
especially if it would help others.
I too believe that Open Source has it's benefits, but I'm firmly against
the believe that everything should be open sourced (as some believe).

And while I'd normally accept that it's a good things for many people to
get together to make a good application great, and a great application
amazing, sometimes having an amazing application isn't the point.
When I wrote my little ticket tracker (which *isn't* great) I wanted only
a few things from it; I needed to be able to track incoming bugs and
comments on those tickets. Maybe some email functions too. That's all.
I don't want it to do *ANYTHING* else and I don't see why it should. I
want it to do only what I need and nothing else. Others are free to do
most of what they like with their programs, but OS isn't the best solution
every time.
That's the original point behind my statement. While OS is a good thing,
it's not always the best thing. Sometimes you just want an application to
do a few specific things and nothing more at all, ever.
Some will understand that, some won't.

>     Ticketing, Inventory, and Monitoring, tasks almost every individual that
> subscribes to this list on a daily basis interacts with via applications,
> logfiles, etc.  Add to this all the data that these tasks compile for the
> administrator's through logs, and finally the archiving of this compiled
> data, and you will see that analyzing and tracking become a major task.

Again, it depends on *your* requirements. Heh, mine was "track the slow
inflow of bugs for the IRC daemon and related services". All I needed to
do was have a web form that could take input, add comments and that's it.
No analyzing, no compiling, just logging and tracking one issue at a time.

> It is not bad to attempt to encourage individuals to learn how
> to build their own applications, srcipts, programs, etc., and if this is
> your goal, then in my opinion you are not helping but hurting those that
> choose to develop.

Partial agreement on this point. Sometimes I find it helpful to look at
other code. Sometimes I find that looking at other code stifles my
creative process and I just end up copying someone else's work. I don't
like it when the latter happens, so I encourage others to do things for
themselves as much as possible and only provide hints to answers rather
than stepping stones to answers.

>     We do not all share the same level of knowledge, and sometimes it is
> more helpfull to show those interested or in learning stages (I am
> permanently stuck in this one) how the clock actually works, instead of
> telling us about the clock but then deny us the marvelous thing it is.

And sometimes it's good for people to just pick up a book and spend a few
days (or weeks) reading and learning, rather than just expecting the
answer on a plate. You'll only have to do that once or twice. Spend some
time and do it right.
I could tell you that a clock uses cogs, springs, arms, pendulms, etc, or
I could say "I have a requirement for a device to measure time. Go make me
one". The latter is much more likely to make you research things for
yourself and to maybe even come up with a novel way to measure time. What
would you gain from learning exactly how a clock works, if all you want to
do is make a better clock?
A better approach would be to analyze the problems you're tackling and
solve those.

>     If you want to encourage us (us is an everyone else in this world) to
> write it ourselves, then you will accomplish this task far easier by
> sharing.  In doing so you will; 1. Inspire some to add new things; 2.
> Educate others on how you did it;   3. Expose your application to endless
> possabilities; 4. Benefit us all!
>     Remmember; sharing is teahing, and teaching is learning.

But you missed the point (which I explained better this time around).
I don't want my application expanded, improved, imprised, etc.
It's perfect just as it is. When a new requirement comes up for me, *then*
i'll add to it, but that's all.

Oh and you're badly mistakign two different kinds of learning.
On the one hand it you're learning about a static system that doesn't
change (eg, a law of physics[1]) then sure it's good to learn and share as
much as possible.
On the other hand if you're talking about design and inspiration, well
that comes from within and is something that you need to work on based on
your own requirements, not someone else's.

Sharing is good, but sharing everythigng is bad (your audience won't learn
anything new themselves).


[1] maybe a bad example. the laws themselves don't 'change', we just
adjust them according to observations and experiementation.