Date: Thu, 13 May 1999 11:16:22 -0700 From: "David Schwartz" <davids@webmaster.com> To: "Chuck Robey" <chuckr@picnic.mat.net> Cc: <chat@FreeBSD.ORG> Subject: RE: cvs commit: src/sys/pci pcisupport.c Message-ID: <000a01be9d6c$b4dffec0$021d85d1@whenever.youwant.to> In-Reply-To: <Pine.BSF.4.10.9905130652150.401-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> OK. Much of what I'm going to say here is pure opinion, understand; I > don't hold it forth as fact (like I did the top paragraph). The > situation that I *think* you want, where the users do the controlling, > doesn't now and never did exist. I've worked for enough companies to > know that you code for your boss, not the public, and what the boss > wants very often has nearly nothing at all to do with that which the > public is clamoring for. There are isolated cases where the connection > between want and need is closer, but it's not the rule. > > My, that sound cynical. No, it sounds silly. In an organized project, someone makes the decision about which ideas turn into code and which don't. The extent to which that decision is or is not distributed varies. Almost always some such capacity remains with the programmers. There are many ways and reasons a project can fail. Code dictates that have little to do with 'customer' demand is a common one. But it's just as possible to fail because programmers code things that customers don't demand. The big issue is, when you are dealing with a non-commercial project, what is your definition of 'fail'? DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000a01be9d6c$b4dffec0$021d85d1>