Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!samsung!sdd.hp.com!mips!darwin.sura.net!jvnc.net!nuscc!ntuix!eoahmad From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) Newsgroups: comp.unix.bsd Subject: Honesty with 386BSD 0.1 Message-ID: <1992Jun24.025455.3548@ntuix.ntu.ac.sg> Date: 24 Jun 92 02:54:55 GMT Organization: Nanyang Technological University - Singapore Lines: 107 This posting is meant for William Jolitz or anyone intimately involved with beta testing 0.1 386BSD. First I would like to apologize if I may make any uncalled for remarks. My intention is to gather discussion on the best methods of releasing new versions. This problem occurs even in commercial packages which are distributed in binary form. 386BSD creates more opportunities (problems) because it is also distributed in source form. Maybe a more honest admission is that I am under stress waiting for something. Stress is not bad for our health. It is just that without a debugger I feel helpless. The debugging time would be more if I simply use printf statements. I dare not embark on a major project without having a debugger. Although I have other options like MSDOS which has even better debuggers(user friendly), I prefer to stick to a more lasting standard (BSD Unix!). I think the intention of William Jolitz is to release 0.1 only when there are almost no obvious bugs. As my colleague says 90% of time in software development is in the last 10% of the code. This is nobel but faulty in the point of view of marketing success. Let me state my opinions first: 1)we can release a product even if there are problems with it. 2)we must set a deadline for the release of a product(firm and honest) 3)the best way to get feedback about a product is from customers/users 4)we must announce new products/improvements frequently I think the Japanese apply all 4 methods. Some companies just apply a subset of the above method. Let me explain in context with 386BSD. 1) Let us face the fact that a product is never perfect. Even in an unlikely scenerio that all bugs are fixed, there are still urges to incorporate new features. Customers also tend to expect that anything new will create new problems. Some companies think that a get an almost perfect product to market is the ultimate aim but it does not ensure a success. Case of MSDOS. Everyone knows that MSDOS 1.0 was too buggy and inadequate and yet it was released by IBM. At least MSDOS 1.0 allows basic programs to run, such as Wordstar, Dbase II etc, at least for the majority of users. 2) If we accept 1, then it would be easy to accept 2. Honesty is very important. Unkept promises creates problems to customers because it upsets their plans. If Microsoft does not release MSDOS 1.0 at the same time as IBM PC XT, the IBM would suffer a lot of losses. The danger is that the product could be dangerous. But all software come with disclaimers. Hardware products must look out for safety portions. The structure design must be solid but it is easy to test it, just subject it to stresses just as crashing the car e.g. For software , just run a typical application. I think for an operating system, the ability to compile a C compiler e.g. is the safety portion. For 386BSD, it is less critical because it is free and comes with sources. It does not have any commitment at all. However DDJ magazine published an article that 386BSD would be released in July without any date though. Who knows 0.1 would be release now. Howeve this article still needs discussion especially for future releases. 3) No matter how much tests we have carried out, we would never know which is more important. The customers may be even better than the original designers in putting the product to good use, bugs or no bugs. In fact few customers trust manufacturers specs 100%. They tend to bend it to suit their needs. In the case of 386BSD, the designer may think that some bugs must be cleared before release but a lot of customers may not bother at all because it does not affect their operations. The customers may even offer their own bug fixes. This occurs even in hardware products. Customers regularly request changes to design to correct flaws because the customers are experts in their specialised areas. In 386BSD, William may be expert in porting designs but he may not be good in debugging support(just an example). Some users are even better than Bill in this area. He may as well learn from him. If 386BSD is not released, how would the customer correct it? 4) Everyone knows that new versions are inevitable. But the success of an enterprise depends on the frequency of this versions. Just look at the Leyland Mini. It is the longes lasting model in the world because probably the design is perfect, but it does not make as much money as a toyota corolla that has changed faces so much. In fact toyota corolla changes face every six months. The same with their video recorders. The frequency depends on the product. For 386BSD I recommend every month. Just throw out the old versions if there is not enough space. If the bug fixes which comes cannot be incorporated in that particular month, just release whatever fixes that had been incorporated. If new features are added and yet not fully functional, just include it, because the customers may contribute in correcting it. I think there is not much problem in copying files to agate.berkeley. There may be valid reasons for delaying the release of new versions of 386BSD which I am not aware like politics but I think by letting out the problems, the customers may contribute towards helping it. For example, if UCB refuces disk space someone else can take over and look for someone who can take over. If UCB refuces to release more codes, customers can lobby UCB into doing so. I hope this article would generate discussions or more new ideas. I dont mind being flamed as long as the reasons are correct and sources of facts pointed out clearly to me so that I can double check. Othman bin Ahmad, School of EEE, Nanyang Technological University, Singapore 2263. Internet Email: eoahmad@ntuix.ntu.ac.sg Bitnet Email: eoahmad@ntuvax.bitnet