Slashdot Mirror

The Open Source Initiative has modified their official definition of an open source software license. The change itself is minor, but they're also calling for more input on other possible improvements to the definition - see below for more.

Russ Nelson writes: "We changed the Open Source Definition today. Some people had the idea that "may not" in Section 1 meant that they had a choice. We changed it to "shall not". Other changes may be in the offing. The OSD says nothing about use licenses or patents, for example.

"A use license is largely unenforcable by itself. How can you tell what people are doing with software if anyone is allowed to redistribute it to anyone they want? Some parties have tried to enforce a use license by requiring the non-removal of certain parts of the code. This is, in itself, already prohibited by the OSD, however it's best not to rely on indirection to keep use licenses off Open Source software.

"Patents are a problem that have been anticipated by some licensors. In part the furor over the APSL 1.0 was produced because they reserved the right to revoke the license if it turned out that they were licensing software patented by someone else. A number of new licenses have specifically included terms that require contributors to license any applicable patents. And yet the OSD does not require this. What is the good of an OSI Certified piece of Open Source unless you can use it? And you certainly shouldn't allow someone to sue any contributor over patent infringement and still have a license to use the software.

"Are there other lapses in the Open Source Definition? Send them to me and I'll summarize for the board. Speaking of the board, Brian Behlendorf (Apache/Collab) and Ian Murdock (he put the ian in Debian/Progeny) have resigned, and Guido van Rossum (creator of Python) and Michael Tiemann (co-founder of Cygnus) have taken their place."

Markar writes "Developers and programers decided to support EL/IX by Cygnus Solutions as the API for Real-time Linux. Only one dissenter was counted after the vote was taken. The lone dissenter wanted to wait for further developements. PlanetIT is carrying more information. " You can also check out more information about the conference as well.

Kaz Kylheku writes, "Ulrich Drepper just posted an announcement to the libc-alpha mailing list that the tarballs are out. This release fixes bugs in diverse areas and improves the stability over last September's glibc-2.1.2 release. The main archive for this is here and it is sure to go out to mirrors like wildfire. Get it, install it, run it---today! "

Kaz Kylheku writes, "Ulrich Drepper just posted an announcement to the libc-alpha mailing list that the tarballs are out. This release fixes bugs in diverse areas and improves the stability over last September's glibc-2.1.2 release. The main archive for this is here and it is sure to go out to mirrors like wildfire. Get it, install it, run it---today! "

malacai pointed out a story on biz.yahoo.com about all the awards that Red Hat has been getting. Plus, their recent (pending) acquisition, Cygnus, also seems to be getting a wall's worth of plaques. Maybe we should think about giving Red Hat some kind of special award for "Most Awards Won by a Linux Company in 1999." One thing's for sure: Red Hat has done lots to promote Linux in general, and deserves strong applause for their efforts no matter which Linux distribution you personally prefer.

Quite a number of you out there are into Lego Mindstorms, as evidenced by the number of book reviews that have been sent my way. Below are a couple of reviews, one from Kurt DeMaagd and the other from Will Ware. Click below to get their take on the O'Reilly book The Unofficial Guide to Lego Mindstorms Robots. The Unofficial Guide to Lego Mindstorms Robots author Jonathan B. Knudsen pages 247 publisher O'Reilly & Associates rating 9/10 reviewer Will Ware & Kurt DeMaagd ISBN 1-56592-692-7 summary Get the most out of your Lego Mindstorms The Unofficial Guide to Lego Mindstorms Robots Review by Will Ware

Last year, Lego released their Mindstorms Robotics Invention System. Using this, children and adults can build simple robots whose behavior can be programmed. The Mindstorms system is a major contender for Coolest Toy on the Planet.

The system contains a RCX programmable brick containing an H8/300 microcontroller, some pushbuttons, a little LCD display, and connectors for motors and sensors (light and physical contact). The user writes a program using a graphical programming language on his Windows box, and downloads it to the RCX via infrared.

Not surprisingly, substantial reverse engineering (1, 2) has been done by hobbyists, and it is possible to develop Mindstorms programs on a Linux box and to download the RCX brick from Linux.

Now O'Reilly has joined the Mindstorms fray, with a book full of fun and useful information about how to build and program Mindstorms robots. The book describes four different robots: Hank is a bumper car robot, Trusty uses light sensors to follow a line along the floor, Minerva has a movable arm, and two identical robots play a game called RoboTag. Along the way, the author discusses the physics and mechanics of robots, programming issues, and the available development environments for Mindstorms.

What's Good? There are detailed building instructions for each of the robots, showing photos at various stages of construction. The designs are simple and appear mechanically sound. There are discussion of the physics and mechanics of tank treads, steering, gears, and other things.

The book's chapters sequentially step through several different software development environments. The first chapter starts with the Windows-based RIS environment that comes on the Mindstorms CDROM. Later chapters give programming examples for NQC (Not Quite C), pbFORTH, Visual Basic, and the legOS operating system, which uses an EGCS cross-compiler to target the H8/300. There are more development platforms available, but these give a good sense of what's possible in Mindstorms programming.

The book has dozens of useful URLs, for both official Mindstorm sites and unofficial hobbyist sites. I particularly liked the fact that the author was aware of some of the recent research in robotics. For instance there is some discussion of Rodney Brooks' subsumption architecture, which is used for the RoboTag robots.

Later chapters of the book often expand on designs from earlier chapters, building more sophistocated robots in an accessible, incremental fashion. For the more adventurous hobbyist, the final chapter talks about building your own sensors and actuators, and how to connect them to the RCX.

What's Bad? Some of the photos are too dark and lack contrast. It would also have been nice if the photography had been in color, but black-and-white photos kept the book more affordable.

This book is for the casual weekend robot-building tinkerer, and it never promised to discuss real-time embedded issues in depth. Still, a few topics might have merited at least brief mention. Systems with real-time multitasking must frequently arrange for synchronization and communication between tasks, using mutexes and mailboxes and the like, which brings the possibility of deadlocked processes. Another danger is that an aggressively efficient compiler will sometimes optimize away reads and writes to hardware registers. The fix is to declare such registers with the volatile keyword.

Review by Kurt DeMaagd

While Lego Mindstorms were officially released for a teenage crowd, they have become popular with a wide variety of technically competent people in many age groups. This widespread fascination has opened up a whole new world of opportunities for using Mindstorms. At the same time, the documentation and tutorial included with the Lego kits provide very little information about how to get the most out of the sets. This book fills the void by providing several start-to-finish robot designs, software to run them, and a wealth of other tips and tricks.

After a brief introduction to robotics and how Legos fit in, the author discusses the basics of using Mindstorms to create them. Both chapters present a problem, provide step by step building instructions, provide the necessary information to program the solution, and finally go into greater detail about the Lego features used to solve the particular problem.

While the chapters did an excellent job of presenting this information in general, they fell victim to a problem that would plague the entire book: some of the building diagrams were nigh unto unreadable. Attempting to build a robot based on fuzzy black and white photographs can be quite a chore. Fortunately, none of the robots were so complex that they robots were completely unbuildable.

The first few chapters presented robots programmed with the default RIS programming environment. In chapter four and following, he shows how to program using languages such as Not Quite C, Forth, Sprit.ocx for Visual Basic--or optionally Visual C++ or another ActiveX-aware language--and legOS. Since much of these sections was documenting API's, it was certainly not the most exciting read, but it does provide concise, easily to reference documentation.

Not Quite C, as the name implies, is a C-like language that can be used to program Mindstorms robots. It overcomes many of the limitations of the default RIS programming environment, most notably the lack of variables. One of its biggest advantages is that it does not require the user to install a new version of the firmware on their RCX unit. In general, it provides an excellent balance between power and usability.

The remaining three means of programming presented in the book are fairly mediocre options. PbForth requires the user to download a new firmware version, and the language itself is very archaic in modern software development terms. Using Sprit.ocx is a viable option for people used to programming in Visual Basic or Visual C++, but the control structures are very clunky and non-intuitive. legOS, while it is probably the most powerful option, takes a significant amount of time to set up and develop applications with.

Two of the projects referenced while discussing the various programming languages were particularly interesting, both of which outlined infrared communication. The first program creates a simple remote control for controlling a robot via the IR port on the RCX. The other example, perhaps the most interesting in the book, was creating two robots who played tag with each other. These two robots also communicated with each other via their IR ports.

The last chapter, targetted toward the hard core Mindstorms users outlined how to create additional sensors for Mindstorms. It sketched out such possibilities as a passive light sensor, a Hall effect sensor (magnetic fields), and a touch multiplexor (allowing you to have more touch sensors than normally allowed on the RCS unit).

In general, the book provides a vast array building and programming tips, tricks, and methods. He gives basic information for the person who is just starting, and introduces the advanced user to the vast network of people and product that have made Mindstorms far more than a child's toy.

Purchase this book at fatbrain.

Table of Contents

• Preface

• 1. Welcome to MINDSTORMS
• What is a Robot?
• Mobile Robots
• What is MINDSTORMS?
• What Now?
• Online Resources

• 2. Hank, the Bumper Tank
• About the Building Instructions
• Building Instructions
• A Simple Program
• Wheels
• Bumpers and Feelers
• Gears
• Multitasking
• Online Resources

• 3. Trusty, a Line Follower
• Building Instructions
• Some Tricky Programming
• The Light Sensor
• Idler Wheels
• Using Two Light Sensors
• Online Resources

• 4. Not Quite C
• A Quick Start
• RCX Software Architecture
• NQC Overview
• Trusty Revisited
• Online Resources

• 5. Minverva, a Robot with an Arms
• Building Instructions
• Programming
• Directional Transmission
• Pulleys
• Mechanical Design
• Two Sensors, One Input
• Where am I?
• Online Resources

• 6. PbFORTH
• Replacement Firmware
• pbForth Overview
• About Forth
• pbFORTH Words
• An Expensive Thermometer
• Minerva Revisited
• Debugging
• Online Resources

• 7. A Remote Control for Minerva
• Two Heads are Better Than One
• The Allure of Telerobotics
• Building Instructions
• Programming the Remote Control
• Programming Minerva
• Online Resources

• 8. Using Sprit.ocx with Visual Basic
• You May Already Have Visual Basic
• About Spirit.ocx
• Calling Spirit.ocx
• Immediate and Delayed Gratification
• Programs, Tasks, and Subroutines
• Tips
• Retrieveing the Datalog
• Online Resources

• 9. RoboTag, a Game for Two Robots
• Building Instructions
• Subsumption Architecture
• Online Resources

• 10. LegOS
• About legOS
• Development Tools
• Hello, legOS
• Function Reference
• New Brains for Hank
• Development Tips
• Online Resources

• 11. Make Your Own Sensors
• Mounting
• Passive Sensors
• Powered Sensors
• Touch Multiplexer
• Other Neat Ideas
• What About Actuators?
• Online Resources

• A. Finding Parts and Programming Environments

• B. A pbFORTH Downloader

• C. Future Directions

• Index

Ok guys, this is purely a rumor, but its one that I've heard from several points on the globe so I'm gonna share it: Vulture Capitalist writes "I just got out of a meeting with Matthew Szulick and it appears as though Red Hat has inked a deal to buy Cygnus. In related news- we also understand that some people at Red Hat were so upset with the acquisition and it's corporate implications that they have decided to resign from their Sr. management (founding) positions. After the failed acquisition attempts with both Linuxcare and TurboLinux- this should prove to be a very interesting deal. I'm personally looking forward to the annual report! " Again, none of this is any more than rumor, but I've caught wind of it from several spots so I figure its worth sharing. What's interesting is that Cygnus has more employees then Red Hat, and actually generates more revenue.

While I was unaware that this was even a problem, Cygnus Solutions announced EL/IX API which is "...a major step to pre-empt the fragmentation of embdedded Linux..." Essentially, it's an open source, configurable API that lets developers create software for embedded devices running Linux or Cygnus "eCos" OS. Standardization is a good idea, I suppose, and embedded seems to be the way the wind is blowing.

With the increasing momentum in the Linux world, more and more productivity applications have been coming out for Linux. Kurt DeMaagd, who's spent quite sometime in other IDEs, has reviwed Cygnus Solutions' "Code Fusion". Click below to read more about it.

• Company: Cygnus Solutions
• Rating: 9/10
• Summary:With the exception of a few minor annoyances, most notably in the installation process, Code Fusion provides a full range of features for an excellent price.

Cygnus is already a familiar face in the Linux world. They are known for products such as GNUPro Toolkit and Source-Navigator, as well as their support for a variety of other open source projects. Their most recent addition to their product line is Code Fusion, a product which merges and enhances the GNUPro Toolkit and Source- Navigator to create a since integrated development environment.

While there have been instances where people have had troubles installing Code Fusion, I was able to set it up and run it without a hitch. Nonetheless, there were several elements of the install process that could be improved. First, you have to enter a different directory and run a separate install script depending on which version of glibc you are running. Once the setup is complete, you then need to setup several environment variables. While this process is well documented, the risk of typographical errors and the general inconvenience warrant automating this process.

After getting past the mild inconveniences of the installation process, I started up the program and began testing. While Code Fusion comes with a couple example projects and the book has some tutorials, I decided to venture out on my own and create a new project from scratch. And what better way to test a program than to write a Hello World app. Of course, to adequately test all of Code Fusions project browsing featuers, I broke it up into 5 classes.

It took me a couple minutes to figure out how to create new files. It seemed logical to me that the Project Editor window, where you can add, move or delete files, would also let you create a file, but that option is lacking. After digging around menus, I found that the Window menu allowed to you open the Source Editor window, where you can create files.

The Source Editor window provides a variety of convenient options. As with any good IDE, it color codes all our your source. The command to build your code is just a click away. Perhaps most conveniently, it is integrated with a variety of version control programs. In general, it provides a very convenient environment for cranking out code.

Having quickly whipped up all of the classes of my Hello World app, I moved to the feature where Code Fusion really shined, the various project browsers. This feature allows you a wide variety of ways to display your program. It includes a cross reference browser, an include browser, a class browser, and a hierarchy browser.

Finally, I tested the debugging features. This includes all of the standard features expected from any debugger, such as breakpoints, watches, stack traces, etc. Unlike a majority of the debuggers on the market, the screen where you edit the code and the screen where you set break points are different. Having been reared on Microsoft Visual Studio, and given that this differs from the industry standard, this is rather inconvenient. In spite of this, I found the debugger to be generally easy to use and it sure beats using a printf every other line.

Overall, Code Fusion is a very useful product. Any software developer, with the exception of the vi-loving death-before-IDE people, will find its wide variety of features helpful. And with a price under $300, it is financially well within the reach of most individuals and companies.

List Price $299 ($207.43 at CDW)

AT writes "Cygnus has released the source for a new x86 backend for gcc. The new code focuses on better PII optimization. Intel contracted the changes from Cygnus. The code isn't quite release quality yet, but it should be intergrated into gcc 2.9x source tree around August. " Hopefully this won't be an isolated incident considering the number of chips coming outta Intel in the not-so-distant-future.

Bananenrepublik writes "On this page, the EGCS steering committee has posted the official schedule for the transition from egcs to gcc-2.95. So expect gcc-2.95 in early July. " It looks pretty aggressive. I wish the team luck, and eagerly await the improved compiler.

Anonymous Coward writes "Cygnus will port the gcc compiler (egcs, soon to be renamed gcc3) to the IA-64 architecture, notably for the Linux OS and applications. Check the press release here. " Essentially, Cygns is working with Intel to port GNUPro Software to IA-64 is the gist of deal. GOod to see people planning ahead, I s'pose.

Drew writes "Anybody who thinks java is slow should check this out. The company soon to be formerly known as Cygnus released libgcj today. "libgcj" is the runtime library for gcj, the java front end to egcs. Find out more at sourceware.cygnus.com "

An anonymous reader linked us to a forbes article about the linux/playstation devel stuff that has been mentioned here like 9 times before. We've got some official word from DJ Delorie @Cygnus who confirms this stuff- Update: 03/26 09:38 by CT : I've got a full blurb from DJ attached below: Worth reading. DJ Delorie writes "There's been a lot of rumors about Sony and Linux lately, but on Monday Cygnus will add fact to rumors by announcing that they've developed the next generation Playstation development tools that Sony will be distributing to game developers. Here's the basics: it includes gcc and gdb, runs on Linux, includes a GPL'd NG Playstation simulator, and will be available as part of the NG Playstation developer's kit.

The compiler targets Toshiba's new 128-bit CPU, and includes extensions to program the custom graphics chips in the next generation Playstation.

The simulator simulates most of the NG Playstation console, but you can't quite use it to play games on it - its CPU outperforms even a Pentium III. However, the simulator lets game designers debug things that would be impossible with hardware, and since it's GPL'd, they can modify it as needed to help them debug.

The tools will be available through Sony's usual developer channels as part of their hardware development systems, and yes, they'll be GPL (the compiler and simulator, at least) for those people who buy them. Cygnus will sell support contracts to game developers.

Eventually, of course, the changes to gcc, gdb, and other FSF programs will get rolled into the public releases.

You will be able to read the press releases on Monday.

Let the games begin! "

An anonymous reader linked us to a forbes article about the linux/playstation devel stuff that has been mentioned here like 9 times before. We've got some official word from DJ Delorie @Cygnus who confirms this stuff- Update: 03/26 09:38 by CT : I've got a full blurb from DJ attached below: Worth reading. DJ Delorie writes "There's been a lot of rumors about Sony and Linux lately, but on Monday Cygnus will add fact to rumors by announcing that they've developed the next generation Playstation development tools that Sony will be distributing to game developers. Here's the basics: it includes gcc and gdb, runs on Linux, includes a GPL'd NG Playstation simulator, and will be available as part of the NG Playstation developer's kit.

The compiler targets Toshiba's new 128-bit CPU, and includes extensions to program the custom graphics chips in the next generation Playstation.

The simulator simulates most of the NG Playstation console, but you can't quite use it to play games on it - its CPU outperforms even a Pentium III. However, the simulator lets game designers debug things that would be impossible with hardware, and since it's GPL'd, they can modify it as needed to help them debug.

The tools will be available through Sony's usual developer channels as part of their hardware development systems, and yes, they'll be GPL (the compiler and simulator, at least) for those people who buy them. Cygnus will sell support contracts to game developers.

Eventually, of course, the changes to gcc, gdb, and other FSF programs will get rolled into the public releases.

You will be able to read the press releases on Monday.

Let the games begin! "

An anonymous reader linked us to a forbes article about the linux/playstation devel stuff that has been mentioned here like 9 times before. We've got some official word from DJ Delorie @Cygnus who confirms this stuff- Update: 03/26 09:38 by CT : I've got a full blurb from DJ attached below: Worth reading. DJ Delorie writes "There's been a lot of rumors about Sony and Linux lately, but on Monday Cygnus will add fact to rumors by announcing that they've developed the next generation Playstation development tools that Sony will be distributing to game developers. Here's the basics: it includes gcc and gdb, runs on Linux, includes a GPL'd NG Playstation simulator, and will be available as part of the NG Playstation developer's kit.

The compiler targets Toshiba's new 128-bit CPU, and includes extensions to program the custom graphics chips in the next generation Playstation.

The simulator simulates most of the NG Playstation console, but you can't quite use it to play games on it - its CPU outperforms even a Pentium III. However, the simulator lets game designers debug things that would be impossible with hardware, and since it's GPL'd, they can modify it as needed to help them debug.

The tools will be available through Sony's usual developer channels as part of their hardware development systems, and yes, they'll be GPL (the compiler and simulator, at least) for those people who buy them. Cygnus will sell support contracts to game developers.

Eventually, of course, the changes to gcc, gdb, and other FSF programs will get rolled into the public releases.

You will be able to read the press releases on Monday.

Let the games begin! "

An anonymous reader linked us to a forbes article about the linux/playstation devel stuff that has been mentioned here like 9 times before. We've got some official word from DJ Delorie @Cygnus who confirms this stuff- Update: 03/26 09:38 by CT : I've got a full blurb from DJ attached below: Worth reading. DJ Delorie writes "There's been a lot of rumors about Sony and Linux lately, but on Monday Cygnus will add fact to rumors by announcing that they've developed the next generation Playstation development tools that Sony will be distributing to game developers. Here's the basics: it includes gcc and gdb, runs on Linux, includes a GPL'd NG Playstation simulator, and will be available as part of the NG Playstation developer's kit.

The compiler targets Toshiba's new 128-bit CPU, and includes extensions to program the custom graphics chips in the next generation Playstation.

The simulator simulates most of the NG Playstation console, but you can't quite use it to play games on it - its CPU outperforms even a Pentium III. However, the simulator lets game designers debug things that would be impossible with hardware, and since it's GPL'd, they can modify it as needed to help them debug.

The tools will be available through Sony's usual developer channels as part of their hardware development systems, and yes, they'll be GPL (the compiler and simulator, at least) for those people who buy them. Cygnus will sell support contracts to game developers.

Eventually, of course, the changes to gcc, gdb, and other FSF programs will get rolled into the public releases.

You will be able to read the press releases on Monday.

Let the games begin! "

An Anonymous reader writes "Cygnus Solutions is changing its name. They're doing that in a Open Source/Free Software way by asking for net contributions. The selected contribution wins a fully loaded PII Linux workstation. Check it out. " Name the Company. Thats a new contest.

HP is contributing Java technology to Mauve, an alternative to Sun's Java Compatability Kit. This is good news for alternative Java implementations such as Kaffe, since the JCK is only available for a fee.

I'm the first to admit that I'm the last person who should write a book review. In fact, this is the first one I've posted on Slashdot. Frankly I don't read books any more- just web pages. I just don't have time- plus that whole paper thing doesn't appeal to me any more. But when "Open Sources:Voices from the Open Source Revolution" got here, I had no option but to read it. Immediately. Edited by Chris DiBona, Sam Ockman and Mark Stone, it's a collection of essays from Open Source glitterati with an impressive roster of names including ESR, RMS, Linus, Larry Wall, Bob Young, Tim O'Reilly, Bruce Perens and more. It's a wonderful read, hit the link below to read the rest. Open Sources

Each of these essays is an interesting read. The book starts off with ESRs 'Brief History of Hackerdom' which is an enjoyable read, although its a history that most of us are already familiar with. Marshall Kirk McKusick's piece follows with an in depth history of UNIX and BSD. Much of this information was new to me- it was one of my favorite sections in the book. And Linus talks about the Linux Kernel.

RMSs piece is, well, an RMS piece. Its interesting, but nothing new if you're familiar with RMS and the FSF. But if you aren't its an excellent little primer on the topic And that is important considering that this books target isn't as much the hacker, as it is the hacker's Boss. This is especially obvious after reading the articles by Bob Young and Michael Tiemann. Each article is an interesting look at the Open Source movement, but told through the eyes of the businessman.

Bruce Perens defines Open Source, A band of folks from Netscape including Tom Paquin talk about Mozilla from Netscape's perspective, and ESR writes a nice bit on the movement from the other side.

But my personal favorite bit is 'Diligence, Patience, and Humility' by Larry Wall. It seems curiously out of place in this book. Most every essay is a good read for "Your Boss" but this one is clearly for the artsy hacker type. Wall talks about communication, programming, philosophy, and pretty much anything else that comes to his mind in this humorous but insightful rambling essay. It alone was worth the price of admission.

So anyway, if your boss asks you what Open Source is, this is the book. If he ask you why it is, this is also the book. If you want to read an interesting collection of essays by the people who made this movement happen, this is the book. It is one of the few books that I'm glad I own- taking its place besides my few other favorite (mostly Dave Barry, Douglas Adams, and various O'Reilly Animal) dead tree editions. Highly recommended. A 9 out of 10.

If you are interested in purchasing this book, click here.

Table of Contents

Acknowledgments

Introduction
Chris DiBona, Sam Ockman, and Mark Stone

A Brief History of Hackerdom
Eric S. Raymond

Twenty Years of Berkeley Unix: From AT&T-Owned to Freely Redistributable
Marshall Kirk McKusick

The Internet Engineering Task Force
Scott Bradner

The GNU Operating System and the Free Software Movement
Richard Stallman

Future of Cygnus Solutions: An Entrepreneur's Account
Michael Tiemann

Software Engineering
Paul Vixie

The Linux Edge
Linus Torvalds

Giving It Away: How Red Hat Software Stumbled Across a New Economic Model and Helped Improve an Industry
Robert Young

Diligence, Patience, and Humility
Larry Wall

Open Source as a Business Strategy
Brian Behlendorf

The Open Source Definition
Bruce Perens

Hardware, Software, and Infoware
Tim O'Reilly

Freeing the Source: The Story of Mozilla
Jim Hamerly and Tom Paquin with Susan Walton

The Revenge of the Hackers
Eric S. Raymond

Appendix A: The Tanenbaum-Torvalds Debate

Appendix B: The Open Source Definition, Version 1.0

Sara Killingsworth wrote in with a press release from Be saying that they have selected Cygnus's GNUPro to be the compiler on their OS. I've attached the full press release below if you're curious. It mentions that Cygnus's compiler solution perfored 20% faster.

FOR IMMEDIATE RELEASE Contacts: Becky Wood DiSorbo (408) 542-9667 bwood@cygnus.com Sara Killingsworth

(602) 961-1515 saralk@home.com

CYGNUS GNUPRO TOOLS POWER BE OPERATING SYSTEM

Cygnus Solutions Delivers Software Development Tools that Increase Stability and Performance of Be, Inc.'s Media Operating Systems

SUNNYVALE, Calif., January 19, 1999 - Cygnus( Solutions today announced that Be(, Inc. selected Cygnus GNUPro software development tools for the recently shipped Release 4 of the Be Operating System (BeOS*). GNUPro(, the leading compiler and debugger toolchain for native and embedded development, provides BeOS developers with the software development power to work at maximum efficiency, and an open-source code base for greatest flexibility during the design cycle. According to recent tests conducted by Be, GNUPro tools performed 20 percent faster than other software development tools. More detailed information can be found at link "An operating system is nothing without good development tools. Giving our developers the best possible tools to work with helps them to create the fastest, most groundbreaking applications," said Scott Paterson, director of Marketing at Be. "As a leader in open-source software development technologies, Cygnus GNUPro enables Be developers to benefit from improved performance and a broader tool chain, which results in rapid innovation and high quality software." GNUPro provides a single-source toolchain for easy portability and maximum code reuse, and supports more than 125 host-target cross-development environments, covering the vast majority of the most popular host-target platforms. "Providing Be with Cygnus' GNUPro tools is further evidence of the increasing platform success of GNUPro and of open source technologies," said Scott Petry, vice president of marketing at Cygnus. "Cygnus ensures that open standard software development technologies, including GNUPro, are the most powerful resources available for commercial development."

About GNUPro
GNUPro includes ANSI-conforming C/C++ compilers, a macro-assembler, the Cygnus Insight( visual debugger, binary utilities, libraries, and broad support for Windows NT/95 and UNIX hosted toolkits. Users benefit from Cygnus' premier software engineering, availability of tools for a wide range of processors, stringent testing (more than five million controlled and documented tests against each host-target combination) and custom enhancements. Cygnus delivers GNUPro through an innovative subscription model that includes regular software upgrades, featuring the latest innovations in GNU technology, as well as mission-critical support services for rapid response and resolution of technical questions or problems. Pricing for a five-user team starts at $7,495 and includes a one-year subscription. For more information on GNUPro pricing and the more than 125 host-target cross-development environments supported by Cygnus GNUPro, contact Cygnus corporate headquarters in Sunnyvale, Calif. at 1-408-542-9600, 1-800-CYGNUS-1, info@cygnus.com, or visit the Web site at link

About Be
Be, Inc., founded in 1990 by Jean-Louis Gassée, is a software company focusing on building new foundations for the next generation of digital content and media design tools. With a team of industry-leading engineers and business executives in the United States and Europe, the company is dedicated to removing the limitations of existing computer architectures and delivering a new level of price performance. In December 1998, Be published Release 4 of the Be Operating System (BeOS), the core product of this strategy. Additional information on Be and the BeOS is available online at link Be, Inc. is headquartered in Menlo Park, California.

About Cygnus Solutions
The market leader in software development technologies for computing applications, Cygnus( Solutions offers build-time and run-time solutions based on an open-source model. From GNUPro( Toolkit to eCos(, the Embedded Cygnus Operating System, Cygnus' open-source and royalty-free software benefits system developers in a wide variety of market segments, including consumer electronics, Internet, telecommunications, office automation, networking, aerospace and automotive. Cygnus' products, custom engineering services, and world-class support services enable developers to bring products to market faster at reduced system development costs. Founded in 1989, with headquarters in Sunnyvale, California, Cygnus has sales and engineering offices throughout North America, Japan, and the United Kingdom.

Cygnus GNUPro Powers BeOS Page 2

*Cygnus and GNUPro are registered trademarks, and Sourceware and eCos are trademarks of Cygnus Solutions. Open Source is a Certification Mark of the Open Source Initiative. All other company and product names are trademarks of their respective owners. "

David Welton writes "eCos has been released, at Cygnus's site. I wonder if something like this would run well (better than linux) on a palmpilot, or similiar platforms? I haven't investigated eCos much. " An open source an embeded OS strikes me as being an excellent idea...

Bob Young gave an interview to techweb in which he states that the Intel deal with Red Hat is not intended to give Red Hat a heads start over other Linux distributors. Ed: It would be great if Red Hat convinces Intel to make pre-announcement technology information available to the whole Linux development community. Rather like Cygnus, it appears that Red Hat does not depend on loans. This is good, and hopefully their prudent strategy will mean that if they IPO they'll keep 51% of their stock so that they cannot be bought out (and killed).

Maciej Stachowiak writes "Cygnus announced a new Open Source Real Time Operating System for the embedded market today. A press release is available. Further information, including licensing and preliminary documentation, is available. This is a good thing for the embedded market, which has always needed highly customizable solutions. "

Maciej Stachowiak writes "Cygnus announced a new Open Source Real Time Operating System for the embedded market today. A press release is available. Further information, including licensing and preliminary documentation, is available. This is a good thing for the embedded market, which has always needed highly customizable solutions. "

Drew Bertola wrote in to let us know Tom Tromey and some of the other guys at Cygnus have the basics of a development enviornment for Java going, including a gcc front end called gjc (which cannot yet create Java executables). The software is being integrated into EGCS. Check it out. (Sorry about the gcj mistake - I had a bit of a headache at 2am)

Aric wrote in to send us a link to the egcs ftp site, along with the simple note that egcs-1.1 has now officially hit the wire. Download, and may your code be optimized.

As part of their 20,000 member drive, the Java Lobby is teaming up with the Java Journal to offer every one of their members a free subscription for a year. This offer is unlike most others in that people who live outside the US can also benefit... In related news, there's a rather interesting article about Java Virtual Machine performance showing that Linux has far to go. But has anyone performed a VolcanoMark test under Kaffe? On the other hand, TowerJ's native compiler does rather well... I wonder what performance Cygnus' offering will have (it's based on gcc and compiles native code).

The NSCA has done some not-very-novel research: build a cluster of computers and solve a parallelisable problem on it. The novelty? Well it runs on NT, so now Microsoft is crowing that NT is wonderfully scalable. As contributor Mark Harrison points out: "I figure if this NT cluster is using NT Server, which it must if it it is using more than 10 TCP/IP connections per node (I know nothing about these parallel systems, but with 124 two-processor nodes, each node must communicate with more than ten other nodes). NT server costs a bunch (about $1,000 per licence, I believe), so the cost is $124,000 for the OS. So much for their tagline, "High-Performance Supercomputing at Mail-Order Prices." How about "Save $123,975 on your supercomputer -- Use Extreme Linux." " Well... it might be time to help Ben Elliston who presented his encapsulation of IP in SCSI in August's Linux Journal which has a higher throughput than ethernet.

This is the first of a series of articles investigating the interplay between Open Source Software and commercial vendors. The common thread will be to find out how authors have earned a living from writing and servicing GPL/Open Source Software.

The series kicks off with Michael Tiemann, one of the founders of Cygnus Solutions, and author of the C++ component of GCC. Cygnus is one of the pioneers in commercial support for open-source software. It sells support and customization services for the gnu programming tools (gcc, gdb, ld, etc). Initially, the Free Software Foundation applauded this, but more recently, RMS feels that by also selling proprietary software Cygnus has betrayed the principle of free software.

In this interview, Michael discusses what it takes to set up a business based on open source software, what Cygnus hopes to add to GCC, and why they took the decision to sell closed source software.

What is written in red, is what Michael wrote to me in an email
What is written in green, is what I transcribed from my notes of our telephone interview. Any mistakes therein are mine.

• How difficult was it for you to set up Cygnus Solutions?
• • How did the banks cope with Cygnus' non orthodox business model?
  • How difficult was it to find the first customers?
  • What advice could you give someone who has written a GPL'd (or similar) program, and wants to live off it by providing services to commercial users?
  • Can one survive purely on the provision of services?
  • What types of services have you found to be the most important for commercial customers? What sort of guaranties do they want? What should one pay special attention to?

• • The greatest challenge in setting up Cygnus was in finding a name under which we could do business. This is not a joke...for three months we went through a process of finding a name, submitting it to the dept. of corporations, only to learn that the name had already been taken. We were about to give up hope when such an ugly name as "Software Support, Inc." had been registered the same year we tried to get it. When we learned that Cygnus Support (note the embedded GNU in Cygnus) was ours to use, we were overjoyed.

    Cygnus was started with virtually no money. At the time, I wanted John Gilmore (whose userid was gnu@sun.com) to be one of the founders (he was employee #5 at Sun, and was the guy who ported BSD Unix to the 68020), not for his money, but for hus programming skills. I put _my_ money where my mouth was, proposing that all three founders put in the same amount of money at the start. At that time, I had less than $3000 in the bank, so I proposed we each put in $2000 at the start, and raise the ante to $5000 when I could afford it. As you can see, we did _nothing_ to try to get banks interested, so there was nothing to explain to them.

    As for finding the first customers...it was just a matter of knocking enough times on the correct doors. As the author of GNU C++, it was pretty easy for me to talk to high-level technical people, who would then introduce me to mid-level managers. We sold GNU support primarily as a cost-saving measure, so we did not need VP level approval. Nowadays we have a much more strategic sell, but we're also much better established, so we can call on and get VP level approvals.

    I've always advised everybody that if they want to start a free software business, they should not let anything stop them. Of those who did, most managed to break even or make a small profit, leading me to believe that there's more to Cygnus's success than merely addressing a market opportunity. We've always been willing to make tough decisions, and we've always listened to customers, even when they were yelling at the top of their voices. Those who do free software for love, rather than money, are not going to survive what we've been through.

    As far as what customers really want...they want somebody who will listen to their needs, formulate a long-term plan, and then deliver without a lot of hassle or risk. Some customers like to see you work; others like to see the work you do; still others think you are doing a great job if they never see you. In the end, it's not the guarantees you offer that make customers come back..it's what you can deliver. The free software model is unique in that it actually gives an incentive for customers to work with you, not independently from you. In the fast-moving high tech world, that advantage has put us in the #1 spot in our market...no mean feat.

• Cygnus and the FSC (Free Software Community)
• • What exactly are you providing to the FSC?

• • We pour about $10M/year into the development of new free software. We run the servers from which 500,000 people have downloaded our stuff. We promote the concept of free software in articles, conferences, and advertising. We sponsor free software projects and pay free software contractors who do work that's related to our business requirements (though not something we'd directly commercialize). We provide a generous matching fund so that employees and customers who want to donate to the FSF can see their donation multiplied.

• How long does it take for your new code to be released in Egcs, or other freely downloadable source code?

• • The std deviation of this number makes an average number meaningless. If you download EGCS, I'll bet that the ChangeLog entries are no more than 45 days old. Compare that to other FSF-controlled packages where they can be months or years old. It is important to realize that we don't control when the FSF releases code.

• How much do you feel you are getting from the FSC? Would it have been simpler to write you own compiler?

• • Simpler, perhaps. But we would not have been able to distinguish ourselves from the other N proprietary companies. I mentioned earlier that people are now chosing Cygnus not because we are cheaper, but because we are _strategic_. We could not have achieved that strategic positioning in the compiler space in any other way.

• What overhead is there with working with the FSC?

• • It's whatever you want. Some people like to spend hours arguing about indentation styles. Others just decide they are going to do somthing and they do it. I wrote the first native-code C++ compiler in 6 month in 1987. It was hard work, and it was rough, but once I demonstrated the momentum I could sustains, dozens joined to the GCC/G++ team.

    In 1989, when GCC 1.x was getting fairly mature, I wrote an instruction scheduler, re-wrote a branch scheduler that had been abandoned, and wrote several cool new optimizations that could not easily fit with GCC 1.x. I declared that we should start GCC 2, with the goal of integrating this new work, new C++ language features, and an eye towards optimal code generation for RISC machines.

    GCC 2.x is now reaching maturity, and it's just not possible to preserve that kind of stability with the while working on advanced/experimental/cool new stuff we want to do. Hence we created EGCS. I've been amazed at the number and quality of volunteers who are now working on that branch. Thus, for GCC 2, the overhead is high, whereas for EGCS, the overhead is negative.

• What sort of friction is there between immediate customer concerns and the interests of the FSC?

• • No difference to any other scarce-resource problem.

• • The FSF's objective is a free software world. The customer's objective is a solution that satisfies his needs. The problem is that commercial work always pays more, so more people do that, which frustrates the FSF that not more people are on its bandwagon.

• Which strengths do you see in the Bazaar and Cathedral models of free software development?

• • Although Eric Raymond is very good at coming up with beautiful theories, I dispute whether they are a true reflection of reality. I see GNU and Linux as two cathedrals. Both Linux and RMS are benevolent dictators. What sets them apart is that Linus is willing to take more risks, to rewrite more of his software, while RMS is a perfectionist. Overall, I believe that risks win, and the risk of reimplementing things lead to a better result. Eric and I were both at the Foresight institute to discuss Netscape releasing their source code. Eric said that Cygnus's model was to provide service to commercial customers for free software products, while Netscape was going to lead the standards with its Free software strategy. I disagree with this since Cygnus too is leading the standards in the embedded market with free software.

• Why did you decide to sell software without source-code, given that this soured your relation with the FSF?

• • We measure success in $$, not FSF relationship. Free software works great for support, not for products.

    Cygnus has been very successful at its challenge. In 8 years we've become the number one tool supplier for the embedded market. Our growth is limited only by the number of sales and technical people we can find to employ. I expect our business will be eventually worth 100 of millions dollars per year. But this has taken lots of effort, and is only achieved by making life easy for our customers. For instance, we support 17 different host-target combinations for Cisco alone. Their routers' CPUs vary from the very simple basic RISC chip to very complex CISC chips with fancy features, yet they want the same code to work on any host-target combination. Contrast this to Sun or Microsoft where the same code will not work on SunOS 4/Solaris or Windows 95/NT. We support SGI, HP, NT (etc) so that our customers do not have to decide on their platform because of us. In total we support 170 different host-target combinations.

    The proprietary model and the free software model provide two different kinds of simplicity. The free software model provides simplicity of APIs: there is no need to waste time reverse-engineering things if you have source. The proprietary model provides simplicity of control: your software does not go off and have a life of its own, you can control your investment, your price points and focus on command performance rather than spend time on building a consensus. For instance, say we have two customers, one of whom has a bad bug he needs fixed, the other of whom has sent us an enhancement to our product. Say furthermore that we only have enough time to service one of their needs. If we fix the bug, then the customer who sent us the enhancement will be disappointed -- they did what the GPL said to do --, and they will wonder why they need support from us, since the guys on the net included their enhancement while we did not. If we add the enhancement, then one of our customers still has a bug, and if he cares nothing for having the source-code, he will look somewhere else for business. So adopting the proprietary model allows us to control our strategy. If the need for strategic control disappears then the software can become free, but this might never happen. For instance, dejagnu was not planned to be commercial software, so we put on the net to get help from the people out there.

    In my opinion, Sun has done a bad job at being a software leader, as has Microsoft. What GNU and Linux are doing is pushing the envelope back up.

• You provide compilers for the embedded market

• • Yes. The embedded market is very different from the traditional desktop market. For instance, the object files that became popular in the embedded market differ from those used in the desktop/workstation markets. Originally embedded people worked on Sun 3's and cross-compiled 68000 code into a.out executables. But a.out has limitations such as not allowing multiple data sections. New formats were devised to address this and other issues.

    Another difference is the embedded market is extremely cost-conscious. For instance, the money made on cellular telephones is made on the subscription. Thus the bill of materials for a cellular telephone must be extremely low. Similarly, end-product functionality is more of a concern that compatibility. Because RISC processors provide approximately twice the compute-power for half the electric power of a CISC processor, they are being adopted more rapidly than in the PC market. MIPS is now dethroning the previous king of the embedded world, the 68000 family, having sold 44 million units last year versus 68000's 42 million.

    Providing one same set of compilers for a wide variety of chips has made us into the standard for the embedded market. We have close ties with CPU companies, such as Toshiba, so that each new chip is released with a new version of our compiler. This makes it easy for our customers to choose which ever chip will give the best cost/performance ratio, without worrying about high porting costs.

• What features did you have to add for this market?

• • We added many features that improve code performance and code size. We provide a very lean and mean implementation of C++ to allow embedded programmers to use the C++ features they need. Indeed, we were the first to ship C++ for the embedded world, for Nortel in 1990. We've added the ability to control via #pragmas the type of return code the compiler should use, so that interrupt routines can be written in C. Another embedded feature is the ability to specify into which segment each function should go. And to help our customers migrate rapidly from chip architecture to chip architecture, we have a whole series of #pragmas to control the way in which data structures are laid out in memory. This allows them to have binary compatibility of data structures even if the code was originally written to access words at odd boundaries, but the target processor does not allow this.

• Are there any new #pragma like commands to control code size at a lower granularity (e.g.: for single functions)

• Are there any new #pragma like commands to control speed as a lower granularity (e.g.: for single functions)

• • We find generally that programmers want the same level of optimization for a particular module. However some optimizations of that kind are described in the processor specific optimization documentation: these are processor dependent trade-offs. For instance, on an R10000 (MIPS), bigger code is faster in that keeps all 4 pipes full. On the other hand, we had to deal with very high space constraints when we worked with Sega. They used the Gnu compiler for the Sega Saturn. And although the SH (Super Hitachi processor) encodes 32 bit instructions into 16 bits, we had to change the compiler significantly to cope with the fact that loading immediate values (such as 57) is very convoluted: you read the value then jump over it, making immediate value loads very expensive when the compiler assumed they would be cheap.

    Generally, we think code size will become less and less of an issue: at the rate at which chips are shrinking and processes are improving (such as the extreme Ultra Violet process), the average DRAM chip will contain 1.7 Gbits in 2001 and 237 Gbits in 2012. Bandwidth problems will be alleviated by developments such as Mitsubishi's M32R chip, which has a core on a 16 Mbit ram, and has a huge bandwidth.

• Do you have any benchmarks to compare the current GCC levels of compilation (code size, speed) with compilers from Metaware, IBM, Microsoft, Borland, Symantec, Intel's VTUNE, etc?

• • We use the Bench++ benchmark. In contrast to SPEC benchmarks, this uses Stepanov's abstraction benchmark to determine the cost of various C++ features. For instance at the 0th level of abstraction, the code uses an integer, at the 1st it uses a double, then a class with a double member, then a class with a double pointer member... including template iterators until the 12th level is reached. GNU beats Sun and HP's compilers by a factor of 10. Similarly, GNU exception handling is 10 times faster than HP's.

    In terms of the SPEC base benchmarks EGCS attains the same level as SGI's compiler (the best in the business) with -O and -O2 options. Beyond that, SGI allows one to specify tons of options, such as cache size, which generates better code. However no one actually uses these options, so it's not much of an issue.

    As a company, other than the CygWin guys, we don't compare ourselves with the PC guys, so I can't give you a comparison. The DJGPP guys may have some info. Metaware is a non factor for us, since none of our customers complain about our performance.

• Future trends
  • What new features would you like to see in future revisions of GCC?

• • We'd like to see a good implementation bridging the gap between C/C++ and Java. There are good ideas in Java. It provides open standards that are very important to the downloadable world I believe will arise in the future: it provides a simple way to connect to the web, which essential to achieving an information aware infrastructure.

    However Sun's current behaviour is very worrying. Anything that Sun writes becomes a Java API. This is not unlike Microsoft, who redefined C APIs, even though a standard existed (POSIX), to such an extent that even "hello world" will not work (stdout and stderr are not available from winMain()). Sun is playing a similar game with Java, and we fear it will lead to incompatibilities, balkanizing Java, and letting the competition win. Although Sun snipes free versions of Java, all it is doing is replaying the Unix wars. We hope that GCC will be the free standard wedge that keeps the door open.

• What do you think of the idea that programs are JIT compiled to optimize the features being used, to maximize memory efficiency (as Intel's VTUNE does) while minimizing total footprint by leaving most of the code in a compressed bytecode format (as www.tao.co.uk is suggesting).

• • We view the problem rather differently: what do you want to use your CPU power for? Do you want to use it for JIT compilation, or for running the application? We think the latter. So the JIT should be done on the server. There is no reason why your processor could not identify itself to the server and let the server produce whatever native implementation is best for it. Profile information could also be sent to the server in this way. We will be showing in an upcoming Dr Dobbs Journal, that the performance one can achieve in native-compiled Java is comparable to that of C. Speedwise, this is a better solution than a Java chip, because Lisp Machines have already shown us that register based machines present many more opportunities for optimizations than stack machines. Powerwise it is also advantageous as compilation is rather expensive on a battery. Even in terms of code size, gzip compressed 32 bit RISC code is comparable in size to the equivalent byte-code.

• What do you think of IBM's idea of simplifying processor state-machines to increase frequency by moving more of the complexity to software?

• • Like EPIC, the proof will be in the proverbial pudding. Different RISC implementations vary greatly in power, although in principle they should provide similar levels of performance. For instance, a 200 Mhz R10000 provides a similar level of performance to a 600 Mhz Alpha.

• Do you anticipate commercial proprietary source-code will at the end of the day dominate the market-place, or do you feel that free software backed up by a service industry will take over?

• • I think the distinction will be like the difference between public and private life. While we may let all the people on the net look at our source-code we don't let them play with our money. I believe that free software will determine the standards in the world. Proprietary software will exist in niches, where customers don't care for the source code. Instead of spending time building a concensus, proprietary software allows a company to focus on producing a piece of software as quickly as possible to catch a market opportunity. For instance, we use ORACLE's database software. We don't have the source-code, and don't want it because its internal complexity is irrelevant to us: we just want to use it.

This is the first of a series of articles investigating the interplay between Open Source Software and commercial vendors. The common thread will be to find out how authors have earned a living from writing and servicing GPL/Open Source Software.

The series kicks off with Michael Tiemann, one of the founders of Cygnus Solutions, and author of the C++ component of GCC. Cygnus is one of the pioneers in commercial support for open-source software. It sells support and customization services for the gnu programming tools (gcc, gdb, ld, etc). Initially, the Free Software Foundation applauded this, but more recently, RMS feels that by also selling proprietary software Cygnus has betrayed the principle of free software.

In this interview, Michael discusses what it takes to set up a business based on open source software, what Cygnus hopes to add to GCC, and why they took the decision to sell closed source software.

What is written in red, is what Michael wrote to me in an email
What is written in green, is what I transcribed from my notes of our telephone interview. Any mistakes therein are mine.

• How difficult was it for you to set up Cygnus Solutions?
• • How did the banks cope with Cygnus' non orthodox business model?
  • How difficult was it to find the first customers?
  • What advice could you give someone who has written a GPL'd (or similar) program, and wants to live off it by providing services to commercial users?
  • Can one survive purely on the provision of services?
  • What types of services have you found to be the most important for commercial customers? What sort of guaranties do they want? What should one pay special attention to?

• • The greatest challenge in setting up Cygnus was in finding a name under which we could do business. This is not a joke...for three months we went through a process of finding a name, submitting it to the dept. of corporations, only to learn that the name had already been taken. We were about to give up hope when such an ugly name as "Software Support, Inc." had been registered the same year we tried to get it. When we learned that Cygnus Support (note the embedded GNU in Cygnus) was ours to use, we were overjoyed.

    Cygnus was started with virtually no money. At the time, I wanted John Gilmore (whose userid was gnu@sun.com) to be one of the founders (he was employee #5 at Sun, and was the guy who ported BSD Unix to the 68020), not for his money, but for hus programming skills. I put _my_ money where my mouth was, proposing that all three founders put in the same amount of money at the start. At that time, I had less than $3000 in the bank, so I proposed we each put in $2000 at the start, and raise the ante to $5000 when I could afford it. As you can see, we did _nothing_ to try to get banks interested, so there was nothing to explain to them.

    As for finding the first customers...it was just a matter of knocking enough times on the correct doors. As the author of GNU C++, it was pretty easy for me to talk to high-level technical people, who would then introduce me to mid-level managers. We sold GNU support primarily as a cost-saving measure, so we did not need VP level approval. Nowadays we have a much more strategic sell, but we're also much better established, so we can call on and get VP level approvals.

    I've always advised everybody that if they want to start a free software business, they should not let anything stop them. Of those who did, most managed to break even or make a small profit, leading me to believe that there's more to Cygnus's success than merely addressing a market opportunity. We've always been willing to make tough decisions, and we've always listened to customers, even when they were yelling at the top of their voices. Those who do free software for love, rather than money, are not going to survive what we've been through.

    As far as what customers really want...they want somebody who will listen to their needs, formulate a long-term plan, and then deliver without a lot of hassle or risk. Some customers like to see you work; others like to see the work you do; still others think you are doing a great job if they never see you. In the end, it's not the guarantees you offer that make customers come back..it's what you can deliver. The free software model is unique in that it actually gives an incentive for customers to work with you, not independently from you. In the fast-moving high tech world, that advantage has put us in the #1 spot in our market...no mean feat.

• Cygnus and the FSC (Free Software Community)
• • What exactly are you providing to the FSC?

• • We pour about $10M/year into the development of new free software. We run the servers from which 500,000 people have downloaded our stuff. We promote the concept of free software in articles, conferences, and advertising. We sponsor free software projects and pay free software contractors who do work that's related to our business requirements (though not something we'd directly commercialize). We provide a generous matching fund so that employees and customers who want to donate to the FSF can see their donation multiplied.

• How long does it take for your new code to be released in Egcs, or other freely downloadable source code?

• • The std deviation of this number makes an average number meaningless. If you download EGCS, I'll bet that the ChangeLog entries are no more than 45 days old. Compare that to other FSF-controlled packages where they can be months or years old. It is important to realize that we don't control when the FSF releases code.

• How much do you feel you are getting from the FSC? Would it have been simpler to write you own compiler?

• • Simpler, perhaps. But we would not have been able to distinguish ourselves from the other N proprietary companies. I mentioned earlier that people are now chosing Cygnus not because we are cheaper, but because we are _strategic_. We could not have achieved that strategic positioning in the compiler space in any other way.

• What overhead is there with working with the FSC?

• • It's whatever you want. Some people like to spend hours arguing about indentation styles. Others just decide they are going to do somthing and they do it. I wrote the first native-code C++ compiler in 6 month in 1987. It was hard work, and it was rough, but once I demonstrated the momentum I could sustains, dozens joined to the GCC/G++ team.

    In 1989, when GCC 1.x was getting fairly mature, I wrote an instruction scheduler, re-wrote a branch scheduler that had been abandoned, and wrote several cool new optimizations that could not easily fit with GCC 1.x. I declared that we should start GCC 2, with the goal of integrating this new work, new C++ language features, and an eye towards optimal code generation for RISC machines.

    GCC 2.x is now reaching maturity, and it's just not possible to preserve that kind of stability with the while working on advanced/experimental/cool new stuff we want to do. Hence we created EGCS. I've been amazed at the number and quality of volunteers who are now working on that branch. Thus, for GCC 2, the overhead is high, whereas for EGCS, the overhead is negative.

• What sort of friction is there between immediate customer concerns and the interests of the FSC?

• • No difference to any other scarce-resource problem.

• • The FSF's objective is a free software world. The customer's objective is a solution that satisfies his needs. The problem is that commercial work always pays more, so more people do that, which frustrates the FSF that not more people are on its bandwagon.

• Which strengths do you see in the Bazaar and Cathedral models of free software development?

• • Although Eric Raymond is very good at coming up with beautiful theories, I dispute whether they are a true reflection of reality. I see GNU and Linux as two cathedrals. Both Linux and RMS are benevolent dictators. What sets them apart is that Linus is willing to take more risks, to rewrite more of his software, while RMS is a perfectionist. Overall, I believe that risks win, and the risk of reimplementing things lead to a better result. Eric and I were both at the Foresight institute to discuss Netscape releasing their source code. Eric said that Cygnus's model was to provide service to commercial customers for free software products, while Netscape was going to lead the standards with its Free software strategy. I disagree with this since Cygnus too is leading the standards in the embedded market with free software.

• Why did you decide to sell software without source-code, given that this soured your relation with the FSF?

• • We measure success in $$, not FSF relationship. Free software works great for support, not for products.

    Cygnus has been very successful at its challenge. In 8 years we've become the number one tool supplier for the embedded market. Our growth is limited only by the number of sales and technical people we can find to employ. I expect our business will be eventually worth 100 of millions dollars per year. But this has taken lots of effort, and is only achieved by making life easy for our customers. For instance, we support 17 different host-target combinations for Cisco alone. Their routers' CPUs vary from the very simple basic RISC chip to very complex CISC chips with fancy features, yet they want the same code to work on any host-target combination. Contrast this to Sun or Microsoft where the same code will not work on SunOS 4/Solaris or Windows 95/NT. We support SGI, HP, NT (etc) so that our customers do not have to decide on their platform because of us. In total we support 170 different host-target combinations.

    The proprietary model and the free software model provide two different kinds of simplicity. The free software model provides simplicity of APIs: there is no need to waste time reverse-engineering things if you have source. The proprietary model provides simplicity of control: your software does not go off and have a life of its own, you can control your investment, your price points and focus on command performance rather than spend time on building a consensus. For instance, say we have two customers, one of whom has a bad bug he needs fixed, the other of whom has sent us an enhancement to our product. Say furthermore that we only have enough time to service one of their needs. If we fix the bug, then the customer who sent us the enhancement will be disappointed -- they did what the GPL said to do --, and they will wonder why they need support from us, since the guys on the net included their enhancement while we did not. If we add the enhancement, then one of our customers still has a bug, and if he cares nothing for having the source-code, he will look somewhere else for business. So adopting the proprietary model allows us to control our strategy. If the need for strategic control disappears then the software can become free, but this might never happen. For instance, dejagnu was not planned to be commercial software, so we put on the net to get help from the people out there.

    In my opinion, Sun has done a bad job at being a software leader, as has Microsoft. What GNU and Linux are doing is pushing the envelope back up.

• You provide compilers for the embedded market

• • Yes. The embedded market is very different from the traditional desktop market. For instance, the object files that became popular in the embedded market differ from those used in the desktop/workstation markets. Originally embedded people worked on Sun 3's and cross-compiled 68000 code into a.out executables. But a.out has limitations such as not allowing multiple data sections. New formats were devised to address this and other issues.

    Another difference is the embedded market is extremely cost-conscious. For instance, the money made on cellular telephones is made on the subscription. Thus the bill of materials for a cellular telephone must be extremely low. Similarly, end-product functionality is more of a concern that compatibility. Because RISC processors provide approximately twice the compute-power for half the electric power of a CISC processor, they are being adopted more rapidly than in the PC market. MIPS is now dethroning the previous king of the embedded world, the 68000 family, having sold 44 million units last year versus 68000's 42 million.

    Providing one same set of compilers for a wide variety of chips has made us into the standard for the embedded market. We have close ties with CPU companies, such as Toshiba, so that each new chip is released with a new version of our compiler. This makes it easy for our customers to choose which ever chip will give the best cost/performance ratio, without worrying about high porting costs.

• What features did you have to add for this market?

• • We added many features that improve code performance and code size. We provide a very lean and mean implementation of C++ to allow embedded programmers to use the C++ features they need. Indeed, we were the first to ship C++ for the embedded world, for Nortel in 1990. We've added the ability to control via #pragmas the type of return code the compiler should use, so that interrupt routines can be written in C. Another embedded feature is the ability to specify into which segment each function should go. And to help our customers migrate rapidly from chip architecture to chip architecture, we have a whole series of #pragmas to control the way in which data structures are laid out in memory. This allows them to have binary compatibility of data structures even if the code was originally written to access words at odd boundaries, but the target processor does not allow this.

• Are there any new #pragma like commands to control code size at a lower granularity (e.g.: for single functions)

• Are there any new #pragma like commands to control speed as a lower granularity (e.g.: for single functions)

• • We find generally that programmers want the same level of optimization for a particular module. However some optimizations of that kind are described in the processor specific optimization documentation: these are processor dependent trade-offs. For instance, on an R10000 (MIPS), bigger code is faster in that keeps all 4 pipes full. On the other hand, we had to deal with very high space constraints when we worked with Sega. They used the Gnu compiler for the Sega Saturn. And although the SH (Super Hitachi processor) encodes 32 bit instructions into 16 bits, we had to change the compiler significantly to cope with the fact that loading immediate values (such as 57) is very convoluted: you read the value then jump over it, making immediate value loads very expensive when the compiler assumed they would be cheap.

    Generally, we think code size will become less and less of an issue: at the rate at which chips are shrinking and processes are improving (such as the extreme Ultra Violet process), the average DRAM chip will contain 1.7 Gbits in 2001 and 237 Gbits in 2012. Bandwidth problems will be alleviated by developments such as Mitsubishi's M32R chip, which has a core on a 16 Mbit ram, and has a huge bandwidth.

• Do you have any benchmarks to compare the current GCC levels of compilation (code size, speed) with compilers from Metaware, IBM, Microsoft, Borland, Symantec, Intel's VTUNE, etc?

• • We use the Bench++ benchmark. In contrast to SPEC benchmarks, this uses Stepanov's abstraction benchmark to determine the cost of various C++ features. For instance at the 0th level of abstraction, the code uses an integer, at the 1st it uses a double, then a class with a double member, then a class with a double pointer member... including template iterators until the 12th level is reached. GNU beats Sun and HP's compilers by a factor of 10. Similarly, GNU exception handling is 10 times faster than HP's.

    In terms of the SPEC base benchmarks EGCS attains the same level as SGI's compiler (the best in the business) with -O and -O2 options. Beyond that, SGI allows one to specify tons of options, such as cache size, which generates better code. However no one actually uses these options, so it's not much of an issue.

    As a company, other than the CygWin guys, we don't compare ourselves with the PC guys, so I can't give you a comparison. The DJGPP guys may have some info. Metaware is a non factor for us, since none of our customers complain about our performance.

• Future trends
  • What new features would you like to see in future revisions of GCC?

• • We'd like to see a good implementation bridging the gap between C/C++ and Java. There are good ideas in Java. It provides open standards that are very important to the downloadable world I believe will arise in the future: it provides a simple way to connect to the web, which essential to achieving an information aware infrastructure.

    However Sun's current behaviour is very worrying. Anything that Sun writes becomes a Java API. This is not unlike Microsoft, who redefined C APIs, even though a standard existed (POSIX), to such an extent that even "hello world" will not work (stdout and stderr are not available from winMain()). Sun is playing a similar game with Java, and we fear it will lead to incompatibilities, balkanizing Java, and letting the competition win. Although Sun snipes free versions of Java, all it is doing is replaying the Unix wars. We hope that GCC will be the free standard wedge that keeps the door open.

• What do you think of the idea that programs are JIT compiled to optimize the features being used, to maximize memory efficiency (as Intel's VTUNE does) while minimizing total footprint by leaving most of the code in a compressed bytecode format (as www.tao.co.uk is suggesting).

• • We view the problem rather differently: what do you want to use your CPU power for? Do you want to use it for JIT compilation, or for running the application? We think the latter. So the JIT should be done on the server. There is no reason why your processor could not identify itself to the server and let the server produce whatever native implementation is best for it. Profile information could also be sent to the server in this way. We will be showing in an upcoming Dr Dobbs Journal, that the performance one can achieve in native-compiled Java is comparable to that of C. Speedwise, this is a better solution than a Java chip, because Lisp Machines have already shown us that register based machines present many more opportunities for optimizations than stack machines. Powerwise it is also advantageous as compilation is rather expensive on a battery. Even in terms of code size, gzip compressed 32 bit RISC code is comparable in size to the equivalent byte-code.

• What do you think of IBM's idea of simplifying processor state-machines to increase frequency by moving more of the complexity to software?

• • Like EPIC, the proof will be in the proverbial pudding. Different RISC implementations vary greatly in power, although in principle they should provide similar levels of performance. For instance, a 200 Mhz R10000 provides a similar level of performance to a 600 Mhz Alpha.

• Do you anticipate commercial proprietary source-code will at the end of the day dominate the market-place, or do you feel that free software backed up by a service industry will take over?

• • I think the distinction will be like the difference between public and private life. While we may let all the people on the net look at our source-code we don't let them play with our money. I believe that free software will determine the standards in the world. Proprietary software will exist in niches, where customers don't care for the source code. Instead of spending time building a concensus, proprietary software allows a company to focus on producing a piece of software as quickly as possible to catch a market opportunity. For instance, we use ORACLE's database software. We don't have the source-code, and don't want it because its internal complexity is irrelevant to us: we just want to use it.

This is the first of a series of articles investigating the interplay between Open Source Software and commercial vendors. The common thread will be to find out how authors have earned a living from writing and servicing GPL/Open Source Software.

The series kicks off with Michael Tiemann, one of the founders of Cygnus Solutions, and author of the C++ component of GCC. Cygnus is one of the pioneers in commercial support for open-source software. It sells support and customization services for the gnu programming tools (gcc, gdb, ld, etc). Initially, the Free Software Foundation applauded this, but more recently, RMS feels that by also selling proprietary software Cygnus has betrayed the principle of free software.

In this interview, Michael discusses what it takes to set up a business based on open source software, what Cygnus hopes to add to GCC, and why they took the decision to sell closed source software.

What is written in red, is what Michael wrote to me in an email
What is written in green, is what I transcribed from my notes of our telephone interview. Any mistakes therein are mine.

• How difficult was it for you to set up Cygnus Solutions?
• • How did the banks cope with Cygnus' non orthodox business model?
  • How difficult was it to find the first customers?
  • What advice could you give someone who has written a GPL'd (or similar) program, and wants to live off it by providing services to commercial users?
  • Can one survive purely on the provision of services?
  • What types of services have you found to be the most important for commercial customers? What sort of guaranties do they want? What should one pay special attention to?

• • The greatest challenge in setting up Cygnus was in finding a name under which we could do business. This is not a joke...for three months we went through a process of finding a name, submitting it to the dept. of corporations, only to learn that the name had already been taken. We were about to give up hope when such an ugly name as "Software Support, Inc." had been registered the same year we tried to get it. When we learned that Cygnus Support (note the embedded GNU in Cygnus) was ours to use, we were overjoyed.

    Cygnus was started with virtually no money. At the time, I wanted John Gilmore (whose userid was gnu@sun.com) to be one of the founders (he was employee #5 at Sun, and was the guy who ported BSD Unix to the 68020), not for his money, but for hus programming skills. I put _my_ money where my mouth was, proposing that all three founders put in the same amount of money at the start. At that time, I had less than $3000 in the bank, so I proposed we each put in $2000 at the start, and raise the ante to $5000 when I could afford it. As you can see, we did _nothing_ to try to get banks interested, so there was nothing to explain to them.

    As for finding the first customers...it was just a matter of knocking enough times on the correct doors. As the author of GNU C++, it was pretty easy for me to talk to high-level technical people, who would then introduce me to mid-level managers. We sold GNU support primarily as a cost-saving measure, so we did not need VP level approval. Nowadays we have a much more strategic sell, but we're also much better established, so we can call on and get VP level approvals.

    I've always advised everybody that if they want to start a free software business, they should not let anything stop them. Of those who did, most managed to break even or make a small profit, leading me to believe that there's more to Cygnus's success than merely addressing a market opportunity. We've always been willing to make tough decisions, and we've always listened to customers, even when they were yelling at the top of their voices. Those who do free software for love, rather than money, are not going to survive what we've been through.

    As far as what customers really want...they want somebody who will listen to their needs, formulate a long-term plan, and then deliver without a lot of hassle or risk. Some customers like to see you work; others like to see the work you do; still others think you are doing a great job if they never see you. In the end, it's not the guarantees you offer that make customers come back..it's what you can deliver. The free software model is unique in that it actually gives an incentive for customers to work with you, not independently from you. In the fast-moving high tech world, that advantage has put us in the #1 spot in our market...no mean feat.

• Cygnus and the FSC (Free Software Community)
• • What exactly are you providing to the FSC?

• • We pour about $10M/year into the development of new free software. We run the servers from which 500,000 people have downloaded our stuff. We promote the concept of free software in articles, conferences, and advertising. We sponsor free software projects and pay free software contractors who do work that's related to our business requirements (though not something we'd directly commercialize). We provide a generous matching fund so that employees and customers who want to donate to the FSF can see their donation multiplied.

• How long does it take for your new code to be released in Egcs, or other freely downloadable source code?

• • The std deviation of this number makes an average number meaningless. If you download EGCS, I'll bet that the ChangeLog entries are no more than 45 days old. Compare that to other FSF-controlled packages where they can be months or years old. It is important to realize that we don't control when the FSF releases code.

• How much do you feel you are getting from the FSC? Would it have been simpler to write you own compiler?

• • Simpler, perhaps. But we would not have been able to distinguish ourselves from the other N proprietary companies. I mentioned earlier that people are now chosing Cygnus not because we are cheaper, but because we are _strategic_. We could not have achieved that strategic positioning in the compiler space in any other way.

• What overhead is there with working with the FSC?

• • It's whatever you want. Some people like to spend hours arguing about indentation styles. Others just decide they are going to do somthing and they do it. I wrote the first native-code C++ compiler in 6 month in 1987. It was hard work, and it was rough, but once I demonstrated the momentum I could sustains, dozens joined to the GCC/G++ team.

    In 1989, when GCC 1.x was getting fairly mature, I wrote an instruction scheduler, re-wrote a branch scheduler that had been abandoned, and wrote several cool new optimizations that could not easily fit with GCC 1.x. I declared that we should start GCC 2, with the goal of integrating this new work, new C++ language features, and an eye towards optimal code generation for RISC machines.

    GCC 2.x is now reaching maturity, and it's just not possible to preserve that kind of stability with the while working on advanced/experimental/cool new stuff we want to do. Hence we created EGCS. I've been amazed at the number and quality of volunteers who are now working on that branch. Thus, for GCC 2, the overhead is high, whereas for EGCS, the overhead is negative.

• What sort of friction is there between immediate customer concerns and the interests of the FSC?

• • No difference to any other scarce-resource problem.

• • The FSF's objective is a free software world. The customer's objective is a solution that satisfies his needs. The problem is that commercial work always pays more, so more people do that, which frustrates the FSF that not more people are on its bandwagon.

• Which strengths do you see in the Bazaar and Cathedral models of free software development?

• • Although Eric Raymond is very good at coming up with beautiful theories, I dispute whether they are a true reflection of reality. I see GNU and Linux as two cathedrals. Both Linux and RMS are benevolent dictators. What sets them apart is that Linus is willing to take more risks, to rewrite more of his software, while RMS is a perfectionist. Overall, I believe that risks win, and the risk of reimplementing things lead to a better result. Eric and I were both at the Foresight institute to discuss Netscape releasing their source code. Eric said that Cygnus's model was to provide service to commercial customers for free software products, while Netscape was going to lead the standards with its Free software strategy. I disagree with this since Cygnus too is leading the standards in the embedded market with free software.

• Why did you decide to sell software without source-code, given that this soured your relation with the FSF?

• • We measure success in $$, not FSF relationship. Free software works great for support, not for products.

    Cygnus has been very successful at its challenge. In 8 years we've become the number one tool supplier for the embedded market. Our growth is limited only by the number of sales and technical people we can find to employ. I expect our business will be eventually worth 100 of millions dollars per year. But this has taken lots of effort, and is only achieved by making life easy for our customers. For instance, we support 17 different host-target combinations for Cisco alone. Their routers' CPUs vary from the very simple basic RISC chip to very complex CISC chips with fancy features, yet they want the same code to work on any host-target combination. Contrast this to Sun or Microsoft where the same code will not work on SunOS 4/Solaris or Windows 95/NT. We support SGI, HP, NT (etc) so that our customers do not have to decide on their platform because of us. In total we support 170 different host-target combinations.

    The proprietary model and the free software model provide two different kinds of simplicity. The free software model provides simplicity of APIs: there is no need to waste time reverse-engineering things if you have source. The proprietary model provides simplicity of control: your software does not go off and have a life of its own, you can control your investment, your price points and focus on command performance rather than spend time on building a consensus. For instance, say we have two customers, one of whom has a bad bug he needs fixed, the other of whom has sent us an enhancement to our product. Say furthermore that we only have enough time to service one of their needs. If we fix the bug, then the customer who sent us the enhancement will be disappointed -- they did what the GPL said to do --, and they will wonder why they need support from us, since the guys on the net included their enhancement while we did not. If we add the enhancement, then one of our customers still has a bug, and if he cares nothing for having the source-code, he will look somewhere else for business. So adopting the proprietary model allows us to control our strategy. If the need for strategic control disappears then the software can become free, but this might never happen. For instance, dejagnu was not planned to be commercial software, so we put on the net to get help from the people out there.

    In my opinion, Sun has done a bad job at being a software leader, as has Microsoft. What GNU and Linux are doing is pushing the envelope back up.

• You provide compilers for the embedded market

• • Yes. The embedded market is very different from the traditional desktop market. For instance, the object files that became popular in the embedded market differ from those used in the desktop/workstation markets. Originally embedded people worked on Sun 3's and cross-compiled 68000 code into a.out executables. But a.out has limitations such as not allowing multiple data sections. New formats were devised to address this and other issues.

    Another difference is the embedded market is extremely cost-conscious. For instance, the money made on cellular telephones is made on the subscription. Thus the bill of materials for a cellular telephone must be extremely low. Similarly, end-product functionality is more of a concern that compatibility. Because RISC processors provide approximately twice the compute-power for half the electric power of a CISC processor, they are being adopted more rapidly than in the PC market. MIPS is now dethroning the previous king of the embedded world, the 68000 family, having sold 44 million units last year versus 68000's 42 million.

    Providing one same set of compilers for a wide variety of chips has made us into the standard for the embedded market. We have close ties with CPU companies, such as Toshiba, so that each new chip is released with a new version of our compiler. This makes it easy for our customers to choose which ever chip will give the best cost/performance ratio, without worrying about high porting costs.

• What features did you have to add for this market?

• • We added many features that improve code performance and code size. We provide a very lean and mean implementation of C++ to allow embedded programmers to use the C++ features they need. Indeed, we were the first to ship C++ for the embedded world, for Nortel in 1990. We've added the ability to control via #pragmas the type of return code the compiler should use, so that interrupt routines can be written in C. Another embedded feature is the ability to specify into which segment each function should go. And to help our customers migrate rapidly from chip architecture to chip architecture, we have a whole series of #pragmas to control the way in which data structures are laid out in memory. This allows them to have binary compatibility of data structures even if the code was originally written to access words at odd boundaries, but the target processor does not allow this.

• Are there any new #pragma like commands to control code size at a lower granularity (e.g.: for single functions)

• Are there any new #pragma like commands to control speed as a lower granularity (e.g.: for single functions)

• • We find generally that programmers want the same level of optimization for a particular module. However some optimizations of that kind are described in the processor specific optimization documentation: these are processor dependent trade-offs. For instance, on an R10000 (MIPS), bigger code is faster in that keeps all 4 pipes full. On the other hand, we had to deal with very high space constraints when we worked with Sega. They used the Gnu compiler for the Sega Saturn. And although the SH (Super Hitachi processor) encodes 32 bit instructions into 16 bits, we had to change the compiler significantly to cope with the fact that loading immediate values (such as 57) is very convoluted: you read the value then jump over it, making immediate value loads very expensive when the compiler assumed they would be cheap.

    Generally, we think code size will become less and less of an issue: at the rate at which chips are shrinking and processes are improving (such as the extreme Ultra Violet process), the average DRAM chip will contain 1.7 Gbits in 2001 and 237 Gbits in 2012. Bandwidth problems will be alleviated by developments such as Mitsubishi's M32R chip, which has a core on a 16 Mbit ram, and has a huge bandwidth.

• Do you have any benchmarks to compare the current GCC levels of compilation (code size, speed) with compilers from Metaware, IBM, Microsoft, Borland, Symantec, Intel's VTUNE, etc?

• • We use the Bench++ benchmark. In contrast to SPEC benchmarks, this uses Stepanov's abstraction benchmark to determine the cost of various C++ features. For instance at the 0th level of abstraction, the code uses an integer, at the 1st it uses a double, then a class with a double member, then a class with a double pointer member... including template iterators until the 12th level is reached. GNU beats Sun and HP's compilers by a factor of 10. Similarly, GNU exception handling is 10 times faster than HP's.

    In terms of the SPEC base benchmarks EGCS attains the same level as SGI's compiler (the best in the business) with -O and -O2 options. Beyond that, SGI allows one to specify tons of options, such as cache size, which generates better code. However no one actually uses these options, so it's not much of an issue.

    As a company, other than the CygWin guys, we don't compare ourselves with the PC guys, so I can't give you a comparison. The DJGPP guys may have some info. Metaware is a non factor for us, since none of our customers complain about our performance.

• Future trends
  • What new features would you like to see in future revisions of GCC?

• • We'd like to see a good implementation bridging the gap between C/C++ and Java. There are good ideas in Java. It provides open standards that are very important to the downloadable world I believe will arise in the future: it provides a simple way to connect to the web, which essential to achieving an information aware infrastructure.

    However Sun's current behaviour is very worrying. Anything that Sun writes becomes a Java API. This is not unlike Microsoft, who redefined C APIs, even though a standard existed (POSIX), to such an extent that even "hello world" will not work (stdout and stderr are not available from winMain()). Sun is playing a similar game with Java, and we fear it will lead to incompatibilities, balkanizing Java, and letting the competition win. Although Sun snipes free versions of Java, all it is doing is replaying the Unix wars. We hope that GCC will be the free standard wedge that keeps the door open.

• What do you think of the idea that programs are JIT compiled to optimize the features being used, to maximize memory efficiency (as Intel's VTUNE does) while minimizing total footprint by leaving most of the code in a compressed bytecode format (as www.tao.co.uk is suggesting).

• • We view the problem rather differently: what do you want to use your CPU power for? Do you want to use it for JIT compilation, or for running the application? We think the latter. So the JIT should be done on the server. There is no reason why your processor could not identify itself to the server and let the server produce whatever native implementation is best for it. Profile information could also be sent to the server in this way. We will be showing in an upcoming Dr Dobbs Journal, that the performance one can achieve in native-compiled Java is comparable to that of C. Speedwise, this is a better solution than a Java chip, because Lisp Machines have already shown us that register based machines present many more opportunities for optimizations than stack machines. Powerwise it is also advantageous as compilation is rather expensive on a battery. Even in terms of code size, gzip compressed 32 bit RISC code is comparable in size to the equivalent byte-code.

• What do you think of IBM's idea of simplifying processor state-machines to increase frequency by moving more of the complexity to software?

• • Like EPIC, the proof will be in the proverbial pudding. Different RISC implementations vary greatly in power, although in principle they should provide similar levels of performance. For instance, a 200 Mhz R10000 provides a similar level of performance to a 600 Mhz Alpha.

• Do you anticipate commercial proprietary source-code will at the end of the day dominate the market-place, or do you feel that free software backed up by a service industry will take over?

• • I think the distinction will be like the difference between public and private life. While we may let all the people on the net look at our source-code we don't let them play with our money. I believe that free software will determine the standards in the world. Proprietary software will exist in niches, where customers don't care for the source code. Instead of spending time building a concensus, proprietary software allows a company to focus on producing a piece of software as quickly as possible to catch a market opportunity. For instance, we use ORACLE's database software. We don't have the source-code, and don't want it because its internal complexity is irrelevant to us: we just want to use it.

This is the first of a series of articles investigating the interplay between Open Source Software and commercial vendors. The common thread will be to find out how authors have earned a living from writing and servicing GPL/Open Source Software.

The series kicks off with Michael Tiemann, one of the founders of Cygnus Solutions, and author of the C++ component of GCC. Cygnus is one of the pioneers in commercial support for open-source software. It sells support and customization services for the gnu programming tools (gcc, gdb, ld, etc). Initially, the Free Software Foundation applauded this, but more recently, RMS feels that by also selling proprietary software Cygnus has betrayed the principle of free software.

In this interview, Michael discusses what it takes to set up a business based on open source software, what Cygnus hopes to add to GCC, and why they took the decision to sell closed source software.

What is written in red, is what Michael wrote to me in an email
What is written in green, is what I transcribed from my notes of our telephone interview. Any mistakes therein are mine.

• How difficult was it for you to set up Cygnus Solutions?
• • How did the banks cope with Cygnus' non orthodox business model?
  • How difficult was it to find the first customers?
  • What advice could you give someone who has written a GPL'd (or similar) program, and wants to live off it by providing services to commercial users?
  • Can one survive purely on the provision of services?
  • What types of services have you found to be the most important for commercial customers? What sort of guaranties do they want? What should one pay special attention to?

• • The greatest challenge in setting up Cygnus was in finding a name under which we could do business. This is not a joke...for three months we went through a process of finding a name, submitting it to the dept. of corporations, only to learn that the name had already been taken. We were about to give up hope when such an ugly name as "Software Support, Inc." had been registered the same year we tried to get it. When we learned that Cygnus Support (note the embedded GNU in Cygnus) was ours to use, we were overjoyed.

    Cygnus was started with virtually no money. At the time, I wanted John Gilmore (whose userid was gnu@sun.com) to be one of the founders (he was employee #5 at Sun, and was the guy who ported BSD Unix to the 68020), not for his money, but for hus programming skills. I put _my_ money where my mouth was, proposing that all three founders put in the same amount of money at the start. At that time, I had less than $3000 in the bank, so I proposed we each put in $2000 at the start, and raise the ante to $5000 when I could afford it. As you can see, we did _nothing_ to try to get banks interested, so there was nothing to explain to them.

    As for finding the first customers...it was just a matter of knocking enough times on the correct doors. As the author of GNU C++, it was pretty easy for me to talk to high-level technical people, who would then introduce me to mid-level managers. We sold GNU support primarily as a cost-saving measure, so we did not need VP level approval. Nowadays we have a much more strategic sell, but we're also much better established, so we can call on and get VP level approvals.

    I've always advised everybody that if they want to start a free software business, they should not let anything stop them. Of those who did, most managed to break even or make a small profit, leading me to believe that there's more to Cygnus's success than merely addressing a market opportunity. We've always been willing to make tough decisions, and we've always listened to customers, even when they were yelling at the top of their voices. Those who do free software for love, rather than money, are not going to survive what we've been through.

    As far as what customers really want...they want somebody who will listen to their needs, formulate a long-term plan, and then deliver without a lot of hassle or risk. Some customers like to see you work; others like to see the work you do; still others think you are doing a great job if they never see you. In the end, it's not the guarantees you offer that make customers come back..it's what you can deliver. The free software model is unique in that it actually gives an incentive for customers to work with you, not independently from you. In the fast-moving high tech world, that advantage has put us in the #1 spot in our market...no mean feat.

• Cygnus and the FSC (Free Software Community)
• • What exactly are you providing to the FSC?

• • We pour about $10M/year into the development of new free software. We run the servers from which 500,000 people have downloaded our stuff. We promote the concept of free software in articles, conferences, and advertising. We sponsor free software projects and pay free software contractors who do work that's related to our business requirements (though not something we'd directly commercialize). We provide a generous matching fund so that employees and customers who want to donate to the FSF can see their donation multiplied.

• How long does it take for your new code to be released in Egcs, or other freely downloadable source code?

• • The std deviation of this number makes an average number meaningless. If you download EGCS, I'll bet that the ChangeLog entries are no more than 45 days old. Compare that to other FSF-controlled packages where they can be months or years old. It is important to realize that we don't control when the FSF releases code.

• How much do you feel you are getting from the FSC? Would it have been simpler to write you own compiler?

• • Simpler, perhaps. But we would not have been able to distinguish ourselves from the other N proprietary companies. I mentioned earlier that people are now chosing Cygnus not because we are cheaper, but because we are _strategic_. We could not have achieved that strategic positioning in the compiler space in any other way.

• What overhead is there with working with the FSC?

• • It's whatever you want. Some people like to spend hours arguing about indentation styles. Others just decide they are going to do somthing and they do it. I wrote the first native-code C++ compiler in 6 month in 1987. It was hard work, and it was rough, but once I demonstrated the momentum I could sustains, dozens joined to the GCC/G++ team.

    In 1989, when GCC 1.x was getting fairly mature, I wrote an instruction scheduler, re-wrote a branch scheduler that had been abandoned, and wrote several cool new optimizations that could not easily fit with GCC 1.x. I declared that we should start GCC 2, with the goal of integrating this new work, new C++ language features, and an eye towards optimal code generation for RISC machines.

    GCC 2.x is now reaching maturity, and it's just not possible to preserve that kind of stability with the while working on advanced/experimental/cool new stuff we want to do. Hence we created EGCS. I've been amazed at the number and quality of volunteers who are now working on that branch. Thus, for GCC 2, the overhead is high, whereas for EGCS, the overhead is negative.

• What sort of friction is there between immediate customer concerns and the interests of the FSC?

• • No difference to any other scarce-resource problem.

• • The FSF's objective is a free software world. The customer's objective is a solution that satisfies his needs. The problem is that commercial work always pays more, so more people do that, which frustrates the FSF that not more people are on its bandwagon.

• Which strengths do you see in the Bazaar and Cathedral models of free software development?

• • Although Eric Raymond is very good at coming up with beautiful theories, I dispute whether they are a true reflection of reality. I see GNU and Linux as two cathedrals. Both Linux and RMS are benevolent dictators. What sets them apart is that Linus is willing to take more risks, to rewrite more of his software, while RMS is a perfectionist. Overall, I believe that risks win, and the risk of reimplementing things lead to a better result. Eric and I were both at the Foresight institute to discuss Netscape releasing their source code. Eric said that Cygnus's model was to provide service to commercial customers for free software products, while Netscape was going to lead the standards with its Free software strategy. I disagree with this since Cygnus too is leading the standards in the embedded market with free software.

• Why did you decide to sell software without source-code, given that this soured your relation with the FSF?

• • We measure success in $$, not FSF relationship. Free software works great for support, not for products.

    Cygnus has been very successful at its challenge. In 8 years we've become the number one tool supplier for the embedded market. Our growth is limited only by the number of sales and technical people we can find to employ. I expect our business will be eventually worth 100 of millions dollars per year. But this has taken lots of effort, and is only achieved by making life easy for our customers. For instance, we support 17 different host-target combinations for Cisco alone. Their routers' CPUs vary from the very simple basic RISC chip to very complex CISC chips with fancy features, yet they want the same code to work on any host-target combination. Contrast this to Sun or Microsoft where the same code will not work on SunOS 4/Solaris or Windows 95/NT. We support SGI, HP, NT (etc) so that our customers do not have to decide on their platform because of us. In total we support 170 different host-target combinations.

    The proprietary model and the free software model provide two different kinds of simplicity. The free software model provides simplicity of APIs: there is no need to waste time reverse-engineering things if you have source. The proprietary model provides simplicity of control: your software does not go off and have a life of its own, you can control your investment, your price points and focus on command performance rather than spend time on building a consensus. For instance, say we have two customers, one of whom has a bad bug he needs fixed, the other of whom has sent us an enhancement to our product. Say furthermore that we only have enough time to service one of their needs. If we fix the bug, then the customer who sent us the enhancement will be disappointed -- they did what the GPL said to do --, and they will wonder why they need support from us, since the guys on the net included their enhancement while we did not. If we add the enhancement, then one of our customers still has a bug, and if he cares nothing for having the source-code, he will look somewhere else for business. So adopting the proprietary model allows us to control our strategy. If the need for strategic control disappears then the software can become free, but this might never happen. For instance, dejagnu was not planned to be commercial software, so we put on the net to get help from the people out there.

    In my opinion, Sun has done a bad job at being a software leader, as has Microsoft. What GNU and Linux are doing is pushing the envelope back up.

• You provide compilers for the embedded market

• • Yes. The embedded market is very different from the traditional desktop market. For instance, the object files that became popular in the embedded market differ from those used in the desktop/workstation markets. Originally embedded people worked on Sun 3's and cross-compiled 68000 code into a.out executables. But a.out has limitations such as not allowing multiple data sections. New formats were devised to address this and other issues.

    Another difference is the embedded market is extremely cost-conscious. For instance, the money made on cellular telephones is made on the subscription. Thus the bill of materials for a cellular telephone must be extremely low. Similarly, end-product functionality is more of a concern that compatibility. Because RISC processors provide approximately twice the compute-power for half the electric power of a CISC processor, they are being adopted more rapidly than in the PC market. MIPS is now dethroning the previous king of the embedded world, the 68000 family, having sold 44 million units last year versus 68000's 42 million.

    Providing one same set of compilers for a wide variety of chips has made us into the standard for the embedded market. We have close ties with CPU companies, such as Toshiba, so that each new chip is released with a new version of our compiler. This makes it easy for our customers to choose which ever chip will give the best cost/performance ratio, without worrying about high porting costs.

• What features did you have to add for this market?

• • We added many features that improve code performance and code size. We provide a very lean and mean implementation of C++ to allow embedded programmers to use the C++ features they need. Indeed, we were the first to ship C++ for the embedded world, for Nortel in 1990. We've added the ability to control via #pragmas the type of return code the compiler should use, so that interrupt routines can be written in C. Another embedded feature is the ability to specify into which segment each function should go. And to help our customers migrate rapidly from chip architecture to chip architecture, we have a whole series of #pragmas to control the way in which data structures are laid out in memory. This allows them to have binary compatibility of data structures even if the code was originally written to access words at odd boundaries, but the target processor does not allow this.

• Are there any new #pragma like commands to control code size at a lower granularity (e.g.: for single functions)

• Are there any new #pragma like commands to control speed as a lower granularity (e.g.: for single functions)

• • We find generally that programmers want the same level of optimization for a particular module. However some optimizations of that kind are described in the processor specific optimization documentation: these are processor dependent trade-offs. For instance, on an R10000 (MIPS), bigger code is faster in that keeps all 4 pipes full. On the other hand, we had to deal with very high space constraints when we worked with Sega. They used the Gnu compiler for the Sega Saturn. And although the SH (Super Hitachi processor) encodes 32 bit instructions into 16 bits, we had to change the compiler significantly to cope with the fact that loading immediate values (such as 57) is very convoluted: you read the value then jump over it, making immediate value loads very expensive when the compiler assumed they would be cheap.

    Generally, we think code size will become less and less of an issue: at the rate at which chips are shrinking and processes are improving (such as the extreme Ultra Violet process), the average DRAM chip will contain 1.7 Gbits in 2001 and 237 Gbits in 2012. Bandwidth problems will be alleviated by developments such as Mitsubishi's M32R chip, which has a core on a 16 Mbit ram, and has a huge bandwidth.

• Do you have any benchmarks to compare the current GCC levels of compilation (code size, speed) with compilers from Metaware, IBM, Microsoft, Borland, Symantec, Intel's VTUNE, etc?

• • We use the Bench++ benchmark. In contrast to SPEC benchmarks, this uses Stepanov's abstraction benchmark to determine the cost of various C++ features. For instance at the 0th level of abstraction, the code uses an integer, at the 1st it uses a double, then a class with a double member, then a class with a double pointer member... including template iterators until the 12th level is reached. GNU beats Sun and HP's compilers by a factor of 10. Similarly, GNU exception handling is 10 times faster than HP's.

    In terms of the SPEC base benchmarks EGCS attains the same level as SGI's compiler (the best in the business) with -O and -O2 options. Beyond that, SGI allows one to specify tons of options, such as cache size, which generates better code. However no one actually uses these options, so it's not much of an issue.

    As a company, other than the CygWin guys, we don't compare ourselves with the PC guys, so I can't give you a comparison. The DJGPP guys may have some info. Metaware is a non factor for us, since none of our customers complain about our performance.

• Future trends
  • What new features would you like to see in future revisions of GCC?

• • We'd like to see a good implementation bridging the gap between C/C++ and Java. There are good ideas in Java. It provides open standards that are very important to the downloadable world I believe will arise in the future: it provides a simple way to connect to the web, which essential to achieving an information aware infrastructure.

    However Sun's current behaviour is very worrying. Anything that Sun writes becomes a Java API. This is not unlike Microsoft, who redefined C APIs, even though a standard existed (POSIX), to such an extent that even "hello world" will not work (stdout and stderr are not available from winMain()). Sun is playing a similar game with Java, and we fear it will lead to incompatibilities, balkanizing Java, and letting the competition win. Although Sun snipes free versions of Java, all it is doing is replaying the Unix wars. We hope that GCC will be the free standard wedge that keeps the door open.

• What do you think of the idea that programs are JIT compiled to optimize the features being used, to maximize memory efficiency (as Intel's VTUNE does) while minimizing total footprint by leaving most of the code in a compressed bytecode format (as www.tao.co.uk is suggesting).

• • We view the problem rather differently: what do you want to use your CPU power for? Do you want to use it for JIT compilation, or for running the application? We think the latter. So the JIT should be done on the server. There is no reason why your processor could not identify itself to the server and let the server produce whatever native implementation is best for it. Profile information could also be sent to the server in this way. We will be showing in an upcoming Dr Dobbs Journal, that the performance one can achieve in native-compiled Java is comparable to that of C. Speedwise, this is a better solution than a Java chip, because Lisp Machines have already shown us that register based machines present many more opportunities for optimizations than stack machines. Powerwise it is also advantageous as compilation is rather expensive on a battery. Even in terms of code size, gzip compressed 32 bit RISC code is comparable in size to the equivalent byte-code.

• What do you think of IBM's idea of simplifying processor state-machines to increase frequency by moving more of the complexity to software?

• • Like EPIC, the proof will be in the proverbial pudding. Different RISC implementations vary greatly in power, although in principle they should provide similar levels of performance. For instance, a 200 Mhz R10000 provides a similar level of performance to a 600 Mhz Alpha.

• Do you anticipate commercial proprietary source-code will at the end of the day dominate the market-place, or do you feel that free software backed up by a service industry will take over?

• • I think the distinction will be like the difference between public and private life. While we may let all the people on the net look at our source-code we don't let them play with our money. I believe that free software will determine the standards in the world. Proprietary software will exist in niches, where customers don't care for the source code. Instead of spending time building a concensus, proprietary software allows a company to focus on producing a piece of software as quickly as possible to catch a market opportunity. For instance, we use ORACLE's database software. We don't have the source-code, and don't want it because its internal complexity is irrelevant to us: we just want to use it.

This is the first of a series of articles investigating the interplay between Open Source Software and commercial vendors. The common thread will be to find out how authors have earned a living from writing and servicing GPL/Open Source Software.

The series kicks off with Michael Tiemann, one of the founders of Cygnus Solutions, and author of the C++ component of GCC. Cygnus is one of the pioneers in commercial support for open-source software. It sells support and customization services for the gnu programming tools (gcc, gdb, ld, etc). Initially, the Free Software Foundation applauded this, but more recently, RMS feels that by also selling proprietary software Cygnus has betrayed the principle of free software.

In this interview, Michael discusses what it takes to set up a business based on open source software, what Cygnus hopes to add to GCC, and why they took the decision to sell closed source software.

What is written in red, is what Michael wrote to me in an email
What is written in green, is what I transcribed from my notes of our telephone interview. Any mistakes therein are mine.

• How difficult was it for you to set up Cygnus Solutions?
• • How did the banks cope with Cygnus' non orthodox business model?
  • How difficult was it to find the first customers?
  • What advice could you give someone who has written a GPL'd (or similar) program, and wants to live off it by providing services to commercial users?
  • Can one survive purely on the provision of services?
  • What types of services have you found to be the most important for commercial customers? What sort of guaranties do they want? What should one pay special attention to?

• • The greatest challenge in setting up Cygnus was in finding a name under which we could do business. This is not a joke...for three months we went through a process of finding a name, submitting it to the dept. of corporations, only to learn that the name had already been taken. We were about to give up hope when such an ugly name as "Software Support, Inc." had been registered the same year we tried to get it. When we learned that Cygnus Support (note the embedded GNU in Cygnus) was ours to use, we were overjoyed.

    Cygnus was started with virtually no money. At the time, I wanted John Gilmore (whose userid was gnu@sun.com) to be one of the founders (he was employee #5 at Sun, and was the guy who ported BSD Unix to the 68020), not for his money, but for hus programming skills. I put _my_ money where my mouth was, proposing that all three founders put in the same amount of money at the start. At that time, I had less than $3000 in the bank, so I proposed we each put in $2000 at the start, and raise the ante to $5000 when I could afford it. As you can see, we did _nothing_ to try to get banks interested, so there was nothing to explain to them.

    As for finding the first customers...it was just a matter of knocking enough times on the correct doors. As the author of GNU C++, it was pretty easy for me to talk to high-level technical people, who would then introduce me to mid-level managers. We sold GNU support primarily as a cost-saving measure, so we did not need VP level approval. Nowadays we have a much more strategic sell, but we're also much better established, so we can call on and get VP level approvals.

    I've always advised everybody that if they want to start a free software business, they should not let anything stop them. Of those who did, most managed to break even or make a small profit, leading me to believe that there's more to Cygnus's success than merely addressing a market opportunity. We've always been willing to make tough decisions, and we've always listened to customers, even when they were yelling at the top of their voices. Those who do free software for love, rather than money, are not going to survive what we've been through.

    As far as what customers really want...they want somebody who will listen to their needs, formulate a long-term plan, and then deliver without a lot of hassle or risk. Some customers like to see you work; others like to see the work you do; still others think you are doing a great job if they never see you. In the end, it's not the guarantees you offer that make customers come back..it's what you can deliver. The free software model is unique in that it actually gives an incentive for customers to work with you, not independently from you. In the fast-moving high tech world, that advantage has put us in the #1 spot in our market...no mean feat.

• Cygnus and the FSC (Free Software Community)
• • What exactly are you providing to the FSC?

• • We pour about $10M/year into the development of new free software. We run the servers from which 500,000 people have downloaded our stuff. We promote the concept of free software in articles, conferences, and advertising. We sponsor free software projects and pay free software contractors who do work that's related to our business requirements (though not something we'd directly commercialize). We provide a generous matching fund so that employees and customers who want to donate to the FSF can see their donation multiplied.

• How long does it take for your new code to be released in Egcs, or other freely downloadable source code?

• • The std deviation of this number makes an average number meaningless. If you download EGCS, I'll bet that the ChangeLog entries are no more than 45 days old. Compare that to other FSF-controlled packages where they can be months or years old. It is important to realize that we don't control when the FSF releases code.

• How much do you feel you are getting from the FSC? Would it have been simpler to write you own compiler?

• • Simpler, perhaps. But we would not have been able to distinguish ourselves from the other N proprietary companies. I mentioned earlier that people are now chosing Cygnus not because we are cheaper, but because we are _strategic_. We could not have achieved that strategic positioning in the compiler space in any other way.

• What overhead is there with working with the FSC?

• • It's whatever you want. Some people like to spend hours arguing about indentation styles. Others just decide they are going to do somthing and they do it. I wrote the first native-code C++ compiler in 6 month in 1987. It was hard work, and it was rough, but once I demonstrated the momentum I could sustains, dozens joined to the GCC/G++ team.

    In 1989, when GCC 1.x was getting fairly mature, I wrote an instruction scheduler, re-wrote a branch scheduler that had been abandoned, and wrote several cool new optimizations that could not easily fit with GCC 1.x. I declared that we should start GCC 2, with the goal of integrating this new work, new C++ language features, and an eye towards optimal code generation for RISC machines.

    GCC 2.x is now reaching maturity, and it's just not possible to preserve that kind of stability with the while working on advanced/experimental/cool new stuff we want to do. Hence we created EGCS. I've been amazed at the number and quality of volunteers who are now working on that branch. Thus, for GCC 2, the overhead is high, whereas for EGCS, the overhead is negative.

• What sort of friction is there between immediate customer concerns and the interests of the FSC?

• • No difference to any other scarce-resource problem.

• • The FSF's objective is a free software world. The customer's objective is a solution that satisfies his needs. The problem is that commercial work always pays more, so more people do that, which frustrates the FSF that not more people are on its bandwagon.

• Which strengths do you see in the Bazaar and Cathedral models of free software development?

• • Although Eric Raymond is very good at coming up with beautiful theories, I dispute whether they are a true reflection of reality. I see GNU and Linux as two cathedrals. Both Linux and RMS are benevolent dictators. What sets them apart is that Linus is willing to take more risks, to rewrite more of his software, while RMS is a perfectionist. Overall, I believe that risks win, and the risk of reimplementing things lead to a better result. Eric and I were both at the Foresight institute to discuss Netscape releasing their source code. Eric said that Cygnus's model was to provide service to commercial customers for free software products, while Netscape was going to lead the standards with its Free software strategy. I disagree with this since Cygnus too is leading the standards in the embedded market with free software.

• Why did you decide to sell software without source-code, given that this soured your relation with the FSF?

• • We measure success in $$, not FSF relationship. Free software works great for support, not for products.

    Cygnus has been very successful at its challenge. In 8 years we've become the number one tool supplier for the embedded market. Our growth is limited only by the number of sales and technical people we can find to employ. I expect our business will be eventually worth 100 of millions dollars per year. But this has taken lots of effort, and is only achieved by making life easy for our customers. For instance, we support 17 different host-target combinations for Cisco alone. Their routers' CPUs vary from the very simple basic RISC chip to very complex CISC chips with fancy features, yet they want the same code to work on any host-target combination. Contrast this to Sun or Microsoft where the same code will not work on SunOS 4/Solaris or Windows 95/NT. We support SGI, HP, NT (etc) so that our customers do not have to decide on their platform because of us. In total we support 170 different host-target combinations.

    The proprietary model and the free software model provide two different kinds of simplicity. The free software model provides simplicity of APIs: there is no need to waste time reverse-engineering things if you have source. The proprietary model provides simplicity of control: your software does not go off and have a life of its own, you can control your investment, your price points and focus on command performance rather than spend time on building a consensus. For instance, say we have two customers, one of whom has a bad bug he needs fixed, the other of whom has sent us an enhancement to our product. Say furthermore that we only have enough time to service one of their needs. If we fix the bug, then the customer who sent us the enhancement will be disappointed -- they did what the GPL said to do --, and they will wonder why they need support from us, since the guys on the net included their enhancement while we did not. If we add the enhancement, then one of our customers still has a bug, and if he cares nothing for having the source-code, he will look somewhere else for business. So adopting the proprietary model allows us to control our strategy. If the need for strategic control disappears then the software can become free, but this might never happen. For instance, dejagnu was not planned to be commercial software, so we put on the net to get help from the people out there.

    In my opinion, Sun has done a bad job at being a software leader, as has Microsoft. What GNU and Linux are doing is pushing the envelope back up.

• You provide compilers for the embedded market

• • Yes. The embedded market is very different from the traditional desktop market. For instance, the object files that became popular in the embedded market differ from those used in the desktop/workstation markets. Originally embedded people worked on Sun 3's and cross-compiled 68000 code into a.out executables. But a.out has limitations such as not allowing multiple data sections. New formats were devised to address this and other issues.

    Another difference is the embedded market is extremely cost-conscious. For instance, the money made on cellular telephones is made on the subscription. Thus the bill of materials for a cellular telephone must be extremely low. Similarly, end-product functionality is more of a concern that compatibility. Because RISC processors provide approximately twice the compute-power for half the electric power of a CISC processor, they are being adopted more rapidly than in the PC market. MIPS is now dethroning the previous king of the embedded world, the 68000 family, having sold 44 million units last year versus 68000's 42 million.

    Providing one same set of compilers for a wide variety of chips has made us into the standard for the embedded market. We have close ties with CPU companies, such as Toshiba, so that each new chip is released with a new version of our compiler. This makes it easy for our customers to choose which ever chip will give the best cost/performance ratio, without worrying about high porting costs.

• What features did you have to add for this market?

• • We added many features that improve code performance and code size. We provide a very lean and mean implementation of C++ to allow embedded programmers to use the C++ features they need. Indeed, we were the first to ship C++ for the embedded world, for Nortel in 1990. We've added the ability to control via #pragmas the type of return code the compiler should use, so that interrupt routines can be written in C. Another embedded feature is the ability to specify into which segment each function should go. And to help our customers migrate rapidly from chip architecture to chip architecture, we have a whole series of #pragmas to control the way in which data structures are laid out in memory. This allows them to have binary compatibility of data structures even if the code was originally written to access words at odd boundaries, but the target processor does not allow this.

• Are there any new #pragma like commands to control code size at a lower granularity (e.g.: for single functions)

• Are there any new #pragma like commands to control speed as a lower granularity (e.g.: for single functions)

• • We find generally that programmers want the same level of optimization for a particular module. However some optimizations of that kind are described in the processor specific optimization documentation: these are processor dependent trade-offs. For instance, on an R10000 (MIPS), bigger code is faster in that keeps all 4 pipes full. On the other hand, we had to deal with very high space constraints when we worked with Sega. They used the Gnu compiler for the Sega Saturn. And although the SH (Super Hitachi processor) encodes 32 bit instructions into 16 bits, we had to change the compiler significantly to cope with the fact that loading immediate values (such as 57) is very convoluted: you read the value then jump over it, making immediate value loads very expensive when the compiler assumed they would be cheap.

    Generally, we think code size will become less and less of an issue: at the rate at which chips are shrinking and processes are improving (such as the extreme Ultra Violet process), the average DRAM chip will contain 1.7 Gbits in 2001 and 237 Gbits in 2012. Bandwidth problems will be alleviated by developments such as Mitsubishi's M32R chip, which has a core on a 16 Mbit ram, and has a huge bandwidth.

• Do you have any benchmarks to compare the current GCC levels of compilation (code size, speed) with compilers from Metaware, IBM, Microsoft, Borland, Symantec, Intel's VTUNE, etc?

• • We use the Bench++ benchmark. In contrast to SPEC benchmarks, this uses Stepanov's abstraction benchmark to determine the cost of various C++ features. For instance at the 0th level of abstraction, the code uses an integer, at the 1st it uses a double, then a class with a double member, then a class with a double pointer member... including template iterators until the 12th level is reached. GNU beats Sun and HP's compilers by a factor of 10. Similarly, GNU exception handling is 10 times faster than HP's.

    In terms of the SPEC base benchmarks EGCS attains the same level as SGI's compiler (the best in the business) with -O and -O2 options. Beyond that, SGI allows one to specify tons of options, such as cache size, which generates better code. However no one actually uses these options, so it's not much of an issue.

    As a company, other than the CygWin guys, we don't compare ourselves with the PC guys, so I can't give you a comparison. The DJGPP guys may have some info. Metaware is a non factor for us, since none of our customers complain about our performance.

• Future trends
  • What new features would you like to see in future revisions of GCC?

• • We'd like to see a good implementation bridging the gap between C/C++ and Java. There are good ideas in Java. It provides open standards that are very important to the downloadable world I believe will arise in the future: it provides a simple way to connect to the web, which essential to achieving an information aware infrastructure.

    However Sun's current behaviour is very worrying. Anything that Sun writes becomes a Java API. This is not unlike Microsoft, who redefined C APIs, even though a standard existed (POSIX), to such an extent that even "hello world" will not work (stdout and stderr are not available from winMain()). Sun is playing a similar game with Java, and we fear it will lead to incompatibilities, balkanizing Java, and letting the competition win. Although Sun snipes free versions of Java, all it is doing is replaying the Unix wars. We hope that GCC will be the free standard wedge that keeps the door open.

• What do you think of the idea that programs are JIT compiled to optimize the features being used, to maximize memory efficiency (as Intel's VTUNE does) while minimizing total footprint by leaving most of the code in a compressed bytecode format (as www.tao.co.uk is suggesting).

• • We view the problem rather differently: what do you want to use your CPU power for? Do you want to use it for JIT compilation, or for running the application? We think the latter. So the JIT should be done on the server. There is no reason why your processor could not identify itself to the server and let the server produce whatever native implementation is best for it. Profile information could also be sent to the server in this way. We will be showing in an upcoming Dr Dobbs Journal, that the performance one can achieve in native-compiled Java is comparable to that of C. Speedwise, this is a better solution than a Java chip, because Lisp Machines have already shown us that register based machines present many more opportunities for optimizations than stack machines. Powerwise it is also advantageous as compilation is rather expensive on a battery. Even in terms of code size, gzip compressed 32 bit RISC code is comparable in size to the equivalent byte-code.

• What do you think of IBM's idea of simplifying processor state-machines to increase frequency by moving more of the complexity to software?

• • Like EPIC, the proof will be in the proverbial pudding. Different RISC implementations vary greatly in power, although in principle they should provide similar levels of performance. For instance, a 200 Mhz R10000 provides a similar level of performance to a 600 Mhz Alpha.

• Do you anticipate commercial proprietary source-code will at the end of the day dominate the market-place, or do you feel that free software backed up by a service industry will take over?

• • I think the distinction will be like the difference between public and private life. While we may let all the people on the net look at our source-code we don't let them play with our money. I believe that free software will determine the standards in the world. Proprietary software will exist in niches, where customers don't care for the source code. Instead of spending time building a concensus, proprietary software allows a company to focus on producing a piece of software as quickly as possible to catch a market opportunity. For instance, we use ORACLE's database software. We don't have the source-code, and don't want it because its internal complexity is irrelevant to us: we just want to use it.

This is the first of a series of articles investigating the interplay between Open Source Software and commercial vendors. The common thread will be to find out how authors have earned a living from writing and servicing GPL/Open Source Software.

The series kicks off with Michael Tiemann, one of the founders of Cygnus Solutions, and author of the C++ component of GCC. Cygnus is one of the pioneers in commercial support for open-source software. It sells support and customization services for the gnu programming tools (gcc, gdb, ld, etc). Initially, the Free Software Foundation applauded this, but more recently, RMS feels that by also selling proprietary software Cygnus has betrayed the principle of free software.

In this interview, Michael discusses what it takes to set up a business based on open source software, what Cygnus hopes to add to GCC, and why they took the decision to sell closed source software.

What is written in red, is what Michael wrote to me in an email
What is written in green, is what I transcribed from my notes of our telephone interview. Any mistakes therein are mine.

• How difficult was it for you to set up Cygnus Solutions?
• • How did the banks cope with Cygnus' non orthodox business model?
  • How difficult was it to find the first customers?
  • What advice could you give someone who has written a GPL'd (or similar) program, and wants to live off it by providing services to commercial users?
  • Can one survive purely on the provision of services?
  • What types of services have you found to be the most important for commercial customers? What sort of guaranties do they want? What should one pay special attention to?

• • The greatest challenge in setting up Cygnus was in finding a name under which we could do business. This is not a joke...for three months we went through a process of finding a name, submitting it to the dept. of corporations, only to learn that the name had already been taken. We were about to give up hope when such an ugly name as "Software Support, Inc." had been registered the same year we tried to get it. When we learned that Cygnus Support (note the embedded GNU in Cygnus) was ours to use, we were overjoyed.

    Cygnus was started with virtually no money. At the time, I wanted John Gilmore (whose userid was gnu@sun.com) to be one of the founders (he was employee #5 at Sun, and was the guy who ported BSD Unix to the 68020), not for his money, but for hus programming skills. I put _my_ money where my mouth was, proposing that all three founders put in the same amount of money at the start. At that time, I had less than $3000 in the bank, so I proposed we each put in $2000 at the start, and raise the ante to $5000 when I could afford it. As you can see, we did _nothing_ to try to get banks interested, so there was nothing to explain to them.

    As for finding the first customers...it was just a matter of knocking enough times on the correct doors. As the author of GNU C++, it was pretty easy for me to talk to high-level technical people, who would then introduce me to mid-level managers. We sold GNU support primarily as a cost-saving measure, so we did not need VP level approval. Nowadays we have a much more strategic sell, but we're also much better established, so we can call on and get VP level approvals.

    I've always advised everybody that if they want to start a free software business, they should not let anything stop them. Of those who did, most managed to break even or make a small profit, leading me to believe that there's more to Cygnus's success than merely addressing a market opportunity. We've always been willing to make tough decisions, and we've always listened to customers, even when they were yelling at the top of their voices. Those who do free software for love, rather than money, are not going to survive what we've been through.

    As far as what customers really want...they want somebody who will listen to their needs, formulate a long-term plan, and then deliver without a lot of hassle or risk. Some customers like to see you work; others like to see the work you do; still others think you are doing a great job if they never see you. In the end, it's not the guarantees you offer that make customers come back..it's what you can deliver. The free software model is unique in that it actually gives an incentive for customers to work with you, not independently from you. In the fast-moving high tech world, that advantage has put us in the #1 spot in our market...no mean feat.

• Cygnus and the FSC (Free Software Community)
• • What exactly are you providing to the FSC?

• • We pour about $10M/year into the development of new free software. We run the servers from which 500,000 people have downloaded our stuff. We promote the concept of free software in articles, conferences, and advertising. We sponsor free software projects and pay free software contractors who do work that's related to our business requirements (though not something we'd directly commercialize). We provide a generous matching fund so that employees and customers who want to donate to the FSF can see their donation multiplied.

• How long does it take for your new code to be released in Egcs, or other freely downloadable source code?

• • The std deviation of this number makes an average number meaningless. If you download EGCS, I'll bet that the ChangeLog entries are no more than 45 days old. Compare that to other FSF-controlled packages where they can be months or years old. It is important to realize that we don't control when the FSF releases code.

• How much do you feel you are getting from the FSC? Would it have been simpler to write you own compiler?

• • Simpler, perhaps. But we would not have been able to distinguish ourselves from the other N proprietary companies. I mentioned earlier that people are now chosing Cygnus not because we are cheaper, but because we are _strategic_. We could not have achieved that strategic positioning in the compiler space in any other way.

• What overhead is there with working with the FSC?

• • It's whatever you want. Some people like to spend hours arguing about indentation styles. Others just decide they are going to do somthing and they do it. I wrote the first native-code C++ compiler in 6 month in 1987. It was hard work, and it was rough, but once I demonstrated the momentum I could sustains, dozens joined to the GCC/G++ team.

    In 1989, when GCC 1.x was getting fairly mature, I wrote an instruction scheduler, re-wrote a branch scheduler that had been abandoned, and wrote several cool new optimizations that could not easily fit with GCC 1.x. I declared that we should start GCC 2, with the goal of integrating this new work, new C++ language features, and an eye towards optimal code generation for RISC machines.

    GCC 2.x is now reaching maturity, and it's just not possible to preserve that kind of stability with the while working on advanced/experimental/cool new stuff we want to do. Hence we created EGCS. I've been amazed at the number and quality of volunteers who are now working on that branch. Thus, for GCC 2, the overhead is high, whereas for EGCS, the overhead is negative.

• What sort of friction is there between immediate customer concerns and the interests of the FSC?

• • No difference to any other scarce-resource problem.

• • The FSF's objective is a free software world. The customer's objective is a solution that satisfies his needs. The problem is that commercial work always pays more, so more people do that, which frustrates the FSF that not more people are on its bandwagon.

• Which strengths do you see in the Bazaar and Cathedral models of free software development?

• • Although Eric Raymond is very good at coming up with beautiful theories, I dispute whether they are a true reflection of reality. I see GNU and Linux as two cathedrals. Both Linux and RMS are benevolent dictators. What sets them apart is that Linus is willing to take more risks, to rewrite more of his software, while RMS is a perfectionist. Overall, I believe that risks win, and the risk of reimplementing things lead to a better result. Eric and I were both at the Foresight institute to discuss Netscape releasing their source code. Eric said that Cygnus's model was to provide service to commercial customers for free software products, while Netscape was going to lead the standards with its Free software strategy. I disagree with this since Cygnus too is leading the standards in the embedded market with free software.

• Why did you decide to sell software without source-code, given that this soured your relation with the FSF?

• • We measure success in $$, not FSF relationship. Free software works great for support, not for products.

    Cygnus has been very successful at its challenge. In 8 years we've become the number one tool supplier for the embedded market. Our growth is limited only by the number of sales and technical people we can find to employ. I expect our business will be eventually worth 100 of millions dollars per year. But this has taken lots of effort, and is only achieved by making life easy for our customers. For instance, we support 17 different host-target combinations for Cisco alone. Their routers' CPUs vary from the very simple basic RISC chip to very complex CISC chips with fancy features, yet they want the same code to work on any host-target combination. Contrast this to Sun or Microsoft where the same code will not work on SunOS 4/Solaris or Windows 95/NT. We support SGI, HP, NT (etc) so that our customers do not have to decide on their platform because of us. In total we support 170 different host-target combinations.

    The proprietary model and the free software model provide two different kinds of simplicity. The free software model provides simplicity of APIs: there is no need to waste time reverse-engineering things if you have source. The proprietary model provides simplicity of control: your software does not go off and have a life of its own, you can control your investment, your price points and focus on command performance rather than spend time on building a consensus. For instance, say we have two customers, one of whom has a bad bug he needs fixed, the other of whom has sent us an enhancement to our product. Say furthermore that we only have enough time to service one of their needs. If we fix the bug, then the customer who sent us the enhancement will be disappointed -- they did what the GPL said to do --, and they will wonder why they need support from us, since the guys on the net included their enhancement while we did not. If we add the enhancement, then one of our customers still has a bug, and if he cares nothing for having the source-code, he will look somewhere else for business. So adopting the proprietary model allows us to control our strategy. If the need for strategic control disappears then the software can become free, but this might never happen. For instance, dejagnu was not planned to be commercial software, so we put on the net to get help from the people out there.

    In my opinion, Sun has done a bad job at being a software leader, as has Microsoft. What GNU and Linux are doing is pushing the envelope back up.

• You provide compilers for the embedded market

• • Yes. The embedded market is very different from the traditional desktop market. For instance, the object files that became popular in the embedded market differ from those used in the desktop/workstation markets. Originally embedded people worked on Sun 3's and cross-compiled 68000 code into a.out executables. But a.out has limitations such as not allowing multiple data sections. New formats were devised to address this and other issues.

    Another difference is the embedded market is extremely cost-conscious. For instance, the money made on cellular telephones is made on the subscription. Thus the bill of materials for a cellular telephone must be extremely low. Similarly, end-product functionality is more of a concern that compatibility. Because RISC processors provide approximately twice the compute-power for half the electric power of a CISC processor, they are being adopted more rapidly than in the PC market. MIPS is now dethroning the previous king of the embedded world, the 68000 family, having sold 44 million units last year versus 68000's 42 million.

    Providing one same set of compilers for a wide variety of chips has made us into the standard for the embedded market. We have close ties with CPU companies, such as Toshiba, so that each new chip is released with a new version of our compiler. This makes it easy for our customers to choose which ever chip will give the best cost/performance ratio, without worrying about high porting costs.

• What features did you have to add for this market?

• • We added many features that improve code performance and code size. We provide a very lean and mean implementation of C++ to allow embedded programmers to use the C++ features they need. Indeed, we were the first to ship C++ for the embedded world, for Nortel in 1990. We've added the ability to control via #pragmas the type of return code the compiler should use, so that interrupt routines can be written in C. Another embedded feature is the ability to specify into which segment each function should go. And to help our customers migrate rapidly from chip architecture to chip architecture, we have a whole series of #pragmas to control the way in which data structures are laid out in memory. This allows them to have binary compatibility of data structures even if the code was originally written to access words at odd boundaries, but the target processor does not allow this.

• Are there any new #pragma like commands to control code size at a lower granularity (e.g.: for single functions)

• Are there any new #pragma like commands to control speed as a lower granularity (e.g.: for single functions)

• • We find generally that programmers want the same level of optimization for a particular module. However some optimizations of that kind are described in the processor specific optimization documentation: these are processor dependent trade-offs. For instance, on an R10000 (MIPS), bigger code is faster in that keeps all 4 pipes full. On the other hand, we had to deal with very high space constraints when we worked with Sega. They used the Gnu compiler for the Sega Saturn. And although the SH (Super Hitachi processor) encodes 32 bit instructions into 16 bits, we had to change the compiler significantly to cope with the fact that loading immediate values (such as 57) is very convoluted: you read the value then jump over it, making immediate value loads very expensive when the compiler assumed they would be cheap.

    Generally, we think code size will become less and less of an issue: at the rate at which chips are shrinking and processes are improving (such as the extreme Ultra Violet process), the average DRAM chip will contain 1.7 Gbits in 2001 and 237 Gbits in 2012. Bandwidth problems will be alleviated by developments such as Mitsubishi's M32R chip, which has a core on a 16 Mbit ram, and has a huge bandwidth.

• Do you have any benchmarks to compare the current GCC levels of compilation (code size, speed) with compilers from Metaware, IBM, Microsoft, Borland, Symantec, Intel's VTUNE, etc?

• • We use the Bench++ benchmark. In contrast to SPEC benchmarks, this uses Stepanov's abstraction benchmark to determine the cost of various C++ features. For instance at the 0th level of abstraction, the code uses an integer, at the 1st it uses a double, then a class with a double member, then a class with a double pointer member... including template iterators until the 12th level is reached. GNU beats Sun and HP's compilers by a factor of 10. Similarly, GNU exception handling is 10 times faster than HP's.

    In terms of the SPEC base benchmarks EGCS attains the same level as SGI's compiler (the best in the business) with -O and -O2 options. Beyond that, SGI allows one to specify tons of options, such as cache size, which generates better code. However no one actually uses these options, so it's not much of an issue.

    As a company, other than the CygWin guys, we don't compare ourselves with the PC guys, so I can't give you a comparison. The DJGPP guys may have some info. Metaware is a non factor for us, since none of our customers complain about our performance.

• Future trends
  • What new features would you like to see in future revisions of GCC?

• • We'd like to see a good implementation bridging the gap between C/C++ and Java. There are good ideas in Java. It provides open standards that are very important to the downloadable world I believe will arise in the future: it provides a simple way to connect to the web, which essential to achieving an information aware infrastructure.

    However Sun's current behaviour is very worrying. Anything that Sun writes becomes a Java API. This is not unlike Microsoft, who redefined C APIs, even though a standard existed (POSIX), to such an extent that even "hello world" will not work (stdout and stderr are not available from winMain()). Sun is playing a similar game with Java, and we fear it will lead to incompatibilities, balkanizing Java, and letting the competition win. Although Sun snipes free versions of Java, all it is doing is replaying the Unix wars. We hope that GCC will be the free standard wedge that keeps the door open.

• What do you think of the idea that programs are JIT compiled to optimize the features being used, to maximize memory efficiency (as Intel's VTUNE does) while minimizing total footprint by leaving most of the code in a compressed bytecode format (as www.tao.co.uk is suggesting).

• • We view the problem rather differently: what do you want to use your CPU power for? Do you want to use it for JIT compilation, or for running the application? We think the latter. So the JIT should be done on the server. There is no reason why your processor could not identify itself to the server and let the server produce whatever native implementation is best for it. Profile information could also be sent to the server in this way. We will be showing in an upcoming Dr Dobbs Journal, that the performance one can achieve in native-compiled Java is comparable to that of C. Speedwise, this is a better solution than a Java chip, because Lisp Machines have already shown us that register based machines present many more opportunities for optimizations than stack machines. Powerwise it is also advantageous as compilation is rather expensive on a battery. Even in terms of code size, gzip compressed 32 bit RISC code is comparable in size to the equivalent byte-code.

• What do you think of IBM's idea of simplifying processor state-machines to increase frequency by moving more of the complexity to software?

• • Like EPIC, the proof will be in the proverbial pudding. Different RISC implementations vary greatly in power, although in principle they should provide similar levels of performance. For instance, a 200 Mhz R10000 provides a similar level of performance to a 600 Mhz Alpha.

• Do you anticipate commercial proprietary source-code will at the end of the day dominate the market-place, or do you feel that free software backed up by a service industry will take over?

• • I think the distinction will be like the difference between public and private life. While we may let all the people on the net look at our source-code we don't let them play with our money. I believe that free software will determine the standards in the world. Proprietary software will exist in niches, where customers don't care for the source code. Instead of spending time building a concensus, proprietary software allows a company to focus on producing a piece of software as quickly as possible to catch a market opportunity. For instance, we use ORACLE's database software. We don't have the source-code, and don't want it because its internal complexity is irrelevant to us: we just want to use it.

This is the first of a series of articles investigating the interplay between Open Source Software and commercial vendors. The common thread will be to find out how authors have earned a living from writing and servicing GPL/Open Source Software.

The series kicks off with Michael Tiemann, one of the founders of Cygnus Solutions, and author of the C++ component of GCC. Cygnus is one of the pioneers in commercial support for open-source software. It sells support and customization services for the gnu programming tools (gcc, gdb, ld, etc). Initially, the Free Software Foundation applauded this, but more recently, RMS feels that by also selling proprietary software Cygnus has betrayed the principle of free software.

In this interview, Michael discusses what it takes to set up a business based on open source software, what Cygnus hopes to add to GCC, and why they took the decision to sell closed source software.

What is written in red, is what Michael wrote to me in an email
What is written in green, is what I transcribed from my notes of our telephone interview. Any mistakes therein are mine.

• How difficult was it for you to set up Cygnus Solutions?
• • How did the banks cope with Cygnus' non orthodox business model?
  • How difficult was it to find the first customers?
  • What advice could you give someone who has written a GPL'd (or similar) program, and wants to live off it by providing services to commercial users?
  • Can one survive purely on the provision of services?
  • What types of services have you found to be the most important for commercial customers? What sort of guaranties do they want? What should one pay special attention to?

• • The greatest challenge in setting up Cygnus was in finding a name under which we could do business. This is not a joke...for three months we went through a process of finding a name, submitting it to the dept. of corporations, only to learn that the name had already been taken. We were about to give up hope when such an ugly name as "Software Support, Inc." had been registered the same year we tried to get it. When we learned that Cygnus Support (note the embedded GNU in Cygnus) was ours to use, we were overjoyed.

    Cygnus was started with virtually no money. At the time, I wanted John Gilmore (whose userid was gnu@sun.com) to be one of the founders (he was employee #5 at Sun, and was the guy who ported BSD Unix to the 68020), not for his money, but for hus programming skills. I put _my_ money where my mouth was, proposing that all three founders put in the same amount of money at the start. At that time, I had less than $3000 in the bank, so I proposed we each put in $2000 at the start, and raise the ante to $5000 when I could afford it. As you can see, we did _nothing_ to try to get banks interested, so there was nothing to explain to them.

    As for finding the first customers...it was just a matter of knocking enough times on the correct doors. As the author of GNU C++, it was pretty easy for me to talk to high-level technical people, who would then introduce me to mid-level managers. We sold GNU support primarily as a cost-saving measure, so we did not need VP level approval. Nowadays we have a much more strategic sell, but we're also much better established, so we can call on and get VP level approvals.

    I've always advised everybody that if they want to start a free software business, they should not let anything stop them. Of those who did, most managed to break even or make a small profit, leading me to believe that there's more to Cygnus's success than merely addressing a market opportunity. We've always been willing to make tough decisions, and we've always listened to customers, even when they were yelling at the top of their voices. Those who do free software for love, rather than money, are not going to survive what we've been through.

    As far as what customers really want...they want somebody who will listen to their needs, formulate a long-term plan, and then deliver without a lot of hassle or risk. Some customers like to see you work; others like to see the work you do; still others think you are doing a great job if they never see you. In the end, it's not the guarantees you offer that make customers come back..it's what you can deliver. The free software model is unique in that it actually gives an incentive for customers to work with you, not independently from you. In the fast-moving high tech world, that advantage has put us in the #1 spot in our market...no mean feat.

• Cygnus and the FSC (Free Software Community)
• • What exactly are you providing to the FSC?

• • We pour about $10M/year into the development of new free software. We run the servers from which 500,000 people have downloaded our stuff. We promote the concept of free software in articles, conferences, and advertising. We sponsor free software projects and pay free software contractors who do work that's related to our business requirements (though not something we'd directly commercialize). We provide a generous matching fund so that employees and customers who want to donate to the FSF can see their donation multiplied.

• How long does it take for your new code to be released in Egcs, or other freely downloadable source code?

• • The std deviation of this number makes an average number meaningless. If you download EGCS, I'll bet that the ChangeLog entries are no more than 45 days old. Compare that to other FSF-controlled packages where they can be months or years old. It is important to realize that we don't control when the FSF releases code.

• How much do you feel you are getting from the FSC? Would it have been simpler to write you own compiler?

• • Simpler, perhaps. But we would not have been able to distinguish ourselves from the other N proprietary companies. I mentioned earlier that people are now chosing Cygnus not because we are cheaper, but because we are _strategic_. We could not have achieved that strategic positioning in the compiler space in any other way.

• What overhead is there with working with the FSC?

• • It's whatever you want. Some people like to spend hours arguing about indentation styles. Others just decide they are going to do somthing and they do it. I wrote the first native-code C++ compiler in 6 month in 1987. It was hard work, and it was rough, but once I demonstrated the momentum I could sustains, dozens joined to the GCC/G++ team.

    In 1989, when GCC 1.x was getting fairly mature, I wrote an instruction scheduler, re-wrote a branch scheduler that had been abandoned, and wrote several cool new optimizations that could not easily fit with GCC 1.x. I declared that we should start GCC 2, with the goal of integrating this new work, new C++ language features, and an eye towards optimal code generation for RISC machines.

    GCC 2.x is now reaching maturity, and it's just not possible to preserve that kind of stability with the while working on advanced/experimental/cool new stuff we want to do. Hence we created EGCS. I've been amazed at the number and quality of volunteers who are now working on that branch. Thus, for GCC 2, the overhead is high, whereas for EGCS, the overhead is negative.

• What sort of friction is there between immediate customer concerns and the interests of the FSC?

• • No difference to any other scarce-resource problem.

• • The FSF's objective is a free software world. The customer's objective is a solution that satisfies his needs. The problem is that commercial work always pays more, so more people do that, which frustrates the FSF that not more people are on its bandwagon.

• Which strengths do you see in the Bazaar and Cathedral models of free software development?

• • Although Eric Raymond is very good at coming up with beautiful theories, I dispute whether they are a true reflection of reality. I see GNU and Linux as two cathedrals. Both Linux and RMS are benevolent dictators. What sets them apart is that Linus is willing to take more risks, to rewrite more of his software, while RMS is a perfectionist. Overall, I believe that risks win, and the risk of reimplementing things lead to a better result. Eric and I were both at the Foresight institute to discuss Netscape releasing their source code. Eric said that Cygnus's model was to provide service to commercial customers for free software products, while Netscape was going to lead the standards with its Free software strategy. I disagree with this since Cygnus too is leading the standards in the embedded market with free software.

• Why did you decide to sell software without source-code, given that this soured your relation with the FSF?

• • We measure success in $$, not FSF relationship. Free software works great for support, not for products.

    Cygnus has been very successful at its challenge. In 8 years we've become the number one tool supplier for the embedded market. Our growth is limited only by the number of sales and technical people we can find to employ. I expect our business will be eventually worth 100 of millions dollars per year. But this has taken lots of effort, and is only achieved by making life easy for our customers. For instance, we support 17 different host-target combinations for Cisco alone. Their routers' CPUs vary from the very simple basic RISC chip to very complex CISC chips with fancy features, yet they want the same code to work on any host-target combination. Contrast this to Sun or Microsoft where the same code will not work on SunOS 4/Solaris or Windows 95/NT. We support SGI, HP, NT (etc) so that our customers do not have to decide on their platform because of us. In total we support 170 different host-target combinations.

    The proprietary model and the free software model provide two different kinds of simplicity. The free software model provides simplicity of APIs: there is no need to waste time reverse-engineering things if you have source. The proprietary model provides simplicity of control: your software does not go off and have a life of its own, you can control your investment, your price points and focus on command performance rather than spend time on building a consensus. For instance, say we have two customers, one of whom has a bad bug he needs fixed, the other of whom has sent us an enhancement to our product. Say furthermore that we only have enough time to service one of their needs. If we fix the bug, then the customer who sent us the enhancement will be disappointed -- they did what the GPL said to do --, and they will wonder why they need support from us, since the guys on the net included their enhancement while we did not. If we add the enhancement, then one of our customers still has a bug, and if he cares nothing for having the source-code, he will look somewhere else for business. So adopting the proprietary model allows us to control our strategy. If the need for strategic control disappears then the software can become free, but this might never happen. For instance, dejagnu was not planned to be commercial software, so we put on the net to get help from the people out there.

    In my opinion, Sun has done a bad job at being a software leader, as has Microsoft. What GNU and Linux are doing is pushing the envelope back up.

• You provide compilers for the embedded market

• • Yes. The embedded market is very different from the traditional desktop market. For instance, the object files that became popular in the embedded market differ from those used in the desktop/workstation markets. Originally embedded people worked on Sun 3's and cross-compiled 68000 code into a.out executables. But a.out has limitations such as not allowing multiple data sections. New formats were devised to address this and other issues.

    Another difference is the embedded market is extremely cost-conscious. For instance, the money made on cellular telephones is made on the subscription. Thus the bill of materials for a cellular telephone must be extremely low. Similarly, end-product functionality is more of a concern that compatibility. Because RISC processors provide approximately twice the compute-power for half the electric power of a CISC processor, they are being adopted more rapidly than in the PC market. MIPS is now dethroning the previous king of the embedded world, the 68000 family, having sold 44 million units last year versus 68000's 42 million.

    Providing one same set of compilers for a wide variety of chips has made us into the standard for the embedded market. We have close ties with CPU companies, such as Toshiba, so that each new chip is released with a new version of our compiler. This makes it easy for our customers to choose which ever chip will give the best cost/performance ratio, without worrying about high porting costs.

• What features did you have to add for this market?

• • We added many features that improve code performance and code size. We provide a very lean and mean implementation of C++ to allow embedded programmers to use the C++ features they need. Indeed, we were the first to ship C++ for the embedded world, for Nortel in 1990. We've added the ability to control via #pragmas the type of return code the compiler should use, so that interrupt routines can be written in C. Another embedded feature is the ability to specify into which segment each function should go. And to help our customers migrate rapidly from chip architecture to chip architecture, we have a whole series of #pragmas to control the way in which data structures are laid out in memory. This allows them to have binary compatibility of data structures even if the code was originally written to access words at odd boundaries, but the target processor does not allow this.

• Are there any new #pragma like commands to control code size at a lower granularity (e.g.: for single functions)

• Are there any new #pragma like commands to control speed as a lower granularity (e.g.: for single functions)

• • We find generally that programmers want the same level of optimization for a particular module. However some optimizations of that kind are described in the processor specific optimization documentation: these are processor dependent trade-offs. For instance, on an R10000 (MIPS), bigger code is faster in that keeps all 4 pipes full. On the other hand, we had to deal with very high space constraints when we worked with Sega. They used the Gnu compiler for the Sega Saturn. And although the SH (Super Hitachi processor) encodes 32 bit instructions into 16 bits, we had to change the compiler significantly to cope with the fact that loading immediate values (such as 57) is very convoluted: you read the value then jump over it, making immediate value loads very expensive when the compiler assumed they would be cheap.

    Generally, we think code size will become less and less of an issue: at the rate at which chips are shrinking and processes are improving (such as the extreme Ultra Violet process), the average DRAM chip will contain 1.7 Gbits in 2001 and 237 Gbits in 2012. Bandwidth problems will be alleviated by developments such as Mitsubishi's M32R chip, which has a core on a 16 Mbit ram, and has a huge bandwidth.

• Do you have any benchmarks to compare the current GCC levels of compilation (code size, speed) with compilers from Metaware, IBM, Microsoft, Borland, Symantec, Intel's VTUNE, etc?

• • We use the Bench++ benchmark. In contrast to SPEC benchmarks, this uses Stepanov's abstraction benchmark to determine the cost of various C++ features. For instance at the 0th level of abstraction, the code uses an integer, at the 1st it uses a double, then a class with a double member, then a class with a double pointer member... including template iterators until the 12th level is reached. GNU beats Sun and HP's compilers by a factor of 10. Similarly, GNU exception handling is 10 times faster than HP's.

    In terms of the SPEC base benchmarks EGCS attains the same level as SGI's compiler (the best in the business) with -O and -O2 options. Beyond that, SGI allows one to specify tons of options, such as cache size, which generates better code. However no one actually uses these options, so it's not much of an issue.

    As a company, other than the CygWin guys, we don't compare ourselves with the PC guys, so I can't give you a comparison. The DJGPP guys may have some info. Metaware is a non factor for us, since none of our customers complain about our performance.

• Future trends
  • What new features would you like to see in future revisions of GCC?

• • We'd like to see a good implementation bridging the gap between C/C++ and Java. There are good ideas in Java. It provides open standards that are very important to the downloadable world I believe will arise in the future: it provides a simple way to connect to the web, which essential to achieving an information aware infrastructure.

    However Sun's current behaviour is very worrying. Anything that Sun writes becomes a Java API. This is not unlike Microsoft, who redefined C APIs, even though a standard existed (POSIX), to such an extent that even "hello world" will not work (stdout and stderr are not available from winMain()). Sun is playing a similar game with Java, and we fear it will lead to incompatibilities, balkanizing Java, and letting the competition win. Although Sun snipes free versions of Java, all it is doing is replaying the Unix wars. We hope that GCC will be the free standard wedge that keeps the door open.

• What do you think of the idea that programs are JIT compiled to optimize the features being used, to maximize memory efficiency (as Intel's VTUNE does) while minimizing total footprint by leaving most of the code in a compressed bytecode format (as www.tao.co.uk is suggesting).

• • We view the problem rather differently: what do you want to use your CPU power for? Do you want to use it for JIT compilation, or for running the application? We think the latter. So the JIT should be done on the server. There is no reason why your processor could not identify itself to the server and let the server produce whatever native implementation is best for it. Profile information could also be sent to the server in this way. We will be showing in an upcoming Dr Dobbs Journal, that the performance one can achieve in native-compiled Java is comparable to that of C. Speedwise, this is a better solution than a Java chip, because Lisp Machines have already shown us that register based machines present many more opportunities for optimizations than stack machines. Powerwise it is also advantageous as compilation is rather expensive on a battery. Even in terms of code size, gzip compressed 32 bit RISC code is comparable in size to the equivalent byte-code.

• What do you think of IBM's idea of simplifying processor state-machines to increase frequency by moving more of the complexity to software?

• • Like EPIC, the proof will be in the proverbial pudding. Different RISC implementations vary greatly in power, although in principle they should provide similar levels of performance. For instance, a 200 Mhz R10000 provides a similar level of performance to a 600 Mhz Alpha.

• Do you anticipate commercial proprietary source-code will at the end of the day dominate the market-place, or do you feel that free software backed up by a service industry will take over?

• • I think the distinction will be like the difference between public and private life. While we may let all the people on the net look at our source-code we don't let them play with our money. I believe that free software will determine the standards in the world. Proprietary software will exist in niches, where customers don't care for the source code. Instead of spending time building a concensus, proprietary software allows a company to focus on producing a piece of software as quickly as possible to catch a market opportunity. For instance, we use ORACLE's database software. We don't have the source-code, and don't want it because its internal complexity is irrelevant to us: we just want to use it.

This is the first of a series of articles investigating the interplay between Open Source Software and commercial vendors. The common thread will be to find out how authors have earned a living from writing and servicing GPL/Open Source Software.

The series kicks off with Michael Tiemann, one of the founders of Cygnus Solutions, and author of the C++ component of GCC. Cygnus is one of the pioneers in commercial support for open-source software. It sells support and customization services for the gnu programming tools (gcc, gdb, ld, etc). Initially, the Free Software Foundation applauded this, but more recently, RMS feels that by also selling proprietary software Cygnus has betrayed the principle of free software.

In this interview, Michael discusses what it takes to set up a business based on open source software, what Cygnus hopes to add to GCC, and why they took the decision to sell closed source software.

What is written in red, is what Michael wrote to me in an email
What is written in green, is what I transcribed from my notes of our telephone interview. Any mistakes therein are mine.

• How difficult was it for you to set up Cygnus Solutions?
• • How did the banks cope with Cygnus' non orthodox business model?
  • How difficult was it to find the first customers?
  • What advice could you give someone who has written a GPL'd (or similar) program, and wants to live off it by providing services to commercial users?
  • Can one survive purely on the provision of services?
  • What types of services have you found to be the most important for commercial customers? What sort of guaranties do they want? What should one pay special attention to?

• • The greatest challenge in setting up Cygnus was in finding a name under which we could do business. This is not a joke...for three months we went through a process of finding a name, submitting it to the dept. of corporations, only to learn that the name had already been taken. We were about to give up hope when such an ugly name as "Software Support, Inc." had been registered the same year we tried to get it. When we learned that Cygnus Support (note the embedded GNU in Cygnus) was ours to use, we were overjoyed.

    Cygnus was started with virtually no money. At the time, I wanted John Gilmore (whose userid was gnu@sun.com) to be one of the founders (he was employee #5 at Sun, and was the guy who ported BSD Unix to the 68020), not for his money, but for hus programming skills. I put _my_ money where my mouth was, proposing that all three founders put in the same amount of money at the start. At that time, I had less than $3000 in the bank, so I proposed we each put in $2000 at the start, and raise the ante to $5000 when I could afford it. As you can see, we did _nothing_ to try to get banks interested, so there was nothing to explain to them.

    As for finding the first customers...it was just a matter of knocking enough times on the correct doors. As the author of GNU C++, it was pretty easy for me to talk to high-level technical people, who would then introduce me to mid-level managers. We sold GNU support primarily as a cost-saving measure, so we did not need VP level approval. Nowadays we have a much more strategic sell, but we're also much better established, so we can call on and get VP level approvals.

    I've always advised everybody that if they want to start a free software business, they should not let anything stop them. Of those who did, most managed to break even or make a small profit, leading me to believe that there's more to Cygnus's success than merely addressing a market opportunity. We've always been willing to make tough decisions, and we've always listened to customers, even when they were yelling at the top of their voices. Those who do free software for love, rather than money, are not going to survive what we've been through.

    As far as what customers really want...they want somebody who will listen to their needs, formulate a long-term plan, and then deliver without a lot of hassle or risk. Some customers like to see you work; others like to see the work you do; still others think you are doing a great job if they never see you. In the end, it's not the guarantees you offer that make customers come back..it's what you can deliver. The free software model is unique in that it actually gives an incentive for customers to work with you, not independently from you. In the fast-moving high tech world, that advantage has put us in the #1 spot in our market...no mean feat.

• Cygnus and the FSC (Free Software Community)
• • What exactly are you providing to the FSC?

• • We pour about $10M/year into the development of new free software. We run the servers from which 500,000 people have downloaded our stuff. We promote the concept of free software in articles, conferences, and advertising. We sponsor free software projects and pay free software contractors who do work that's related to our business requirements (though not something we'd directly commercialize). We provide a generous matching fund so that employees and customers who want to donate to the FSF can see their donation multiplied.

• How long does it take for your new code to be released in Egcs, or other freely downloadable source code?

• • The std deviation of this number makes an average number meaningless. If you download EGCS, I'll bet that the ChangeLog entries are no more than 45 days old. Compare that to other FSF-controlled packages where they can be months or years old. It is important to realize that we don't control when the FSF releases code.

• How much do you feel you are getting from the FSC? Would it have been simpler to write you own compiler?

• • Simpler, perhaps. But we would not have been able to distinguish ourselves from the other N proprietary companies. I mentioned earlier that people are now chosing Cygnus not because we are cheaper, but because we are _strategic_. We could not have achieved that strategic positioning in the compiler space in any other way.

• What overhead is there with working with the FSC?

• • It's whatever you want. Some people like to spend hours arguing about indentation styles. Others just decide they are going to do somthing and they do it. I wrote the first native-code C++ compiler in 6 month in 1987. It was hard work, and it was rough, but once I demonstrated the momentum I could sustains, dozens joined to the GCC/G++ team.

    In 1989, when GCC 1.x was getting fairly mature, I wrote an instruction scheduler, re-wrote a branch scheduler that had been abandoned, and wrote several cool new optimizations that could not easily fit with GCC 1.x. I declared that we should start GCC 2, with the goal of integrating this new work, new C++ language features, and an eye towards optimal code generation for RISC machines.

    GCC 2.x is now reaching maturity, and it's just not possible to preserve that kind of stability with the while working on advanced/experimental/cool new stuff we want to do. Hence we created EGCS. I've been amazed at the number and quality of volunteers who are now working on that branch. Thus, for GCC 2, the overhead is high, whereas for EGCS, the overhead is negative.

• What sort of friction is there between immediate customer concerns and the interests of the FSC?

• • No difference to any other scarce-resource problem.

• • The FSF's objective is a free software world. The customer's objective is a solution that satisfies his needs. The problem is that commercial work always pays more, so more people do that, which frustrates the FSF that not more people are on its bandwagon.

• Which strengths do you see in the Bazaar and Cathedral models of free software development?

• • Although Eric Raymond is very good at coming up with beautiful theories, I dispute whether they are a true reflection of reality. I see GNU and Linux as two cathedrals. Both Linux and RMS are benevolent dictators. What sets them apart is that Linus is willing to take more risks, to rewrite more of his software, while RMS is a perfectionist. Overall, I believe that risks win, and the risk of reimplementing things lead to a better result. Eric and I were both at the Foresight institute to discuss Netscape releasing their source code. Eric said that Cygnus's model was to provide service to commercial customers for free software products, while Netscape was going to lead the standards with its Free software strategy. I disagree with this since Cygnus too is leading the standards in the embedded market with free software.

• Why did you decide to sell software without source-code, given that this soured your relation with the FSF?

• • We measure success in $$, not FSF relationship. Free software works great for support, not for products.

    Cygnus has been very successful at its challenge. In 8 years we've become the number one tool supplier for the embedded market. Our growth is limited only by the number of sales and technical people we can find to employ. I expect our business will be eventually worth 100 of millions dollars per year. But this has taken lots of effort, and is only achieved by making life easy for our customers. For instance, we support 17 different host-target combinations for Cisco alone. Their routers' CPUs vary from the very simple basic RISC chip to very complex CISC chips with fancy features, yet they want the same code to work on any host-target combination. Contrast this to Sun or Microsoft where the same code will not work on SunOS 4/Solaris or Windows 95/NT. We support SGI, HP, NT (etc) so that our customers do not have to decide on their platform because of us. In total we support 170 different host-target combinations.

    The proprietary model and the free software model provide two different kinds of simplicity. The free software model provides simplicity of APIs: there is no need to waste time reverse-engineering things if you have source. The proprietary model provides simplicity of control: your software does not go off and have a life of its own, you can control your investment, your price points and focus on command performance rather than spend time on building a consensus. For instance, say we have two customers, one of whom has a bad bug he needs fixed, the other of whom has sent us an enhancement to our product. Say furthermore that we only have enough time to service one of their needs. If we fix the bug, then the customer who sent us the enhancement will be disappointed -- they did what the GPL said to do --, and they will wonder why they need support from us, since the guys on the net included their enhancement while we did not. If we add the enhancement, then one of our customers still has a bug, and if he cares nothing for having the source-code, he will look somewhere else for business. So adopting the proprietary model allows us to control our strategy. If the need for strategic control disappears then the software can become free, but this might never happen. For instance, dejagnu was not planned to be commercial software, so we put on the net to get help from the people out there.

    In my opinion, Sun has done a bad job at being a software leader, as has Microsoft. What GNU and Linux are doing is pushing the envelope back up.

• You provide compilers for the embedded market

• • Yes. The embedded market is very different from the traditional desktop market. For instance, the object files that became popular in the embedded market differ from those used in the desktop/workstation markets. Originally embedded people worked on Sun 3's and cross-compiled 68000 code into a.out executables. But a.out has limitations such as not allowing multiple data sections. New formats were devised to address this and other issues.

    Another difference is the embedded market is extremely cost-conscious. For instance, the money made on cellular telephones is made on the subscription. Thus the bill of materials for a cellular telephone must be extremely low. Similarly, end-product functionality is more of a concern that compatibility. Because RISC processors provide approximately twice the compute-power for half the electric power of a CISC processor, they are being adopted more rapidly than in the PC market. MIPS is now dethroning the previous king of the embedded world, the 68000 family, having sold 44 million units last year versus 68000's 42 million.

    Providing one same set of compilers for a wide variety of chips has made us into the standard for the embedded market. We have close ties with CPU companies, such as Toshiba, so that each new chip is released with a new version of our compiler. This makes it easy for our customers to choose which ever chip will give the best cost/performance ratio, without worrying about high porting costs.

• What features did you have to add for this market?

• • We added many features that improve code performance and code size. We provide a very lean and mean implementation of C++ to allow embedded programmers to use the C++ features they need. Indeed, we were the first to ship C++ for the embedded world, for Nortel in 1990. We've added the ability to control via #pragmas the type of return code the compiler should use, so that interrupt routines can be written in C. Another embedded feature is the ability to specify into which segment each function should go. And to help our customers migrate rapidly from chip architecture to chip architecture, we have a whole series of #pragmas to control the way in which data structures are laid out in memory. This allows them to have binary compatibility of data structures even if the code was originally written to access words at odd boundaries, but the target processor does not allow this.

• Are there any new #pragma like commands to control code size at a lower granularity (e.g.: for single functions)

• Are there any new #pragma like commands to control speed as a lower granularity (e.g.: for single functions)

• • We find generally that programmers want the same level of optimization for a particular module. However some optimizations of that kind are described in the processor specific optimization documentation: these are processor dependent trade-offs. For instance, on an R10000 (MIPS), bigger code is faster in that keeps all 4 pipes full. On the other hand, we had to deal with very high space constraints when we worked with Sega. They used the Gnu compiler for the Sega Saturn. And although the SH (Super Hitachi processor) encodes 32 bit instructions into 16 bits, we had to change the compiler significantly to cope with the fact that loading immediate values (such as 57) is very convoluted: you read the value then jump over it, making immediate value loads very expensive when the compiler assumed they would be cheap.

    Generally, we think code size will become less and less of an issue: at the rate at which chips are shrinking and processes are improving (such as the extreme Ultra Violet process), the average DRAM chip will contain 1.7 Gbits in 2001 and 237 Gbits in 2012. Bandwidth problems will be alleviated by developments such as Mitsubishi's M32R chip, which has a core on a 16 Mbit ram, and has a huge bandwidth.

• Do you have any benchmarks to compare the current GCC levels of compilation (code size, speed) with compilers from Metaware, IBM, Microsoft, Borland, Symantec, Intel's VTUNE, etc?

• • We use the Bench++ benchmark. In contrast to SPEC benchmarks, this uses Stepanov's abstraction benchmark to determine the cost of various C++ features. For instance at the 0th level of abstraction, the code uses an integer, at the 1st it uses a double, then a class with a double member, then a class with a double pointer member... including template iterators until the 12th level is reached. GNU beats Sun and HP's compilers by a factor of 10. Similarly, GNU exception handling is 10 times faster than HP's.

    In terms of the SPEC base benchmarks EGCS attains the same level as SGI's compiler (the best in the business) with -O and -O2 options. Beyond that, SGI allows one to specify tons of options, such as cache size, which generates better code. However no one actually uses these options, so it's not much of an issue.

    As a company, other than the CygWin guys, we don't compare ourselves with the PC guys, so I can't give you a comparison. The DJGPP guys may have some info. Metaware is a non factor for us, since none of our customers complain about our performance.

• Future trends
  • What new features would you like to see in future revisions of GCC?

• • We'd like to see a good implementation bridging the gap between C/C++ and Java. There are good ideas in Java. It provides open standards that are very important to the downloadable world I believe will arise in the future: it provides a simple way to connect to the web, which essential to achieving an information aware infrastructure.

    However Sun's current behaviour is very worrying. Anything that Sun writes becomes a Java API. This is not unlike Microsoft, who redefined C APIs, even though a standard existed (POSIX), to such an extent that even "hello world" will not work (stdout and stderr are not available from winMain()). Sun is playing a similar game with Java, and we fear it will lead to incompatibilities, balkanizing Java, and letting the competition win. Although Sun snipes free versions of Java, all it is doing is replaying the Unix wars. We hope that GCC will be the free standard wedge that keeps the door open.

• What do you think of the idea that programs are JIT compiled to optimize the features being used, to maximize memory efficiency (as Intel's VTUNE does) while minimizing total footprint by leaving most of the code in a compressed bytecode format (as www.tao.co.uk is suggesting).

• • We view the problem rather differently: what do you want to use your CPU power for? Do you want to use it for JIT compilation, or for running the application? We think the latter. So the JIT should be done on the server. There is no reason why your processor could not identify itself to the server and let the server produce whatever native implementation is best for it. Profile information could also be sent to the server in this way. We will be showing in an upcoming Dr Dobbs Journal, that the performance one can achieve in native-compiled Java is comparable to that of C. Speedwise, this is a better solution than a Java chip, because Lisp Machines have already shown us that register based machines present many more opportunities for optimizations than stack machines. Powerwise it is also advantageous as compilation is rather expensive on a battery. Even in terms of code size, gzip compressed 32 bit RISC code is comparable in size to the equivalent byte-code.

• What do you think of IBM's idea of simplifying processor state-machines to increase frequency by moving more of the complexity to software?

• • Like EPIC, the proof will be in the proverbial pudding. Different RISC implementations vary greatly in power, although in principle they should provide similar levels of performance. For instance, a 200 Mhz R10000 provides a similar level of performance to a 600 Mhz Alpha.

• Do you anticipate commercial proprietary source-code will at the end of the day dominate the market-place, or do you feel that free software backed up by a service industry will take over?

• • I think the distinction will be like the difference between public and private life. While we may let all the people on the net look at our source-code we don't let them play with our money. I believe that free software will determine the standards in the world. Proprietary software will exist in niches, where customers don't care for the source code. Instead of spending time building a concensus, proprietary software allows a company to focus on producing a piece of software as quickly as possible to catch a market opportunity. For instance, we use ORACLE's database software. We don't have the source-code, and don't want it because its internal complexity is irrelevant to us: we just want to use it.

This is the first of a series of articles investigating the interplay between Open Source Software and commercial vendors. The common thread will be to find out how authors have earned a living from writing and servicing GPL/Open Source Software.

The series kicks off with Michael Tiemann, one of the founders of Cygnus Solutions, and author of the C++ component of GCC. Cygnus is one of the pioneers in commercial support for open-source software. It sells support and customization services for the gnu programming tools (gcc, gdb, ld, etc). Initially, the Free Software Foundation applauded this, but more recently, RMS feels that by also selling proprietary software Cygnus has betrayed the principle of free software.

In this interview, Michael discusses what it takes to set up a business based on open source software, what Cygnus hopes to add to GCC, and why they took the decision to sell closed source software.

What is written in red, is what Michael wrote to me in an email
What is written in green, is what I transcribed from my notes of our telephone interview. Any mistakes therein are mine.

• How difficult was it for you to set up Cygnus Solutions?
• • How did the banks cope with Cygnus' non orthodox business model?
  • How difficult was it to find the first customers?
  • What advice could you give someone who has written a GPL'd (or similar) program, and wants to live off it by providing services to commercial users?
  • Can one survive purely on the provision of services?
  • What types of services have you found to be the most important for commercial customers? What sort of guaranties do they want? What should one pay special attention to?

• • The greatest challenge in setting up Cygnus was in finding a name under which we could do business. This is not a joke...for three months we went through a process of finding a name, submitting it to the dept. of corporations, only to learn that the name had already been taken. We were about to give up hope when such an ugly name as "Software Support, Inc." had been registered the same year we tried to get it. When we learned that Cygnus Support (note the embedded GNU in Cygnus) was ours to use, we were overjoyed.

    Cygnus was started with virtually no money. At the time, I wanted John Gilmore (whose userid was gnu@sun.com) to be one of the founders (he was employee #5 at Sun, and was the guy who ported BSD Unix to the 68020), not for his money, but for hus programming skills. I put _my_ money where my mouth was, proposing that all three founders put in the same amount of money at the start. At that time, I had less than $3000 in the bank, so I proposed we each put in $2000 at the start, and raise the ante to $5000 when I could afford it. As you can see, we did _nothing_ to try to get banks interested, so there was nothing to explain to them.

    As for finding the first customers...it was just a matter of knocking enough times on the correct doors. As the author of GNU C++, it was pretty easy for me to talk to high-level technical people, who would then introduce me to mid-level managers. We sold GNU support primarily as a cost-saving measure, so we did not need VP level approval. Nowadays we have a much more strategic sell, but we're also much better established, so we can call on and get VP level approvals.

    I've always advised everybody that if they want to start a free software business, they should not let anything stop them. Of those who did, most managed to break even or make a small profit, leading me to believe that there's more to Cygnus's success than merely addressing a market opportunity. We've always been willing to make tough decisions, and we've always listened to customers, even when they were yelling at the top of their voices. Those who do free software for love, rather than money, are not going to survive what we've been through.

    As far as what customers really want...they want somebody who will listen to their needs, formulate a long-term plan, and then deliver without a lot of hassle or risk. Some customers like to see you work; others like to see the work you do; still others think you are doing a great job if they never see you. In the end, it's not the guarantees you offer that make customers come back..it's what you can deliver. The free software model is unique in that it actually gives an incentive for customers to work with you, not independently from you. In the fast-moving high tech world, that advantage has put us in the #1 spot in our market...no mean feat.

• Cygnus and the FSC (Free Software Community)
• • What exactly are you providing to the FSC?

• • We pour about $10M/year into the development of new free software. We run the servers from which 500,000 people have downloaded our stuff. We promote the concept of free software in articles, conferences, and advertising. We sponsor free software projects and pay free software contractors who do work that's related to our business requirements (though not something we'd directly commercialize). We provide a generous matching fund so that employees and customers who want to donate to the FSF can see their donation multiplied.

• How long does it take for your new code to be released in Egcs, or other freely downloadable source code?

• • The std deviation of this number makes an average number meaningless. If you download EGCS, I'll bet that the ChangeLog entries are no more than 45 days old. Compare that to other FSF-controlled packages where they can be months or years old. It is important to realize that we don't control when the FSF releases code.

• How much do you feel you are getting from the FSC? Would it have been simpler to write you own compiler?

• • Simpler, perhaps. But we would not have been able to distinguish ourselves from the other N proprietary companies. I mentioned earlier that people are now chosing Cygnus not because we are cheaper, but because we are _strategic_. We could not have achieved that strategic positioning in the compiler space in any other way.

• What overhead is there with working with the FSC?

• • It's whatever you want. Some people like to spend hours arguing about indentation styles. Others just decide they are going to do somthing and they do it. I wrote the first native-code C++ compiler in 6 month in 1987. It was hard work, and it was rough, but once I demonstrated the momentum I could sustains, dozens joined to the GCC/G++ team.

    In 1989, when GCC 1.x was getting fairly mature, I wrote an instruction scheduler, re-wrote a branch scheduler that had been abandoned, and wrote several cool new optimizations that could not easily fit with GCC 1.x. I declared that we should start GCC 2, with the goal of integrating this new work, new C++ language features, and an eye towards optimal code generation for RISC machines.

    GCC 2.x is now reaching maturity, and it's just not possible to preserve that kind of stability with the while working on advanced/experimental/cool new stuff we want to do. Hence we created EGCS. I've been amazed at the number and quality of volunteers who are now working on that branch. Thus, for GCC 2, the overhead is high, whereas for EGCS, the overhead is negative.

• What sort of friction is there between immediate customer concerns and the interests of the FSC?

• • No difference to any other scarce-resource problem.

• • The FSF's objective is a free software world. The customer's objective is a solution that satisfies his needs. The problem is that commercial work always pays more, so more people do that, which frustrates the FSF that not more people are on its bandwagon.

• Which strengths do you see in the Bazaar and Cathedral models of free software development?

• • Although Eric Raymond is very good at coming up with beautiful theories, I dispute whether they are a true reflection of reality. I see GNU and Linux as two cathedrals. Both Linux and RMS are benevolent dictators. What sets them apart is that Linus is willing to take more risks, to rewrite more of his software, while RMS is a perfectionist. Overall, I believe that risks win, and the risk of reimplementing things lead to a better result. Eric and I were both at the Foresight institute to discuss Netscape releasing their source code. Eric said that Cygnus's model was to provide service to commercial customers for free software products, while Netscape was going to lead the standards with its Free software strategy. I disagree with this since Cygnus too is leading the standards in the embedded market with free software.

• Why did you decide to sell software without source-code, given that this soured your relation with the FSF?

• • We measure success in $$, not FSF relationship. Free software works great for support, not for products.

    Cygnus has been very successful at its challenge. In 8 years we've become the number one tool supplier for the embedded market. Our growth is limited only by the number of sales and technical people we can find to employ. I expect our business will be eventually worth 100 of millions dollars per year. But this has taken lots of effort, and is only achieved by making life easy for our customers. For instance, we support 17 different host-target combinations for Cisco alone. Their routers' CPUs vary from the very simple basic RISC chip to very complex CISC chips with fancy features, yet they want the same code to work on any host-target combination. Contrast this to Sun or Microsoft where the same code will not work on SunOS 4/Solaris or Windows 95/NT. We support SGI, HP, NT (etc) so that our customers do not have to decide on their platform because of us. In total we support 170 different host-target combinations.

    The proprietary model and the free software model provide two different kinds of simplicity. The free software model provides simplicity of APIs: there is no need to waste time reverse-engineering things if you have source. The proprietary model provides simplicity of control: your software does not go off and have a life of its own, you can control your investment, your price points and focus on command performance rather than spend time on building a consensus. For instance, say we have two customers, one of whom has a bad bug he needs fixed, the other of whom has sent us an enhancement to our product. Say furthermore that we only have enough time to service one of their needs. If we fix the bug, then the customer who sent us the enhancement will be disappointed -- they did what the GPL said to do --, and they will wonder why they need support from us, since the guys on the net included their enhancement while we did not. If we add the enhancement, then one of our customers still has a bug, and if he cares nothing for having the source-code, he will look somewhere else for business. So adopting the proprietary model allows us to control our strategy. If the need for strategic control disappears then the software can become free, but this might never happen. For instance, dejagnu was not planned to be commercial software, so we put on the net to get help from the people out there.

    In my opinion, Sun has done a bad job at being a software leader, as has Microsoft. What GNU and Linux are doing is pushing the envelope back up.

• You provide compilers for the embedded market

• • Yes. The embedded market is very different from the traditional desktop market. For instance, the object files that became popular in the embedded market differ from those used in the desktop/workstation markets. Originally embedded people worked on Sun 3's and cross-compiled 68000 code into a.out executables. But a.out has limitations such as not allowing multiple data sections. New formats were devised to address this and other issues.

    Another difference is the embedded market is extremely cost-conscious. For instance, the money made on cellular telephones is made on the subscription. Thus the bill of materials for a cellular telephone must be extremely low. Similarly, end-product functionality is more of a concern that compatibility. Because RISC processors provide approximately twice the compute-power for half the electric power of a CISC processor, they are being adopted more rapidly than in the PC market. MIPS is now dethroning the previous king of the embedded world, the 68000 family, having sold 44 million units last year versus 68000's 42 million.

    Providing one same set of compilers for a wide variety of chips has made us into the standard for the embedded market. We have close ties with CPU companies, such as Toshiba, so that each new chip is released with a new version of our compiler. This makes it easy for our customers to choose which ever chip will give the best cost/performance ratio, without worrying about high porting costs.

• What features did you have to add for this market?

• • We added many features that improve code performance and code size. We provide a very lean and mean implementation of C++ to allow embedded programmers to use the C++ features they need. Indeed, we were the first to ship C++ for the embedded world, for Nortel in 1990. We've added the ability to control via #pragmas the type of return code the compiler should use, so that interrupt routines can be written in C. Another embedded feature is the ability to specify into which segment each function should go. And to help our customers migrate rapidly from chip architecture to chip architecture, we have a whole series of #pragmas to control the way in which data structures are laid out in memory. This allows them to have binary compatibility of data structures even if the code was originally written to access words at odd boundaries, but the target processor does not allow this.

• Are there any new #pragma like commands to control code size at a lower granularity (e.g.: for single functions)

• Are there any new #pragma like commands to control speed as a lower granularity (e.g.: for single functions)

• • We find generally that programmers want the same level of optimization for a particular module. However some optimizations of that kind are described in the processor specific optimization documentation: these are processor dependent trade-offs. For instance, on an R10000 (MIPS), bigger code is faster in that keeps all 4 pipes full. On the other hand, we had to deal with very high space constraints when we worked with Sega. They used the Gnu compiler for the Sega Saturn. And although the SH (Super Hitachi processor) encodes 32 bit instructions into 16 bits, we had to change the compiler significantly to cope with the fact that loading immediate values (such as 57) is very convoluted: you read the value then jump over it, making immediate value loads very expensive when the compiler assumed they would be cheap.

    Generally, we think code size will become less and less of an issue: at the rate at which chips are shrinking and processes are improving (such as the extreme Ultra Violet process), the average DRAM chip will contain 1.7 Gbits in 2001 and 237 Gbits in 2012. Bandwidth problems will be alleviated by developments such as Mitsubishi's M32R chip, which has a core on a 16 Mbit ram, and has a huge bandwidth.

• Do you have any benchmarks to compare the current GCC levels of compilation (code size, speed) with compilers from Metaware, IBM, Microsoft, Borland, Symantec, Intel's VTUNE, etc?

• • We use the Bench++ benchmark. In contrast to SPEC benchmarks, this uses Stepanov's abstraction benchmark to determine the cost of various C++ features. For instance at the 0th level of abstraction, the code uses an integer, at the 1st it uses a double, then a class with a double member, then a class with a double pointer member... including template iterators until the 12th level is reached. GNU beats Sun and HP's compilers by a factor of 10. Similarly, GNU exception handling is 10 times faster than HP's.

    In terms of the SPEC base benchmarks EGCS attains the same level as SGI's compiler (the best in the business) with -O and -O2 options. Beyond that, SGI allows one to specify tons of options, such as cache size, which generates better code. However no one actually uses these options, so it's not much of an issue.

    As a company, other than the CygWin guys, we don't compare ourselves with the PC guys, so I can't give you a comparison. The DJGPP guys may have some info. Metaware is a non factor for us, since none of our customers complain about our performance.

• Future trends
  • What new features would you like to see in future revisions of GCC?

• • We'd like to see a good implementation bridging the gap between C/C++ and Java. There are good ideas in Java. It provides open standards that are very important to the downloadable world I believe will arise in the future: it provides a simple way to connect to the web, which essential to achieving an information aware infrastructure.

    However Sun's current behaviour is very worrying. Anything that Sun writes becomes a Java API. This is not unlike Microsoft, who redefined C APIs, even though a standard existed (POSIX), to such an extent that even "hello world" will not work (stdout and stderr are not available from winMain()). Sun is playing a similar game with Java, and we fear it will lead to incompatibilities, balkanizing Java, and letting the competition win. Although Sun snipes free versions of Java, all it is doing is replaying the Unix wars. We hope that GCC will be the free standard wedge that keeps the door open.

• What do you think of the idea that programs are JIT compiled to optimize the features being used, to maximize memory efficiency (as Intel's VTUNE does) while minimizing total footprint by leaving most of the code in a compressed bytecode format (as www.tao.co.uk is suggesting).

• • We view the problem rather differently: what do you want to use your CPU power for? Do you want to use it for JIT compilation, or for running the application? We think the latter. So the JIT should be done on the server. There is no reason why your processor could not identify itself to the server and let the server produce whatever native implementation is best for it. Profile information could also be sent to the server in this way. We will be showing in an upcoming Dr Dobbs Journal, that the performance one can achieve in native-compiled Java is comparable to that of C. Speedwise, this is a better solution than a Java chip, because Lisp Machines have already shown us that register based machines present many more opportunities for optimizations than stack machines. Powerwise it is also advantageous as compilation is rather expensive on a battery. Even in terms of code size, gzip compressed 32 bit RISC code is comparable in size to the equivalent byte-code.

• What do you think of IBM's idea of simplifying processor state-machines to increase frequency by moving more of the complexity to software?

• • Like EPIC, the proof will be in the proverbial pudding. Different RISC implementations vary greatly in power, although in principle they should provide similar levels of performance. For instance, a 200 Mhz R10000 provides a similar level of performance to a 600 Mhz Alpha.

• Do you anticipate commercial proprietary source-code will at the end of the day dominate the market-place, or do you feel that free software backed up by a service industry will take over?

• • I think the distinction will be like the difference between public and private life. While we may let all the people on the net look at our source-code we don't let them play with our money. I believe that free software will determine the standards in the world. Proprietary software will exist in niches, where customers don't care for the source code. Instead of spending time building a concensus, proprietary software allows a company to focus on producing a piece of software as quickly as possible to catch a market opportunity. For instance, we use ORACLE's database software. We don't have the source-code, and don't want it because its internal complexity is irrelevant to us: we just want to use it.

This is the first of a series of articles investigating the interplay between Open Source Software and commercial vendors. The common thread will be to find out how authors have earned a living from writing and servicing GPL/Open Source Software.

The series kicks off with Michael Tiemann, one of the founders of Cygnus Solutions, and author of the C++ component of GCC. Cygnus is one of the pioneers in commercial support for open-source software. It sells support and customization services for the gnu programming tools (gcc, gdb, ld, etc). Initially, the Free Software Foundation applauded this, but more recently, RMS feels that by also selling proprietary software Cygnus has betrayed the principle of free software.

In this interview, Michael discusses what it takes to set up a business based on open source software, what Cygnus hopes to add to GCC, and why they took the decision to sell closed source software.

What is written in red, is what Michael wrote to me in an email
What is written in green, is what I transcribed from my notes of our telephone interview. Any mistakes therein are mine.

• How difficult was it for you to set up Cygnus Solutions?
• • How did the banks cope with Cygnus' non orthodox business model?
  • How difficult was it to find the first customers?
  • What advice could you give someone who has written a GPL'd (or similar) program, and wants to live off it by providing services to commercial users?
  • Can one survive purely on the provision of services?
  • What types of services have you found to be the most important for commercial customers? What sort of guaranties do they want? What should one pay special attention to?

• • The greatest challenge in setting up Cygnus was in finding a name under which we could do business. This is not a joke...for three months we went through a process of finding a name, submitting it to the dept. of corporations, only to learn that the name had already been taken. We were about to give up hope when such an ugly name as "Software Support, Inc." had been registered the same year we tried to get it. When we learned that Cygnus Support (note the embedded GNU in Cygnus) was ours to use, we were overjoyed.

    Cygnus was started with virtually no money. At the time, I wanted John Gilmore (whose userid was gnu@sun.com) to be one of the founders (he was employee #5 at Sun, and was the guy who ported BSD Unix to the 68020), not for his money, but for hus programming skills. I put _my_ money where my mouth was, proposing that all three founders put in the same amount of money at the start. At that time, I had less than $3000 in the bank, so I proposed we each put in $2000 at the start, and raise the ante to $5000 when I could afford it. As you can see, we did _nothing_ to try to get banks interested, so there was nothing to explain to them.

    As for finding the first customers...it was just a matter of knocking enough times on the correct doors. As the author of GNU C++, it was pretty easy for me to talk to high-level technical people, who would then introduce me to mid-level managers. We sold GNU support primarily as a cost-saving measure, so we did not need VP level approval. Nowadays we have a much more strategic sell, but we're also much better established, so we can call on and get VP level approvals.

    I've always advised everybody that if they want to start a free software business, they should not let anything stop them. Of those who did, most managed to break even or make a small profit, leading me to believe that there's more to Cygnus's success than merely addressing a market opportunity. We've always been willing to make tough decisions, and we've always listened to customers, even when they were yelling at the top of their voices. Those who do free software for love, rather than money, are not going to survive what we've been through.

    As far as what customers really want...they want somebody who will listen to their needs, formulate a long-term plan, and then deliver without a lot of hassle or risk. Some customers like to see you work; others like to see the work you do; still others think you are doing a great job if they never see you. In the end, it's not the guarantees you offer that make customers come back..it's what you can deliver. The free software model is unique in that it actually gives an incentive for customers to work with you, not independently from you. In the fast-moving high tech world, that advantage has put us in the #1 spot in our market...no mean feat.

• Cygnus and the FSC (Free Software Community)
• • What exactly are you providing to the FSC?

• • We pour about $10M/year into the development of new free software. We run the servers from which 500,000 people have downloaded our stuff. We promote the concept of free software in articles, conferences, and advertising. We sponsor free software projects and pay free software contractors who do work that's related to our business requirements (though not something we'd directly commercialize). We provide a generous matching fund so that employees and customers who want to donate to the FSF can see their donation multiplied.

• How long does it take for your new code to be released in Egcs, or other freely downloadable source code?

• • The std deviation of this number makes an average number meaningless. If you download EGCS, I'll bet that the ChangeLog entries are no more than 45 days old. Compare that to other FSF-controlled packages where they can be months or years old. It is important to realize that we don't control when the FSF releases code.

• How much do you feel you are getting from the FSC? Would it have been simpler to write you own compiler?

• • Simpler, perhaps. But we would not have been able to distinguish ourselves from the other N proprietary companies. I mentioned earlier that people are now chosing Cygnus not because we are cheaper, but because we are _strategic_. We could not have achieved that strategic positioning in the compiler space in any other way.

• What overhead is there with working with the FSC?

• • It's whatever you want. Some people like to spend hours arguing about indentation styles. Others just decide they are going to do somthing and they do it. I wrote the first native-code C++ compiler in 6 month in 1987. It was hard work, and it was rough, but once I demonstrated the momentum I could sustains, dozens joined to the GCC/G++ team.

    In 1989, when GCC 1.x was getting fairly mature, I wrote an instruction scheduler, re-wrote a branch scheduler that had been abandoned, and wrote several cool new optimizations that could not easily fit with GCC 1.x. I declared that we should start GCC 2, with the goal of integrating this new work, new C++ language features, and an eye towards optimal code generation for RISC machines.

    GCC 2.x is now reaching maturity, and it's just not possible to preserve that kind of stability with the while working on advanced/experimental/cool new stuff we want to do. Hence we created EGCS. I've been amazed at the number and quality of volunteers who are now working on that branch. Thus, for GCC 2, the overhead is high, whereas for EGCS, the overhead is negative.

• What sort of friction is there between immediate customer concerns and the interests of the FSC?

• • No difference to any other scarce-resource problem.

• • The FSF's objective is a free software world. The customer's objective is a solution that satisfies his needs. The problem is that commercial work always pays more, so more people do that, which frustrates the FSF that not more people are on its bandwagon.

• Which strengths do you see in the Bazaar and Cathedral models of free software development?

• • Although Eric Raymond is very good at coming up with beautiful theories, I dispute whether they are a true reflection of reality. I see GNU and Linux as two cathedrals. Both Linux and RMS are benevolent dictators. What sets them apart is that Linus is willing to take more risks, to rewrite more of his software, while RMS is a perfectionist. Overall, I believe that risks win, and the risk of reimplementing things lead to a better result. Eric and I were both at the Foresight institute to discuss Netscape releasing their source code. Eric said that Cygnus's model was to provide service to commercial customers for free software products, while Netscape was going to lead the standards with its Free software strategy. I disagree with this since Cygnus too is leading the standards in the embedded market with free software.

• Why did you decide to sell software without source-code, given that this soured your relation with the FSF?

• • We measure success in $$, not FSF relationship. Free software works great for support, not for products.

    Cygnus has been very successful at its challenge. In 8 years we've become the number one tool supplier for the embedded market. Our growth is limited only by the number of sales and technical people we can find to employ. I expect our business will be eventually worth 100 of millions dollars per year. But this has taken lots of effort, and is only achieved by making life easy for our customers. For instance, we support 17 different host-target combinations for Cisco alone. Their routers' CPUs vary from the very simple basic RISC chip to very complex CISC chips with fancy features, yet they want the same code to work on any host-target combination. Contrast this to Sun or Microsoft where the same code will not work on SunOS 4/Solaris or Windows 95/NT. We support SGI, HP, NT (etc) so that our customers do not have to decide on their platform because of us. In total we support 170 different host-target combinations.

    The proprietary model and the free software model provide two different kinds of simplicity. The free software model provides simplicity of APIs: there is no need to waste time reverse-engineering things if you have source. The proprietary model provides simplicity of control: your software does not go off and have a life of its own, you can control your investment, your price points and focus on command performance rather than spend time on building a consensus. For instance, say we have two customers, one of whom has a bad bug he needs fixed, the other of whom has sent us an enhancement to our product. Say furthermore that we only have enough time to service one of their needs. If we fix the bug, then the customer who sent us the enhancement will be disappointed -- they did what the GPL said to do --, and they will wonder why they need support from us, since the guys on the net included their enhancement while we did not. If we add the enhancement, then one of our customers still has a bug, and if he cares nothing for having the source-code, he will look somewhere else for business. So adopting the proprietary model allows us to control our strategy. If the need for strategic control disappears then the software can become free, but this might never happen. For instance, dejagnu was not planned to be commercial software, so we put on the net to get help from the people out there.

    In my opinion, Sun has done a bad job at being a software leader, as has Microsoft. What GNU and Linux are doing is pushing the envelope back up.

• You provide compilers for the embedded market

• • Yes. The embedded market is very different from the traditional desktop market. For instance, the object files that became popular in the embedded market differ from those used in the desktop/workstation markets. Originally embedded people worked on Sun 3's and cross-compiled 68000 code into a.out executables. But a.out has limitations such as not allowing multiple data sections. New formats were devised to address this and other issues.

    Another difference is the embedded market is extremely cost-conscious. For instance, the money made on cellular telephones is made on the subscription. Thus the bill of materials for a cellular telephone must be extremely low. Similarly, end-product functionality is more of a concern that compatibility. Because RISC processors provide approximately twice the compute-power for half the electric power of a CISC processor, they are being adopted more rapidly than in the PC market. MIPS is now dethroning the previous king of the embedded world, the 68000 family, having sold 44 million units last year versus 68000's 42 million.

    Providing one same set of compilers for a wide variety of chips has made us into the standard for the embedded market. We have close ties with CPU companies, such as Toshiba, so that each new chip is released with a new version of our compiler. This makes it easy for our customers to choose which ever chip will give the best cost/performance ratio, without worrying about high porting costs.

• What features did you have to add for this market?

• • We added many features that improve code performance and code size. We provide a very lean and mean implementation of C++ to allow embedded programmers to use the C++ features they need. Indeed, we were the first to ship C++ for the embedded world, for Nortel in 1990. We've added the ability to control via #pragmas the type of return code the compiler should use, so that interrupt routines can be written in C. Another embedded feature is the ability to specify into which segment each function should go. And to help our customers migrate rapidly from chip architecture to chip architecture, we have a whole series of #pragmas to control the way in which data structures are laid out in memory. This allows them to have binary compatibility of data structures even if the code was originally written to access words at odd boundaries, but the target processor does not allow this.

• Are there any new #pragma like commands to control code size at a lower granularity (e.g.: for single functions)

• Are there any new #pragma like commands to control speed as a lower granularity (e.g.: for single functions)

• • We find generally that programmers want the same level of optimization for a particular module. However some optimizations of that kind are described in the processor specific optimization documentation: these are processor dependent trade-offs. For instance, on an R10000 (MIPS), bigger code is faster in that keeps all 4 pipes full. On the other hand, we had to deal with very high space constraints when we worked with Sega. They used the Gnu compiler for the Sega Saturn. And although the SH (Super Hitachi processor) encodes 32 bit instructions into 16 bits, we had to change the compiler significantly to cope with the fact that loading immediate values (such as 57) is very convoluted: you read the value then jump over it, making immediate value loads very expensive when the compiler assumed they would be cheap.

    Generally, we think code size will become less and less of an issue: at the rate at which chips are shrinking and processes are improving (such as the extreme Ultra Violet process), the average DRAM chip will contain 1.7 Gbits in 2001 and 237 Gbits in 2012. Bandwidth problems will be alleviated by developments such as Mitsubishi's M32R chip, which has a core on a 16 Mbit ram, and has a huge bandwidth.

• Do you have any benchmarks to compare the current GCC levels of compilation (code size, speed) with compilers from Metaware, IBM, Microsoft, Borland, Symantec, Intel's VTUNE, etc?

• • We use the Bench++ benchmark. In contrast to SPEC benchmarks, this uses Stepanov's abstraction benchmark to determine the cost of various C++ features. For instance at the 0th level of abstraction, the code uses an integer, at the 1st it uses a double, then a class with a double member, then a class with a double pointer member... including template iterators until the 12th level is reached. GNU beats Sun and HP's compilers by a factor of 10. Similarly, GNU exception handling is 10 times faster than HP's.

    In terms of the SPEC base benchmarks EGCS attains the same level as SGI's compiler (the best in the business) with -O and -O2 options. Beyond that, SGI allows one to specify tons of options, such as cache size, which generates better code. However no one actually uses these options, so it's not much of an issue.

    As a company, other than the CygWin guys, we don't compare ourselves with the PC guys, so I can't give you a comparison. The DJGPP guys may have some info. Metaware is a non factor for us, since none of our customers complain about our performance.

• Future trends
  • What new features would you like to see in future revisions of GCC?

• • We'd like to see a good implementation bridging the gap between C/C++ and Java. There are good ideas in Java. It provides open standards that are very important to the downloadable world I believe will arise in the future: it provides a simple way to connect to the web, which essential to achieving an information aware infrastructure.

    However Sun's current behaviour is very worrying. Anything that Sun writes becomes a Java API. This is not unlike Microsoft, who redefined C APIs, even though a standard existed (POSIX), to such an extent that even "hello world" will not work (stdout and stderr are not available from winMain()). Sun is playing a similar game with Java, and we fear it will lead to incompatibilities, balkanizing Java, and letting the competition win. Although Sun snipes free versions of Java, all it is doing is replaying the Unix wars. We hope that GCC will be the free standard wedge that keeps the door open.

• What do you think of the idea that programs are JIT compiled to optimize the features being used, to maximize memory efficiency (as Intel's VTUNE does) while minimizing total footprint by leaving most of the code in a compressed bytecode format (as www.tao.co.uk is suggesting).

• • We view the problem rather differently: what do you want to use your CPU power for? Do you want to use it for JIT compilation, or for running the application? We think the latter. So the JIT should be done on the server. There is no reason why your processor could not identify itself to the server and let the server produce whatever native implementation is best for it. Profile information could also be sent to the server in this way. We will be showing in an upcoming Dr Dobbs Journal, that the performance one can achieve in native-compiled Java is comparable to that of C. Speedwise, this is a better solution than a Java chip, because Lisp Machines have already shown us that register based machines present many more opportunities for optimizations than stack machines. Powerwise it is also advantageous as compilation is rather expensive on a battery. Even in terms of code size, gzip compressed 32 bit RISC code is comparable in size to the equivalent byte-code.

• What do you think of IBM's idea of simplifying processor state-machines to increase frequency by moving more of the complexity to software?

• • Like EPIC, the proof will be in the proverbial pudding. Different RISC implementations vary greatly in power, although in principle they should provide similar levels of performance. For instance, a 200 Mhz R10000 provides a similar level of performance to a 600 Mhz Alpha.

• Do you anticipate commercial proprietary source-code will at the end of the day dominate the market-place, or do you feel that free software backed up by a service industry will take over?

• • I think the distinction will be like the difference between public and private life. While we may let all the people on the net look at our source-code we don't let them play with our money. I believe that free software will determine the standards in the world. Proprietary software will exist in niches, where customers don't care for the source code. Instead of spending time building a concensus, proprietary software allows a company to focus on producing a piece of software as quickly as possible to catch a market opportunity. For instance, we use ORACLE's database software. We don't have the source-code, and don't want it because its internal complexity is irrelevant to us: we just want to use it.

This is the first of a series of articles investigating the interplay between Open Source Software and commercial vendors. The common thread will be to find out how authors have earned a living from writing and servicing GPL/Open Source Software.

The series kicks off with Michael Tiemann, one of the founders of Cygnus Solutions, and author of the C++ component of GCC. Cygnus is one of the pioneers in commercial support for open-source software. It sells support and customization services for the gnu programming tools (gcc, gdb, ld, etc). Initially, the Free Software Foundation applauded this, but more recently, RMS feels that by also selling proprietary software Cygnus has betrayed the principle of free software.

In this interview, Michael discusses what it takes to set up a business based on open source software, what Cygnus hopes to add to GCC, and why they took the decision to sell closed source software.

What is written in red, is what Michael wrote to me in an email
What is written in green, is what I transcribed from my notes of our telephone interview. Any mistakes therein are mine.

• How difficult was it for you to set up Cygnus Solutions?
• • How did the banks cope with Cygnus' non orthodox business model?
  • How difficult was it to find the first customers?
  • What advice could you give someone who has written a GPL'd (or similar) program, and wants to live off it by providing services to commercial users?
  • Can one survive purely on the provision of services?
  • What types of services have you found to be the most important for commercial customers? What sort of guaranties do they want? What should one pay special attention to?

• • The greatest challenge in setting up Cygnus was in finding a name under which we could do business. This is not a joke...for three months we went through a process of finding a name, submitting it to the dept. of corporations, only to learn that the name had already been taken. We were about to give up hope when such an ugly name as "Software Support, Inc." had been registered the same year we tried to get it. When we learned that Cygnus Support (note the embedded GNU in Cygnus) was ours to use, we were overjoyed.

    Cygnus was started with virtually no money. At the time, I wanted John Gilmore (whose userid was gnu@sun.com) to be one of the founders (he was employee #5 at Sun, and was the guy who ported BSD Unix to the 68020), not for his money, but for hus programming skills. I put _my_ money where my mouth was, proposing that all three founders put in the same amount of money at the start. At that time, I had less than $3000 in the bank, so I proposed we each put in $2000 at the start, and raise the ante to $5000 when I could afford it. As you can see, we did _nothing_ to try to get banks interested, so there was nothing to explain to them.

    As for finding the first customers...it was just a matter of knocking enough times on the correct doors. As the author of GNU C++, it was pretty easy for me to talk to high-level technical people, who would then introduce me to mid-level managers. We sold GNU support primarily as a cost-saving measure, so we did not need VP level approval. Nowadays we have a much more strategic sell, but we're also much better established, so we can call on and get VP level approvals.

    I've always advised everybody that if they want to start a free software business, they should not let anything stop them. Of those who did, most managed to break even or make a small profit, leading me to believe that there's more to Cygnus's success than merely addressing a market opportunity. We've always been willing to make tough decisions, and we've always listened to customers, even when they were yelling at the top of their voices. Those who do free software for love, rather than money, are not going to survive what we've been through.

    As far as what customers really want...they want somebody who will listen to their needs, formulate a long-term plan, and then deliver without a lot of hassle or risk. Some customers like to see you work; others like to see the work you do; still others think you are doing a great job if they never see you. In the end, it's not the guarantees you offer that make customers come back..it's what you can deliver. The free software model is unique in that it actually gives an incentive for customers to work with you, not independently from you. In the fast-moving high tech world, that advantage has put us in the #1 spot in our market...no mean feat.

• Cygnus and the FSC (Free Software Community)
• • What exactly are you providing to the FSC?

• • We pour about $10M/year into the development of new free software. We run the servers from which 500,000 people have downloaded our stuff. We promote the concept of free software in articles, conferences, and advertising. We sponsor free software projects and pay free software contractors who do work that's related to our business requirements (though not something we'd directly commercialize). We provide a generous matching fund so that employees and customers who want to donate to the FSF can see their donation multiplied.

• How long does it take for your new code to be released in Egcs, or other freely downloadable source code?

• • The std deviation of this number makes an average number meaningless. If you download EGCS, I'll bet that the ChangeLog entries are no more than 45 days old. Compare that to other FSF-controlled packages where they can be months or years old. It is important to realize that we don't control when the FSF releases code.

• How much do you feel you are getting from the FSC? Would it have been simpler to write you own compiler?

• • Simpler, perhaps. But we would not have been able to distinguish ourselves from the other N proprietary companies. I mentioned earlier that people are now chosing Cygnus not because we are cheaper, but because we are _strategic_. We could not have achieved that strategic positioning in the compiler space in any other way.

• What overhead is there with working with the FSC?

• • It's whatever you want. Some people like to spend hours arguing about indentation styles. Others just decide they are going to do somthing and they do it. I wrote the first native-code C++ compiler in 6 month in 1987. It was hard work, and it was rough, but once I demonstrated the momentum I could sustains, dozens joined to the GCC/G++ team.

    In 1989, when GCC 1.x was getting fairly mature, I wrote an instruction scheduler, re-wrote a branch scheduler that had been abandoned, and wrote several cool new optimizations that could not easily fit with GCC 1.x. I declared that we should start GCC 2, with the goal of integrating this new work, new C++ language features, and an eye towards optimal code generation for RISC machines.

    GCC 2.x is now reaching maturity, and it's just not possible to preserve that kind of stability with the while working on advanced/experimental/cool new stuff we want to do. Hence we created EGCS. I've been amazed at the number and quality of volunteers who are now working on that branch. Thus, for GCC 2, the overhead is high, whereas for EGCS, the overhead is negative.

• What sort of friction is there between immediate customer concerns and the interests of the FSC?

• • No difference to any other scarce-resource problem.

• • The FSF's objective is a free software world. The customer's objective is a solution that satisfies his needs. The problem is that commercial work always pays more, so more people do that, which frustrates the FSF that not more people are on its bandwagon.

• Which strengths do you see in the Bazaar and Cathedral models of free software development?

• • Although Eric Raymond is very good at coming up with beautiful theories, I dispute whether they are a true reflection of reality. I see GNU and Linux as two cathedrals. Both Linux and RMS are benevolent dictators. What sets them apart is that Linus is willing to take more risks, to rewrite more of his software, while RMS is a perfectionist. Overall, I believe that risks win, and the risk of reimplementing things lead to a better result. Eric and I were both at the Foresight institute to discuss Netscape releasing their source code. Eric said that Cygnus's model was to provide service to commercial customers for free software products, while Netscape was going to lead the standards with its Free software strategy. I disagree with this since Cygnus too is leading the standards in the embedded market with free software.

• Why did you decide to sell software without source-code, given that this soured your relation with the FSF?

• • We measure success in $$, not FSF relationship. Free software works great for support, not for products.

    Cygnus has been very successful at its challenge. In 8 years we've become the number one tool supplier for the embedded market. Our growth is limited only by the number of sales and technical people we can find to employ. I expect our business will be eventually worth 100 of millions dollars per year. But this has taken lots of effort, and is only achieved by making life easy for our customers. For instance, we support 17 different host-target combinations for Cisco alone. Their routers' CPUs vary from the very simple basic RISC chip to very complex CISC chips with fancy features, yet they want the same code to work on any host-target combination. Contrast this to Sun or Microsoft where the same code will not work on SunOS 4/Solaris or Windows 95/NT. We support SGI, HP, NT (etc) so that our customers do not have to decide on their platform because of us. In total we support 170 different host-target combinations.

    The proprietary model and the free software model provide two different kinds of simplicity. The free software model provides simplicity of APIs: there is no need to waste time reverse-engineering things if you have source. The proprietary model provides simplicity of control: your software does not go off and have a life of its own, you can control your investment, your price points and focus on command performance rather than spend time on building a consensus. For instance, say we have two customers, one of whom has a bad bug he needs fixed, the other of whom has sent us an enhancement to our product. Say furthermore that we only have enough time to service one of their needs. If we fix the bug, then the customer who sent us the enhancement will be disappointed -- they did what the GPL said to do --, and they will wonder why they need support from us, since the guys on the net included their enhancement while we did not. If we add the enhancement, then one of our customers still has a bug, and if he cares nothing for having the source-code, he will look somewhere else for business. So adopting the proprietary model allows us to control our strategy. If the need for strategic control disappears then the software can become free, but this might never happen. For instance, dejagnu was not planned to be commercial software, so we put on the net to get help from the people out there.

    In my opinion, Sun has done a bad job at being a software leader, as has Microsoft. What GNU and Linux are doing is pushing the envelope back up.

• You provide compilers for the embedded market

• • Yes. The embedded market is very different from the traditional desktop market. For instance, the object files that became popular in the embedded market differ from those used in the desktop/workstation markets. Originally embedded people worked on Sun 3's and cross-compiled 68000 code into a.out executables. But a.out has limitations such as not allowing multiple data sections. New formats were devised to address this and other issues.

    Another difference is the embedded market is extremely cost-conscious. For instance, the money made on cellular telephones is made on the subscription. Thus the bill of materials for a cellular telephone must be extremely low. Similarly, end-product functionality is more of a concern that compatibility. Because RISC processors provide approximately twice the compute-power for half the electric power of a CISC processor, they are being adopted more rapidly than in the PC market. MIPS is now dethroning the previous king of the embedded world, the 68000 family, having sold 44 million units last year versus 68000's 42 million.

    Providing one same set of compilers for a wide variety of chips has made us into the standard for the embedded market. We have close ties with CPU companies, such as Toshiba, so that each new chip is released with a new version of our compiler. This makes it easy for our customers to choose which ever chip will give the best cost/performance ratio, without worrying about high porting costs.

• What features did you have to add for this market?

• • We added many features that improve code performance and code size. We provide a very lean and mean implementation of C++ to allow embedded programmers to use the C++ features they need. Indeed, we were the first to ship C++ for the embedded world, for Nortel in 1990. We've added the ability to control via #pragmas the type of return code the compiler should use, so that interrupt routines can be written in C. Another embedded feature is the ability to specify into which segment each function should go. And to help our customers migrate rapidly from chip architecture to chip architecture, we have a whole series of #pragmas to control the way in which data structures are laid out in memory. This allows them to have binary compatibility of data structures even if the code was originally written to access words at odd boundaries, but the target processor does not allow this.

• Are there any new #pragma like commands to control code size at a lower granularity (e.g.: for single functions)

• Are there any new #pragma like commands to control speed as a lower granularity (e.g.: for single functions)

• • We find generally that programmers want the same level of optimization for a particular module. However some optimizations of that kind are described in the processor specific optimization documentation: these are processor dependent trade-offs. For instance, on an R10000 (MIPS), bigger code is faster in that keeps all 4 pipes full. On the other hand, we had to deal with very high space constraints when we worked with Sega. They used the Gnu compiler for the Sega Saturn. And although the SH (Super Hitachi processor) encodes 32 bit instructions into 16 bits, we had to change the compiler significantly to cope with the fact that loading immediate values (such as 57) is very convoluted: you read the value then jump over it, making immediate value loads very expensive when the compiler assumed they would be cheap.

    Generally, we think code size will become less and less of an issue: at the rate at which chips are shrinking and processes are improving (such as the extreme Ultra Violet process), the average DRAM chip will contain 1.7 Gbits in 2001 and 237 Gbits in 2012. Bandwidth problems will be alleviated by developments such as Mitsubishi's M32R chip, which has a core on a 16 Mbit ram, and has a huge bandwidth.

• Do you have any benchmarks to compare the current GCC levels of compilation (code size, speed) with compilers from Metaware, IBM, Microsoft, Borland, Symantec, Intel's VTUNE, etc?

• • We use the Bench++ benchmark. In contrast to SPEC benchmarks, this uses Stepanov's abstraction benchmark to determine the cost of various C++ features. For instance at the 0th level of abstraction, the code uses an integer, at the 1st it uses a double, then a class with a double member, then a class with a double pointer member... including template iterators until the 12th level is reached. GNU beats Sun and HP's compilers by a factor of 10. Similarly, GNU exception handling is 10 times faster than HP's.

    In terms of the SPEC base benchmarks EGCS attains the same level as SGI's compiler (the best in the business) with -O and -O2 options. Beyond that, SGI allows one to specify tons of options, such as cache size, which generates better code. However no one actually uses these options, so it's not much of an issue.

    As a company, other than the CygWin guys, we don't compare ourselves with the PC guys, so I can't give you a comparison. The DJGPP guys may have some info. Metaware is a non factor for us, since none of our customers complain about our performance.

• Future trends
  • What new features would you like to see in future revisions of GCC?

• • We'd like to see a good implementation bridging the gap between C/C++ and Java. There are good ideas in Java. It provides open standards that are very important to the downloadable world I believe will arise in the future: it provides a simple way to connect to the web, which essential to achieving an information aware infrastructure.

    However Sun's current behaviour is very worrying. Anything that Sun writes becomes a Java API. This is not unlike Microsoft, who redefined C APIs, even though a standard existed (POSIX), to such an extent that even "hello world" will not work (stdout and stderr are not available from winMain()). Sun is playing a similar game with Java, and we fear it will lead to incompatibilities, balkanizing Java, and letting the competition win. Although Sun snipes free versions of Java, all it is doing is replaying the Unix wars. We hope that GCC will be the free standard wedge that keeps the door open.

• What do you think of the idea that programs are JIT compiled to optimize the features being used, to maximize memory efficiency (as Intel's VTUNE does) while minimizing total footprint by leaving most of the code in a compressed bytecode format (as www.tao.co.uk is suggesting).

• • We view the problem rather differently: what do you want to use your CPU power for? Do you want to use it for JIT compilation, or for running the application? We think the latter. So the JIT should be done on the server. There is no reason why your processor could not identify itself to the server and let the server produce whatever native implementation is best for it. Profile information could also be sent to the server in this way. We will be showing in an upcoming Dr Dobbs Journal, that the performance one can achieve in native-compiled Java is comparable to that of C. Speedwise, this is a better solution than a Java chip, because Lisp Machines have already shown us that register based machines present many more opportunities for optimizations than stack machines. Powerwise it is also advantageous as compilation is rather expensive on a battery. Even in terms of code size, gzip compressed 32 bit RISC code is comparable in size to the equivalent byte-code.

• What do you think of IBM's idea of simplifying processor state-machines to increase frequency by moving more of the complexity to software?

• • Like EPIC, the proof will be in the proverbial pudding. Different RISC implementations vary greatly in power, although in principle they should provide similar levels of performance. For instance, a 200 Mhz R10000 provides a similar level of performance to a 600 Mhz Alpha.

• Do you anticipate commercial proprietary source-code will at the end of the day dominate the market-place, or do you feel that free software backed up by a service industry will take over?

• • I think the distinction will be like the difference between public and private life. While we may let all the people on the net look at our source-code we don't let them play with our money. I believe that free software will determine the standards in the world. Proprietary software will exist in niches, where customers don't care for the source code. Instead of spending time building a concensus, proprietary software allows a company to focus on producing a piece of software as quickly as possible to catch a market opportunity. For instance, we use ORACLE's database software. We don't have the source-code, and don't want it because its internal complexity is irrelevant to us: we just want to use it.

This is the first of a series of articles investigating the interplay between Open Source Software and commercial vendors. The common thread will be to find out how authors have earned a living from writing and servicing GPL/Open Source Software.

The series kicks off with Michael Tiemann, one of the founders of Cygnus Solutions, and author of the C++ component of GCC. Cygnus is one of the pioneers in commercial support for open-source software. It sells support and customization services for the gnu programming tools (gcc, gdb, ld, etc). Initially, the Free Software Foundation applauded this, but more recently, RMS feels that by also selling proprietary software Cygnus has betrayed the principle of free software.

In this interview, Michael discusses what it takes to set up a business based on open source software, what Cygnus hopes to add to GCC, and why they took the decision to sell closed source software.

What is written in red, is what Michael wrote to me in an email
What is written in green, is what I transcribed from my notes of our telephone interview. Any mistakes therein are mine.

• How difficult was it for you to set up Cygnus Solutions?
• • How did the banks cope with Cygnus' non orthodox business model?
  • How difficult was it to find the first customers?
  • What advice could you give someone who has written a GPL'd (or similar) program, and wants to live off it by providing services to commercial users?
  • Can one survive purely on the provision of services?
  • What types of services have you found to be the most important for commercial customers? What sort of guaranties do they want? What should one pay special attention to?

• • The greatest challenge in setting up Cygnus was in finding a name under which we could do business. This is not a joke...for three months we went through a process of finding a name, submitting it to the dept. of corporations, only to learn that the name had already been taken. We were about to give up hope when such an ugly name as "Software Support, Inc." had been registered the same year we tried to get it. When we learned that Cygnus Support (note the embedded GNU in Cygnus) was ours to use, we were overjoyed.

    Cygnus was started with virtually no money. At the time, I wanted John Gilmore (whose userid was gnu@sun.com) to be one of the founders (he was employee #5 at Sun, and was the guy who ported BSD Unix to the 68020), not for his money, but for hus programming skills. I put _my_ money where my mouth was, proposing that all three founders put in the same amount of money at the start. At that time, I had less than $3000 in the bank, so I proposed we each put in $2000 at the start, and raise the ante to $5000 when I could afford it. As you can see, we did _nothing_ to try to get banks interested, so there was nothing to explain to them.

    As for finding the first customers...it was just a matter of knocking enough times on the correct doors. As the author of GNU C++, it was pretty easy for me to talk to high-level technical people, who would then introduce me to mid-level managers. We sold GNU support primarily as a cost-saving measure, so we did not need VP level approval. Nowadays we have a much more strategic sell, but we're also much better established, so we can call on and get VP level approvals.

    I've always advised everybody that if they want to start a free software business, they should not let anything stop them. Of those who did, most managed to break even or make a small profit, leading me to believe that there's more to Cygnus's success than merely addressing a market opportunity. We've always been willing to make tough decisions, and we've always listened to customers, even when they were yelling at the top of their voices. Those who do free software for love, rather than money, are not going to survive what we've been through.

    As far as what customers really want...they want somebody who will listen to their needs, formulate a long-term plan, and then deliver without a lot of hassle or risk. Some customers like to see you work; others like to see the work you do; still others think you are doing a great job if they never see you. In the end, it's not the guarantees you offer that make customers come back..it's what you can deliver. The free software model is unique in that it actually gives an incentive for customers to work with you, not independently from you. In the fast-moving high tech world, that advantage has put us in the #1 spot in our market...no mean feat.

• Cygnus and the FSC (Free Software Community)
• • What exactly are you providing to the FSC?

• • We pour about $10M/year into the development of new free software. We run the servers from which 500,000 people have downloaded our stuff. We promote the concept of free software in articles, conferences, and advertising. We sponsor free software projects and pay free software contractors who do work that's related to our business requirements (though not something we'd directly commercialize). We provide a generous matching fund so that employees and customers who want to donate to the FSF can see their donation multiplied.

• How long does it take for your new code to be released in Egcs, or other freely downloadable source code?

• • The std deviation of this number makes an average number meaningless. If you download EGCS, I'll bet that the ChangeLog entries are no more than 45 days old. Compare that to other FSF-controlled packages where they can be months or years old. It is important to realize that we don't control when the FSF releases code.

• How much do you feel you are getting from the FSC? Would it have been simpler to write you own compiler?

• • Simpler, perhaps. But we would not have been able to distinguish ourselves from the other N proprietary companies. I mentioned earlier that people are now chosing Cygnus not because we are cheaper, but because we are _strategic_. We could not have achieved that strategic positioning in the compiler space in any other way.

• What overhead is there with working with the FSC?

• • It's whatever you want. Some people like to spend hours arguing about indentation styles. Others just decide they are going to do somthing and they do it. I wrote the first native-code C++ compiler in 6 month in 1987. It was hard work, and it was rough, but once I demonstrated the momentum I could sustains, dozens joined to the GCC/G++ team.

    In 1989, when GCC 1.x was getting fairly mature, I wrote an instruction scheduler, re-wrote a branch scheduler that had been abandoned, and wrote several cool new optimizations that could not easily fit with GCC 1.x. I declared that we should start GCC 2, with the goal of integrating this new work, new C++ language features, and an eye towards optimal code generation for RISC machines.

    GCC 2.x is now reaching maturity, and it's just not possible to preserve that kind of stability with the while working on advanced/experimental/cool new stuff we want to do. Hence we created EGCS. I've been amazed at the number and quality of volunteers who are now working on that branch. Thus, for GCC 2, the overhead is high, whereas for EGCS, the overhead is negative.

• What sort of friction is there between immediate customer concerns and the interests of the FSC?

• • No difference to any other scarce-resource problem.

• • The FSF's objective is a free software world. The customer's objective is a solution that satisfies his needs. The problem is that commercial work always pays more, so more people do that, which frustrates the FSF that not more people are on its bandwagon.

• Which strengths do you see in the Bazaar and Cathedral models of free software development?

• • Although Eric Raymond is very good at coming up with beautiful theories, I dispute whether they are a true reflection of reality. I see GNU and Linux as two cathedrals. Both Linux and RMS are benevolent dictators. What sets them apart is that Linus is willing to take more risks, to rewrite more of his software, while RMS is a perfectionist. Overall, I believe that risks win, and the risk of reimplementing things lead to a better result. Eric and I were both at the Foresight institute to discuss Netscape releasing their source code. Eric said that Cygnus's model was to provide service to commercial customers for free software products, while Netscape was going to lead the standards with its Free software strategy. I disagree with this since Cygnus too is leading the standards in the embedded market with free software.

• Why did you decide to sell software without source-code, given that this soured your relation with the FSF?

• • We measure success in $$, not FSF relationship. Free software works great for support, not for products.

    Cygnus has been very successful at its challenge. In 8 years we've become the number one tool supplier for the embedded market. Our growth is limited only by the number of sales and technical people we can find to employ. I expect our business will be eventually worth 100 of millions dollars per year. But this has taken lots of effort, and is only achieved by making life easy for our customers. For instance, we support 17 different host-target combinations for Cisco alone. Their routers' CPUs vary from the very simple basic RISC chip to very complex CISC chips with fancy features, yet they want the same code to work on any host-target combination. Contrast this to Sun or Microsoft where the same code will not work on SunOS 4/Solaris or Windows 95/NT. We support SGI, HP, NT (etc) so that our customers do not have to decide on their platform because of us. In total we support 170 different host-target combinations.

    The proprietary model and the free software model provide two different kinds of simplicity. The free software model provides simplicity of APIs: there is no need to waste time reverse-engineering things if you have source. The proprietary model provides simplicity of control: your software does not go off and have a life of its own, you can control your investment, your price points and focus on command performance rather than spend time on building a consensus. For instance, say we have two customers, one of whom has a bad bug he needs fixed, the other of whom has sent us an enhancement to our product. Say furthermore that we only have enough time to service one of their needs. If we fix the bug, then the customer who sent us the enhancement will be disappointed -- they did what the GPL said to do --, and they will wonder why they need support from us, since the guys on the net included their enhancement while we did not. If we add the enhancement, then one of our customers still has a bug, and if he cares nothing for having the source-code, he will look somewhere else for business. So adopting the proprietary model allows us to control our strategy. If the need for strategic control disappears then the software can become free, but this might never happen. For instance, dejagnu was not planned to be commercial software, so we put on the net to get help from the people out there.

    In my opinion, Sun has done a bad job at being a software leader, as has Microsoft. What GNU and Linux are doing is pushing the envelope back up.

• You provide compilers for the embedded market

• • Yes. The embedded market is very different from the traditional desktop market. For instance, the object files that became popular in the embedded market differ from those used in the desktop/workstation markets. Originally embedded people worked on Sun 3's and cross-compiled 68000 code into a.out executables. But a.out has limitations such as not allowing multiple data sections. New formats were devised to address this and other issues.

    Another difference is the embedded market is extremely cost-conscious. For instance, the money made on cellular telephones is made on the subscription. Thus the bill of materials for a cellular telephone must be extremely low. Similarly, end-product functionality is more of a concern that compatibility. Because RISC processors provide approximately twice the compute-power for half the electric power of a CISC processor, they are being adopted more rapidly than in the PC market. MIPS is now dethroning the previous king of the embedded world, the 68000 family, having sold 44 million units last year versus 68000's 42 million.

    Providing one same set of compilers for a wide variety of chips has made us into the standard for the embedded market. We have close ties with CPU companies, such as Toshiba, so that each new chip is released with a new version of our compiler. This makes it easy for our customers to choose which ever chip will give the best cost/performance ratio, without worrying about high porting costs.

• What features did you have to add for this market?

• • We added many features that improve code performance and code size. We provide a very lean and mean implementation of C++ to allow embedded programmers to use the C++ features they need. Indeed, we were the first to ship C++ for the embedded world, for Nortel in 1990. We've added the ability to control via #pragmas the type of return code the compiler should use, so that interrupt routines can be written in C. Another embedded feature is the ability to specify into which segment each function should go. And to help our customers migrate rapidly from chip architecture to chip architecture, we have a whole series of #pragmas to control the way in which data structures are laid out in memory. This allows them to have binary compatibility of data structures even if the code was originally written to access words at odd boundaries, but the target processor does not allow this.

• Are there any new #pragma like commands to control code size at a lower granularity (e.g.: for single functions)

• Are there any new #pragma like commands to control speed as a lower granularity (e.g.: for single functions)

• • We find generally that programmers want the same level of optimization for a particular module. However some optimizations of that kind are described in the processor specific optimization documentation: these are processor dependent trade-offs. For instance, on an R10000 (MIPS), bigger code is faster in that keeps all 4 pipes full. On the other hand, we had to deal with very high space constraints when we worked with Sega. They used the Gnu compiler for the Sega Saturn. And although the SH (Super Hitachi processor) encodes 32 bit instructions into 16 bits, we had to change the compiler significantly to cope with the fact that loading immediate values (such as 57) is very convoluted: you read the value then jump over it, making immediate value loads very expensive when the compiler assumed they would be cheap.

    Generally, we think code size will become less and less of an issue: at the rate at which chips are shrinking and processes are improving (such as the extreme Ultra Violet process), the average DRAM chip will contain 1.7 Gbits in 2001 and 237 Gbits in 2012. Bandwidth problems will be alleviated by developments such as Mitsubishi's M32R chip, which has a core on a 16 Mbit ram, and has a huge bandwidth.

• Do you have any benchmarks to compare the current GCC levels of compilation (code size, speed) with compilers from Metaware, IBM, Microsoft, Borland, Symantec, Intel's VTUNE, etc?

• • We use the Bench++ benchmark. In contrast to SPEC benchmarks, this uses Stepanov's abstraction benchmark to determine the cost of various C++ features. For instance at the 0th level of abstraction, the code uses an integer, at the 1st it uses a double, then a class with a double member, then a class with a double pointer member... including template iterators until the 12th level is reached. GNU beats Sun and HP's compilers by a factor of 10. Similarly, GNU exception handling is 10 times faster than HP's.

    In terms of the SPEC base benchmarks EGCS attains the same level as SGI's compiler (the best in the business) with -O and -O2 options. Beyond that, SGI allows one to specify tons of options, such as cache size, which generates better code. However no one actually uses these options, so it's not much of an issue.

    As a company, other than the CygWin guys, we don't compare ourselves with the PC guys, so I can't give you a comparison. The DJGPP guys may have some info. Metaware is a non factor for us, since none of our customers complain about our performance.

• Future trends
  • What new features would you like to see in future revisions of GCC?

• • We'd like to see a good implementation bridging the gap between C/C++ and Java. There are good ideas in Java. It provides open standards that are very important to the downloadable world I believe will arise in the future: it provides a simple way to connect to the web, which essential to achieving an information aware infrastructure.

    However Sun's current behaviour is very worrying. Anything that Sun writes becomes a Java API. This is not unlike Microsoft, who redefined C APIs, even though a standard existed (POSIX), to such an extent that even "hello world" will not work (stdout and stderr are not available from winMain()). Sun is playing a similar game with Java, and we fear it will lead to incompatibilities, balkanizing Java, and letting the competition win. Although Sun snipes free versions of Java, all it is doing is replaying the Unix wars. We hope that GCC will be the free standard wedge that keeps the door open.

• What do you think of the idea that programs are JIT compiled to optimize the features being used, to maximize memory efficiency (as Intel's VTUNE does) while minimizing total footprint by leaving most of the code in a compressed bytecode format (as www.tao.co.uk is suggesting).

• • We view the problem rather differently: what do you want to use your CPU power for? Do you want to use it for JIT compilation, or for running the application? We think the latter. So the JIT should be done on the server. There is no reason why your processor could not identify itself to the server and let the server produce whatever native implementation is best for it. Profile information could also be sent to the server in this way. We will be showing in an upcoming Dr Dobbs Journal, that the performance one can achieve in native-compiled Java is comparable to that of C. Speedwise, this is a better solution than a Java chip, because Lisp Machines have already shown us that register based machines present many more opportunities for optimizations than stack machines. Powerwise it is also advantageous as compilation is rather expensive on a battery. Even in terms of code size, gzip compressed 32 bit RISC code is comparable in size to the equivalent byte-code.

• What do you think of IBM's idea of simplifying processor state-machines to increase frequency by moving more of the complexity to software?

• • Like EPIC, the proof will be in the proverbial pudding. Different RISC implementations vary greatly in power, although in principle they should provide similar levels of performance. For instance, a 200 Mhz R10000 provides a similar level of performance to a 600 Mhz Alpha.

• Do you anticipate commercial proprietary source-code will at the end of the day dominate the market-place, or do you feel that free software backed up by a service industry will take over?

• • I think the distinction will be like the difference between public and private life. While we may let all the people on the net look at our source-code we don't let them play with our money. I believe that free software will determine the standards in the world. Proprietary software will exist in niches, where customers don't care for the source code. Instead of spending time building a concensus, proprietary software allows a company to focus on producing a piece of software as quickly as possible to catch a market opportunity. For instance, we use ORACLE's database software. We don't have the source-code, and don't want it because its internal complexity is irrelevant to us: we just want to use it.

Despite initial expectations that set-top boxes and PCs would converge, the trend towards RISC chips such as MIPS continues. An oft cited reason for this is the lower power requirements of RISC solutions, which might give low power x86 manufacturers such as Centaur, Transmeta (?), and Cyrix for their MediaGX chips an advantage. Perhaps however, it is not x86 that is being fled, but domination by Microsoft that is being avoided. After all, set-top boxes are a cost, not a revenue to content-selling cable operators: do they really want to upgrade their infrastructure each time Microsoft comes up with a new version of Windows? A winner in this market will be Cygnus solutions, sellers of GnuPro tools to the embedded market, and thus Free Software Standards.

Gnu-Win32 has released b19. Some people may be wondering why I'm posting software for windows here, but if this thing is stable and usable, then we can all develop under unix, and compile of windows versions for our less enlightened friends at the other end of the computing spectrum.