This semester, my software engineering class is working on a project to bring the San Jose Cinequest film festival catalog to the Blackberry. RIM has generously donated us some devices.

Being a keyboard person and not very touchy-feely, I like the devices much better than the iPhone. Developing for them is another story. I am not the only one who has gripes about that.

• The development environment is a quaint, homegrown Windows program.
• RIM lives in the world of points and clicks. There is no provision for automatic builds and tests. I am thankful for the third-party bb-ant-tools and Dave Mitchell who figured out how to get the signing tool to work outside Windows. (The tool looks for signature files with the relative path ..\bin\sigtool.csk, with backslashes in the path name—how lame is that?)
• The API documentation is less than stellar. Check out the documentation of RichTextField. If you stare hard enough at it, you can probably figure out how to set up the offsets, attributes, and fonts. But what are those cookies? And how do you set colors?
• Many methods have this ominous comment: “Framework: This element may be called by the underlying framework. Members that are invoked by the framework may not behave exactly as documented.” Huh?
• Some things seem just impossibly hard. For example, I cannot figure out how to set patterns for “active regions” (those items that you can quickly select with the nifty trackball) in a single ActiveRichTextField. RIM only provides an example that sets them application-wide (using an unilluminating mess of factories and cookies).
• Networking is bizarre. There are four (!) different networks to which you may want to connect, and it is up to you, dear developer, to code your way through the selection process.
• There are two (!) separate developer forum sites (here and here), which are both sad.

Ok, why am I surprised? It's not that the Windows API is a walk in the park, and you can't expect RIM to have the same developer resources as Microsoft. But I haven't programmed with Windows for many years. With everything that I have done recently, I had access to source code, and there was a public bug list.

Publicly available source need not mean open source. Long before Sun saw the wisdom of open-sourcing Java, most of the library source was included with the JDK (and it was easy to get the rest through a free “research license”). And the bug parade has been there since JDK 1.0. There have been many times where I scratched my head about some weird behavior, and I could either read the source or find a bug report. Or, if I wasn't able to do that, someone else was, and that someone would post intelligent answers on a forum.

With access to the source, third-party programmers can produce better tools. There have been some people (here and here) who put together a unit test library for Blackberry programming, but one could a lot better with source code for the device and simulator.

It is just crazy how unproductive it is not to have the source. Come on, RIM, and everyone else out there who still locks their source away from public view. If you had super-great APIs and dev tools, maybe there would be a competitive advantage to that secrecy. But otherwise, what's the point? You'll have happier, smarter, and more productive developers if you let them use the source.