; ) Be Dope archive *  icon tarot *  qJLG * haiku
interviews *  bookstore *  newsletter

visit mikepop.net for more info about Mike Popovic


"The barriers between your ideas and their implementation are so thin"

Pavel Císler is the creator of one of the mostly widely used BeOS applications - Tracker. He's also the heart and soul of the OpenTracker.org movement and the creator of the program that in turn helps create other parts of BeOS and many BeOS apps - Eddie.



Pavel on the Magic Cap OS
In your opinion why did the Magic Cap OS and devices never catch on?

I think the main reason is because the Magic Cap devices that ended up shipping, while cool, were missing a lot of the features that make devices such as the Palm Pilot successful -- they were way too inconvenient to use for a simple PDA -- they didn't fit in a pocket, the batteries didn't last too long and they were way over-priced. Of course all that is easy to judge now, five years later.

What was the coolest thing about the Magic Cap OS?

There were a lot of cool things -- programming Magic Cap for one was really neat. From a user's perspective I'd say Magic Cap had a ton of small usability features that made it easy to use that still didn't make it into products like WinCE and Palm Pilot. Magic spent a lot of energy on doing user tests and trying to design the right set of functionality for limited hardware with a small and hard to read LCD screen.

Do you see a similarity between what the Magic Cap devices were trying to be and some flavors of today's "Internet Appliances" ? Do you think that General Magic basically got it right, but the timing was all wrong?

Had Magic delivered on it's initial plan of having a device the size of a wallet, and in the right price range, they might have been where Pilot is now or even more successful. Also, Magic failed to realize the importance of internet at the right time -- they came out with a web-enabled device eventually but it only shipped in vertical markets. Had they shipped a web-enabled device a couple years ago and if they still had at least some of their original visibility at that time, things might have been different. Also, if they started with the same approach and the same team of people right now, when the hardware is more advanced, the internet is booming and Internet Appliances are hot, they would probably be a very serious player. So in a way yes, they probably were a bit ahead of the time.

Be Dope: Describe the major projects have you worked on since joining Be.

Pavel: My main focus for almost my entire time at Be was Tracker. Besides that I wrote FileTypes, parts of the Installer, helped Jeff with the MediaPlayer, did a bunch of kit work.

How did you first hear of Be, and who or what made you decide to work there?

I first heard of Be from a colleague at General Magic, I then saw the MacTech magazine article. I was drawn to Be mainly because I loved how easy it is to code for the system. I also liked BeOS itself, the modern design, responsiveness, the way it took the best from existing operating systems and put it together in a consistent package. After General Magic I was looking to work more on operating systems so Be was a pretty straightforward step for me.

What is your computer background?

I started out as a hardware engineer but I transitioned from computer hardware to software early on in my career. Obviously, software lets you see the results of your efforts faster. I've done my share of hacking on Z80, 6502 machines, I've had an Atari ST, after that a bunch of Macs, did a lot of Mac programming. I came to the United States almost six years ago, first worked at General Magic on the Magic Cap operating system, then at Be.

What are the OpenTracker and OpenDeskbar projects all about?

Tracker and Deskbar constitute most of what is considered the desktop of BeOS. With OpenTracker and OpenDeskbar Be is open-sourcing the code for these two applications. Third party developers, hobbyists, etc. will have a chance to add their features, help fix bugs that annoy them, or just mess around with the code.

Why did Be decide to make these components of BeOS open source, and what was your role in the decision-making process?

After Be decided to re-focus all of it's energy on the Internet Appliance, I felt that a lot of BeOS users (including myself) will not be happy with the fact that the desktop version of BeOS is not going to evolve at the pace we were used to in the past. I had pretty ambitious plans for the next version of Tracker and felt disappointed that I will not be able to make them come true, at least not in the form and timeframe I originally anticipated. It occurred to me that by open-sourcing Tracker and Deskbar Be could draw from the enormous talent of its developer community and that we could see the desktop version of the operating system evolve after all. I went and suggested this to our COO, Steve Sakoman and was lucky because he and JLG had already been thinking about open-sourcing parts of BeOS so my idea fit right in.

Why did you choose the OpenTracker License for OpenTracker and OpenDeskbar?

We chose the OpenTracker license, which is pretty much a FreeBSD-style license with only a few minor restrictions. The idea was to be as open as possible with this effort, we decided not to use a license that would give Be some form of unique privilege and control over the source code the way for instance the Mozilla and Apple Darwin licenses do. When developers look for existing code on the web to help them not have to reinvent the wheel, in my experience none of them will turn away from BSD-licensed code. The license is simple, flexible, has very few strings attached. BSD-licensed code can be easily incorporated in other projects that are covered by a more restrictive license. BSD-licensed code can also be included in closed-source project without the risk of having a wolf-pack of blood-thirsty open source bigots breathing down your neck and yelling at you to release the code or else... (I'm talking about folks who spend most of their day posting to various mailing lists rather than actual developers here :-).

What kind of work went into preparing the source of Tracker and Deskbar to be open?

A lot of energy went into cleaning up the code for public consumption. After all you are showing off your work to the public, developers will be reading/hacking your code and god forbid maybe even learning new programming tricks from it. I did a lot of cleanup of the Tracker code, some in the Deskbar code.

Also, both Deskbar and Tracker depend on some private system APIs. These APIs are private not so much because Be wants to hide them from third party developers but more because they may not be ready for public consumption. With some of them changes are anticipated in the future and we may not want to lock into keeping it compatible. Obviously, these private APIs either had to be replaced by public ones or made available in the source in some form. I didn't have the luxury of doing preparation work in the BeOS kits in anticipation of open-sourcing the Tracker and Deskbar -- the decision came after the BeOS 5 was feature frozen. Therefore in the cases where a workaround using public API wasn't available, I had to expose some of the private API in the open-sourced code but do it in a way that would make it easy to replace the API in the future. Developers will have to be careful when using some of the code from Tracker and Deskbar in their own apps -- calls that do not originate in the Be header files may break in the future. In other words, the only API that is guaranteed to stay compatible is that found in the header files shipped with each version of BeOS.

If you got to choose another component of BeOS to open source in this manner, what would it be?

Tracker and Deskbar could be the first two in a series. I can see Be open-sourcing for instance FileTypes or some preference panels. (Note that this is pure speculation, definitely not a promise).

Some components are hard to open-source -- for instance NetPositive contains a lot of licensed code for which Be pays per-copy royalties. To open-source NetPositive, we would have to remove significant portions of the code.

What does the future hold for "Eddie"?

The ToDo list of Eddie is very long, I'll probably still be working on it when I retire. I get a ton of feedback from all the Eddie users out there and I have to say all of it has helped make Eddie a great tool. I'm also thinking about porting it to a different platform - I'm told that porting BeOS applications to other OSes is pretty straightforward.

What is your favorite computer game?

That would probably be gcc. I don't play computer games too much. I do like Starcraft and SimCity though.

If the BeOS was an animal, what kind would it be?

George Hoffman, he is just amazing.

Who is your favorite muppet, if any, and why?

I don't know, I guess the Trash Monster? [Oscar the Grouch -ed.] Didn't have them back in my Iron Curtain homeland.

Finish this sentence: "Programming for BeOS kicks ass because ______"

... the barriers between your ideas and their implementation are so thin.

- published March 28, 2000

More Interviews:

Mike Clifton
creator of Moho

Scott Barta
NetPositive author

Joe Palmer
the father of the BeBox

Seth Flaxman
CEO of ABiSoft

Scot Hacker
BeOS Bible author

Michael Alderete
Be's Webmaster

Melanie Walker
Be Web Diva

Dominic Giampaolo
Be engineer and creator of the BFS

Douglas Irving Repetto
creator of geektoys


Home | qJLG | Icon Tarot | Story Archive | Interviews | Bookstore | Newsletter | About | Advertise | Contact