Posts in My Projects

Wednesday, June 30, 2010

Contribute to Spaz webOS, Get a Free Palm Pre Plus

Palm Pre

Our move to using oAuth for authentication in Spaz is going well. Many people have stepped up to help get the SpazCore libraries working, and Spaz Desktop has been updated to use the new authentication methods, both in the 0.8 branch and master.

However, Spaz webOS still hasn’t had work done on it to get oAuth working. July 16th is the Twitter Basic Auth cutoff, so we don’t have much time.

Here’s the big news: Palm has donated Palm Pre Plus phones for AT&T for me to GIVE AWAY to the top 3 contributors to Spaz webOS from now until July 12. That’s the day (I believe) we need to submit Spaz webOS to Palm for review, so it can be ready by the 16th.

So, you want a free phone? Get your ass in gear. Download the SDK now: http://bit.ly/duAHNg

To get through Palm’s review process, I believe we need to submit by July 12th. So before then, two things need to happen in Spaz webOS:

  • Twitter accounts need to use oAuth to authenticate, using xAuth to exchange username/password for auth keys initially
  • Image uploaders need to use oAuth Echo to post

We’ve already accomplished this in the Spaz Desktop 0.8 branch, so doing it in webOS is very doable. Whether it gets done in time is up to you. I am on Twitter, available via email, and in #spaz on irc.freenode.net regularly to answer any questions.

Palm has been a major supporter of open source, and Spaz is (AFAICT) the only open source microblogging client available on the platform. Help me keep it going, please.

Posted in AIR, My Projects, JavaScript, jQuery, Spaz, webOS by funkatron on 06/30 at 12:00 PM
(0) CommentsPost a comment

Thursday, April 22, 2010

Building the Future of Spaz

1975: And the Changes To Come

Spaz has been around a long time: since early 2007, which I think makes it 77 in Internet Years. It’s been a while since I started playing with the Twitter API in RealBasic, and later under AIR after I saw the Pownce desktop client and wanted to make my app look cool like it.

A lot has happened since then. A lot of cool stuff with Spaz, and lot of cool stuff for me, and a lot of sometimes cool and sometimes not so cool stuff with Twitter. Now we have a desktop client, still on AIR, and a native mobile client for webOS. Spaz isn’t SUPAR POPULAR, and it’s not proved to be anything but a giant time and money sinkhole, but it’s been a very fun ride.

Through all of this, Spaz has stuck with open technologies: JavaScript, HTML and CSS. We’ve done so because we’re dedicated to true openness and transparency. The Spaz Statement of Purpose spells out the project’s reason for being. And in the light of Twitter’s moves to make the microblogging client scene more of a closed monoculture1, the significance of Spaz as a counter to closed technologies is greater than ever.

After some recent events – a big career move for me, some horseshit policy changes by Apple, and some disappointing moves by Twitter – I decided we needed to assess where Spaz is headed. So, like any good open source project guy, I went to IRC: I called a meeting on Freenode in #spaz. Turnout was encouraging, and we made some important decisions.

Here’s what’s going to happen:

Most urgent: implementation of OAuth/xAuth by June 1

In June, Twitter is shutting off HTTP Basic Auth support. For client apps to function, they must start using OAuth or xAuth. Spaz Desktop has been approved to use xAuth, an OAuth variant where the user enters their username and password, and the server exchanges these for an OAuth access token. This means we can support a more typical user experience, but don’t have to store credentials anywhere — we just store the access token.

Earlier this week I added support in the SpazCore Twitter library to authenticate with an OAuth access token instead of Basic Auth. This should allow apps using SpazCore to use either Basic Auth (for systems that still support it, like StatusNet) or OAuth/xAuth. Much more needs to be done, though, to get Spaz Desktop and Mobile ready.

Short term: get Spaz Desktop 0.10 out the door in June

The Spaz 0.9 branch, which is the development branch for 0.10, has been stuck in dev for far too long. The codebase has been refactored considerably, and a number of cool features either have been implemented or are planned, but it needs to actually get ready and usable. We need a push, and assistance from a number of motivated folks who are willing to put the time in. Our 0.10 milestone entry on spaz.lighthouseapp.com outlines the various tasks that need to be completed.

Longer term:

1. Move Spaz Desktop from AIR to Titanium Desktop by October 2010

I’ve been a big fan of Appcelerator’s Titanium for a long time, and their Desktop product offers a compelling alternative to AIR for these reasons:

  • Titanium is a true open platform: open source with a liberal license
  • JavaScript is fully a first-class citizen in terms of language support2
  • Titanium allows leveraging Ruby, Python or PHP
  • Better Linux support
  • Web Worker support
  • Full interaction with external processes
  • Native installers for each supported platform that includes the runtime

The big knock I see against Titanium is poor documentation, and that’s something I really hope Appcelerator works to rectify.

All in all, though, Titanium is a better fit for us, technology and philosophy-wise. Porting to Titanium is probably about 20 hours of work as it stands now.

2. Start development of web-based mobile/tablet client

I really like powerful mobile devices, and I really like multitouch tablet devices like the iPad. What I don’t like are the restrictions being placed on developers by companies that refuse to be transparent about their policies. I think the way around that is to make a great mobile/multitouch web app.

A web app will also make Spaz available to all devices with mobile webkit browsers. It would run on Android, Palm webOS, and likely BlackBerry and Nokia devices (I’m not super familiar with those, but I believe they have webkit browsers now or will soon).

While Spaz will be a hosted web application, it will still be FOSS, and anyone would be able to get the source and set up their own install. In this sense, it would be an interesting complement to StatusNet.

If folks are motivated to create native clients for their preferred devices, that’s definitely a possibility — either with a wrapper system like PhoneGap, or a native UI system like Titanium Mobile. It just would not be, at least initially, a primary goal.

What about webOS? Not sure right now. It requires dedicated folks who will keep up with it. Nick Carter has helped a lot, but we need more help, and/or we need to leverage the stuff we do in the web-based mobile client. That may necessitate moving away from Mojo as a framework, though. Palm’s dev relations team has indicated that they are interested in making web apps first class on their system, though, and I suspect they’ll have some interesting stuff to make that possible.

3. Target StatusNet as a top-tier service

StatusNet has always been a favorite service of mine. They match our principles, and I think Spaz as a FOSS client and StatusNet as a FOSS service complement each other well. StatusNet needs better clients, and I think Spaz is decently positioned to be a part of that. So, I think we should create a StatusNet API library to support any StatusNet-specific features available, and implement support for this in Spaz.

We should also consider other services, like Facebook and RSS feeds. The first step would be developing SpazCore libraries for these.

How to help

If you’re interested in helping with Spaz, here’s what you can do:

You don’t have to be a programmer. We will work with you to learn new skills. All you have to be is interested in building something cool with us.


  1. Reducing choice is one of the reasons (maybe the primary reason) for Twitter’s purchase and repackaging of Tweetie as The Official iPhone Client. As Tweetie’s source is unlikely to be released, it does seem that we’re reducing choice and becoming less open/more closed. That isn’t necessarily their goal, but it’s a consequence. 

  2. Adobe has, as an organization, not demonstrated that they consider JavaScript as important as Flash within AIR. Feel free to search this blog to find more on the subject. 

Posted in AIR, My Projects, JavaScript, Mobile, The Web Problem, Spaz, webOS by funkatron on 04/22 at 10:57 AM
(5) CommentsPost a comment

Saturday, April 10, 2010

My Friend Twitter

Molly: A Dog With A Lot On Her Mind

This is going to make two blog posts in a row that are “off the cuff” for me. This one particularly so, because it involves a lot of emotion, and not a lot of certainty. There are some arguments to be made, but most of it is about how I feel. That’s something that’s hard to justify logically; it just is.

I’ve been frustrated with Twitter regarding how it relates to its developer community for several months now. My perspective might be different from some folks, I think, because I’ve been a part of that community for a long time. The Twitter Dev Talk Google Group shows me as joining on March 15, 2007. I remember being proud that I was asked to be a moderator for the group; it felt good to be both friends with some folks at Twitter, and a “Friend of Twitter” as someone from the company referred to me and a few others once.

It felt good because Twitter really seemed to make an effort to be open and transparent with their development community. We were part of what helped them get off the ground — not the biggest part by any means, but a part. At the time, the vibe I got from Twitter was that they were a group of people trying to build Cool Stuff. I liked that because I like building Cool Stuff too, for the sake of building it. It felt like it was being built by guys who had the same passion for making things that I do. I would hear that they really liked what I was doing in creating an open source, multi-platform client for Twitter; that it was important to have options like that.

Over the years I often found myself defending Twitter’s API team when folks would air their own frustrations. Some of those frustrations were valid, and some of them were based on really unrealistic expectations. I often said that it was foolish to build a business on top of Twitter, because (except in very rare circumstances) there was no guarantee of any service level of API feature permanence. Things were often pretty spotty back then in terms of uptime and performance; that frustrated a lot of people. But I had their back, ya know? I was a Friend.

Things grew, and things changed. That’s not really surprising at all. I’m happily naive of most things related to VC investment, but I suppose to keep up with all the traffic Twitter got as it became more popular, they needed money to pay for services and hire people. If you aren’t making any money, you need to ask people to give it to you. And now you have to worry about what they want, too.

In the past year or so, it felt like I was seeing a shift in how Twitter related to its developers. People move around in a big company, and that was surely part of it – I didn’t know all the New Dudes. And I had really withdrawn from the dev mailing list, because I was tired of dealing with spam and talking about uptime and downtime and social graphs and pagination limits.

But it got weirder when they announced Chirp, their “official developer conference.” Doing this event made sense, but I felt like some of their choices about who was speaking didn’t. I didn’t see guys like Cameron Kaiser, Abraham Williams, Marco Kaiser, JazzyChad, or Damon Cortesi listed as speakers. Instead, I saw execs, pundits, and VC investors.

Now I’ve been to a lot of developer conferences, both as an attendee and a speaker. And I’ve never seen a speaker lineup so devoid of actual developers. Anyone who knows me, knows that I generally believe pundits and VC investors (and execs to some extent) to be moronic at best, and pure evil at worst — corrupting the purity and passion for Making Cool Stuff.

Then there was how some stuff was handled. When Chirp was first announced in late January, before the speaker lineup was finalized, I inquired about speaking there myself. A friend suggested I talk about my experiences as an open source dev, and this seemed like a pretty darn good idea – I wanted to talk about what I’d learned, what motivates us as developers, and how we define success. So I made an official inquiry, and was told by a Twitter employee that they’d look into it and get back to me soon. I didn’t hear anything for a couple weeks, so I sent a follow-up, and was told that things were filling up on the main day (well, that’s why I asked early!) but that there might be an unconference opportunity. There’d be a public announcement about it in March.

Well, the conference is on April 15th. Not knowing until March what might happen is just not enough time to plan. And to buy a $450 ticket, and then hotel in SF, and then airfare; I just couldn’t afford that. Of course, it turns out that cheaper, hackday-only tickets would be made available, but these weren’t released until March 30, 15 days before the conference1. Far too short notice, and by this time the speaker lineup described above was set, which indicated to me that this wasn’t a conference for developers like me.

So in this, I saw a pretty big chasm between where I was, and where Twitter was. Before then I hadn’t quite realized what it was like, but this kinda dumped on me like a ton of bricks. Getting a bit of the runaround hurt my ego, for sure, and that’s part of it. I don’t really think that’s a good reason to get upset, but I did feel like I had a longstanding relationship with Twitter, and through this, and the way Chirp was being presented, I didn’t feel like this was the same organization I’d interacted with for the past three years.

And, well, it wasn’t. They used to have 6 employees, and now they’re over 140. Duh.

So with all that, then we have Twitter dropping an enormous bombshell yesterday on their dev community, by creating official clients for both BlackBerry and iPhone. Twitter had done a few things before to add services that had previously been handled by third parties, but in general they’d had a very hands-off approach with the dev community, sticking with their core features and letting developers handle stuff like url shortening, photo uploading, and — most significantly — all non-web clients. Twitter has enjoyed a very diverse, very organic community of applications and services. Client apps that serve as primary user tools for interacting with Twitter are a very large part of that community. Twitter’s moves in that space have suddenly and dramatically changed the playing field for all of them.2

There was no warning, and there were no apologies. No statements made to developers that Twitter knew this was going to impact a lot of them; no attempt to unruffle feathers or explain how this was what Twitter needed to do as a company. We did get a couple notes on the dev list, but they could be summed up as follows: “it happened, now find other things to do.” That’s what angered me more than anything last night.

This really isn’t about my own client, Spaz. Spaz is not popular, and I doubt even having a directly-competing Official Client on desktop or webOS would impact its numbers – folks choose Spaz because they like it, and if they don’t that’s fine with me. Spaz exists as an alternative to closed source, commercial apps, and it’s even MORE important now that it exists, I think.

I guess it’s about respect. It’s about a relationship I had, and I think many of us had, with Twitter, that doesn’t seem to be there anymore. And that’s frustrating, and disappointing. But mostly I guess it’s just sad.


  1. Curiously, this wasn’t announced on the API announcement mailing list or the twitter dev mailing list; in fact, there was very little information about Chirp posted there. Far more information was available on sites like TechCrunch. This made me wonder further at whom this conference was aimed. 

  2. It would be naive to expect Twitter to not move into other platforms it decides are key to its experience. Or in any other services it decides to do internally. This is a very big reminder that we can only count on something for the term of the contract, and few of us have a contract with Twitter. 

Posted in My Projects, Development by funkatron on 04/10 at 12:42 PM

Tuesday, December 29, 2009

An Open Source Milestone: Spaz webOS 1.0

President Wilson at First Regularly Scheduled Airmail Service Ceremony

I really don’t like to toot my own horn. Well, actually I do, but I’m also embarassed by it, so writing the title for this post was a bit painful. Nevertheless, I do think it’s accurate: Spaz webOS 1.0 is now available in the Palm App Catalog, and that’s a significant milestone for the project, and for open source on webOS.

I first started playing with webOS a year ago, over Christmas break at my day job. In June, Spaz webOS was in the App Catalog at release, and back then I was quite proud of the fact that we’d been able to ship a truly open source, transparent app on the first day of a new platform. And now, a year since I first cobbled together a Hello World in Mojo, Spaz has reached a reasonable level of maturity – at least as mature as something called “Spaz” will ever have.

Originally I was going to call this release v0.6. I am shy of using 1.0 because I am painfully aware of all the flaws in my software, and it certainly never feels “done” or “ready” to me. However, a recent discussion with Keith Casey led me to think more seriously about using the “1.0” designation – Spaz webOS is very much Safe To Use, but a pre-1.0 version might make some potential users to think otherwise.

And potential users are a bit more of a consideration now, because in a couple weeks (probably the week of January 11), Spaz webOS will start charging $2 for App Catalog downloads in the United States. This is something I’ve been planning for a while, but it’s still stepping out a bit, both for me (I’ve never charged for software before) and for open source software in general. To be clear, here’s how it will work:

  1. Spaz webOS will cost $2 to download in App Catalog markets that support payments. Right now the only market that supports payments is the US. It will be free in all other markets.
  2. Spaz will still be completely open source. The full source code will always be available.
  3. I will not stop users from packaging and installing Spaz webOS themselves. In fact, I encourage it! I always need more testers, designers and developers. Hacking, patching, and messing with Spaz are fully endorsed. If you can’t help in one of these ways, consider donating to the SpazCore project.
  4. Revenue made from paid App Catalog downloads will be used to support development and offset equipment and hosting costs. I’ve never made any money from Spaz, and despite some generous donations over the past couple years, I’m still well in the red. I don’t do this for the money (obviously), but lightening the burden and compensating myself and other people who have given their time for Spaz is reasonable, I think.

Another thing that isn’t changing is the principles that guide the Spaz project. I wrote up a statement of purpose a while, back, which I’ll replicate here:

  1. Spaz was built for the sake of building it. It is not a means to an end. However, creating it has had several good consequences.
  2. Spaz demonstrates that making things is good, and sharing how you make them is better.
  3. Spaz is a necessary counter to closed, hidden technologies. Spaz must always be open.
  4. The value of Spaz does not lie in the judgements of others, but in the process of building it, and the enjoyment derived by those who use it.
  5. We welcome anyone who wishes to participate in the Spaz Project with open arms, as long as they understand and respect the purposes of the project.
  6. The Spaz project values clear and open communication between participants.

This is how I think software should be made. If you agree, I hope you’ll consider supporting what we’re doing in a way you see fit. We always need help!

Thank you for making Spaz far more than I could have imagined.

Posted in My Projects, JavaScript, jQuery, Mobile, Spaz, webOS by funkatron on 12/29 at 05:01 PM
(0) CommentsPost a comment

Friday, July 31, 2009

Results of Spaz webOS Pricing Survey

Smell the Money

Yesterday I put together a short survey that asked some questions about what people would be willing to pay for Spaz webOS. It’s been my plan all long to change a small fee (when possible — you can’t yet in the Palm App Catalog) for Spaz webOS, and use the revenue to support further development. Since I believe strongly that Spaz must be an open, transparent project, here are the results so far from 145 responses:

…and here are some comments on the results:

What is the most you would pay to purchase Spaz in the Palm App Catalog?

From doing a little math on this, it seems like $2 is the optimal price point in terms of revenue generation, followed closely by $3.

What 1-3 features would make you more likely to purchase Spaz in the app catalog?

First off, lots of people ignored the request to pick 1-3, which isn’t surprising (you couldn’t set a max number of choices). That being said, 4 items were far and away the most popular choices

  1. Faster Performance (56%)
    Spaz does seem to perform slower than comparable apps. Part of this is because we use a combined timeline, and therefore it takes longer to build results. We also initially requested a LOT more messages from Twitter at startup than comparable apps, and processing them takes more time. We’ve lowered the default numbers (you can up them in prefs), but it’s still higher.

    We’ve also had some CPU usage issues. Those have been dramatically lowered since initial release, but there’s probably more we can do. This shows up especially while processing new messages.

    The other issue I think this response refers to is sluggish scrolling speed. This one perplexes me a bit, but I’m guessing we may be running into performance limits of the Pre’s webkit renderer. We’re going to do some experiments with stripping out CSS styling and markup on our timelines to see if the scroll speed improves in either case. If so, we will need to modify how we style and/or build the markup for our timeline.

  2. Direct uploading to image hosting services like Twitpic (54%)
    This was really close to #1, which tells you how badly the lack of direct file upload APIs in webOS is hurting devs. What’s most frustrating is that the email-based workarounds actually took longer to implement than direct uploads would — we already have plenty of code from the desktop app we could have adapted. Here’s another plead to Palm to please expose the file upload APIs to 3rd-party developers ASAP!

  3. New message notifications even if the app is closed (42%)
    I’ve heard this a lot. I kind of assumed people would just leave an app open if they wanted it still running, but how I use things isn’t necessarily how others will. One consequence of implementing this will be reduced battery life, so we will need to be careful about it. Note that Palm recommends not doing background network requests more than 15min per hour. We won’t exceed that if and when we do implement this.

  4. Facebook support
    This one kinda surprised me. I only added it as a bit of an afterthought, but I suppose it makes sense, especially since there’s not a good native Facebook app for the Pre. I actually know very little about the Facebook API and am not super duper excited about building for their walled garden, but if someone wants to build a SpazCore lib for it, we’ll probably implement something.

Also of note were some of the “Other” responses. They included:

  • “More optimized code (use less cpu!)”
    This falls under Faster perf, fo sho.

  • “tweet with google maps link to current location”
    This is on the list to get implemented

  • “hit user pic in timeline to @reply”
    We’re going to implement something that lets you do actions on a message without going to the detail view. Kinda sucks right now.

  • “low power consumption”
    The way you do that is to make fewer network requests. This responder will not want background checking, then 8)

  • “more identica/laconica support”
    I’d like to see this happen too. If you want it to happen, volunteering to code a Laconica-specific API (or somehow scraping up funding to sponsor development) would help us out a lot. We don’t have time to do much with non-Twitter APIs right now.

  • “Livejournal support”
    Seems like a microblogging client isn’t a good match for this, but if we add ping.fm support, you should be able to post to LJ through that. As for reading LJ posts, I think RSS feed support would allow that.

  • “It needs a non-offensive name before I would purchase it anywhere”
    We had to get one of these, although I’m surprised we only got one in nearly 150 responses. It’s not changing. Read the FAQ. Sorry!

  • “Since last 2 updates it really drains my battery. LOVE it’s look and feel though.”
    These are the kinds of things we need to get reported to us. Can’t fix it if you don’t report it. Go to our support site and file an issue, please. Please make sure Spaz is the only culprit involved, though.

  • “Direct blip.fm support (streaming via clicking a link)”
    That would be interesting. If someone’s willing to look into it dev-wise, I have no issue with it.

  • “Why? When tweed is free. And there’s more twitter apps to come.”
    No applications are allowed to charge for apps at the moment. That will change in the future, though. I wouldn’t assume Tweed will remain free, but I have no idea what their plans are.

  • “Copy and paste”
    Talk to Palm, dude. 8)

  • “Change the name!!!”
    Okay, maybe we got another one, but this didn’t claim I was making fun of physically or mentally disabled people. Sorry, not changing.

  • “None”
    This surprised me a little. You could have written “shits money and cleans my house.” Surely that would make you more likely to buy it, yes?

Posted in My Projects, Development, Mobile, Spaz, webOS by funkatron on 07/31 at 01:40 PM
(7) CommentsPost a comment
Page 1 of 9 pages  1 2 3 >  Last »