> > You don't have the time to learn a little simple perl and SQL?
>
> I think you are over simplifying. It takes a little more than some
> "simple" "simple" perl and SQL to do the tasks. For one I would have to
> understand what I was trying to do, where place the program, how to
> interface with the OpenSRS software client. It would take at least some
> basic knowledge of Apache, DNS, some programming experience (people just
> don't wake up and start programming ... there is *some* skill required to
> program) I would also need a little skill on how to debug perl programs, or
> learn on the job.
>
> So I will agree it is not a very difficult task for someone with some
> experience in programming, some sql experience, some apache experience,
> some dns experience ;) Basically someone with your technical background and
> skill might take all that for granted.
>
David, you've made some very valid points, and I can understand your
position, but I've been ploughing through your messages this morning (for
that is what is in Ireland), and you're simply not making sense.
You've contradticted yourself several times in your last three or four
posting. By your own admission, here and in at least one other posting, you
admit that you don't have the technical know-how to implement these value-
added services, which, as William pointed out, OpenSRS have thus far being
telling us is how to compete. Yet you tell us in other postings that by
implementing these value adds, you will have more time to spend on marketing,
selling and supporting them. But how can you market, sell, or more
importantly SUPPORT something you simply don't understand?
This is like RSP's who continue to work solely on the OpenSRS UI, because
they're too lazy to install the scripts on their server. Even I don't have a
world-available UI, but at least I took the time to install the UI on my
server for my own use. These people shouldn't be allowed use the RSP system.
I'm not saying you're doing this, I'm saying that people probably are, and
they're the people who'll use the value-adds to compete with people who are
much more deserving - people who have put time and effort into developing
their own value-add's, and UNDERSTAND them, and so can SUPPORT them.
But this brew-ha-ha is turning into a "you're wrong and I'm right" argument,
which is achieving nothing, aside from filling up my Inbox with the same
arguments over and over again. Whether you can or can't support the value-
adds is in essence unimportant, and I was only stating the above to make a
point. The simple truth is that this is once again plainly and simply an
economic matter. OpenSRS may or may not implement these value-adds. You may
or may not be able to support them. But I don't care about either - I want to
know what the long-term effects will be on ME if they're implemented. Will
the SRS turn into a McDonalds franchise farce, or will it add value to MY
business? THAT is the question we should all be asking ourselves.
Which I think is the point William is trying to make. I don't think William
is necessarily going about proving his point the right way (sorry William,
but you're pretty much ranting and repeating yourself at this stage, and it's
not helping), but I agree with the sentiment. There's a risk that
implementing this will turn the SRS into a farce.
A RISK. It's up to OpenSRS to evaluate that risk, and decide if it's worth
taking. And given OpenSRS's past history, I would presume, nay hope, that
they'll give a large consideration to what the RSP's think, and the quality
of those RSP's, and not just how their revenues will be affected. The RSP's
are their lifeblood, it just remains to be seen if they are willing to deal
with script kiddies, incompetents and unethical operators, or continue
dealing with reasonably intelligent, ethical ones. By creating barriers of
entry if they do implement value-adds, it might be to everyone's benefit.
Again, it's the support, QoS, and availability of OpenSRS staff - including
management - that defines OpenSRS as someone I want to do business with. If
we start seeing mini-RCOM's on the list, I would have to rethink that
position. This to me is the second most important factor.
adam
