From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,88ed72d98e6b3457 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-27 09:52:06 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!wn14feed!worldnet.att.net!207.35.177.252!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Standard Library Interest? References: <6Ingb.30667$541.13861@nwrdny02.gnilink.net> <3F82B4A4.5060301@noplace.com> <3F82F527.3020101@noplace.com> <3F846B5E.9080502@comcast.net> <3F855460.6020804@noplace.com> <3F86211B.103@comcast.net> <3F8640CA.6090306@noplace.com> <3F881515.4060305@noplace.com> <6lijb.140205$%h1.139381@sccrnsc02> <3F8E9531.9040209@noplace.com> <3F8EDB1A.1010007@noplace.com> <3F914520.9080906@noplace.com> <8Pdlb.4756$7t3.157424@news20.bellglobal.com> <3F96803B.8010308@noplace.com> <3F976548.6030107@noplace.com> In-Reply-To: <3F976548.6030107@noplace.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <2Jcnb.640$9j3.136189@news20.bellglobal.com> Date: Mon, 27 Oct 2003 12:37:31 -0500 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1067276222 198.96.223.163 (Mon, 27 Oct 2003 12:37:02 EST) NNTP-Posting-Date: Mon, 27 Oct 2003 12:37:02 EST Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:1742 Date: 2003-10-27T12:37:31-05:00 List-Id: Marin David Condic wrote: > O.K. I'm not dismissing an Open Source route, and I'm not dismissing an > all-volunteer, unpaid, organically grown route either. What I *am* > dismissing is the idea that we can somehow survey all the Ada users out > there But you don't need _all_. Vendors won't get all users input either. > and come up with a coherent set of requirements on which to base > it. This is not unachievable either. Pleasing everyone is unachievable, but surely some sort of compromise can be reached. > I'm dismissing the notion that once implemented, all those Ada users > are then going to drop what they *are* using in favor of the library put > out there. Yes, but so what? This is totally irrelevant, IMO. > I'm further dismissing the idea that the vendors will then > see the light and get on board and start distributing it. Now there's a point. I don't believe it, but you obviously do. Maybe you're even right about this, but because this is not carved in stone, I don't see it as a reason to pause. > We've been down a route that was some version of "Lets get everyone's > consensus on what they want and then try to come up with something that > will be adopted by all..." Its been tried more than once. I've seen the same process worked through major corporations. If you insist that _all_ interested parties agree on a set of requirements, the project is then almost doomed to failure. One way to get a better concensus is to form smaller teams. Solicit input from the entire community, yes. But at the project level, only allow the contributors to the project deem what is going to be accepted, or not, or to require more R&D. You must eliminate those that only raise obsticals, from holding the progress of the project up. Sadly, many IT people are good at raising issues/problems, but few are willing to make good suggestions (and even fewer, to contribute to those suggestions). So I would suggest, those that are not contributing, do not have a direct say in the project (again, input is OK, but they do not hold things back). > There is no > standard library being shipped by vendors as a result of that. Well, I don't think it is quite that simple. One firm is not going to develop and ship a toolset, if another is going to develop and ship a different set. So in the end, nobody does. There are probably a number of other reasons as well. > That's > why I'm saying lets try a *different* route Agreed. > - one that would be to get > the *vendors* to act as "Customer Representatives" and stipulate what it > is they want to see done. (Think of it as a Republic rather than a > Democracy) The vendors are in a good position to know what sort of > requirements their customers might have and - rather than try to get a > consensus from a few thousand users - you get it from a handful of > representatives. I'm not against this, but only skeptical of it. ;-) > Given that you might get requirements from the vendors as customer > representatives, one would presume that they would bundle it and ship it > to their customers once built. But how are you going to get the vendors to make it a priority, and work together with other vendors? > That's where I see the critical difference and where it is that we > apparently disagree - you want to start with a few hundred or more > requirements writers and hope that consensus across a few thousand (or > more) users is going to result, thus bringing the vendors on board. I > want to start with 2, 3, 4 vendors and let them bring the customers/end > users on board. Your approach has been tried a number of times and not > resulted in much. Mine has yet to be tried and may fail for a whole > different batch of reasons - but they will be *different*. :-) > > MDC I am not convinced (yet) that all has been tried on the volunteer side. You might be right in saying there is not enough volunteer resources (Ada-wise) and you might be right in saying we can't reach a concensus. But I am not convinced that it otherwise that it could not work. 8-) I do applaud your efforts for trying to get something to happen. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg