Articles / Open Letter to Red Hat and ...

Open Letter to Red Hat and Robert Young

Red Hat's IPO put them in a position to make waves in the Linux Community, and after discussing it in various forums and thinking long and hard about thier position, I have made some observations. I only hope to see them succeed for the sake of the open source community in general, but there are hard buisness facts to contend with as well.

My Open Letter to Red Hat and Robert Young

By Robert W. Current

Well, let's start off with a disclaimer. I do not work for Red Hat Linux. I do not own shares in Red Hat Linux. I am not a programmer, investor, market analyst, IT professional, or any one that has any financial ties to the computing industry.

I am a Linux user. Well, more correctly I am a UNIX user, I use Linux at home, FreeBSD on my system at work, and have used IRIX and DEC-UNIX (now know and Tru64 UNIX) on and off for the last 6 years. I know UNIX better than I know MacOS, Windows, or any other computer operating system. Not that it makes me an expert, I'm not Alan Cox or Dennis M. Ritchie by any stretch of the imagination. Actually, more than anything, I am a chemist working on my Ph.D. Now, I have learned a thing or two in my time. I am not a BOFH, although I like to think of myself as the "end user from hell" the worst combination of trying to get my own work done on a system, and playing hobby systems administrator for kicks. I tried to get an articles section going on freshmeat, I run current.nu, but it's all just at a hobby level.

I decided to spout off on this issue because of a story I read on SlashDot about "What if Red Hat bought SCO?" to which I replied "What if Pigs had Wings?" It was sort of a joke, because I didn't think much about SCO being a great value to Red Hat. When my post got moderated up to a 5 (top of the heap at SlashDot), I figured maybe I do have something to say about this. Maybe the SCO purchase makes some sense, from a pure business standpoint, but I still maintain they are not, because businesses fail, and I don't see Linux as a business. Red Hat as a company is not your traditional software company, and that is why it stands a chance to succeed where a company like Microsoft could fail. Adapting strategies like Microsoft, and buying out a company like SCO puts Red Hat into Microsoft's ballpark. Once you play like the enemy, what's the point of the battle? To succeed with a product like Linux, you have to be revolutionary, not traditional.

Here are the steps I see that Red Hat can take now that it has acquired the financial resources to make some "big plays."

  1. Dump resources into GCC, if GCC dies, Linux dies with it. You may think this is un-needed, because there are other people with an interest in GCC, and that will help out the project. But, truth be know, Red Hat's fate is in the hands of the GCC project right now, and all the strengths and shortfalls of GCC are directly evident in Red Hat's products. Red Hat is focusing on Intel hardware, but sells SPARC and Alpha products too, and GCC is not as strong on these platforms, so as a result, Red Hat's products are also weak on these platforms.

  2. Dump resources into a GPL office suite, without KOffice or a Gnome Office, or some other open source office suite, in a few years everyone will just be downloading Red Hat for free, and buying a $400 copy of Microsoft Office for Linux every year. With a complete functional office suite, there will be a whole new "consumer" market opened for Red Hat. The Office Suite has to be good, and strong. Even with the best of Office Suites, they will still struggle with "MSOffice" compatibility issues that will plague customer conversions from Microsoft Windows to Linux. But you can't even get your foot in the door with a commercial office suite that's not compatible with MSOffice running on an "alternative platform."

  3. Make what they have now work better. One of the most commonly used applications that ships with Red Hat is Netscape, you would think that Red Hat would have an interest in getting all the plug-ins and bells and whistles working out of the box, so their customers have something useful after installation. If AOL really wants to dump the Mozilla project, Red Hat should enter some negotiations to pick up the ball and run with it. Developing a multi-platform browser by a Linux company may sound a little "overboard" but the press coverage alone of something like that would payoff well. If AOL won't let go with it reasonably, Red Hat still has to ship a full featured powerful browser. People think "Internet" when they think "Linux" so shipping a product that average users have trouble getting onto the net with would be a fatal mistake.

    Red Hat may even want to consider shipping KDE as default, because users that are happy with Gnome/Enlightenment are generally able to change their default window manager on their own. Users that have trouble changing their default window manager might like the polish and functionality of KDE better out of the box.

  4. Subscription Plans. I can not stress enough how important I think this is.

    Ditch the $60 box set whenever we feel like releasing something new, and be up front and honest. Sell a "Subscription to Red Hat Linux" for about $100 that includes 4 complete CD sets per year, that come out on a regular schedule, and are sure to have the most up to date software from the whole GPL community. People with a lot of bandwidth don't usually buy a boxed set anyway, so give the people without bandwidth the product they really want! Offer to throw in a "emergency patches" CD in once in a while for major security issues, Red Hat sucking up the cost of an extra $5 CD per customer will probably be sure to get you thousands of people standing in line to pay $100 a year for a subscription that insures security.

    Red Hat has to break the mold cast by traditional software companies. Open source software is a fast moving target, that's a given. They are selling something that is available freely on the Internet. Red Hat is not a traditional software company, and as such, should not be subject to traditional roles of "Version 5.0" etc... The model I am proposing puts Red Hat more into the lines of a traditional "publishing house" than it does a software company. Red Hat could learn great things from the ways newspapers and magazines run their businesses. Publishing is a high volume, high dollar business world, and that's the model that would more closely fit open source software. Red Hat buying out a place like CDROM.COM would make bucket loads of sense in this regard. CDROM.COM knows how to maintain a HUGE mirror of all the latest and greatest open source software, and they have "subscription" plans for FreeBSD and other OS's that have proven to work.

    Sure, you could say that there isn't going to be huge changes to the Linux kernel and basic operations every 3 months to justify a whole new distribution. But, it is needed to note that it's not just the OS that is on the CD. There are many open source projects and applications that make quantum leaps frequently. People in general want the newest, most up to date set of applications, and if anything they use at all has been updated in the last three months, they want it. This is where Red Hat can sell a product. By making sure that the customers are happy, they keep their client base, and keep making money. That's the bottom line in business, keep the product shipping, the customers happy, and the money rolling in. A publishing house style company can go a long way where a traditional "Version 5.0" style OS company will fall flat.

  5. One thing that is an annoyance about Red Hat today is that RPMs are great from a packaging standpoint, but Red Hat has muffled them up a bit. But, there are the standard RPMs that ship with Red Hat, then there are the updates on the update FTP site, and then there are the contribs. The updates are nice, the contribs are a mess. Red Hat needs to clean up it's contribs, and merge them with the updates. Red Hat needs to make it much more painless for open source developers to contribute RPMs of their latest work, and get them ordered well into the updates (maybe contribs should be rechecked, and updates the "officially checked" packages). FreeBSD ports updates are frequent, and always work, Red Hat doesn't handle their software updates nearly as well right now, and needs to do this. Kernel updates through RPMs are a good idea for "end users" who are not real UNIX hackers, but should probably be available up through the current kernel with warnings about bugs. Red Hat still only has 2.2.5 in RPM, but 2.2.12 is out at this time.

    Pushing RPM might not fly really well with the open source community in general, but if Red Hat wants to make it's business fly, they really need to bend over backwards to get open source developers to contribute RPMs. RPMs are at the core of what the customers of Red Hat have to work with, and without the latest software in RPM format, Red Hat users might as well be using another distribution. Maybe you can argue that open source shouldn't be forced into packaging in this format. But Red Hat as a company needs RPMs of the latest software, either they have to work like crazy to make them available to their customers, or make it completely painless for developers to build an RPM of their software. On way or another, the software availability is a major component of Red Hat's product, so it's something they need to focus on.

  6. Cygnus and Borland both might make great acquisitions. Cygnus has the support of the open source community because they choose to maintain GCC. Borland has a great number of products that would develop faster if open sources, and could really give Red Hat some momentum. Borland might be a bit out of Red Hat's price range today, but maybe someday.

    Some people have proposed that Red Hat look to buy SGI sometime soon. SGI is loosing ground, and support is one of their lacking. SGI using Red Hat was their solution, and it's not working as you can tell from the $16 to $11 drop. SGI's MIPS products are solid on the hardware side, but just troll the SGI newsgroups, and you will find users are very unhappy with IRIX. It's not that UNIX in general is giving them problems, but SGI's problems with IRIX, various bugs, chaos in patches and updates, nightmear upgrade stories, etc. Buying SGI would only give Red Hat another Support headache, just when they really need to get their support more streamline, and focus it on a mass market. It would be a move in the wrong direction.

    Red Hat is already working with SGI on their new systems, it's not a great fit. Mostly because people like the hardware, and the flexibility of Linux, but still have fears about SGI and Red Hat support. I think they should continue this partnership, but both parties should be ready open up really fast to people like Alan Cox. If they have the money, Red Hat should Alan right to the SGI home offices, and pay him well. Let the hardware and OS speak for itself, and let someone like Alan make it speak as clearly as B.B. King talks through Lucille. Then, let Red Hat and SGI deal with their own support issues at the corporate level.

    But if Red Hat is to make any acquisitions, they should be in the software market, not the hardware market, they need to stick to what they do best. And if they bought someone out and open sources the software, that would both get Red Hat some press coverage, and make the open source community more willing to support Red Hat with it's purchasing dollars.

  7. Someone like Compaq or Dell on the other hand would be an excellent place to form a "partnership" on a long term scale. Red Hat needs to get in tight with one of the Intel based hardware vendors that can help them scale up to 2+ CPU servers with RAID on one hand, and looking down towards laptops and PDAs on the other hand. Both Dell and Compaq have something strong going on both the server and PDA fronts, and would be ideal partners.

    Companies like Intel and AMD are not something that could benefit Red Hat as directly as company that actually produces complete consumer systems. Only if Red Hat were to be directly developing a compiler would a alliance with a CPU manufacture make as much sense.

    Those are some areas where the growth would be a little less painful. And a "partnership" rather than a "buy-out" would allow them to gain some "help" and not "acquire the headache."

  8. Support the LSB 100% of course! Let the LSB do thier own thing, and make thier own moves, and don't try to influance them for Red Hat's personal benifit. But, now that Red Hat has some resources, support one of the great efforts in the Linux community.

Well, most of my thoughts on Red Hat, if they offered me some shares or something I am sure I could come up with more for them. I have some much cooler ideas for VA Linux Systems, if they would listen, but I approached them once, and they never returned my mail.

RSS Recent comments

30 Aug 1999 00:26 scherrey

Sure Fire Method to Make RedHat Go Under...
This is not to knock the obviously well-intentioned and thought-out open letter but the recommendations given by this letter and much of the linux/open source community are guaranteed to result in the demise of RedHat which would be a terrible hit on developers (such as myself) and users alike (not to mention the market in general).

Everyone seems to be saying "If only linux/redhat/et al had this feature..." or "Linux would rule if it could run this software..." which finally amounts to asking linux, via RedHat, Inc., to be all things to all people which is why many of the formerly successful technical industry companies (Borland/Inprise, Novell, pre-Gerstner IBM, et al) collapsed. They were trying to emulate Microsoft (or their perspective of Microsoft) and went after a market that either didn't exist or required more resources than a company even as big as Microsoft would be able to break through.

While many are explicit about their comparison to Microsoft, even those who are not are obviously thinking about "destroying the monster" when they provide their advice. All due consideration to Gates & company aside (warrented or otherwise), Microsoft got to where it is today because of two things: 1) A big company going after a different market didn't want to be distracted by an adjunct market so it walked up and handed it to them. 2) Microsoft recognized the value of this, concentrated on its core business and waited till other markets developed on their own (i.e. by competitors) then capitalized on its base technology to make major inroads into these new markets.

Had #1 never happened its unlikely #2 would have ever been able to occur and create the behemouth we all know and love/loath today. Prior to #1, Microsoft was a relatively successful language developer shop not too dissimilar to Borland and would have likely been a very significant player even today but nothing like it is now thanx to that gift from above by one of the few companies capable of creating a new market like the PC industry. Had, instead, (assuming #1 never happened) Microsoft tried moving into server, desktop, et al markets simultaneously it would be gone or in the same shape Inprise is today (i.e. nowheresville).

What's the lesson here? RedHat needs to consolidate its success and let the other aspects of the business develop on their own before throwing significant resources at them (like the desktop market and joe user). Fortunately, RedHat seems to have figured that out all by themselves even without hiring me as their business strategy consultant (what were the odds of that happening?!?!?). RedHat is positioning itself to own the backend. Even with its (intentionally or otherwise) stealth business model (since one purchase of RedHat != one server install and many companies don't realize their current dependence on RedHat/Linux), linux, and thus RedHat, has already started showing up on the market ownership screens of all the industry watchers. With the IPO and new product announcements, RedHat has revealed its intentions for all to see buts its too late for the opposition cause they were long since penetrated ala Trojan Horse.

RedHat will continue its normal distribution that can be downloaded for free even though a significant percentage will continue to purchase new copies and updates. To protect against the inevitable reduction of this market (or, rather, its slowing growth), specialized distributions that focus on backend operations like eCommerce will become the focus of reoccuring revenues. RedHat is also capitalizing on the defacto association of Linux == RedHat. Companies will standardize on RedHat as their linux distribution and only accept compiled software RPMs for their version release. RedHat's stamp of approval for a piece of software will make that software viable in the marketplace. As more companies (open software and otherwise) recognize this and the market becomes more credible, RedHat will insure the kind of revenue growth that justifies its stock price (I'm looking for a split within 9 months - no I don't currently own any). All of this goes on with RedHat simply concentrating on its core market and not trying (ie, blowing lots of capital) to replace Windows and its apps on the desktop.

Even with all this, however, opportunities like Microsoft's #1 just don't happen any more, or do they? Well, not exactly and possibly not as profoundly but something along these lines could be coming down the pike. IBM created the Intel/PC market and Microsoft owns the software side (which is the most important part). Microsoft has failed to recognize fully the liability of this position as demonstrated by its inability to implement its technology for other platforms. The promised PowerPC/NT has never appeared (possible canceled?) and the Alpha platform is on the verge of being abandoned even though its the one area most likely to help NT or Win2K to scale up enough to compete with *NIX.

The promise of Open Source, Linux, and the RedHat business model is Platform Independence. Theoretically, a company developing code for Linux should be able to move it to any platform Linux runs on. RedHat's out there with Intel, SPARC, and Alpha support right now. As long as it makes it relatively inexpensive to move to new platforms it will automatically be positioned to own the software market for whatever hardware platform manages to create the next large market. I doubt I'm the only person who's noticed that Intel's latest chip offerings haven't exactly been meeting the potential of Moore's law performance/price-wise and pundits are already backpeddeling on the promises of the Merced architecture telling us to wait for the next chip after that! This is *really* bad news for Microsoft (who have enough problems just supporting the next Intel architectures) because its very expensive to port their core technology to new platforms plus, limitations of their architecture and general poor design of their apis has caused most successful software implementations on top of their technology to use Intel platform-dependent calls or operations that make the software difficult to port even if the Microsoft technology was available on new platforms.

RedHat's #1 gift giver could inadvertantly be Microsoft who has blown the PC industry into a market much larger than IBM ever imagined or, to the chagrin of their mainframe/midsize divisions, intended. The success of this industry has created new opportunities and new problems that require more scalable environments that the Intel boxes aren't meeting. Microsoft has created this market and given it viability but doesn't appear to be prepared to follow through on it. RedHat very well could be.

So, back to the letter, what advice given might help RedHat follow through with its strategy? I'll take it point by point.

1. "Dump resources into GCC"
I give it a 7/10. Yes GCC is critical and one of its great features is its flexible platform support. However, this is also a huge liability. Even more important would be getting support from other compiler vendors. The linux kernel has a lot of gcc-specific constructs (which has led to interesting "discussions" between Linus and the egcs team) that it might better do without. I think the ability to build RedHat with more than one compiler will help keep it on track. I am not at all suggesting the abdandonment of gcc but I'd like to see less dependence on a single product.

2. "Dump resources into a GPL Office Suite"
0/10. Wrong answer. Waste of development resources. There are other companies much better positioned to go after this market. Certainly RedHat should encourage this effort but more so by policy and improving their own technology to support such development rather than capital resources and direct development of such technologies. Remember that WordPerfect once owned the WP market. They could again as could some of the other existing or still-to-come contenders. This kind of effort is what killed Borland.

3. "Make what they have now work better"
10/10 intent, 4/10 execution. Tweaking their primary packages (from an admin/configuration perspective) to better integrate with their primary technology is absolutely the right thing to do. Taking on responsibility for Mozilla or other Open Source efforts would not only waste a lot of effort on distracting, non-core technology but would likely alienate many other developers/pundits who fear or are concerned about one distribution controlling such an effort. GUI environment selections are pretty detailed tactical decisions at this point and are therefor outside the scope of this debate.

4. "Subscription Plans"
4/10. This might be a decent idea as an option for people who want it but most big companies don't want every version/update. Internal standards for what versions of software will be deployed in the corporation and the relative slowness for the groups to upgrade make this option less attractive for the users who will be the main source of the new income.

5. "Improve RPM"
9/10. A RedHat package with the RedHat "Seal of Approval" is going to be the sign of a successful, viable, credible product from a corporate perspective. I hate RPMs and am strictly a .tar.gz (or bz) source kinda guy but that option's not going to take you corporate. A package mechanism of precompiled code that can help make installs safe, track licenses, help upgrade existing systems, and generally mechanize the admin process in a standard manner is a big win for RedHat. Maybe existing RPM technology can be extended to do this (I question this) but they need to do something (anything) that will.

6. "Aquire Cygnus or Borland"
2/10. Cygnus is into a lot of businesses, especially embedded platforms and development tools. The development tools might be useful but the fact is that RedHat offers little to leverage by aquiring the company and doing so would probably hurt Cygnus' credibility somewhat so this option doesn't fly. Inprise/Borland, by my computation, is about half the market value of RedHat (INPRISE is 50M shares @ $4, REDHAT is 6M shares @ $80) . I like Borland's development tools but they've got zero *NIX experience. Also, shortly before, during, and after the aquisition they incurred a huge brain drain (mainly towards Microsoft) of their compiler developers which is their biggest asset from a RedHat perspective. Some sort of relationship/investment to port tools to their platform could be a great benefit for both companies. Borland's not going to release their source so they need to work closely with a distribution vendor. Ownership makes no sense because of the existing and long-time-coming dependency Borland has on Microsoft platforms. Too distracting.

7. "Parner w./Hardware Vendors"
10/10. Gotta sign the deals. Get $50/cpu... oops, Janet Reno won't like that! We'll know we've won when we see a little RedHat logo button show up on our next computer's keyboard. Naturally, RedHat's already moving forward with this.

8. "Support the LSB"
7/10. Supporting the concept of the LSB is definately a go. The actual LSB or group concensus may be detrimental in the long run. The goals of many of its members certainly overlap but may also go against thos of RedHat's (and Linux') when its all over. Standards, especially those that encourage/enable platform-independence, are generally good. Getting a standard directory structure and boot/configuration script mechanism implemented is a great but small part of the whole effort. Gotta balance these things out and I think RedHat's comments/effort to this issue thus far have shown this desire.

CONCLUSION: Whew - I really intended to just hit on a few points and be done with it. I've seen a lot of "suggestions" (demands?) of RedHat and have formulated these options over the last several months. Most such posts were nonsense or so out of context that they simply didn't warrent replies. Robert's letter, even though I disagree with a significant portion, is the first coherent and thoughtful one that I have run across that justified and provided a foundation for me to "correct some incorrect yet reoccuring perceptions" so I hope he takes this as a complement more than a criticism.

Benjamin Scherrey
scherrey@proteus-tech.com

PS: Please pardon any poor grammar or spelling as I'm typing this in as I make it all up... :-)

30 Aug 1999 01:54 badlandz

Benjamin Scherrey's Comments...
Ben, thanks for the comment, seriously. I by no means am working on developing the Red Hat strategy, only spent maybe a couple hours even thinking about it. You made some good points. But..
As for "#4, Subscription Plans." I think that corporate deployment of software is a lame excuse for not encouraging rapid development. Red Hat has to have a product to sell, and I still maintain a publishing house style would break the mold as needed.
Corporate deployment of software will not remain the same in the comming 2 to 10 years, it will probably change rapidly. Gone will be the days of "a PC on everyones desk." The day of "department servers" and "thin clients" is comming faster than you think. Most Linux hobbists have an Xterminal sitting off thier main workstation already (old 486's to run X on and -query thier workstation from another room). Upgrading each indiviual users workstation will die fast. I would estimate (very poor guess) that at least 70%+ of the users in a corporate environment will rely on a minimal hardware of thier own. A PDA with uplink to the server, and an Xterminal (or some GUI interface to the server). Security of files is a non-issue in corporate environments. Companies want "integrated databases of information" not client contacts fragmented on 100 diffrent workstations in the sales office.
There is a need to sreamline the upgrade process today, and when it get's to the point where every employee in a buisness haveing some need for the information infrastructure, it will get worse if the server-client plan is not fully exploited. It's a matter of buisness costs of operation. There is cost savings in using a server-terminal system vs. a mulitiple workstation environment. You have to think of the consumers, not all buisnesses are software development firms where each user needs the power to compile on thier own box. And even these cases may start to shift to this scheme, only with a higher server/user ratio, so that teams can work on the same code.
UNIX has a longstanding tradition of multiuser systems. Red Hat now is at a "workstation" market, and that's fine for home users. But corporate users will want server-client systems, and thus cut down on the upgrade problems. IT pros will not be running around updateing everyones system, they will only be maintaining the servers, and clients will be handled in bulk (possably through diskless workstations anyway, so only firmware upgrades will be done).
As for home users, that's a whole diffrent issue. People get a kick out of "subscriptions" and like to show off thier new toys and play. ;-) I don't see it as a huge problem there either.
Primarily, I see it as making "baby-steps" instead of "huge jumps." When you make baby steps, your less likely to bring a whole system down. If you wait a year between upgrades, your going to have so many changes, all at once, things will break. If Red Hat made "baby steps" and carefully monitored the increments, it would work. The trick would be a close focus on not making things break from release to release.
I totally agree that most corporate environments suck at keeping all systems up to date already. But I disagree that development should be slowed down until they cetch up. They don't need slower product releases, they need to face up to faulty infrastructure, and depoly solutions that will work.
Short term costs would be eased by converting current workstations into X-terminals, and just focusing on developing the server infrastructure. Long term solutions would mean synking PDA's and mobile users to the servers, and making things run smoothly.
I guess this is where my UNIX roots come to show, and maybe I am outa touch with the "workstation" craze. But, I seriously believe that IT is just that, Information Technology. The information comes first, and formost. It should be solid, connected, integrated, and shared (within the confinds of the company). Running servers that keep the front office in contact with the CEO's, and keep the sales team in touch with the shipping office, and keep the CEO's in contact with the sales numbers are NEEDED. Server-Client is the way this is done, and where NT fell flat on it's face.
Knocking down the number of systems to upgrade by even a 10 to 1 ratio (easily done by moving to server client methods) would ease the upgrade process the way that IT needs. Plus, throw in the fact that it's a timed, quartly sync. Not product X came out in Febuary, product Y came out in July, etc.. with 300 diffrent software packages all needing to be maintained, all with diffrent release dates. Insted, you plan your quarters, and know when the server software and applications will be changing (and improving).
I could go on, and on, and on, and on... ;-) But, I think if you don't see my point, we'll have to agree to disagree.
As for the other disagreements, you may be right. I am not a big fan of the aquisition plans in general. And, _IF_ they did any, then dang well better just open source the stuff and cross thier fingers that outside development groups will use the code and send in the patches. Red Hat has to keep it's eye on it's own product, which is shipping a product, and that product is CD's full of OS+Software. That in itself done right is a job and a half, adding development of the OS+Software is a throwing a lot more burden on thier sholders. Frankly, I never understood Red Hat Development Labs anyway, sure it's fun to have enough money to let guys just code, but that's not what thier buisness is. Thier buisness is getting the code to the users, not makeing the code itself.

30 Aug 1999 01:58 docbear

re: Open letter to Red Hat
There are many areas in which I agree and many in which I disagree. There is one area in which I would like to comment, right now and that is item #5 re RPMs.

The RPM format is a good one, but a layer is really needed above that, or RPM needs to be extended to match the functionality of the Debian .deb package functions.

If a user selects to install an application package from either CD or network and there are package dependencies that are not currently met, the user should be presented with a y/n dialog to install all required packages in addition to the one requested, rather than a simple failure message. If the user is attempting to install the application from a packaged CD set, they should be prompted to insert the relavent CD(s) and the requisite packages should be installed.

Please note that this is a good way to convince users to purchase the "official" CDs, since the cheap CD vendors often screw up CD order information.

I would also add that you might find a market in selling a full CD set without the printed docs, for the experienced folks that want a full distribution without paying for the cost or shipping of the intro manual.

I also like the subscription suggestions, but understand that it could be difficult to make a quarterly schedule. On the other hand, this is what your corporate customers will be demanding....

I completely disagree that Red Hat should get into the applications arena, at least at present. The aps are coming. Support wine and speed them up, perhaps. This is a dangerous ground, since there are already mainstream aps vendors that need support, such as Corel and Star/Sun.

Other than improving the installation process, as mentioned earlier, I think that the best way that RH can leverage its new wealth is to help protect Linux against all of the lawsuits that are sure to come for violation of BS software patents. I would hope that Red Hat could also call on Oracle, IBM, HP, SGI, and Compaq to help in the legal defense of these issues that were spelled out in the "Halloween Documents".

I'll add one one item. Help bring all Unix variants together. Give a little and gain a lot.

--doc

30 Aug 1999 02:00 badlandz

Whops...
My comment above (which I don't see showing up yet) had some misleading statements. Specificly, I think I said (but can't read it yet) that corprations don't care about security, something like it was a "non-issue." What I MEANT was, they don't care if users loose thier safe secure netscape cache, because they shouldn't be using thier workstations for personal use anyway. On a grand scheme of network security from the outside world, OF COURSE THEY CARE. ;-) I only mean that it won't hurt them a bit to think that users will not have thier "privacy" when keeping personal files. I am sure most will agree that standard UNIX protocol for file security for users is sufficent anyway.

30 Aug 1999 07:27 cypherpunks

Question for Benjamin Scherrey:
From Benjamin's post:
"I like Borland's development tools but they've got zero *NIX experience. Also, shortly before, during, and after the aquisition they incurred a huge brain drain (mainly towards Microsoft) of their compiler developers which is their biggest asset from a RedHat perspective."

What aquisition?

Are you saying *Borland* was acquired, or what?

If that's what you're saying, then I think you're wrong - they weren't acquired by anybody, they just (stupidly, IMO) changed their name. (And it seems they've changed their mind and now agree with me; they're emphasizing the Borland name again.)

There never was a company named "Inprise" (which I assume is what you thought "acquired Borland") before Borland *themselves* became that company.

Christian R. Conrad

30 Aug 1999 10:02 monkiushome

Of Course Help KOFFICE
Robert Current is RIGHT ON when he says Red Hat should be involved in getting strategic software like KOFFICE out as quickly as possible.

Benjamin Scherrey thinks he knows "what Red Hat's market is", but he is wrong. If RedHat tries to "own" the Linux framework, they will poison the community against them--they have no desire to do it, and aren't trying to do it.

Meanwhile, Mandrakesoft is doing just what Mr. Current proposed--hiring developers active in KOffice and KDE, just as Red Hat employs kernel and GNOME developers.

Why?

Because the Linux distribution vendor's job is, precisely, to help Linux succeed as an Open Source play, without recourse to commercial packages for all the business-critical applications.

When Red Hat (and Mandrake, and Caldera, and...) work to make Linux suceed without trying to "own" it or take it over for themselves alone they win the loyalty of Linux users worldwide.

That is what got Red Hat to the top of the heap, and that is the only thing I think can keep them there.

30 Aug 1999 12:34 cypherpunks

Red Hat's business model
I think the original author fails to understand Red Hat's publicly stated business model.

In its IPO filing, Red Hat stated that it did not expect to profit substantially (if at all) from selling Red Hat Linux CD-ROMS. Read that again carefully - Red Hat expects to lose money or, at best, break even on the revenues from CD-ROM sales. Red Hat expects to make money (if they ever do) by positioning www.redhat.com as a Linux related web portal. Specifically, they hope to attract lots of advertising and site sponsors.

Once you understand this, you understand why Red Hat is not going to "dump resources into" anything that ends up on a CD-ROM. Preparing, distributing, and supporting Red Hat Linux CDs is a _cost_ to Red Hat, not a profitable business. They expect the profit to come from millions of visitors to their web site. If you don't believe me, read their IPO filing with the SEC at:

P.S. sorry for posting as "cypherpunks," but I forgot my username and password - I guess it's been a while since I've posted here.
Raf

30 Aug 1999 15:07 bjidzik

Go for the desktops!
I've been using RedHat Linux as my primary desktop for about a year now & have pieced together a lot of add-ons (TV, multimedia, NT/Netware clients, etc). I've been extremely impressed with Linux & have removed all my M$ stuff in favor of Star Office, Netscape, KDE, etc.

From a "user" perspective, I'd soon like to see out-of-the-box support for TV/video playback, videoconferencing, full multimedia plugin support for Netscape, & a full featured office suite such as Star Office.

I'd also like to see more support for Netscape calendaring, LDAP, & IMAP in KDE & Star Office as well. I'd also benefit greatly from graphical user tools to manage NT & Netware environments.

While I don't mind compiling & installing plugins, libraries, & editing configuration files, it is time consuming, & definately won't fly for a typical "Windoze" users.

If a person can run full videoconferencing, multimedia, & access network resources using Linux out of the box, then I'd be willing to deploy Linux to every desktop. I think RedHat is in an excellent position to make a lot of this happen. Please, GO FOR IT!

30 Aug 1999 16:52 badlandz

Subscriptions Vs. Portal
CypherPunk wrote: "In its IPO filing, Red Hat stated that it did not expect to profit substantially (if at all) from selling Red Hat Linux CD-ROMS. Read that again carefully -
Red Hat expects to lose money or, at best, break even on the revenues from CD-ROM sales. Red Hat expects to make money (if they ever do) by
positioning www.redhat.com as a Linux related web portal. Specifically, they hope to attract lots of advertising and site sponsors. "
You mean, advertising pays bills? Like newspapers and magizines? Oh, ;-) hint.. hint... "subscriptions!"
I didn't detail the execution of subscriptions, only emphisized the importance. I do have some ideas in mind as to how to implement it, and do it well... But I figured I shoved my foot far enough in my mouth in a public forum already. I'm sure someone at Red Hat can put One and One together, and figure out the details... If not, I might be avaliable for consulting ;-)
ok, sorry, I know this sounds like a troll because of the tone in which I say it... I just was hoping to get the gears turning in a few heads, honestly, I don't have the time or energy to fully layout what I think they should do, nor have I been asked to, so I tried to keep it semi-readable and short.

31 Aug 1999 02:43 badlandz

Caspian Foxworth's Comments
Caspian, you obviously understand some of Red Hat's technical shortfalls, and I do not disagree with most of what you said. OTOH, what I layed out was a "skim" across the top of a proposed buisness model for Red Hat's possable buisness success, not a down and dirty look into the technical problems.
Your very correct, I have personally tried to tweak Red Hat for some other motives, and found you to be dead on right about it's technical shortfalls, most notably, the 120M minimal install. I have even went so far as to give up, use a 7 floppy Debian install, tweak the compatibility of the install to match Red Hat, and then RPM it back up. There's a underlying market (which I won't go into) and a huge future technical market share, and Red Hat obviously is having some trouble seeing past the next 12 month growth of Linux.
Now, Microsoft is probably a bad way to compare Red Hat point by point in the market. It's obvious from the base install and the attempt of "look and feel" they went after that Red Hat want's to be a Windows Substitute. Bad plan. They totally blew away some basic underlying advantages of being a UNIX when they did that, and gave Slackware and Debian some support in the GNU community albeit unintentional on thier part, bad plan for the future of Linux, and bad plan for Red Hat to be able to sustain growth beyond the next 2 years.
The more I think about it, the more I wish I could walk in and have a heart to heart talk with Bob Young and tell him where his plans have fallen flat, and where he needs a kick in the ass to get his "vision" of a solid Linux future to really be a vision with a future. Not to sound arrogent, but, Red Hat hasn't even really looked at the major hardware market shifts, and are still focusing on haveing "Workstation" and "Server" as the only two install bases with some definitions of workstation and server being too tight and not flexable enough.
Agreed that Debian will be able to adapt and grow well, because they have users pushing it into markets and applications that are used on a day to day basis. One obvious example is the Linux Router Project, which although not Debian, is heavily rooted in Debian. Debain is an easier "adapt" to these nitch positions, which will be very important for the future of Linux itself. The whole Embedded scene is exploding, Red Hat has all but missed the boat already. To make up a lame mediphore, they better hire a chopper pilot to get them out to the Linux Freighter that is already at sea sailing for the Promised Land. They missed the boat.
Yes, I also firmly agree that Red Hat is a service based company, and they shouldn't be selling Linux as Linux. But, I proposed the subscription plan at a lower cost than I know they would be happy with because of this. Basically it's a model to saturate the world with thousands of Linux CD's, and get the fast moving GPL software out there at a fast and ferious pase, the same way the GPL software is being developed. Get the stuff out there, at a massive rate, force the world to see the rate the software is evolving, and create a vehicile to spread the word. Now, "boxed set" doesn't fit this mold at all. But, if Red Hat has taken the "portal" idea as a serious income stream, then they have to consider its shortfalls. Some people still read print, some people still need print even for advertizement, some people don't have bandwidth to get the product, and some people just plain will avoid the portals. A subscription model would allow a new vehical to get the people to see the ads, would allow people to take the "printed portal" with the software, would allow some flexability, and would rapidly grow the market share so that they can have more inroads to the "service and support" contracts they want as well. But, right now, I have doubts about even how they are "selling" thier support level stuff, thier product line names, etc...
Yea, I'm not saying pretty things about GNU/GPL, and touting how GNU/GPL would best be served. But the reason is that Red Hat is a buisness, not a software house trying to make a living writing Open Source code. They need to think long and hard about the bottom line, the income stream, and the money. GNU/GPL, like it or not, has to come secondary. Only when the buisness model works and there is a revenue stream can Red Hat think about paying out (either in the form of full time employment or contract agreements) software developers. There are GNU/GPL software developers that don't like to look at it this way, but if they saw Red Hat making big dollars, they would be less likely to resent it when Red Hat called them up a few months later and said "Hey buddy, love your work, some kick ass stuff there, I see your actually writing this code at night and work as a system admin by day. How would you feel if we set you up at your current income for a while to develop your stuff, your own way, at home, and get some of your bugs fixed :-)? We would love to see you succede, and your project obviously has promise,. We just want to get you started out coding full time. Where you go from there is your choice, and under your own control. And flat out, it's a win-win for us, we get to give back something to you after we got a great piece of software from you, and you get a catalyst to chase your own dreams."
I don't think Red Hat should sacrifice technical quality, and your die on right that they already have. A faster release schedule would be a potential pitfall. But, Red Hat has to fix thier faults, not slow down because they suck. Red Hat has to focus it's "in house" efforts on polishing and packaging, because that's what they do, they ship a "Distribution of Linux." And that means, packaging. If they can't package at the rate the software develops, they will loose out in the end to Debian (not that that would be a bad thing for Linux, but it would be a bad thing for thier stock holders, for thier empolyees, and for thier market share).
High Quality Manuals... Heh... Well, there's always O'Reilly. Yea, your right there too, manuals need to be there, but a manual is a "book" and can't keep up with the current rate of software development. Red Hat has to restructure there as well. The manuals have to be more complete, more stable, more polished, and probably more fragmented. One book on "Red Hat Linux" when "Red Hat Linux" is a product with OS, Kernel, and a bucket load of software is somewhat insane. How can they write a good technical manual that covers all of the stuff on thier media? They can't, and they need to own up to it. Along with making thier install more flexable, they need to nitch out thier user manuals, maybe work out a deal with SAMs or O'Reilly, and have diffrent "manual sets" for Home Users, for System Administrators, for E-Buisness Solutions, etc... And then, maybe market support packages for the diffrnet nitches to match the manual sets as well.
For the GNU/GPL community out there, YES, Do NOT BACK RED HAT!!! Do your thing, your way, with your own style. Just write the code, let Red Hat worry about Red Hat, and you worry about your software. Caspian Foxworth is dead on right about Red Hat being the wrong thing to keep your eyes on. Even Jordan Hubbard who leads FreeBSD will tell software developers to look at broad market Linux first, preferably just write good open source code, let the distributions (and branches of *BSD and Linux) worry about how to get your software running on thier systems. If your not collecting a paycheck from Red Hat, don't even worry a second about feeling loyal to Slackware, Debian, or anyone else. ;-) In the end, if Red Hat does become dominate, they will roll your packages up themselfs, or send you a check to do it. If your ambitous, and want your software to thier end consumers, then you can do it yourself. If your in it for the codeing pleasure, just code.... I could only dream of being so tallented.
As for RPM itself, don't give up on it altogether though. If your sure it has a shortfall, don't just flame, dig deep and confirm that the feature isn't there in the code, and it's just not a matter of someone not exploiting it to it's fullest usability yet. Stop in somewhree like Daniel Veillard's site, and see how some people are trying to address these issues. And once your dead on positive of it's problems, fix em... it's open source after all, and if the package format sucks, it's not written in stone, you can "code it right." :-)
Hmm... Debian... dselect sucks ;-) Maybe I should write a piece on how Debian could add the polish they need to compete with Red Hat? ;-) Frankly, I found Debian lacking, I use it still on some boxes, but have found that what I wanted Debian for, FreeBSD did for me better.
OK, I'm off to read our local mail about the latest IRIX crisis, something about timed KOing long term calculations and dropping NFS mounts and loosing days worth of data at a time.... My gosh, SGI has really got thier head up thier as.... Oh well... another day, another software game. Oh, hehe, better think about my "real job" too, gotta get this frucking GC to shoot out some good data too.Yea, I agree, and I have WAY more to say about it than I have time to write about. There are solutions though. I could go on for days and days, but the truth of the matter is, it needs to be fixed from INSIDE Red Hat, and only sitting down and talking to the people that are doing it would really matter, trying to type it all out without direct feedback from the people who could make the changes, in a public forum, and trying to fix the theory without having anyone in Red Hat able to respond is not only practically impossable, but almost a waste of time IMHO. Sure wish Red Hat would would give me a call or something, I almost would love to hear "how idiotic" my ideas for them are... ;-)

31 Aug 1999 15:59 mia

The Issue
Redhat is surley a nice distribution. The RedHat and Linux go together in the means that people new to the Linux world often mis-think the same about RedHat and Linux.

Of course, it helping RedHat in getting more user base.

In my opinion the problem accures when you try to take full control on what you do. Aka, trying to tweak Redhat like you used to do with your other Linux distributions.

Take for examples the tools Debian offers you and you will notice a different attitude and understanding.

If Redhat will add the option to check for new packages, the ability to automatically obtain them from the web, install and continure to run without any problem it will help them to get another market share.

The reason that i like Linux so much is MY control on every bit and byte. I decide if this or that package / application is needed or not. I managed to install a working 55MB mail server running Debian slink and i am very happy with it.

If RedHat will copy Microsoft moves they will 100% fail. The Linux user base is so different from the Microsoft one. I want to understand what i do not to hit next next next finish.

Ofir Arkin
WebMaster www.linuxpowered.com

09 Sep 1999 22:56 badlandz

Red Hat in Europe
I see Red Hat is making a move to expand it's market. I see they are looking towards Europe. Interesting, I wish them well.
If they were really looking to expand thier market, they might be well served to keep looking in the US as well, specifically, the educational and scientific market.
If Red Hat were to put a team of developers to packaging some useful scientific applications, they would gain some of the "traditional" UNIX market in Universities and research institutes. For example, they could look at SAL, and .rpm up all the GPL and open sourced applications listed on that site. Furthermore, they could work with some of the commercial firms listed in SAL to help get some "demos" onto thier "third disk" in thier boxed set.
Although this isn't a "big" userbase, this could be a profitable user base. The Educational and scientific market would be more likely to purchace "support contracts" than your typical home user or ISP.

Screenshot

Project Spotlight

WackoWiki

A small, lightweight, handy, expandable Wiki clone.

Screenshot

Project Spotlight

patool

A portable command line archive file manager.