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.

I have had a great experience with an extremely funny sounding product. Double Choco Latte is one of the better (I won't say best, they all have strong and weak points.) ticketing systems out there. Once the new code is finished with the contact management, it will be 10x better. Derek -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Daniel Golding Sent: Thursday, August 08, 2002 11:28 AM To: Scott Granados; nanog@merit.edu Subject: RE: ticket tracking I strongly recommend RT, which has the advantage of being both Open Source, and having several available support options. - Dan

-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Scott Granados Sent: Thursday, August 08, 2002 12:02 AM To: nanog@merit.edu Subject: ticket tracking

While we're talking about change management...

What are people using for ticket tracking for support issues. Is it all remedy or what do people like to use.

Feel free to answer off list:).

Scott