funkatron.com

I had a really fun time the other night on the webOSRoundup live podcast recording. We do it over Skype + UStream, so folks in the chat can watch us while we dick around and try to fix technical issues. I love doing stuff like this because I get to act like I know what I’m talking about – it’s a lot like this blog in that respect.

One of the major topics of discussion was a recent announcement to the Twitter developer community about the way users interact with Twitter, and where developers should focus their efforts. There were also updates to the API TOS, but that really didn’t change much. The “money quote” was in the letter, signed by Ryan Sarver, that went out:

…developers ask us if they should build client apps that mimic or reproduce the mainstream Twitter consumer client experience.  The answer is no.

While follow-up discussion has basically been Twitter employees saying “oh, we didn’t mean that you can’t, just that you probably won’t make money doing it.” While the folks posting this probably believe that, I think the folks who actually control what Twitter does meant what was said. And what was said was “you should not make client apps,” and not “you probably won’t make money making client apps.”

A lot of people have asked if this means 3rd party client apps are banned. No, not at the moment. But Twitter’s overriding purpose is to make their investors money, and if it becomes more lucrative to ban 3rd party clients outright, or restrict API access to blessed or paying developers, I have no doubt the company will do so. People have short attention spans, and if Twitter is still around in 2 years, things may have changed enough where they don’t care so much that they can’t use Tweetdeck.

The second point that came up in this discussion was how this affects webOS. There is no official client on webOS, but there is a very active set of 3rd-party devs who work on clients, including myself with Spaz. Right now, I believe there’s no official client simply because Twitter doesn’t care about webOS. At the moment, webOS market share is too low to matter to them. When that changes, they will be more interested in it.

And rest assured, HP Palm wants an official client. It’s in a list of apps they want, like Netflix and Skype. If HP/P has to build it themselves and just have the approval of Twitter (Twitter certainly doesn’t build all their official clients in-house), they will – like they did with FaceBook.

What does that mean for the various independently-developed Twitter clients? Probably that they will need to be accept that their products will be niche. I’m speculating, but I suspect HP/P will not put much effort into promoting 3rd party clients. There’s a good chance an official Twitter app will be pre-installed as well, which means many (most?) users won’t bother looking in the App Catalog for another option.

Does that mean you’re screwed? No. But it means you’re gonna have to accept a role as a “hobbyist” rather than trying to make this your day job. As Alex Payne said:

Get cozy with [Twitter], or work at arm’s length. Operating in between the hobbyist and professional roles could be difficult, and developers may be understandably frustrated as they’re forced to rethink their projects and products

I suppose it’s possible that HP/P might pluck some lucky indie developer out of obscurity and bring them on to develop the official client. More power to that person if it happens. I hope you’ll enjoy removing features from your client and making space for ads.

Me, I’ll keep making Spaz, and improving its interoperability with other microblogging systems like the StatusNet-based Identi.ca. I’ve never made money on Spaz, and I like it that way — it keeps me focused on doing the right thing, not what will improve my financial position.

Luckily I can do that, but not everyone can, and those webOS developers who rely on their Twitter apps for income would be well-advised to consider whether their want to tie their success to a single company anymore — a company with which they have no financial relationship, and one that has clearly stated their intent to control the end-user market.

I’ve been doing conferences since July of 2006, when I attended OSCON in Portland, OR. Since then I’ve been to 4 or 5 a year, mostly as a speaker (#humblebrag) but sometimes as an attendee plebian as well. They have included joints like:

• OSCON
• Open Source Bridge
• SXSWi
• php|tek & works
• Brooklyn Beta

So I’ve gotten to see quite a range of conferences, from 10,000 people at SXSW, to 150 people at Brooklyn Beta. And after several years of this, I’ve come to the conclusion that the best conferences are:

• Intimate
• Intelligent
• Welcoming
• Focus on sharing and learning from one another

With conferences like this, there’s a lot less separation between speaker and attendee, which I like a lot. I personally LOVE jabbering with anyone who wants to hear me, so I love it when attendees come up and ask questions or share their own experiences with me. And this is a LOT easier at smaller conferences that actively encourage this kind of atmosphere.

Last year, I attended two conferences that met those criteria for me: Open Source Bridge and Brooklyn Beta. Both of them were small, volunteer-driven, not profit-motivated, and intimate. The people who attended were across the board there because they love what they do. They love making great things, sharing what they create, and sharing how they create. And that’s why everyone was there.

So I am very excited that some dedicated folks are trying to bring this kind of experience to the PHP community. The PHP Community Conference on April 21-22 in Nashville, TN is going to be an intimate, friendly, intelligent conference for folks who use PHP. You’ll learn new stuff about a variety of topics, from technical PHP issues to open source community building.

Plus, how often do speakers like Rasmus Lerdorf, Andrei Zmievski, Lorna Mitchell and Terry Chay come to Nashville? For once you can attend a top-notch PHP conference that isn’t on the west coast or Chicago.

I’m speaking as well, but what I’m most excited about is being able to learn and share with other folks who love building things with PHP. I’m confident that this will be the best PHP conference of 2011. And I hope you’ll be there so I can meet you and talk about the awesome stuff you’re doing.

This year, while doing taxes, I put together numbers on the out-of-pocket costs for maintaining Spaz. These include VPSes on Linode and Rackspace, and paid accounts on lighthouseapp.com. As I posted on Twitter:

Since folks were asking, I received $353.84 in donations in 2010 vs the ~$1700.00 expenses.

I’ve never deluded myself into thinking the Spaz Project was even a break-even proposition: I make enough money in my day job to put some into Spaz, and I never expected to get it back. It’s fulfilling for me and worth the investment to provide a transparent, open option for microblogging users.

Still, many folks in the webOS community have encouraged me to consider putting out a pay-for version of Spaz that people can purchase as a way to support the project. I wasn’t really comfortable with just putting out an identical product like that, but I think I came up with a reasonable value-add: additional themes.

Most users don’t really care about additional themes in an app, but some people LOVE them. I’m one of those people. I’ve always intended to put out Spaz with multiple themes, but work on adding features and improving performance have had higher priority, so I never got around to implementing it.

Recently I finally finished up the theme switching code, and was able to create a new theme. I informally put out a beta with this theme, called “Clean.” I also received a theme from Spaz contributor Will Honey and Bee Rad that mirrors the look of his awesome new audio app Koto Player.

So, my idea is to release a Spaz webOS “Special Edition” with at least 5 new themes (so 6 total, including the default “Dreadnaught” theme). This would be a pay-for download in the app catalog, probably for $2-3. Note that motivated individuals would be able to download and integrate themes themselves if they so desire, and all contributed themes in the Special Edition would be under a liberal license that’s compatible with Spaz’s “New BSD” license.

In addition, I will donate 50% of the revenue from the Spaz webOS Special Edition to @webosinternals. Their tireless work has made the webOS developer community the most open, transparent, and fun in mobile dev. We need to support them so they can continue to be awesome.

One issue that will come up with having multiple versions of Spaz is cross-app launching integration. Apps in the catalog must have unique IDs, so the Special Edition will have a different appid than the “regular” Spaz. I’ll probably put out a simple code snippet that checks for each one, so app devs don’t have to manually try to support all three — that would suck.

If you’re interested in making a theme, all the info is available at help.getspaz.com.

So I’ll admit I sat through the entire event on two liveblogs. I’ve invested a bunch of time in webOS dev, and I really, really like the platform. This event would say a lot about the future direction of webOS. Hitting a home-run with the press would go a long way to ensuring the platform is around for a long time. So I was pretty interested.

My reaction, after chewing on it for an evening, is mixed at best. Some stuff was really encouraging, but vague information and poor, confusing messages continue to plague HP/Palm.

New Hardware demos: (B)

All the tech looks solid. The interaction between devices is impressive. The tablet looks great, the Pre 3 and Veer hit their markets solidly, and all 3 look powerful enough to run webOS properly.

This would be a slam-dunk A if we didn’t get the vague release timeframes that have plagued Palm in the past. “Summer” (in the northern hemisphere) gives us a timeframe between 3-7 months from now. And if we learned anything from the Pre launch, people forget quickly how awesome your stuff looked in a press event a couple months ago. Even on the short end, this seems contrary to HP’s proclamations that “when HP makes announcements, it will be getting ready to ship”. Based on past experience, it’s hard to believe HP/Palm will ship these devices in short order. I’d love to be wrong, though.

Also, no carriers were announced. That’s disappointing, and may indicate problems HP is having getting interest after the poor performance of the Pre and Pixi.

New Software Partnerships: (B)

Solid stuff. Skype is a big one, as is Kindle. Both are key apps that webOS has suffered without. The publisher partnerships are interesting, but it remains to be seen whether the concept apps turn into long-term publishing relationships. If Enyo comes through with its potential to be a cross-platform development framework, targeting an app for webOS will likely make more sense for big name third parties.

Support for older devices: (F)

HP really dropped the ball here. Not only did they go back on a promise to bring webOS 2.0 to the Pre and Pixi, they seemed unprepared with the news. It seems clear that not everyone was on the same page, and some Palm/HP employees weren’t even aware of this. In addition, no clear plan to make it up to loyal webOS users was presented.

This would be less of an issue if carriers had been announced. Folks stuck with a Sprint Pre would at least have a clear upgrade path that gets them on the 2.0 train. For now, it’s hard for them to be optimistic.

My personal experience (which might get me in trouble for saying, but c’est la vie): webOS 2.x runs pretty well on the Pre Plus. In some ways, the apparent performance is superior to 1.4.5. I’ve heard it runs poorly on the original Pre, though.

Developer Info: (D)

I was surprised at how short the developer presentation was last night. Enyo is exciting, no doubt – it’s a very solid framework that is far more flexible than Mojo, and allows for much better development workflows & utilization of superior dev tools.

So that’s awesome, but it also means that if you’ve invested a lot of time in Mojo dev (like me), you can just toss that out. There is no upgrade or conversion path. It’s completely different, and you’ll be writing your app from scratch. And whether Enyo can run on 1.4.5 devices (packaged with the app itself) is up in the air, so if you want to support the users you have now, you now have two codebases to maintain.

@webosinternals on Twitter asked a lot of questions last night about dev topics that remain unanswered. I’ll c+p here:

• “No word on app catalog going global at the developer event?”
• “No word on allowing hybrid apps into the app catalog at the developer event?” (was answered via Twitter by @unwiredben)
• “No word from the PR folks about the 2.0 OTA broken promise at the developer event?”
• “No word on how the palm profile works on multiple devices and the effect of that on app sales at the developer event?”
• “No word on the fate of the mojo push messaging service at the developer event?”
• “No word on whether HP is going to sell these new devices in other countries, or whether the release date hinges on US carrier acceptance?”

Even worse, devs I’ve spoken with expect to be let down by HP/Palm – they expect to get unclear, vague answers. Or silence.

Fundamentally, I have to wonder how much effort HP is putting into webOS dev relations. I’ve dealt with the folks there and they’re stand-up people, but my general impression is that they’re hamstrung and unable to communicate clearly to webOS devs. This is the time dev relations needs to be at its strongest, most forward, and clearest. Making folks rely on casual Q&A at social events, or catching Twitter posts is not how it should be done. If HP really wants a top notch dev program, they need to step up and fix this ASAP, or risk alienating their dev core.

If HP can get their communication problems sorted out and start being what I’d call “aggressively transparent” with its development community, I think we’ll get back on the right track. Here’s hoping.

Please read Alex’s original post, if you haven’t. What follows are some thoughts in response to his post.

• These are all native OS X apps:

  • Dress Assistant
  • Time Machine
  • Twitter for Mac

  I also think they all fly in the face of UX consistency within a system GUI, which I think is one of the things people bitch about with non-native apps.

• The definition of “native” is really fuzzy here. it seems like you mean “uses the GUI toolkit that ships with the OS.” By this definition, though, I’d argue that many popular OS X apps are not “native,” even though they’re Cocoa apps. On Linux, Gnome and KDE apps are both “native,” but they certainly don’t look the same.

• Some of your examples of people wanting native apps are people simply liking an app better because it’s designed better, and provides a consistent aesthetic with the rest of their desktop. That can and is often accomplished independent of the SDK you use. “Native” is not in any way synonymous with “better,” but lots of people toss it out there as if the argument is so obvious, it needs not be explained. It’s a lot like saying “it scales.”

• Cross platform and “native” aren’t necessarily mutually exclusive. It’s harder, yes, but not impossible. there are tons of variables involved, and I think you’re oversimplifying a pretty complex problem.

• Cross platform is not, by definition, user-hostile. It can be harder to file off the rough edges, depending on the dev platform and the application, but I think that’s a matter of UX effort.

• IME, “Native” UIs matter way less to users on mobile. Like, unless it looks like a fucking turd and totally nonfunctional, most users don’t care. Is it relatively smooth to navigate? Bonus. Spaz webOS is, from what I can tell, probably the most popular Twitter client on webOS. Why? Because it’s free. You know how many of my users have praised it for using “native” widgets, for the most part? Like 4, and they are all ultranerds.

• Many (most?) of the AIR apps I’ve seen really should just be web apps, because there’s no great benefit to them being desktop apps.

• Why are we okay with using some web apps if it’s such a huge issue? I prefer to use Gmail’s web interface, for example, and I prefer to use Google Reader in a SSB — although with a custom theme. Is it just that my expectations are different?

• I think for many teams, like the one you mention, the choices are probably these (pick one):

  1. a really strong web app (that might not support some browsers)
  2. a cross-platform app based on web tech (devs can use existing skills)
  3. a native app for a single platform — probably not OS X.

  Which do you choose? I guarantee you that for a company like Pandora, it does not make financial sense to do native Windows and OS X clients. Folks who 1. care and 2. would pay are grey-bearded unicorns in the grand scheme of things.

• So why don’t devs want to do native apps? I’d argue it’s because it’s too hard, especially when you need to support multiple platforms with widely varying capabilities. If you want better integration with the rest of the devices, make it easier for the people driving new app dev to do so. Asking them to jump from JavaScript to ObjC is not something most will swallow, and the trend is not going to reverse back to devs doing lower-level coding. Some types of applications will always require it, but many (most!) won’t. A high-level language like JavaScript (especially with the work that’s been done to speed it up) with hooks into a fast GUI toolkit (not the DOM) is, I believe, where we should be headed.