funkatron.com

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.

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 monoculture¹, 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 support²
• 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:

• Read our Statement of Purpose and Diversity Statement
• Read “How Can I Participate in the Spaz Project?”
• Talk to us about what you’re interested in doing
• Make a commitment to putting in a certain amount of time every week. Even a half-hour a week helping with user support is a big help.

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.

I am super proud to announce that Elizabeth Naramore has agreed to become Support Lead for Spaz. Liz is an accomplished PHP developer and a tireless community organizer for open source. I am honored that she’s chosen to help Spaz.

If you are interested in helping with user support for Spaz, please check out the Spaz User Support Team Google group, and tell Elizabeth you want to help.

I’m really happy to announce that Ron Devera has agreed to become the UI Lead for Spaz Desktop.

Spaz has been a very informally organized project since I began it back in spring 2007. A number of people have contributed important pieces of code, and support was primarily handled by @kibitzer for over a year.

So why a title and all that? It seems like a good idea at the moment. I’ve been trying to establish more structure in the development and support efforts of Spaz to make it easier for others to contribute, including Lighthouse (development coordination) and Tender (user support) sites where volunteers can see who needs help and what needs to be done. Adding an “official” team member is a part of these efforts.

Ron is a smart, talented developer, with a diverse set of skills, and he’s demonstrated an ongoing commitment to making his contributed “Leopaz” theme very high-quality. He’s a strong JavaScript, Ruby and HTML/CSS dev, and his attention to detail has made Leopaz the strongest theme Spaz offers. I’m very excited about having him a part of the team.

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.