pmuellr is Patrick Mueller

other pmuellr thangs: home page, twitter, flickr, github

Friday, July 13, 2007

erlang meet-up

I went to the first erlounge RDU meet-up tonight to find out more about Erlang. The meet-up was arranged by Kevin Smith, who provided a short presentation.

I had done a little boning up on Erlang last night, so the presentation wasn't completely foreign to me, and I was able to squeeze a few questions in while the S5 presentation took forever to switch slides. Some of those questions:

  • Q: Does Erlang compile to binary, or use bytecodes, or ???

    A: Compile to bytecodes.

  • Q: What's the deployment story for web server code?

    A: Run yaws, a web server written in Erlang. Presumably, you'd be able to proxy to this via Apache, like other stand-alone servers (on a shared host, for instance; TextDrive doesn't currently have it installed, asking about it now).

After doing a bit of reading last night, I came away a little less enthusiastic than when I started. Not sure why. The meet-up re-invigorated me a bit. It's probably time to buy the book. Even if I don't actually do anything with Erlang, it's always nice to see what's going on with other languages, in hopes of maybe transferring some of those ideas, as appropriate, into other work you're doing.

On the negative side, it sounds like the error reporting (compilation and runtime) is fairly nasty. And the doc is largely man pages. And there's no real unicode support. And it's compiled.

It was a good omen to see my old young buddy, and fellow Building-50x-ite Chris Grindstaff at the meet-up. Chris has been yammering on about Ruby for years. Coincidently, the erlounge RDU meet-up group is an off-shoot of the Raleigh-area Ruby Brigade. Hmmm.

Monday, July 09, 2007

a history of transparency

Two projects in IBM have recently decloaked, both which I've had the pleasure of working on: Jazz and Project Zero. Both projects have come under some attack by folks as being "not open source". For instance, see Mark Pilgrim's typically humorous response to Project Zero.

I'm not interested in talking about that specific aspect of the projects. I'm an open source commie from way back, but the fact of the matter is that IBM contributes a lot of open source to various communities, and at the same time produces commercial, proprietary software.

What I'm quite happy about with both products is the transparency they provide to IBM's product development process. The term "transparent" I've borrowed from Stephen O'Grady, which he used to describe the Jazz development process. I thought I'd give a quick rundown on the transparency I've experienced in my 20+ years of software development at IBM.

From 1985 till about 1995 I worked on projects internal to IBM, and didn't really have a need to deal with customer feedback on the products I was working on, because they were internal to IBM. We did have a 'newsgroup'-like system called "IBMPC Conferencing" that was a fantastic resource for IBMers. Not a whole lot of people used it (relatively), which was unfortunate, but also kept the wheat/chaff percentage quite high. It did serve as a way to communicate with our internal customers though.

The IBMPC conferencing system expanded sometime in the early 1990's to allow customers access to a restricted set of 'newsgroups' called CFORUMs. This was quite convenient for IBM developers, since it used the same news system we already knew how to use, and customers also had access to it somehow. Sometime later, IBM created a real NNTP server named, which served the same purpose as CFORUMs, but used the more 'standard' NNTP protocol.

By this time, I was working on VisualAge Smalltalk, and we created at least one newsgroup for it on the NNTP server. For other projects I was involved with later, we also created newsgroups on the server.

So, we've provided some kind of newsgroup-y access to product groups for a while. However, we were limited in what we could actually discuss on the newsgroups. While we would frequently accept bug reports from users posted to the newsgroups, we couldn't really provide bug tracking numbers, since there was no way for users to access our bug tracking systems. We did it anyway, to at least give our users a shorter handle by which to reference the bugs. For new feature requests, or requests for when the next release would be made available, you'd typically see a response of "We cannot provide information regarding future versions of the product". Which was insanely frustrating for us developers. But we bit our tongues and pasted that response into posts, a lot.

So now, roll forward to the mid-late 2000's, with Jazz and Project Zero. We have 'newsgroup'-y access like we have had for a while. But we also have access to the bug tracking systems. And source code management systems. And a general notion of talking more openly about future release content and dates (I hope!)

It certainly seems to me, that over time, we've become more transparent with our development processes for our commercial products. I think this is great for customers, who will have more direct access to the product development teams and the product development process itself. It's also great for the development groups within IBM, as these open processes are a great equalizer: both new hires and CTOs have the opportunity to converse equally with customers.

I'm a firm believer in this sort of transparency being a benefit to everyone, and I'm looking forward to this becoming the rule rather than the exception for more IBM products.