Date: Sat, 15 May 1999 16:42:52 -0700 From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com> To: Studded <Studded@gorean.org> Cc: chat@FreeBSD.ORG, davids@webmaster.com Subject: Re: cvs commit: src/sys/pci pcisupport.c Message-ID: <64137.926811772@zippy.cdrom.com> In-Reply-To: Your message of "Sat, 15 May 1999 10:24:26 PDT." <373DADCA.F6C2A2A0@gorean.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> we tried. My point is that you can't have it both ways. You can't say > "FreeBSD is a valid solution for the real world demands of commercial use" > and at the same time say "but we have no responsibility to actually respond > to real world needs." Sorry to disappoint you, but that's exactly what we have. You're falling into the same trap as the others again - you're looking at a free software product as somehow equivalent to commercial OSes in every respect and of course that's not the case. Just because FreeBSD is a "valid solution for the real world demands of yadda yadda" (and it is) doesn't make it an *equivalent* solution to a fully commercial product and you need to understand and appreciate the limitations of having an all-volunteer crew when you sign on. FreeBSD is at the stage where its very professionalism becomes something of a liability in this respect, our simulation of commercial OS development being close enough that many people have begun to perceive us as playing in the same pool as Solaris or SCO in every respect. This is not the case, and it's not a question of technical merit, speedy response to users questions, comparative bug counts or any of the things that engineers measure when they're assessing the worthiness of a commercial OS solution, it's a question of predictability. I cannot predict to a "customer" just when feature X is going to make it in or if the 3 developers currently working on it will remain there and not go onto something else, or even if feature X will remain a priority for the project at large. In a commercial OS, the marketing department sets the objectives and lots of engineers are paid to fulfill them - whether they're the right objectives or not, or whether the engineers actually succeed is almost immaterial. What's important is that the company in question can tell its customers that a committment to feature X exists and is part of the operating system's road map. I, on the other hand, can make vague hand-waving motions about how someone MIGHT be working on this and it MIGHT become a feature that's actually usable, but there's no predictability at all. What you're buying for your money is predictability, not quality, not even assurances that you'll make it, simply the ability to say that work is being done in a "serious" manner. To put it another way, when people ask me what new features will be in FreeBSD over the next 12 months, I have to shrug my shoulders and say "how the hell should I know?" This also comes as quite a shock to folks who think I'm somehow supposed to know these things or that it's even possible to know. When you have a set of developers who fade in and out at random intervals or who accomplish sudden, superhuman feats of programming and move long-stalled projects forward by months in just a few days, you can't predict a thing. I also used the plan out all the things that "would be really nice" at the beginning of the year and post this as a roadmap, but these roadmaps turned into liabilities once I found out how few of the items on it got done at the end of the year and that users expected ALL of those items to have been done, treating the roadmap as more of a committment, and got very pissy about it when only some of the "promises" were fulfilled. It doesn't matter how many disclaimers you slap on it either, people expect us to fulfill our mission statements just like the commercial organizations do. > As for your other argument INRE "that's a good idea but we have no one to > do it," that's a copout, plain and simple. If the project had adopted a No, it's the truth, plain and simple. Where are your contributions? If you want more predictability and scheduling, then be a part of the solution rather than part of the problem. I just see a lot of vague, pointless bitching here and I honestly don't see anything more than that. - Jordan 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?64137.926811772>