Shortchanging Your Business with User-Hostile Platforms | Hacker News Reader

Shortchanging Your Business with User-Hostile Platforms

al3x.net

136 pointsssclafani93 comments

This is a fascinating question. AIR and the new mobile app frameworks are great for prototyping and getting an app out there really quickly, and perhaps then you can make the decision to either build native apps for your biggest platforms; or not.

Alex is obviously pointing to the verbal minority (of which he is a part), because for every person out there that speaks out against, say, the Tweetdeck AIR app; there are probably millions that are satisfied with it and in fact prefer it to the native alternatives (that don't have columns, even though they might be native).

The problem with listening to the verbal minority is that you're then building for the verbal minority, and not the bulk of your true user base.

Startups are all about priorities, right? And logically you should prioritize things that will materially affect your business (such as stability) over things that aren't real problems but get written up anyway. EDIT: I mean, he did leave Campfire because of a stability issue, even though there's a native app for it ;-)

You can dismiss the "verbal minority", or you could treat them as leading indicators. Personally, I'll err on the side of building something that's up to my standards rather than seeing if I can get away with mediocrity.

It's entirely possible to focus on both stability and, say, a quality desktop application. If you're under-resourced to accomplish both goals, maybe you didn't plan correctly.

It is also possible that both moving to a native app and achieving five nines of uptime (from four nines) will do less for the business than changing the call to action on the pricing page. Luckily, God gave us AB testing.

Not to mention there's often good money to be made at the nine fives level.

How is this an argument against making a native app? Don't you have to make the native app before you can AB test it?

It is an argument about competing priorities when resource constrained: try the cheap stuff prior to dropping six figures of dev time on a feature to rescue business which all available evidence says is one account worth $20 a month. (You could go try to find evidence that users actually want to download native apps. For example, put a download button on your page, then see if anyone clicks it. If nobody does, send me half of your six figure dev budget and you're now strictly better off. It is downright disturbing how many very expensive features fail to change user behavior because business processes optimize for the satisfaction of people other than the people who actually pay money for stuff.)

I agree with your last sentence, but not the one before it. Alex isn't arguing that users consciously prefer native apps; most don't even know what "native app" means. He's arguing that native apps feel better to users and that this feeling is worth something. How much it's worth is hard to quantify. The test you describe wouldn't answer that. As for this:

which all available evidence says is one account worth $20 a month

... surely you haven't reviewed all available evidence on this question? Or did God give it to us when he gave us AB testing? I'm joking, but I think you're trivializing a nontrivial question. I'd like to know how to find "all available evidence"; my experience is that this kind of thing can be very hard to measure.

Edit: it's worth remembering that Steve Jobs made almost an identical argument to Alex's in his critique of Flash last year, even emphasizing that it was his most important point: "We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps" (http://www.apple.com/hotnews/thoughts-on-flash/). Sub-standard apps are exactly what the OP is about.

If it is so easy, and you are unhappy with every available solution, then why not make one of your own?

In marketing circles, this "verbal minority" is referred to as "tastemakers":

"One that determines or strongly influences current trends or styles"

from: http://www.yourdictionary.com/tastemaker

I'm not sure I follow the connection from being "verbal minority" to being a "tastemaker". You can definitely be both, but just being one doesn't mean you're the other.

I think developers frequently suffer from "This doesn't flatter my sensibilities, so it must be crap. There is a sense of cosmic justice, so this will hurt the business."

I was told, repeatedly, that Mac owners are Jobs-loving HIG fascists who look down on Java apps. Separately, their conversion rate was double PC owners. Who am I supposed to believe, the experts or my lying eyes?

I don't think your criticism is entirely fair; for one, you can only compare OS X users to Windows users, which isn't at issue. Perhaps if you had a native version of your application the conversion rate would be 4x that of Windows. Furthermore, I would suggest that Bingo card applications have a different target audience than developer chat applications and that the former is less bothered by platform inconsistencies.

It was telling to me at the time that actual business results directly contrary to hypothesized outcomes identified in advance are treated as having no informational value with regards to the original claim.

So, your new working hypothesis is what, that Mac users secretly prefer Java UIs? That might prove too much.

I don't think it's a secret that Mac users are, by and large, more comfortable than Windows users at paying for and installing software. The paradox of choice is in less egregious effect, and they have fewer scars from past attempts.

No, that's clearly not his new working hypothesis.

How about: Users prefer "good" UI. Users evaluate "good" partly in terms of expectations.

Java apps done right on Mac OS X look, feel and behave like actual Mac OS X applications, Cyberduck is a free FTP client written in Java for Mac OS X. It is a great example of what is possible in Java.

But there are plenty of apps out there that are mere ports (Qt, or Java) and you can feel it. The drag handles are in the wrong location, the app doesn't behave right when you resize it, the buttons are in the wrong place, or switched from where they are supposed to be. I will still use it, but if something "native" comes along I will switch to it in a heart beat.

First, I disagree that well-done Java apps on OS X actually hold up as OS X applications. It is as Alex says; there's an uncanny valley, and Java apps fall right into it. Cyberduck is as good as it gets, and, compare it to Panic's Transmit.

Second, if you've seen Bingo Card Creator, you know that his users weren't buying it for its elegant OS X-ish interface.

I have used Transmit and found it to be less easy to use than Cyberduck, that and I am cheap, I used to pirate software, since I switched to Mac OS X entirely at the beginning of my college career I refuse to pirate software that runs on my Mac.

I've used Cyberduck for years, I'm a fairly technical person, I care about native apps... and yet I never realised that Cyberduck was written in Java.

So they've done a pretty amazing job. Perhaps that's possible in AIR too, but I don't know of any such apps (then again, I didn't know of any such Java apps until a moment ago).

Yes, that's a great example. If you sat me down in front of the two, I could not easily tell you which was the Objective-C application and which was Java. I used Cyberduck on an almost daily basis for years without ever realizing it was Java. That is the app that convinced me Java has a place on Mac OS X.

That's because Cyberduck calls the native Cocoa Objective-C APIs[1]. This is doable, but it's a lot of work and won't run on anything other than OS X. Something cross platform that uses Swing won't feel as nice. Also, it uses a third party binding to the Cocoa libraries. Apple deprecated theirs quite some time ago.

[1]: http://trac.cyberduck.ch/browser/trunk/source/ch/cyberduck/u...

He has a point. I'm an ex-air developer. I moved to WPF. So yes, ok there are heaps of bad air app out there, because the learning curve is so low.

That being said I think AIR can be very close to native. It takes that extra mile of programming that most don't do. In the end, you might as well make it native.

But think about this for a moment. An AIR app can and does run well on both Mac and PC. I understand native is better, but it's not a simple matter of money and time. You need to find the skills for a decent mac developer. Most of them are gone crusading in the world of iOS and too busy to make a mac client. .NET developers are plentiful though. my 5c.

I figure Flex and AIR are just becoming the new PHP. People love to hate, but I really like programming in both even though my favorite languages are Python and Scheme.

When people say programming in Flex is annoying.. have they ever done SWT development, or Swing? GUI work in general usually bugs the crap out of me, but MXML with AS and HTML with JS are fantastic.

Indeed. These group chat businesses should support open standards like XMPP or IRC. Yes, XMPP and IRC suck, but there are tons of clients available that work with each. If you support one of these, the user can use your "beautiful" web or AIR client, or they can bring their own real client. You get happy users without having to write any code.

I've worked at several jobs with distributed teams, and the one that used IRC was the easiest. (I've also used Outlook Communicator, which is, as you'd guess, the worst fucking software product of all time. Except for Windows and Outlook, of course.)

The company I work at currently uses a XMPP server to do internal chat which allows us to communicate between members.

Ditched Balsamiq a long time ago for this very reason. Would have been a good app if he didn't decide to build it on such a terrible foundation.

Still, he seems to be doing fine business wise. Maybe it's not as big a deal as al3x makes it out to be.

It takes some Enron-level hand waving to dismiss the cost of developing a native OSX app. Just hire a contractor, indeed. Would we prefer it? Yes. Would we pay for it? Don't be so sure.

Funny--he started out "after another Campfire outage this week", I thought the post was going to be about the unreliability of Campfire, its platform (ruby, dash of C, AFAIK), and the uptime issues causing user-hostility amongst 37signal's customers.

Which was going to be (and still is) ironic since BankSimple is likely using the same technology stack.

After being down voted: so Alex can call all AIR developers lazy because they don't want to leave their comfort zone and write native apps, but I can't insinuate the same thing about 37signal's not wanting to leave their Ruby comfort zone to make a reliable messaging app? Oh, right, we hate AIR, but love Ruby. Sorry, I missed that there was a double standard. :-)

We're using a bit of Ruby, but not C, and mostly Scala and Clojure. Either way, I think reliability is a process thing, not a technology thing.

Yes, true. I am admittedly showing my bias. Thanks for the reply.

I meant to up vote you, but missed (iPad.)

Can you elaborate on heat you mean by process and not technology?

Wow, really? First of all, 37signals DID step out of their comfort zone by using Erlang rather than Ruby for their backend to handle sending chat messages out to clients. Secondly, I was under the impression that BankSimple was essentially using Ruby on Rails for their front end, and Scala and other JVM-based languages on the backend. Finally, how is Ruby at all related to the Adobe AIR client in question?

Thanks for the correction--I last used campfire pre-erlang and missed the switch:

http://37signals.com/svn/posts/1728-nuts-bolts-campfire-love...

I always appreciate a quality call, but I can't agree that native is a good proxy for good UI or even just for the principle of least surprise. We use so many different UIs nowadays. Various OSs, crazy web UIs, different phones, games, vim, etc. So for me, the question is not so much "is this app native?" but rather "am I a native of the app's UI? (or let's say naturalized :)". iCal doesn't feel native to me, even though I use a Mac. It feels awkward after having used Google Calendar for a while. (I would even say iCal has a horrible UI but that's another matter)

I happen to think that a good UI is not just a matter of getting used to it, although that's a big part of it. There are some things I do hundereds if not thousands of times a day, and I want them to be very fast, regardless of what is native. I want them to be the same in that particular app on all platforms I use. I don't want the keyboard shortcuts of gmail or vim to change depending on what machine I happen to use.

I have built some pretty impressive AIR apps for our customers (5 apps, 40 KSLOC or so total). It takes a good level of software discipline to make apps that perform, can be reused and are maintainable (like any good desktop app). We chose AIR because of Linux / Window cross compatibility and its beautiful appearance.

I'm sorry but I just don't see what the big deal is. Alex names mog as an example of users wanting native desktop support, yet most are just fine using the flash version. It's difficult to draw conclusions based on a developer's perspective (which I've often been guilty of)

I've never liked AIR and QT/WebKit apps (or even the Opera web browser) because there's this feeling similar to that of Uncanny Valley, where something just doesn't feel right. The scroll bar doesn't work well, something happens too fast or too slow, selection doesn't behave as it should, the buttons look weird. Something along those lines.

I think "Uncanny Valley" is exactly right. It was something we faced when building an AIR app, we could mimic the look of the each OS pretty closely but it never felt quite right.

In the end we opted to a stylize feel of each OS but not an attempt to recreate the look and feel exactly.

I second that, Uncanny Valley is exactly it. It was the same a few years ago on the web when web apps tried to duplicate native functionality (think filebrowsers etc.), it never worked right. In fact, Dropbox (however much I love it) still has that problem in their web UI.

Opera has been native for a while...

I think the point he's making is that a lot of the UI elements don't quite look or feel right, kind of like how a lot of Adobe CS apps have "native" dialogues full of weird mistakes.

Sometimes little look and feel things have a huge impact on how people react to apps: I remember (and I could be wrong, it's been a while) pretty much instantly not liking Opera on OS X when I first tried it since it had smooth scrolling turned on by default, something almost no Cocoa apps do.

Oh, yes, I'm just pointing out that they changed that because people who have seen opera recently might be confused by the comment.

Am I the only one who wants a JS-HTML combo app that will be both cross-platform and fast, and not one native app for each platform for most of the apps?

A webapp is not a replacement for a desktop app. There are very legitimate reasons for wanting a desktop app, more for some types of apps than others.

I'm somehow not familiar with any of the apps he's referencing. Is he talking about mobile apps or desktop?

desktop

I see, thanks. My comment above doesn't apply, then. However, I think you can get very nice-looking, cross-platform, native apps with python and QT, GTK or other toolkits.

Qt for the win!

Examples? I've seen okay looking GTK and QT apps running under a specific OS or distribution, but usually when you try to run them on a different OS they fall apart.

I wrote a small mail notifier a while ago, it displayed fine on Linux with minimal changes. I don't have any other examples handy, though, sorry...

Qt supports different native styles, Qt looks - and behaves - native in Windows, OS X, GNOME, KDE, ... Try QtCreator for example, or VLC, or VirtualBox, or any other application made in Qt.

Check out their whitepaper "Qt Cross-Platform Application Framework": http://qt.nokia.com/files/pdf/qt-4.4-whitepaper

webapp vs native, do users really care about the technology as long as you can make them happy?

The approach we took is native for mobile and webapp for everything else.

Our users are asking for a "desktop app", so we are looking at wrapping our webapp in a SSB and distributing that.

I think what it comes down to is that as a developer, you've lost your way if you're creating a product you personally wouldn't want to use. Even if it were the case that the average user might not be that turned off by AIR (and I'm not convinced that's the case), if you've decided to base your product on a platform that's basically a deal-breaker if you're shopping around for apps (as AIR is for me), then I think you've set a really bad tone for your future enthusiasm for what you're making.

A frequent drum-beat on HN is having passion for what you create. Even if it saved me time in the short run and got me some degree of free platform support, I think having to work on an AIR app that I would probably never use in real life would probably doom the project in the long run.

When I think about the independent software projects that I love, it's obvious that the developers behind them love them as well. I (and I don't want to speak for everyone) can't see myself loving an AIR app.

I think what it comes down to is minimum viable product. Perhaps even budgeting. Maybe an assumption that since you don't like AIR, you can't see anyone else liking it.

Very good article. We use Yammer and their AIR client is a constant source of frustration. Bloated, CPU-eating, inconsistent and annoying.

I use Balsamiq Mockups when I have to, but I always find the experience annoying. If there was a Mac-native app with similar functionality, I'd switch in an instant.

I thought this article's unnamed product was Yammer.

It's all about getting shit done and bringing value to clients. Design fetishism affects very small percentage of both users and builders (which are also sophisticated users)

"Design fetishist", by all accounts I've read, is an excellent description of Steve Jobs and Apple. Therefore design fetishism does not affect a small percentage of users.

The first Apple computer was shipped as a barebones circuit board...even Apple had to work their way to excellent UX.

In my experience there is a difference between applications that feel 'a bit off' (in that they don't completely honor the platforms interface guidelines but aren't opposed either), and really user-hostile platforms.

In the first, the user interface is fast, stable, and does its job on every platform. The developers didn't have time to make a real native application, but have made sure of usability on every platform. Widget kits like QT allow to get very close to native look&feel. In this case, the usefulness of the software can make up for the non-nativeness.

On the other hand, really horrifying user-hostile platforms also exist. I've frequently experienced these in "enterprise software". Makers of such products seem to think that user experience doesn't matter at all. The interfaces, feel bulky and slow and generic, sometimes based on 80s screen scraping, and live in a world of their own, ignoring any user friendliness guideline since the same era. Not even starting about the web-applications that only support IE6... This is not the uncanny valley, this is stuff straight out of nightmares.

Would he have considered the product at all if it was Windows-native only?

Nope.

Do you think an AIR application will result in less users overall than a Windows only application?

edit: make that less "paying users", by whichever standard the application in question uses

Keep in mind that although 60% of our AIR client users are on Windows, 0% of the teams use Windows exclusively. Targeting a single OS would be a fatal decision for us.

Arggh. There's this thing called IRC. Problem solved.

"It seemed like a decision that had everything to do with what’s in the best interests of the business, and nothing to do with what’s good for the customer."

They already told you they're a small team, with mostly windows users and AIR allowed them to offer a cross platform solution. This is a polite way of saying "you're an outlier, you're not our target user, please go away and stop bothering us".

"People seem to hate AIR. Wherever you see AIR apps, there are support forum threads opened by customers begging for a native alternative"

I've personally never noticed this, got any examples?

Let me say here: I'm not a fan of AIR - I'm completely indifferent to it as a technolgoy - but so far you're just bitching about your personal experiences with one application and wishing the world were different from how it is so you'd find it more enjoyable.

"a moderator sheepishly explaining that they just don’t “have the time” "

What's to be sheepish about!? There's no shame in not having the time to build native apps for every platform. I don't have the time to write all of my code in assembly so I use high level languages. If you tried to run a modern operating system on 1980s hardware you wouldn't get particularly far. Technologies are built and adopted to improve productivity and get products to market faster - AIR is one of these. Whether or not it is the best choice for one application or another, or whether you happen to enjoy it or not has no bearing on how much actual time a company or individual has to develop software! They make a choice about a technology based on their goals and the information at their disposal. Why should they be feeling sheepish?

"The fact that some subset of users are willing to shell out for these native apps should be a wake-up call. That’s money that those service providers are letting slip away."

No, it's money they're making by opening their product using an API and not trying to be all things to all people. By allowing 3rd party developers to build on their platform they still get your money, but they just don't have to do any extra work for it building a native app for your platform.

"In a nutshell, what you’re communicating with an AIR app is that your business priorities (saving time and money) are more important than what your customers want."

Or maybe you're just trying to build a minimum value proposition, make some money, test the market, receive feedback, learn something, iterate and improve. You seem to think these guys are dishing up an AIR application in an afternoon then taking your hard earned cash and throwing it onto a gigantic "Scrooge McDuck" style money bin, then taking the yacht out for an afternoon spin to laugh at their sucker customers. You don't like the product, don't bloody buy it! That's what the free market is there for.

"“We don’t have time” is the common excuse for delivering an AIR app instead of a good native app. Money, though, can buy someone else’s time. For a price, you can find a great contractor to build a native app for any platform under the sun."

Okay then why don't you build this app that you're after? Just learn to program, then build it yourself. Oh, don't have time? Well just pay someone else to do it for you. If you have the money, fantastic, compete and make a better product. What makes you think that these people are any different from you? That they don't exist in the same world of limitations and constraints that we all do every single day of our lives?

"Humans are gifted with extremely sensitive bullshit detectors."

Yeah mine started going fucking bonkers about paragraph 2 ...

You could have made this article about how flawed you think AIR is as a technology, cited examples of applications that have vocal user communities looking for a native app etc.

Instead you've just made outlandish claims that people building technology and working to create products are lazy, that they're somehow compelled to produce mediocre products (rather than settling for the best they can afford to produce and shipping something in the hopes that some people will get good use out of it).

Software is a constant process of settling for mediocrity. Nothing is ever finished. No software developer has ever typed one last semi-colon, sit back and said "you know what? There's nothing else I'd add to that, it's perfect".

Who keeps upvoting this!?

"People seem to hate AIR. Wherever you see AIR apps, there are support forum threads opened by customers begging for a native alternative"

I've personally never noticed this, got any examples?

In the post you're quoting, he linked to four forum threads for four separate products, along with a couple of blog posts.

Won't there be even more complaining how shitty a native software is?

Probably. However, that's not what the parent asked for.

Oops! Missed that sorry

Alex's point is that they should have built a native windows app in that case. Even on Windows, AIR apps kinda suck.

It all comes down to the oft-rehashed point from 37signals: build half a product, not a half-assed product.

AIR always feels half-assed. It's slow, resource-intensive, doesn't look like the other apps, and generally gives a slightly uncomfortable feeling.

Sometimes.

I like Tweetdeck and Balsamiq Mockups and don't care they use AIR.

You should try our app. AIR is kind of crappy by default but we've put a lot of work into making it feel native. Lots of people love it:

http://twitter.com/#!/mtamizi/status/24547982921703424 http://twitter.com/#!/ochekurishvili/status/22690462684 http://twitter.com/#!/pradeep24/status/24582785423384576

Very well said, dools. I'm a co-founder of the app in question, which is HipChat (http://www.hipchat.com).

If we'd started out making native apps for every platform we wouldn't be where we are today. Sure AIR isn't perfect but it's allowed a 3-man bootstrapped team to create a product that hundreds of companies love to use every day and are happy to pay for.

Alex mentioned his team was going to try setting up their own IRC or Jabber server. That's awesome! The whole reason we're creating HipChat is because the vast majority of business have absolutely NO IDEA how to do that. The fact that more technical teams are willing to invest their precious work hours setting up and maintaining their own group chat system is a testament to how powerful a tool it is.

Of course if you set up your own chat system you won't get drag + drop file sharing, archived history, or inline image previews no matter how technical your team is. :)

Oh and we'll be opening up XMPP access soon so anyone who really needs a native app is more than welcome to build one.

I rationally agree with the decision your team has made, but I realized I no longer have any AIR apps running on any of my systems. They've been unconsciously filtered out for native or web alternatives.

If your team does decide to build for a platform/OS I hope it's OS X first :D. Best of luck either way!

I genuinely enjoyed this comment. Really. It's probably the most passionate response I've received.

I was going to argue with you point-by-point, particularly about your false claim that I didn't include any examples (which another commenter addressed, and you acknowledged). At the end of it all, after a lot of flailing, I think this is really your thesis:

"Software is a constant process of settling for mediocrity."

I think we're just going to have to agree to disagree there. If that's how you approach what you do, then I understand your position. If that's your approach, then sure, AIR is a reasonable choice. That isn't my approach, and I think it's also not the approach of the people who, much to your befuddlement, keep upvoting this story and tweeting positively about the post.

If anyone's still interested my blog-in-reply is here: http://news.ycombinator.com/item?id=2111686

Yeah, settling for mediocrity didn't work out for those Twitter guys either =)

Am I the only one that enjoys using Air apps? I found the post to be a bit whiny for my tastes, and furthermore, I wonder if the OP is happy with any service at all.

Seems more like an issue of a problem customer than a problem service.

There's a lot to be said about the potential of the WebKit HTML/JS portion of AIR that's far less used than the Flash or Flex counterparts.

In my experience, the lack of a sane garbage collector burned me in the end. I believe the reasoning was that Flash apps were ephemeral, from page load to page load, and definitely not meant for a desktop application with a long life.

It was very hard to ever really free memory, and I remember writing a fairly straight-forward AIR app which would start at 70MB RSS, and balloon to 1GB the next morning.

I've used AIR apps(as a consumer, not a developer) and there are times when I get a little frustrated with the experience. Still, I use the software because it saves me time and makes my life 10x easier. Overall if customers are criticizing your use of AIR as a platform rather than praising you for solving their problem, then you have bigger problems than the AIR vs. Native debate. Many users will tolerate even the crappiest of experiences, see IE6-IE8, so long as it solves their needs.

This is exactly the reason I have been rethinking the way my company develops apps. As the world splits and there isn't one standard technology like there used to be with Windows, I feel it is imperative to be thinking about how to go cross platform as quickly and easily as possible without cross platform tools. I think it means lighter native apps, simpler in design to do one specific task, and then more sophisticated tasks in the browser.

I guess the same applies for apps in the mobile space too. iOS Apps built using frameworks such as Titanium and PhoneGap always seem a little off.

There is an interesting discussion about this in Dan Benjamin's latest episode of the 'Build And Analyze' series with Marco Arment. http://5by5.tv/buildanalyze/8

PhoneGap apps feel very off because they're simply HTML/JS wrapped in a WebKit component, but Titanium is far different. Titanium makes native controls. Its virtually impossible to tell the difference between an app created in Titanium versus some JS crap wrapped in PhoneGap.

There is very informative discussion on StackOverflow about Titanium vs PhoneGap :

http://stackoverflow.com/questions/1482586/comparison-betwee...

So what should I take away from this? That businesses should focus on customers using Windows first?

If the team is small and the product has some value to you, it only means the team focused on the right featureset.

Personally I'm grateful if an AIR client is available, because that means I can use it on Linux, my OS.

I really need to write a post on "Shortchanging your blog readers by spewing opinion but disabling comments". Whats with this? DaringFireball is the worst of the lot. Is this some new trend?

Daring Fireball doesn't present itself as a forum for comments. There's a very detailed post on why it doesn't accept comments - http://daringfireball.net/2010/06/whats_fair

It's not a new trend. I haven't allowed comments on my blog for years. I want people to post thoughtful responses on their own turf. If someones care enough, they can respond on their own blog.

But how does one find those follow up posts? I don't see any pingbacks on your blog either.

Its an interesting problem though, I actually find a lot of value in comments, especially when the topics aren't too sensational and the people aren't entrenched in their camps. I actually come to HackerNews and Reddit specifically for comments but not every story gets there.

The only people being cut out are those who are too lazy to post on their own blog or start a discussion thread on their favorite forum/link aggregator. I think blocking people who don't care enough to do that from commenting might be a net win.

Try Sococo teamspace. Window sharing, chat, voice, doc, really neat presence indicators. Its built exactly for a distributed development team.

Runs on Windows, Mac, Linux.

Reply on news.ycombinator.com