Volume Number: 24 (2008)
Issue Number: 03
Column Tag: The Industry

Geoff Perlman on REALbasic

Catching up with Geoff and REALbasic 2008

by Norman Palardy

At MacWorld 2008 REAL Software announced the first release of REALbasic for 2008. MacTech Executive Editor, Edward Marczak and columnist Norman Palardy had an opportunity to ask REAL Software CEO Geoff Perlman about the announcement, REALbasic, and REAL Software.

Norman Palardy: The press release went out: It was announced on the various boards, MacNN and MacWorld, it's on your website, it's been published in your forums and sent to your mailing list. But, it's a press release so it only says so much. Can you tell us what's new in REALbasic 2008 R1?

Geoff Perlman: The big thing is introspection. It is the most heavily requested feature of all time. That is what's appearing in this release. There is always a lot of maintenance. There are a few minor features but introspection is the big thing.

NP: For somebody who might not be familiar, what is the current pricing of REALbasic and how do you handle updates?

GP: The standard edition is $100 and the professional edition is $500. The difference is that the professional edition, among other things, adds access to database servers and cross platform compilation. Actually, I should back up because we just made a change with this release. We are no longer calling it the standard edition. It is now called the Personal edition, and this is to help distinguish between editions. People ask us "why don't I use one or the other"? If you are writing software for yourself, then chances are the personal edition is appropriate. If you are writing software for other people, the professional edition is probably what you need.

Obviously there are times when you might be writing software for other people and the Personal edition would work. But most of the time we find that when people are writing software for somebody else they need some feature that is in the Professional Edition.

NP: That is an interesting name change. I wasn't aware of that, but it should help give people better clarity, as you said, as to what the intended audience is.

NP: Some time ago you guys switched from the traditional dot-1 dot-2 dot-3 kind of release naming to a different schedule and a different naming scheme. How frequent are updates nowadays?

GP: We release every 90 days. Occasionally it is less than 90 days. We made that change for a number of reasons. First of all, our customers are developers. Even if they are one hour a week developers, versus 40 hour week, they are developers and we need to be able to respond more quickly to what they want. We felt having a year, or a year and half or two year development cycle doesn't make sense. We can't respond to the market quickly enough that way. The other thing is that the smaller you make a project in scope or in time, the more likely you are to succeed. So, for us internally, by breaking our delivery schedule down into ninety day segments, we are much more successful at meeting our deadlines and getting things done on time than we were before. So it worked out really well.

NP: At one of the REAL World conferences you had mentioned that REALbasic has surpassed 100,000 users. That was over a year ago. What is the user base up to now? You have to be well beyond that.

GP: At this point we have over 125,000 users.

GP: I will tell you that we track the percentage of new customers we get each month versus renewals from existing customers. And the percentage of new customers has been climbing almost every month, which is really great.

NP: And are they renewals? Obviously those numbers tell you about broader appeal, lots more people trying it out and what not. But the update numbers must tell you something too.

GP: Yeah they do. I think it works better on the new model. With the old model, people would look at each individual release rather than thinking 'I just want to make sure I'm up to date'. The new model actually allows us to do a lot more maintenance on the existing code. It's a change of philosophy. Rather than feeling like they are buying this particular update or this particular new version, they are buying the next six months or the next twelve months of updates or versions. As a result of that change in their thinking about what they are buying we can get away with pouring more time into maintenance. Before there had to be lots of new features in each release because if there wasn't, there wouldn't be a reason for people to upgrade.

I am a big believer that the road to happiness is managing people's expectations. If you want people to be happy, manage their expectations. Get their expectations to an appropriate level and, of course, you have to meet those expectations. And I think that's where you can get into trouble by having a big discrepancy between what people are expecting and what you are delivering. So one of the things we keep trying to do is bring those two things together.

NP: And you feel the new release model is helping you do that better?

GP: Oh absolutely. I would never go back. It works so much better. Look at it this way: Suppose you knew we were working on a feature and we got close to the release date and decided it's just not ready so we are not going to put that in this version. We ship it and you know that the next version is a year a year and a half away. And you were waiting for that feature. With our rapid release model, worst case it's 90 days away. That's not very far. So really it allows us to produce a better, higher quality product than when we were using the traditional model.

NP: I think there are a lot of things that have really come along nicely with the new model and, like anything else, there have probably been growing pains to get to that point.

Ed Marczak: Imagine if Microsoft did this with Office. You just pay this one fee and then there were continual releases. I think that would be a much more successful model for them.

GP: Well, in fact, Microsoft has announced they are moving away from the monolithic release. They are actually moving to this model.

EM Oh really? Wow!

GP: Probably not every 90 days, though.

NP: Let's be realistic, software is never perfect. It is never bug free so it is constantly evolving and gaining new features and gaining new fixes. This model fits better with that reality.

GP: Everyone would love to have code that is bug free but they don't want a static product either. Static, bug free code is extraordinarily expensive. For example NASA claims that the code that runs the space shuttle is bug free. But they also say that it costs $25,000 per line of code.

NP: That's a lot of money to be spending on one line of code.

GP: Right.

NP: Over the course of the past year the company has had some changes. You have had personnel changes, and now a product name change. How are those things impacting your ability to deliver as a company? Or are they having an impact. I mean loosing developers has got to have in impact.

GP: We have only lost one developer in the last year and he actually still continues to do work for us on contract. Honestly, like the product, our development team evolves. And that's not a bad thing because what we need in our development team changes and developers don't always keep up with changes in technology. [Take] for example when we added support for Mach-O, which is the one of the two executable formats, and really the only one now that Apple supports. We started supporting that years before that change was made and there was a lot of debate in the engineering team because they really preferred the old PEF format and they believed it was better.

I said 'guys,it doesn't matter if it's clear or not' because Apple is saying that Mach-O is the blessed format so it's a pointless debate whether Mach-O or PEF are the better format. Now we don't support PEF because with Mac on Intel, Mach-O is the only format. Sometimes people's attitudes about technology don't change with the tide and if that is the case, if they leave and we bring in new developers that have a different take on things, we're going to make sure that the people coming in are looking at development the way that we do. Honestly, I think one of our strengths with REALbasic has been that we have been successfully able to keep up with technology. If you bought version 1 of REALbasic it ran only on a Mac and it was PowerPC and 68K. Now it runs on Mac OS X on Intel. It runs on Linux and Windows up to Vista. You can build console apps. We have abstracted our customers from lots and lots of those platform details.

NP: And it was only recently that you quit supporting OS 9. Realistically you have to at some point. You supported it long after Apple said 'OS9 is dead'

GP: The other thing is that it's important to recognize that if you try to develop an application for 100% of your target market you won't make anybody happy. The application will be too feature rich. There will be too many options and it will be too complex. So our attitude, and I think this is Apple's attitude as well, is make 80% of your potential customers happy you will have a much better product than going for 100%.

NP: Do you find when you are building a cross platform tool like you are that you have to make platform specific compromises in any way?

GP: No, we try to make it so that when we look at any piece of technology we say, "how do we make this cross platform?" Generally speaking we don't have to make those compromises if it's supported on more than one platform. Going back to the 80/20 rule, 80% of the functionality that 80% of your customers want is probably going to be supported on all three platforms. So we just have to make sure that we provide an API that makes sense across all three. But we're not afraid to add something that is platform specific either and let the developer make the decision as to whether to use that or not. AppleScript on the Mac or the Registry on Windows are other examples. Generally speaking we don't have to make those kind of compromises because it's either cross platform or it's platform specific. If it's cross platform we can usually come up with a good API and if it's platform specific then it's not a problem.

NP: I was just wondering about the trade-offs. When you look at some of the other tool kits they always seem to trade something off. Or they don't use native controls. I was just wondering if you encountered that in developing REALbasic as a cross platform framework

GP: I think that if you recognize that you should design for 80% of your potential customers then you give up very little, if anything. I think it is when you try to make everybody happy and pitch your solution as the be all end all solution, the Holy Grail solution, that's when you run into trouble.

NP: Over the years that we've known each other and dealt with each other, I might have asked you 'who do you see as your primary customer, is it a Mac user, is it a Windows user is it a Linux user' and you've always said 'That's not necessarily the way we perceive ourselves. We're a cross platform company so they are all our users". Right?

GP: Our user base is pretty broad but it's basically people that want to build cross platform applications and they want to do it quickly. They don't want a big learning curve. They want to be abstracted from all the platform details and I think we do cross platform better than anybody in the world. Frankly, I'm not afraid to say that. I ask people, "think of a cross platform tool set that does a better job than we do". I don't think there is one out there.

NP: There aren't a lot of them to start with. Which ones have a rapid application development environment like REALbasic? The list gets pretty short really really quickly and that is one of the attractions of REALbasic. I'm curious about the product name change. Do you see that as targeting a particular kind of developer? I think people who develop software for a living have this notion of "professional developers" versus "hobbyists".

GP: I think what it is, is that "standard" as a name was a mistake from the very beginning. If someone says 'This is a standard version of anything' that implies this is the version you should buy. It's the standard. And that's really never what we meant and we really should have taken a different approach in the first place. Over the years what we've found is our users tend to be people writing software for themselves or people writing software for somebody else. We recognize the people that are writing for themselves buy standard and the people writing for others buy pro. The people writing software for other people are generally being paid to write software therefore they are professionals. So the professional version makes sense.

The problem is that, honestly, it is a marketing thing. It's like some corporate IT guy has to explain why he needs the $500 version when there is $100 version available. "Standard" sounds like that is what you need; it's the standard version. If it's personal versus professional he can go to his boss and say this one is clearly for individuals, and that the publisher (us) is telling you to buy the professional if you are building for other people. The IT guy builds for other people therefore he needs the professional edition. That's a very easy way for people to pick the right product for them.

But honestly if the question is 'do hobbyists programmers exist I can tell you they definitely do.

NP: I have no doubt they do but I think a lot of people who use that moniker use it in a derogatory sense and that's an unfortunate thing because there are certainly a lot of people who program as a hobby and that doesn't make them ineffective or unskilled.

GP: No, no. What I have found is that hobbyists are people who describe themselves by saying "I don't do this professionally. No one is paying me to do it. I just do it on my own". Believe it or not, we get a lot of psychologists that buy REALbasic and they're developing the software pretty much for themselves although it is going to be used by other people. I guess that is developing for other people, but they will build software to do psychological testing and often times that's going to be on one platform. It doesn't need to be cross platform, so they're sort of the exception, where they are building software for other people but really they only need one platform, they don't need SSL or database access or that kind of stuff.

NP: REALbasic has been around for...

GP: Ten years this July 4th.

NP: Over the course of ten years, one of the things that hasn't really sort of sprouted up of its own accord is a big third party market. I'm not sure how it came about with a thing like Visual Basic. Do you see that as being important to the overall success of REALbasic as well having a big vibrant successful third party market?

GP: Well, I will say this, the thing I think is important to the success of REALbasic is that customers need to be able to get all their needs met. So it's not a question of a third party market or not. Having all their needs met is what makes the product successful. Or is at least one of the elements that makes the product successful. I think in the past we have taken on way too much and tried to put everything and the kitchen sink into the product and that has limited the opportunities for third party developers. But if you've been watching the release notes for the last couple of releases you've been seeing the word deprecated showing up, and what you are going to see in the future is that we're going to start trimming down the product a little bit. The features that only a small group of users need are going to become more third party opportunities so we can focus on the core product and make it even better. And, honestly, I think that is a mistake we made in the beginning was not recognizing that we really should stick to the core product and try to develop the third party market. Now, there is a fine line there.

When I worked at 4D long ago there was a big third party product called AreaList. It was a grid control and they never built a good grid control into 4D. They were afraid they would upset the makers of AreaList because anyone who was doing any serious development with 4D used AreaList. They were basically going to screw the developer of AreaList if they built something in that did the same thing. I think that was a mistake because a lot of customers looked at 4D and didn't know much about third party market. So what happened was people said "Well it's kinda weak when it comes to grid control". So you have to pick your battles. With things that are really important, it's the 80/20 rule again. If it's important to 80% of your customers, it probably means it needs to be built into the product. If it's less than 20%, probably that is a good third party opportunity. And we're going to really try in the coming years build up the third party market and partner with third party developers so that we can get them the exposure that they need to our customer base to help them be successful. That's a win win situation.

NP: Actually you just led right into my next question which is exactly that: If it's important, is there something you see REAL needing to do to help bring that to fruition ?

GP: Well, you've already seen that we are selling books on our website, Soon we will be selling RB Developer Magazine. We're probably at some point going to have a third party section of the website. When people are evaluating REALbasic we want to make sure that they know there is this set of third party tools out there.

EM To know there's a vibrant community.

GP: Exactly: knowing that the community is there, knowing the third party community is there helps us and it also helps those communities to grow and to continue to be vibrant. So it's totally a win win situation. I can't tell you when that is going to happen but it is definitely something that's very important to us going forward.

NP: Thanks for taking the time and letting us do this.

GP: No problem. Thank you.

Norman Palardy has worked with SQL databases since 1992, and has programmed in C, C++, Java, REALbasic and other languages on a wide variety of platforms. In his 15+ years of IT experience, Norman has developed innovative and award-winning applications for TransCanada Pipelines, Minerva Technologies (now XWave), Zymeta Corporation, and the dining and entertainment industry. He holds a BSc from the University of Calgary in Alberta.