Well at least you didn't send this one in caps! :-)
I apologize for the delay, but I did not want to respond until I could
do so with some level of specificity. That required me to co-ordinate
with numerous people inside the organization (or do the CEO on the IBM
commercial thing and say "next week" and watch everyone run around).
I will not repeat that I am disappointed with our handling of this issue
(uh, I guess I just did). I will commit to three things:
- there will be new client code by the middle of September
- it will be upgradable such that it will not require breaking scripts
to install a new version and
- it WILL be platform agnostic.
To say anything more would be to try and excuse or explain, neither of
which is relevant. Once again, sorry.
I will have someone contact you directly on your specific issue.
Regards
Robert Macleod wrote:
> Hi Elliot,
>
> Are you now able to share the plans for the client code with us ?
>
> I have just tried to install the latest client (2.8.3.2) and having
> struggled to get it working resorted to the manual :-)
>
> It is bad enough that there is are only detailed installation
> instructions for the Linux/Unix platform but I was deeply disappointed
> to find that the entire coverage for the Windows platform is the
> paragraph below:-
>
> "The client library has not been specifically tested on the Windows
> platform. Some have noted problems compiling the ciphers. If you are
> unable to compile Crypt::DES or Crypt::Blowfish, try Crypt::Blowfish_PP
> (an implementation written in Pure Perl). While slower than the standard
> Crypt::Blowfish module, Crypt::Blowfish_PP requires no compilation."
>
> I though that the client code was meant to be platform agnostic but the
> required modules for HTTPS do not appear to be available for the Windows
> platform.
>
> I was bad enough before that the client had stagnated but it now appears
> to be moving backwards at least for resellers on the Windows platform.
>
> These issues impact my business and make it more and more difficult for
> me to justify continuing to stay with OpenSRS.
>
> Regards
> Rob
>
>
> -----Original Message-----
> From: owner-discuss-list@opensrs.org
> [mailto:owner-discuss-list@opensrs.org] On Behalf Of Elliot Noss
> Sent: 07 April 2004 12:12
> To: Robert Macleod; elliot noss; Todd Jagger
> Cc: discuss-list@opensrs.org
> Subject: Re: Managed DNS Service concerns (tangent)
>
> Yes and no. The issue here is one of form not substance.
> There are two things.
>
> The first is a simple HR issue. We have recently added a new fellow, Lee
> Garrison, as VP, Products (separately, we are very excited about Lee
> joining us. He brings a bit of a different skill set than we have had in
> the past). The client code migration path, and communicating it, falls
> into his area of responsibility. He just started on Monday and
> understands quite well that this is on his plate for quick turnaround.
>
> The second is how much or how little to communicate. Do we talk about
> what we are planning to do next week or next year? My preference is
> always to give you guys as much visibility as possible, but the longer
> the time horizon the bigger and more complicated the communication
> becomes.
>
> A lot of work has been done on this issue internally. It is just not yet
> visible.
>
> I don't want to commit Lee to a date on his third day in the office, but
> it will be soon. Robert, if there is a specific issue that you are
> wrestling with please speak to your rep or let me know offlist and we
> will see if we can get you the info you need to make a decision, or the
> resources to help you with something.
>
> I know this is not the answer you were looking for, but I hope it helps.
>
> Regards
>
> On Wed, 7 Apr 2004 07:05:10 +0100
> "Robert Macleod" <robert.macleod@natweb.net> wrote:
>
>>Hi Elliot,
>>
>>Are you now able to share the plans for the client code with us ?
>>
>>Regards
>>Rob
>>
>>-----Original Message-----
>>From: owner-discuss-list@opensrs.org
>>[mailto:owner-discuss-list@opensrs.org] On Behalf Of elliot noss
>>Sent: 05 February 2004 22:26
>>To: Todd Jagger
>>Cc: discuss-list@opensrs.org
>>Subject: Re: Managed DNS Service concerns (tangent)
>>
>>Ok. Time permits.
>>
>>First, I want to talk briefly about client code and RWI.
>>We are, I am,
>>in complete agreement with the comments made. The one thing that I want
>
>
>>to make sure is clear is that these items are not being ignored. We
>>have spent lots of time and lots of money (little of it well) on these
>>two issues. In any organization some things go well and others go, um,
>>less well. These two are right at the bottom of my personal list. There
>
>
>>have been too many statements unfulfilled on these two items and I do
>>not want to add to the list. I will say folks are working on these
>>things and, especially with client code, I will be unhappy if you do
>>not see a clear plan shortly (within a month?).
>>
>>Next, with regard to the level of new services. I personally do not
>>agree with the comments below in a couple of ways. When OpenSRS was
>>first introduced it was (quite good) beta code. The original designer
>>chosen did nothing but make pretty pictures for a few months and we had
>
>
>>to switch all of our plans. We had signed contracts and we had a market
>
>
>>moving at a million miles an hour. We pushed this baby bird out of its
>>nest quite early.
>>
>>The point of all that is that the level of new services launched today
>>is miles ahead of when we first released OpenSRS and 100's of yards
>>ahead of where the first certs release was. IMHO, each release of a new
>
>
>>service is a little better than the previous.
>>
>>And SO WHAT. None of that matters, because if there is one lesson we
>>have learned and learned well is that we will always learn more in the
>>first six months being in the market than we ever will just talking
>>with customers and whoever for whatever length of time. If you would
>>rather someone else sand off the rough edges so be it. I would suggest
>>that offering a service early provides two HUGE advantages for you.
>>First, it allows you to participate meaningfully in the evolution of
>>the service.
>>Second, it allows you to learn how to market the service.
>>IMHO, there is
>>much more impact today in the way a service is marketed (and by this I
>>mean all elements, bundling, pricing, packaging, not just where you
>>stick the link or what keyword you buy) than in its features.
>>
>>As for your input, there is an extremely high level of involvement with
>
>
>>customers at all stages of planning and design. Don't believe me? Speak
>
>
>>to your rep and ask to get involved. Anyone willing to be demanding is
>>welcome. Many, many of you have participated in surveys, in placeware
>>sessions, in one-on-one conversations with product management and sales
>
>
>>and in the NSE program. Again, this pales in comparison, no matter how
>>well done, no matter how much done, to being in the market.
>>
>>Lastly, wrt the comment about the process being used in the development
>
>
>>of blogware vs the development of dns, there are some important
>>contextual differences. They are not what I want to comment on though.
>>Rather I want to highlight that we are learning not only about each new
>
>
>>service, but also about the process of developing new services in
>>general.
>>
>>Each time we do it we try and do it a little better. We hope to learn a
>
>
>>little more from each introduction. The approach we took with blogware
>>was much different. Your feedback there is helpful. We will try and
>>take the best of each process and leave the worst. It will never be
>>perfect, but our goal is that it just always be a little bit better.
>>
>>Be assured, with every thing we do your feedback is what drives it.
>>When it doesn't seem that way please remind yourself that you all
>>provide feedback in a number of different ways, meaning no one of you
>>hears it all, and listening to everyone will NEVER mean pleasing
>>everyone. By definition.
>>
>>Thanks for this. It is a great post.
>>
>>Regards
>>
>>Todd Jagger wrote:
>>
>>
>>>Hello,
>>>
>>>Pardon me for inserting this extrapolated tangent into this thread,
>>>however Rob's statements I think deserve some (more) discussion here
>>>as they pertain not only to the DNS service but other Tucows products
>>
>>as well.
>>
>>>Let me preface by saying each of us has a different business model,
>>>needs, goals, customers, etc. What may be critical to one may be
>>>unimportant, or even undesired, by another, and vice versa. Tucows
>>>can't be everything to everybody and they have a significant challenge
>>
>>>in trying to tailor their offerings and services to a vastly diverse
>
>
>>>customer base. While any endeavor has room for improvement I think
>>>overall Tucows has done an exceptional job and, above all, stayed
>>>consistent with high standards of ethics and
>>>professionalism. In
>>>addition they overall seem sincerely interested in what we want.
>>>Sometimes they also appear to ignore what we tell them, but at least
>
>
>>>they're listening. ;-)
>>>
>>>Whether or not Tucows offers X service or Y product is not the topic
>
>
>>>here. Tucows is going to offer the products and services they
>>>determine; that is their prerogative, just as ours is whether or not
>>>to resell that service or product, or to do business with Tucows at
>>
>>all.
>>
>>>What concerns me is the development these products are given and the
>
>
>>>level at which they are offered. It seems in each case we're given
>>>something one or two notches shy of a kick-ass product, and that
>>>directly impacts our abilities to sell them to our customers.
>>>
>>>To use Rob's example, the DNS service without the ability to
>>>configure
>>
>>TTL.
>>
>>>And the apparent stagnation of the client code interface
>>>and RWI. We
>>
>>>resellers have been bemoaning the state of the client code and RWI
>>>usability for literally years. The latest word is that new client
>>>code is important and probably 6+ months down the road.
>>>I remember
>>>that same "official word" perhaps 2 years ago, back when the SF
>>>client
>>
>>>was the model on which the client code was to be built.
>>>Specific bugs
>>
>>>and suggestions have gone unimplemented. (Does the client code
>>>currently require a payment method - e.g. credit card input - for
>>>renewals? This was the first reason I went to the SF code. We don't
>
>
>>>want to keep numbers on file, customers' credit cards expire or they
>>>change cards or addresses; what is Tucows's model for getting payment
>
>
>>>on renewals? None apparently from the client code.)
>>>
>>>The email product has the potential to be a great outsourced service
>
>
>>>for those of us that offering fits our needs (mine does), and while
>>>some of the product are excellent, it falls short of being superior on
>>
>>>multiple levels. The new feature additions are an improvement but
>>>don't quite take it to the A list. The webmail interface is still
>>>clunky, even compared to something like Squirrelmail, and doesn't even
>>
>>>come close to the web interface of Cyrusoft's SilkyMail.
>>>And besides,
>>
>>>how many people want to use webmail for their primary mail client?
>>>Not many I know. My clients want the features to be usable from
>>>their
>>
>>>email client, and the webmail is something to use when they're not at
>>
>>their computer.
>>
>>>Features like the shared address books are great but aren't going to
>
>
>>>mean anything to my customers unless they can share them from a mail
>>>client. There's no mention of the protocol (is it LDAP?
>>>ISMP? ACAP?
>>>or something proprietary from Stalker?) There are many other issues,
>
>
>>>some of which I've raised, and Bruce & Peter, you know how to reach
>>
>>me.
>>
>>>:-)
>>>
>>>The point here is that with core reseller products it seems we're
>>
>>given
>>
>>>a less than complete, and thus less than competitive,
>>>solution. It
>>>almost seems that the products (at least the Email and Managed DNS)
>>>were determined prior to extensive discussion about what resellers
>>>needed/wanted in the offering, and now that the products are out there
>>
>>>it might be difficult or impossible to mold them to what our
>>>customers
>>
>>>need. This leaves us in a difficult position of either offering
>>>something we're not excited about, or not offering it at all.
>>>
>>>This is in stark contrast to what's going on with the Blogware
>>>development. That product is being tested, hammered on, Bugzilla'ed,
>
>
>>>discussed in detail, and most importantly modified to what the
>>>resellers want. I'm convinced it's going to be, already is really, a
>
>
>>>top-notch product that's ahead of the curve, not behind it like Email,
>>
>>>Managed DNS, client code, RWI.
>>>
>>>IMHO, I'd really like to see Tucows re-tool the quality of the
>>
>>products
>>
>>>in the same spirit they're developing Blogware.
>>> Remember guys, this
>>
>>is
>>
>>>technology --- you don't want to be playing catch-up.
>>>
>>>Thanks for listening
>>>tj
>>
>>
>>--
>>Elliot Noss
>>Tucows Inc.
>>416-538-5494
>>enoss.blogware.com
>>
>
>
-- Elliot Noss Tucows Inc. 416-538-5494 enoss.blogware.com
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:37:58 EDT