DrunkenBlog

Martin Pittenauer of SubEthaEdit

If you're not aware, SubEthaEdit is a Rendezvous-based, collaborative and distributed text editor, built using Cocoa and available for Mac OSX only. It's garnered rave reviews since it's release, including an Apple Design Award and an O'Reilly Innovators Award, and was hailed as flagship application of Rendezvous.

Martin Pittenauer of TheCodingMonkeys graciously agreed to go slumming answer a whole slew of questions about SubEthaEdit along with a whole lot of other stuff that's only loosely related. Cocoa, WWDC, Obj-C, being a Mac user in Germany, topless women... it's all there.

Which prolly means that after this no other company will ever, ever agree to answer my questions again... so savor this one.

What's your role at CodingMonkeys? I know you were responsible for SubEthaEdit's website, for example, which has garnered kudos for its' presentation.

Well, aside from coding, all of us are performing "the rest of the stuff" that keeps TheCodingMonkeys going. Being a XSLT/XHTML geek, one of my jobs is to maintain SubEthaEdit's website, which in time for 2.0 now is completely powered by XML workflows, which makes updating and generating news feeds a lot easier. I'm also "Chief Propaganda Minister", meaning I'm doing all the email correspondance, most of the user support and the occasional blog comment... ;)

Version 2.0 was a big release for you guys in terms of features, infrastructure, and version numbers. You guys obviously keep tabs on most-requested features via the bug-tracker on your website, and many of them seem to focus on "BBEdit has this...". One of the big features of your app is the lack of bloat: do you foresee a problem in integrating some of the most-requested features, like FTP/SFTP support, while still keeping the program lean and approachable?

We try to listen very closely to what our users are requesting and I hope we got in a bunch of the most requested features for 2.0. As you mentioned a lean application that conforms to Apple Human Interface Guidelines is one of our top most priorities. Sometimes we have to find different solutions for problems to satisfy our users while not giving in to the bloat way of doing things.

The FTP/SFTP support you are mentioning is a very good example. With the support for inter-application workflows we added for 1.1, its possible to edit documents on FTP servers complete with upload on save through your favorite FTP client. Most users are very happy with this kind of FTP support and if I remember correctly we only received 2 or 3 requests for a FTP stack within SubEthaEdit since we added that feature half a year ago.

Developing an editor is like walking a tightrope between adding useful new features and becoming everything and the kitchen-sink. We will try to continue to do that.

Something I've noticed on your website is that you go to pains to reiterate that SubEthaEdit is not just for coders, even though its obvious main focus is as a plain-text editor with developer-oriented features. What type of demographic breakdown have you seen with SubEthaEdits' usage, and have you been surprised by the types of users it has attracted?

While we have thought of a few use cases outside of coding, like writing meeting minutes together, we were quite surprised where and how SubEthaEdit is used. For example, most ironically, we never thought about usage in educational contexts. Neither did we think about note taking at conferences, which is a domain where SubEthaEdit is used quite extensively.

While I don't have any hard numbers on non-development related usage, its quite clear from feedback that it makes up a significant percentage and we are trying to support these kind of usages with new features, that also benefit development usage, like e.g. invitations.

Most of our users have a development background, be it applications, scripts or web, but occasionally there is a hollywood script writer, a marketing manager or a NASA scientist to spice up that crowd... ;)

The current version of SubEthaEdit was also a big break with the past, in that you have "gone paid", but the application is still free for non-commercial usage. So far this seems to have gone relatively smoothly for you guys, compared to others. Why do you think this is?

I'd guess one of the reasons for that, is that it isn't a really big break for most of the user base, because we tried to limit required payment to users that have a financial benefit from using SubEthaEdit.

Secondly these commercial users we are asking to contribute to the future of TheCodingMonkeys and its software by paying a license fee, are very understanding and supportive. As one of our customers put it: "I make a good living programming[...] I wouldn't be a nice person if I denied others the same opportunities."

With any license change there can be confusion about what is allowed or acceptable, especially when the license terms are on the honor system, or somewhat vague. Has this been a problem during your license change, and are there any common situations you've encountered that you might want to expound upon to alleviate any confusion?

Up until now, there wasn't a lot of confusion. However, if someone is wondering I might want to stress again that educational use and use at conferences still is free. If there is anything unclear in terms of licensing, just drop us a mail.

Prior to version 2.0, you only had a low-key link on your website for donations via paypal. What was your experience since the release of v1.0 in terms of appreciable support?

We got about twenty donations via Paypal between 1.0 and 2.0. Budget-wise these (and more) were completely sucked up by the nasty trademark trouble we were experiencing, but I think the support was very important psychologically and provided us with an impression how valuable SubEthaEdit is to some users. All donators received free commercial licenses with the release of 2.0 and are enjoying our eternal gratitude.

Twenty donations divided by three people spread out over a year doesn't exactly allow for a legal war-chest, or even allow one to drop their day job. Have things improved significantly with the introduction of v2.0?

Things have improved. However it's probably to early to draw any conclusions as I guess quite some commercial users are most understandingly waiting for at least a 2.0.1 version before they are willing to commit to buying a license.

A lot of thought must have gone into your current license scheme, and many different options must have been evaluated and considered. Could you give a quick breakdown on the options considered, and why were they discarded in favor of the current license?

Shortly after releasing 1.0 we got a lot of requests to open source the complete application. We considered that, but decided against it for quite a few reasons. Most importantly because we don't want to become maintainers and want to stay coders. Another important reason, even if that sounds odd, is emotional attachment to the application and its codebase.

We spend a lot of time arguing what would be a fair license for 2.0. Fair to old users, new users and to us. So personal, educational and conference usage more or less had to stay free. Anything else would have felt unfair.

Having considered that, we decided to ask commercial users for contribution, for reasons I mentioned above. We hope SubEthaEdit is quite moderately priced and should be affordable to those that make enough money to be considered a commercial enterprise.

In the past you have considered releasing the source to certain parts of SubEthaEdit... considering the nature of SubEthaEdit, I found this to be an interesting idea as I had a hard time figuring out how you would break apart the apps enough to do this, unless you had a very, very modular design. What parts were you considering open sourcing?

With 2.0 the application's design is in fact very much more modular than it was with 1.0. One part we considered to open source and that actually is open source by now is our rendezvous code that supports IPv6 and multihoming.

Many would consider this to be giving away a competitive advantage. What was your motivation behind releasing a chunk of your application under the BSD license?

The main motivation in this case was to get feedback on our implementation and to improve the state of Rendezvous implementations in general. We are living in multi-homed environments mostly, and there are issues common to most implementations (even some of Apple's) with that, we'd really like to see improved.

I think it's fair to say that the name SubEthaEdit didn't win many fans when it was announced. You were put in a position to where the name of SubEthaEdit had to change, and while I love Douglas Adams, even I have to admit that by adding the "Edit" to "SubEtha", the name rolls off the tongue like a brick. Have the "I hate the name!" emails mostly died down by this point?

To us feedback on the name was very mixed. In fact I had a little scoreboard for "hate the name" and "love the name" mails and it was quite balanced with a small majority on the hate-side. Changing an application's name always sucks and I too lamented when Chimera and Phoenix had to be renamed. If we had any alternatives we certainly would not have changed the name.

Speaking for myself, I really like the new name, not only because it pays tribute to Douglas, who first had a vision of collaborative and wiki-style ideas in computing. I also like that I can use the abbreviation "see" for my SubEthaEdit command line alias. If you experience problems with the name rolling off tongues exactly the way bricks don't, I'd suggest pronouncing it with a silent "Edit" or calling it "SEE".

The first thing one notices when installing the new version is that the icon color changed from blue to green. Is this an homage to green guy from the hitchhikers' book cover, or is there another story behind it?

Oh, never thought of that. Interesting idea. In fact we chose to change colors to mark a significant change in the application (New network protocol, new document sharing metaphor, invitations and more features). After experimenting a little bit the only color that looked good seemed to be green and with iTunes doing the same for 4.x, we figured that would be a good move.

Many don't realize what kind of time commitment a project can be, whether open source or freeware or shareware. This can be even more problematic when you have a group of people who all have their own lives, yet have to come together on a project. Hell, I can't keep up with my blog. Has this been a problem for CodingMonkeys?

Sure. Considering we have to finish our studies at university, while working for money to pay the rent, while developing Macintosh software, while having enough of our "own lives" to stay sane, the 24 hour limit on each day really gets on our nerves...

I think it works because we are really good friends and can stand each other for quite some time, even in pre-release "work or sleep" crunch mode.

Often when an application "goes paid", or has major license changes, this can change the community dynamic. The type of people who may feel compelled to write syntax modes or to send in detailed bug reports may not feel compelled to do so once its something they're paying for. Is this something you are concerned about?

I was a little bit afraid of something like that, but currently the dynamic is very much the same than ever. I try to have a close contact to our contributers and haven't heard anything negative in that direction yet. I hope this is a sign that the change wasn't that dramatical at all and we managed to find a fair solution licence-wise.

Rendezvous, or ZerConf networking, was introduced back in MacOS 10.2. We're now approaching MacOS 10.4, and while the pace of Rendezvous-enabled apps has picked up recently, on the whole the 3rd party applications really harnessing rendezvous aren't very numerous, let alone apps that really show it off. This was surprising to me, as I expected it to become much more pervasive in 3rd party apps. Why do you think Rendezvous hasn't been integrated more heavily by developers?

Rendezvous is a technology that enables applications to do no-configuration-networking. One of the reasons why there aren't more Rendezvous applications is that there aren't a lot of networked applications in the first place.

I'm not going to reiterate on the old "Networking is just one letter away from not working" saying, but even if networking makes sense in your application domain it's hard to do it right. Even more so if you add it later on.

Another thing is that most people expect Rendezvous to be a silver bullet in terms of networking. For example, when we first introduced SubEthaEdit a lot of people seemed to think all the collaboration logic and the network protocol where completely handled by Rendezvous.

Rendezvous is a great and ingenious way to announce and locate services on a local subnet, but you still have to do the other stuff yourself. Most Rendezvous enabled applications make the whole network stuff look ridiculously easy, not so much because it is, but rather because Rendezvous enables the developer to hide a lot of the "loose ends" of networking from users.

I'd imagine that there are two targets that needed to be solved, both the technical issues and the UI paradigm issues. Arguably SubEthaEdit "showed the way" in terms of a UI paradigm, so I sort of assumed we'd be seeing it showing up in Calendars, Outliners, etc once people realized how it could work outside of iTunes & printers. If rendezvous is only one part of the puzzle, could Apple stepping in with more extensive APIs built around collaboration be a catalyst?

Well, Apple provides some nice APIs for networking in general (e.g. CFStream and NSStream with 10.3). I think they will continue to improve them, but I'm not sure what they can do to make it easier for developers to network applications.

I'd love to be proven incorrect on this, but as it seems now, there is no "out-of-the-box-networking" you can just "plug" in your application. It requires thought and effort on your side and while Apple can help with providing great tools, they probably can't do all the hard stuff for you.

CodekMonkeys hasn't been shy in showing its love for Apples' Cocoa frameworks. As a CS student, you've invariably been exposed to other technologies, such as Java. What is it about Cocoa that has enthralled you?

Cocoa is a very mature application framework. While working with it and getting more experience you can see that a lot of thought went into it and most of the time a very elegant solution was found. The three of us had some experience with other frameworks, like AWT, Swing, PowerPlant or even MFC but never really felt "at home" there. This changed with Cocoa, and we are thankful for that.

Another important factor, even if you supposed differently in your "Rhapsody in Yellow" post, is Objective-C. It's an elegant, dynamic, readable and really object oriented language combining the best of C and Smalltalk. Using Cocoa with a language less suited feels like driving a racing car on a bumpy country lane. That's why there is so little interest in Cocoa-Java.

Ah, I had my own little scoreboard going for the "Rhapsody in Yellow" post. :) Is SubEthaEdit a wholly Obj-C app then, or have you had occasion to incorporate Carbon or straight C?

Aside from CFStream that we are using to do networking, there are only some sprinkles of Carbon and plain C for things like Apple Events or UUID generation for example, but that's quite minor stuff.

Before 2.0 we used BSD's regex.h and had a lot more C stuff in there, mainly in the syntax highlighting routines, but with Sonobe-san's excellent "OgreKit" Objective-C wrapper for our new regular expression library "Oniguruma" there is no need to do that anymore.

Every rose has its thorns, and every developer always has some bones to pick with a technology, even if they wouldn't trade it for the world. Have you found there to be challenges when working with Cocoa?

One thing might be that it has a quite steep and longish learning curve, but considering the complexities of an application framework, that's probably more of a challenge to the developer than a real disadvantage of Cocoa.

Another thing is that back when we started learning Cocoa, the documentation was a bit sketchy, with a lot of "Description forthcoming"s in there. That however has changed dramatically since then.

In fact it's much less disadvantages of Cocoa one might complain about, but the lack of better support for certain Mac OS X APIs, like e.g. QuickTime, within it. However we are confident, that Apple will continue to improve Cocoa in these parts while maintaining an elegant, non-bloated framework. All in all there are amazingly few thorns on this rose.

Other developers have complained about the speed and efficiency of working with text in Cocoa and Carbon. Is this something you've noticed, or are the complaints due to poor optimization on the developers part?

While there is always room for improvement, the Cocoa text system made a remarkable jump in terms of speed with Panther.

However it always depends on what you are trying to do: Loading megabytes of text into a standard NSTextView naturally is slow, because that's not really what it is intended to do, considering it has to keep lay-outing the whole text and can't rely on fixed-width font assumptions to do so.

Having said that, we will try to figure out how to handle very large quantities of text more efficiently in the future.

For v2.0, you've moved the low-level networking to the BEEP protocol (blocks extensible exchange protocol). What led you to BEEP, and then to choose it as your networking layer over other protocols?

We researched a lot of options for a new network protocol. We wanted efficiency, extensibility and something that would fit our requirements without being an ugly hack. We had evaluated a few technologies and chose BEEP because it was the best fit for what we were trying to do.

BEEP provides a simple and most importantly standardized framework for everything you will have to handle when you design and implement a network protocol, that deserves the name. It's an IETF standard (RFC 3080) and as we recently found out is also used in Apple's Xgrid software.

Having our own Objective-C implementation of BEEP powering our networking layer has great advantages: If we want to add a feature like TLS encryption or authentification in the future, we should be able to do so without breaking compatibility with the current protocol.

Secondly BEEP enables us to do more stuff more efficiently than before with e.g. reduced resource load by using multiplexed channels over a single connection or better status channel capabilities. Last but not least we won't have to implement a networking stack for another application when we write one; we can just take our BEEP library and create a profile for the new application.

What's next for SubEthaEdit? You've come a long, long way with version 2.0 and laid a lot of pipe. You've given hints as to further features, such as a CLI tool that is in the works. Is there anything else you're excited about coming down the pipe for SubEthaEdit?

We've got a few great things coming, on both, the collaborative and the plain-normal-editor side, but I really don't want to ruin surprises here.

I don't want to talk about features currently in prototyping, because that might result in disappointment if they don't make it in the application in a reasonable timeframe. Let's just say we will continue to have an open ear to our user base and the most requested features, while having a few new innovations up our sleeves...

For 2.0.1 which should be ready before WWDC, we mostly plan to re-add a few localizations and fix bugs.

Awwww, fair enough. But in the interest of nailing you down on one point for your users' greater good... would you be willing to swear a blood oath to never, ever release a text editor with a metal interface? And possibly joining my jihad on those who commit this grave sin?

Hehe. You can consider us part of the "Metal Hating Coalition", especially if it's a third party application. If I remember correctly, using metal in an application like ours would even violate Apple HIGs.

So yes, you have our word that we will do what we can, to stay as far away from a metal interface as possible.

Apple doesn't exactly have a whole lot of marketshare outside of the USA and Japan, and what is has of Europe is spread thin. How long have you been using macs, and how were you first exposed to them?

TheCodingMonkeys consist of one "classic" 10+ years Macintosh user, that was lucky enough to have relatives who worked with Macs and two more recent converts coming from Risc OS and from Linux that first experienced Mac OS X at university in a "QuickTime for Java" programming course two years ago.

What hardware do the CodeMonkeys use?

It's probably fair to say, that TheCodingMonkeys are three PowerBooks (867MHz, 1GHz, 1.25GHz) with guys attached. Our webserver is hosted off-site, more or less at the other end of Germany, somewhere near Berlin and runs FreeBSD.

If you're from California, or Palo Alto or Cupertino, you can have a skewed idea of what its like to be a mac user in other parts of the country, let alone outside of the USA & Japan. Are there difficulties involved in being a Mac user outside of the USA?

Most of the time we don't really experience that much difficulties, as everyone tends to spawn his own little Macintosh-universe bubble, converting friends and the like.

If you are confronted with the reality of computing in Germany it's another story however. There is a lot of strange prejudices and urban myths, like "Microsoft owns Apple" or "Macs are only for graphic stuff" because most people never have seen a Macintosh, let alone having worked with one. Spotting a fellow Macintosh user in a café for instance is a very rare occurrence.

For me, visiting Silicon Valley feels a little bit like coming home in terms of computing platforms. Most people know Apple as a brand, you can see people using Macintoshs in public and there are Apple Stores. Macintosh geek paradise... ;)

We may have Apple Stores, but I've heard that Germans serve beer in their movie theaters, and a former roomie used to have a German girl who'd visit who thought nothing at all of sunbathing topless on our patio. When questioned about this behavior, she intimated that it was fairly normal there. One would think Macs would be more popular in such a beautiful culture. Why do you think Apple struggles so much outside of the USA for share?

The grass is always greener on the other side, I guess... ;)

I'm not sure what keeps Apple from getting a (slightly) bigger market share in Germany. Most certainly it has to do with getting a bigger mind share, which currently increases thanks to the success of iPod, iTunes and (hopefully beginning next week) iTMS. Some people start realizing that the guys that make these wonderful music players also make computers and customers searching for quality computing solutions should be drawn to Apple. I think Apple Germany should invest more in marketing to exploit this "iPod-phenomenon", e.g. placing a few TV ads would be a good start.

If you could push one feature request or perhaps a bug on your wish-list to the top of Apples' radar, what would it be?

While I have a few bugs and requests (like adding a Monaco font with bold and italic variants to Mac OS X) waiting in my bugreport account, I'm very pleased with the kind of responsiveness and support you are getting if you find a bug in e.g. WebKit or Rendezvous. The engineers at Apple are doing great work.

But to answer your question: My biggest request would be to improve the Finder. Especially in terms of networking (FTP, WebDAV, etc.) and innovation.

Apple recently said it would slow down the release schedule for MacOS X. From a developers' perspective, do you view this as a good thing or a bad thing?

Considering that Panther is a real mature platform to base software on, it's a good idea. Developers would love to always use the newest features and therefore the newest version of Mac OS X, but there are users that don't want to update their OS on a yearly basis. Taking the pace out of this "race" is a good thing.

Fragmenting the user base with yearly updates has been something some of us have watched with concern. Have their been 10.3 features you were interested in using but had to forgo for backwards compatibility?

In 1.x? Not really. However with the release of 2.0 we decided to base our application on Panther, because we wanted to use Controller-Layer features and hope to be able to provide better long-term support for an application based on 10.3.

With introduction of our web preview feature we had a few difficulties within that area, because the requirements for WebKit, "10.2.7 or 10.2.x with Safari 1.0 installed", understandably generated a little bit of confusion.

The 2004 WWDC is almost upon us, and with it Apple will be announcing Tiger, and presumably some new hardware. As a developer, what are you hoping to see in terms of Tiger?

From a developer's point of view and judging from the session descriptions already available, I'm really looking forward to better XML and new XSLT support within Cocoa and to WebKit advancements. Last years' WWDCs however managed to bring new and innovative technology (Rendezvous, Bindings) to developers, that nobody had reckoned on. I hope this trend continues.

On the hardware side, I hope to see continued evolution, but don't really care about new desktop machines. There might be news or statements about G5 PowerBooks (which certainly would be interesting), but it's probably way to early to expect shipping or even announced products in that timeframe. I'm fearing gadget related announcements (iPod, iSight, etc.) because they would drain my bank account. If there are significant ones, I will be first in line at the Apple Store in SF... ;)

Software-wise I tend to get a bit unrealistic. I'm hoping for an improved version of iChat with VoIP support and a framework accessible to 3rd party developers.

With Dominic Giampaolo (BFS) and Pavel Cisler (BeOS Tracker) working at Apple I'm also hoping for a better Finder, complete with a metadata driven filesystem. It would be great to have "smart playlists" within the Finder, so to speak and to be able to free the user a little bit from hierarchical structures. E.g. I could tag all "Drunken Batman"-related files on my harddisk (with Address Book support, certainly) and then have a search or a playlist for all things related to you.

As I said, I tend to get unrealistic, and it might be asking for too much to have this in 10.4 already, but with Apple announcing to slow down releases of Mac OS X and the resulting possible later release date for Tiger, I'm still hoping on something like that. Besides, it would be cool to crush WinFS two years before it's released... ;)

Germans are known for beer... in the spirit of the site, what's the CodingMonkeys' spirit of choice?

While we really enjoy Bavarian beer, I have to admit that TheCodingMonkeys' traditional drink of choice has become a nice cool pint of Guinness.

 Posted by drunkenbatman
    June 08, 2004, at 08:56 PM