Date: Mon, 2 Nov 1998 20:09:35 -0600 (CST) From: <snowfox@Mcs.Net> To: freebsd-chat@FreeBSD.ORG Subject: An Explosion at the Bazaar Message-ID: <199811030209.UAA06560@Mars.mcs.net>
next in thread | raw e-mail | index | archive | help
An Explosion at the Bazaar I've thought of writing a series of documents along these lines for some time, and today's Halloween document made me itch. I saw a lot of my own ideas in this document and its thoughtful analysis, and new ones exploded within me. A hefty thank-you to Microsoft(?) and everyone who had something to say about the document. I'd be interested in knowing whether others share an interest in this type of analysis and proposal. Given some feedback, I plan to edit the following document and find a home for it on the web, possibly splitting it into three more documents and creating a discussion board for each. Other needful topics I'd like to give voice to are: OSS implementation of open protocols for closed systems Visual system and deployment diagramming (UML) The discussion, advancement and enhanced visibility of mature software development methodologies C++ migration and component interfacing The ongoing application of use cases and use studies against a broader market An active, unified PR unit A developer support unit targeting hopeful new programmers A graphical design unit Programmer- and artist-target PR and recruiting units A non-monetary reward (recognition) program The first, rough draft then - An Explosion at the Bazaar - Are We Ready? Open Source Software is at a critical juncture. Various OSS UNIX flavors are gaining greater visibility every day. Intel, Oracle, Sun, Silicon Graphics, all the major players are buying into the OSS development model. RedHat stands ready to break new ground, not only in corporate environments, but also in end-users' homes. Advocacy groups are leveraging the current Microsoft court fiasco to raise the visibility of OSS projects and the promises that they deliver upon. OSS projects have never been so well known as they are today. But are we ready? Can we maintain the integrity of the OSS promise and support it through the phenomenal growth ahead? I believe this is a critical question; let me restate it: As OSS projects realize new applications and user bases, can they continue to be successfully deployed? The traditional OSS user has been a technically adept UNIX technician or a technical hobbyist. The UNIX technician learns and understands the complexities of system operation. His job depends on it, and the intricate understanding of the system necessary to make it function is his key asset. The hobbyist thrives on the complexities of system operation; her love for the software being used is often seeded in the very fact that it can be difficult to deploy. This creates the critical sense of ownership of the system and the necessary knowledge - this is, indeed, the very same attraction that has pushed technically adept users to embrace and extend OSS! The State of the System The Internet has grown at an alarming rate. Intranets: exponentially. Company LANs are standard. Corporations and consumer alike have realized the incredible benefits they offer. The need for new installations has exploded. This has necessitated the induction of individuals to staff IT divisions who are no longer technically adept; the existing pools have been long-exhausted. The result of this is that package solutions, usually provided by Microsoft, have become the rule. Smaller departments and organizations adopt these closed technologies, and as these departments grow, few are willing to replace the underlying technologies. "If it works, don't fix it." It is equally true that new computer users are paying a premium for easy-to-use, out of box solutions. Windows is almost universally the law in homes everywhere. And where the consumers go, the industry follows. This is true not only of consumer application development, but in skill base as well. Little Johnny makes good with a year's Windows experience and becomes the next IT department head on hobbyist skills alone is no longer the exception. It has fast become the standard. Ease of Use, Desirability of Deployment If the rapid growth of closed software is the problem, there is but a single response available to the OSS community: OSS must become simple to install, easier to use. OSS already represents the smallest purchase price. An operating system comparable to Windows NT can be had overnight at no cost to a person with a modem and a brave heart. Similarly, a CD-ROM set can be purchased with RedHat Linux or FreeBSD as well as an incredible suite of powerful applications for less than the cost of Windows 98. But does OSS represent the lowest TCO for a corporation, the easiest route for the new consumer? No. Both packages still require an extensive skill-set. On installing RedHat, one is faced with DiskDruid and a dead end if she isn't aware of just what partitions need to be created in order to create a functioning UNIX system. On installing FreeBSD, the user often needs to remove and adjust device configurations to merely load the installation utility. Both packages, even in their simplest and most straightforward modes of installation, present the user with a confounding number of technical details and alarming questions. It is entirely unreasonable to expect a user to know what I/O ports and interrupts are in use, or to think that they won't panic or feel so intimidated as to be insulted when they see a stream of ed0, sd0, ttyp1, etc. roll by. The simple, common response is to call the operating system a farce and turn toward the pretty vision of Windows and its graphical installation. I believe it would be rare for an individual without an organizational mandate or an attack of "alternative techno lust" to complete the installation. And certainly, neither OS is something I'd recommend to my mother when she asks, "Do you think you could set me up for e-mail?" Did you laugh? There's a critical point here, and a very good example of what I've just explained. I gave her DOS and she brought those skills to a large educational institution. Once they decided computers might be a nice way of managing their accounting, they turned to the accountant with computer experience and DOS became the rule. Later I gave her Windows, and she took those skills to her new job at the Northern Illinois Library System, which now thrives entirely on Windows '98 and Windows NT. NILS is now funding and educating smaller libraries that wish to deploy Internet connectivity. Consumers are now going to the library for their first taste of computing and all that it has to offer, and that first taste is a closed operating system with a well-known label. What if she'd been able to place a CD-ROM in her machine and fall in love with a little red daemon bouncing across the screen? He'd have been willing to ask her name and perhaps a password and do the rest for her. I wish she'd met a suave agent in a red hat, one who'd simply said, "Let me take care of the details, hon. The software's on me." At most, a user should be presented with a single, attractive screen of user options with a brave "Expert" button for the veteran. The rest of the installation should have been automated. A window manager with a reasonable set of default programs, all networking services intact, a daily help tip and an avatar helping with "Learning Experiments" for the curious... this should be the default installation. The rest would have been history: We would have seen Thousands of new installations stemming from her alone. What Do We Need? Firstly, it would be fair to acknowledge that Linux and FreeBSD have made commendably strong steps toward a Windows level of Plug and Play functionality. And while each comes closer every day, neither has yet met or surpassed it. Meeting the Windows ante in this regard is of absolute, critical importance! Secondly, I haven't seen the kind of focus on simple installation and wide deployment that is going to establish OSS of any type as a mainstream product by making it accessible to today's new IT professional or the home user, tomorrow's professional. The time for this came long ago, and the OSS effort will continue to suffer for it every day that it doesn't exist. Plug and Play With the advent of Plug and Play standards and the standardization of PCI and PCMCIA peripherals, Plug and Play has become a much more attainable goal. OSS development efforts have taken advantage of this. Legacy hardware will, however, be around for some time. If hardware needs to be disabled or removed to complete an install however, this is an error, a product defect. I've heard the Windows pundits chuckling over Microsoft's alleged mistake in destroying installations if users attempt to upgrade to Windows 98 with certain removable media devices powered on. Is locking during the install if FreeBSD hasn't correctly detected my Adaptec SCSI controller any less of an error? To see these errors removed, these types of device conflicts must be resolved more gracefully. The system must be scrubbed and analyzed, and to best do this, we need a concerted effort between all OSS OS developers. A common, accessible table of known hardware types and their appropriate drivers must be created. Problems which arise from incorrect hardware detection and how to resolve them must be made public knowledge. Teams shouldn't have to analyze each others' source to discover what works. I'm sure many of us remember the pains the XFree86 team took to elicit Diamond's and S3's cooperation in creating accelerated servers for their hardware. The effort would be furthered by a unified OSS driver division, capable of eliciting support and cooperation from hardware manufacturers. This can be accomplished by making UNIX support a desirable commodity, thus forcing manufacturers to aide the driver developers. How? The first step is branding. Create an "OSS Ready," or a "UNIX Ready" emblem, owned by the FSS. Allow cooperative manufacturers to display the emblem on their packaging. The manufacturers would then have a new selling point at little or no cost. And once a strong hardware manufacturer realizes the value in this and makes it an advertising commodity, other hardware manufacturers will be forced to follow suit. The development teams will be blessed with early hardware prototypes, ready documentation and the accessibility of the manufacturers' support engineers. And OSS OS projects will be able to leverage the higher visibility of open operating systems in further advertising efforts. Ease of Installation Currently, I know of no simple facility for creating easy installation applications. A standard suite of libraries need to be created to control an installation and configuration engine. RPM and FreeBSD packages are a step in the proper direction, however placing files is only the first step to a useful installation. Managing installed packages should be handled in a clean, orthogonal fashion. The same interface needs to be available to all packages which don't provide native graphical configuration options. If a clean configurator exists, if developers only need to create simple scripts for user actions and refashion man pages to allow inline links from the installation procedure, they WILL do it. This ease of configuration needs to exist from the moment the user is first asked a question. Reasonable defaults and aide in discerning the various options needs to exist from the first boot onward. This is the single step that could push the OSS OS ahead of systems such as Windows NT. Can you see a day where the new lone IT professional sits there, scratching his head and wondering what a Windows Primary Domain Controller is, thinking it might be easier to lead his company back to the helpful daemon after all? (Microsoft, Windows 98, Windows NT, Adaptec, Diamond, Plug-n- Play, RPM and Red Hat are registered trademarks. The author makes no claims of trademark ownership herein.) 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?199811030209.UAA06560>