REAL Software, the opposite of love is not hate, it is indifference.

I am worried about REALbasic, or now, REAL Studio. I have been a fan since it was a Mac-only product, running on OS 9, maybe even OS 8. I have been a writer for REALbasic Developer Magazine, spoken at multiple REAL World conferences, was an adviser to the Association of REALbasic Professionals, and am now a board member of that organization. I have loved this product and have been sad and mad at both REAL Software and the community.  The stages of grief:

  • Denial: This can’t really be the state of the community.
  • Anger: Why are they going in that direction?
  • Bargaining: I have had debates with Geoff.
  • Depression: Saddened that I may have to move on from my favorite programming language.
  • Acceptance: This will be bad for REAL Software, as more people get to this stage. I am just about there.

In the past, I have written posts about the state of REALbasic and its community. The longer I observe the community, the more sad & angry I get. I have been using REALbasic since v2. In that time, I have seen REALbasic flourish and now stagnate. It has stagnated for years and is now settling for mediocrity instead of excellence. So, if anyone from REAL Software is reading this article, it is for your own edification. It is not to solely bash the product REALbasic.

I’ll get straight to the point of the problem:  REAL Software favors the hobbyist and allows the professional high-demand customers to flop around on the ground like fish gasping for breath out of water.  The problem with this thought pattern is when these “fish” die, it will be nearly impossible to bring them back.  The side affect of these dying fish is two-fold for those of us professionals still gasping.  The REALbasic ecosystem is unhealthy, and instead of a giving community, it is a black hole of novice questions that could easily be answered by opening the language reference in the REALbasic product itself. 3rd party vendors are ridiculed for trying to make a living by actually charging money for their work. It is no use trying to rationalize with the people in the community — the people there now want everything for free, and don’t want to put in an effort.  This is the class of people that REALbasic is attracting.  Perhaps you are reading this and are having trouble getting a grasp of what I’m saying.  For you, here is a real world example.  Go to your nearest Target store. Look around, study the people… how do they dress & how do they act?  Got it?  Good. Now, go to the nearest Walmart and see the difference.  REAL Software is attracting far too many Walmart class people to REALbasic.

Yes, previously I blamed the community.  But after further thought, it is the company behind the community.  If REAL Software wanted to change the community they could. They have the power to change it, and heal the flailing REALbasic ecosystem.  Here is how they could do it:

  1. A 3-tier product is too complex.  It wreaks of Microsoft’s 7 OS SKUs. Offer the language and sell cross-platform development as an add-on.  Up-sell the the database server if you really must keep it.
  2. Consider dropping the database server. The licensing options are not attractive and there are too many open source alternatives.
  3. Allow developers to pre-compile code (libraries) that can be sold as REALbasic add-ons. This is a much better alternative to the half-baked “encryption” we now have, which has been broken in the past (2006!), and the broken option is the default!  A few years ago I mentioned the latter and watched as a developer made the “new” encryption option selected by default, and check in the change, but mysteriously it was removed by the next release of REALbasic.
  4. Allow an API for the IDE so that 3rd party software can extend it.   Allow tools to analyze the code, insert code snippets, drive the IDE, and extend it.  One of the best tools that I used in VB was from a third party.
  5. Work on reducing the size of the executable created.  When I release a shareware product, I am embarrassed by the size the binary.
  6. Speed up the launch of the IDE.  I have reduced my plugins to the bare minimum that I can. In the time it takes for REALbasic to start up, I can launch Xcode a number of times.
  7. Pre-compile plugins in the background as the developer is coding. When I want to make a build, I don’t want to wait for that.
  8. Plugins should be able to be added dynamically without needing to re-launch REALbasic.  (See 6 & 7 above.)
  9. Give the fanatics the ability to make REALbasic the best IDE & language possible.

And now the do not’s:

  1. We should not have had to wait for Apple’s removal of Carbon APIs before Cocoa APIs were taken seriously. Get it done!
  2. Stop canceling the REAL World developer conferences!  No, we don’t want mini-regional PR conferences. We want one big conference where we can gather with like minds.
  3. Customers do not want to hear about “small company” & “limited resources”; we want solutions. If REAL Software can not provide them, it would be nice to be able to point them to a 3rd party that had the ability because the IDE was able to be extended.
  4. You are not Apple! Stop trying to be everything to everybody.  Concentrate on the core of REALbasic & do it well. Let others build, say, a report writer.

If you are still reading this, you probably see a theme. The IDE needs to be opened up so that REAL Software can work on the language & IDE. Power users need more tools. Until then, I fear for the future of REALbasic as more of the fish die when the Acceptance stage is reached.  For years I thought that Xcode and Interface Builder were too complicated. That may have been the case at one time.  But it isn’t anymore and REAL Software should be concerned about their Mac-only customers.  After spending the past few months in Xcode, it is not nearly as bad nor as complicated as I had thought. It looks better and better every day.

This has been a loving warning letter to REAL Software…  from a long time customer, supporter, and evangelist who has been pushed out of his comfort zone due to your corporate decisions.  For your sake, I hope you take to heart what has been written.  If changes aren’t made soon, it will stop hurting me when I launch REALbasic, because I won’t be launching it anymore.

6 thoughts on “REAL Software, the opposite of love is not hate, it is indifference.

  1. Jay

    I definitely agree with your point “Allow an API for the IDE so that 3rd party software can extend it.”

    If you have not done so already please post this to the mailing list and the forums. I would like to see this discussion be at the forefront. Maybe we can organize feature requests in the Feedback application and push these things to the top.

  2. Anthony G. Cyphers

    I don’t think that there’s a single line in this letter that I don’t agree with. I’d happily sign my name to the bottom, as well.

    A couple of weeks ago, I experienced the third-party backlash you mentioned, on the forums.

    I really hope RS takes a good long look at the community and what the product has become, and starts doing the things it should be doing to target enterprise-level customers. You’ll make more money from those guys than the hobbyists.

  3. Geoff Perlman

    Some of the things you mentioned are things we would like to or are planning to do. We don’t want to promise and not deliver. So we have learned not to talk about something new until we are sure it’s going to happen. Some of the things you mentioned above are actually really difficult to do even if they don’t appear to be on the surface. We do listen carefully to our customers via our Feedback system and the surveys we do twice per year. We can’t always do what everyone wants of course but we try to do the things that seem to have the greatest impact based on the cost of doing them. That’s because doing one thing means you are not doing another of course.

    Regarding pricing of third party plug-ins, they will sell at what the market will bear. Some will be fine with the price, some will not. That’s the nature of selling just about anything. We don’t focus on the hobbyist but we don’t turn them away either because some hobbyists eventually become full time developers. We certainly don’t want to create a barrier to entry.

    So don’t worry Christian. Be happy. 🙂

  4. Scott Steinman

    I am in agreement with Christian’s list, especially the lack of IDE plugins. I am now using Visual Studio for the first time and finding it about as quick to develop applications. Why? When Visual Studio does not have a tool or feature I need, I can just purchase it as a third-party IDE plugin. These tools do a lot of the work for me.

    The lack of this feature in the Real Studio IDE severely limits Real Studio as a professional tool. IDEA, a Java IDE from a _small_ company (also with limited resources), has hundreds of plugins that improve the product immensely and helped create a healthy third-party tool ecosystem.

    A few years ago, I worked feverishly (as a labor of love) on a program called Reality Check that would bring to REALbasic what other IDEs had as an add-on: checking for errors in program _design_ and automatically fixing them. Due to the lack of IDE plug-ins or access to compiler symbol information, I had to import and export RB projects (instead of working within the IDE), start writing an entire compiler front end to get symbol information, and write a program to parse the RB documentation to build the beginnings of a symbol table. My other IDEs gave programmers access to this information in a controlled manner through a plugin API that kept almost all plugins from having deleterious interactions with the IDE when bugs existed.

    By making the IDE a closed system, Real Software prevented yet another third-party tool from being developed (anybody remember the SlayFire Reality profiler?). The third-party tool market for RB is nearly non-existent. This diminishes the RB ecosystem immensely and prevents Real Studio from being an enterprise-ready tool. If Real Software truly has limited resources and can’t do much, why not let the community fill the gap and help add tools to improve the product? (By the way, my product was open source and free of cost so it would benefit no one but Real Software and REALbasic users). Instead, the enthusiasm of those who want to help improve Real Studio is dampened. It is a shame.

  5. Paul Rodman

    I’m busy learning XCode and Cocoa Obj-C programming at present, which is both giving me a new appreciation of just how powerful and rich the RB language is without the enormous complexity of the Cocoa frameworks and the XCode tools, as well as making me appreciate just how bad RB is at making native Mac apps.

    The main problem I have (and have had for the past couple of years) is that RS release schedules are so short that by the time an alpha/beta is at the stage I can test it (on my humongous app), it’s too late to fix fundamental problems before the thing goes FC. I was not able to use three out of the last six releases because of (relatively major) bugs (the big database rewrite fiasco, contextual menus in Windows on tab panels, and bevelbutton problems on Windows, amongst others. 2010r1 seems OK, but I dread the upcoming Cocoa-support and LLVM releases.

  6. Scott Steinman

    Paul, there may be a breaking-in period for Cocoa, but to not do it would be very bad for REALbasic’s future on Mac OS X. In order to survive on Mac OS X, let alone add new controls and platform-specific APIs, this must be done. It’s a massive change in the compiler and frameworks so we can’t expect to be perfect at first, but it’s not a deal-breaker because Carbon Intel builds will still allow us to release products until Cocoa support is completed. I’d rather have it released even in imperfect form so it get wider everyday testing that can find subtle problems and get them ironed out.

    As for LLVM, I don’t see that as being much of an issue at all. Problems in LLVM have had to be tackled by Apple (and maybe the Linux community) already. LLVM is mostly just a swappable replacement for gcc.

Comments are closed.