Ben Goodger, writing about Chrome:

Autoupdate is one of Chrome's killer features. It is magical because it continuously updates an entire development platform invisibly, frequently. Supporting it has driven how we structure our development processes. It was also one of Chrome's first features. Delving back into project history long before we launched publicly in 2008, the autoupdate project was one of the very first we started working on. The idea was to give people a blank window with an autoupdater. If they installed that, over time the blank window would grow into a browser. And today, some five years after our autoupdater started updating a mostly blank window that could barely load webpages, it is now an engine for delivering an incredibly sophisticated web technology platform onto our users' computers, which in turn allo

If I could start building ThinkUp all over again, I would've built its autoupdater first. No app should annoy users with the work of downloading and installing a new release; it's a big reason why app stores are a better way to get software. Speaking of, you should download ThinkUp beta 15 right now.

God forbid that they even pay lip service to the notion that users might perhaps be given options—for then they might start to use them, and then where would we be? Sheer anarchy! Far better to reduce everything to a single dumbed-down inescapable standard, relentlessly mediocre and devoid of any color or possibility, like a tapioca straitjacket.

I haven't used Facebook Comments, but every day I wrestle with whether or not ThinkUp should have yet another configurable user setting, or if the software should just decide what's best by default. The next time that comes up, I'm going to think about that tapioca straitjacket. (Worth noting that Evans does admit Facebook Comments reduced trolling at TechCrunch, and that if he were setting up a new site he'd use it again.)

At Lifehacker, my original vision was to create a new kind of tech blog, one that wasn't yet another "boys worshipping tech toys" site, one that was helpful, friendly, and welcoming versus snarky, sensational, and cutting. (That was no small task in the Gawker-verse, and I learned much in the process.) Today at ThinkUp, I have a similar goal. We encourage contributions not only by women, but open source newbies and non-usual suspects of all stripes: designers, user experience experts, writers, students, and enthusiastic users. We explicitly identify inclusiveness as one of the best characteristics of our small, up-and-coming community. Still, uptake is slow, the on-ramp steep, and for me, it constantly begs the question: what we can do better?

That's why an essay by UX designer Vitorio Miliano, Designers and Women in Open Source, caught my eye. Miliano theorizes that there aren't many designers in the open source world for the same reasons there aren't many women: because open source communities alienate non-coders and newbies by design. He writes:

I believe the problems with open source not being able to handle non-programmers in their projects is the same problem as the rampant sexism: open source culture is not feminist. Feminism is fundamentally about equality for everyone, not just women, and designers of any gender are just as alienated as women programmers, because it’s not an equally welcoming environment. There’s no perceived value in open source for mentoring, facilitation, disciplining of unruly users, training of newcomers or non-technical users, etc., which are needed to support both designers of any gender and women in any role.

That's a punch in the gut for OSS leaders who work hard, often in their spare time, to create a democratic process and collaborative workflow for total strangers located around the world to create something as complex and technical as software. (Especially those of us who identify as feminists.)

But Miliano's right. And as far as I can see, it's up to OSS leaders to work even harder to redesign their communities to encourage diversity instead of prevent it. Because it helps me to think aloud and write things out, here are some approaches we've implemented, discussed, or are considering at ThinkUp.

Welcome Wagons, Mentors, Conversion Rates, and the Power of Nice People

The best part about working on an open source project is that you're not just building a software application; you're building a community. In addition to making first-class software, ThinkUp's goal is to be the ultimate "gateway project," a friendly, accessible virtual neighborhood that people want to live in and build up, especially if they've never been a part of OSS before. One of my main metrics for measuring our success is how many community members' first-time OSS contribution happened at ThinkUp. We love handing out the Nerd Merit badge to first-time contributors.

Converting a newcomer into a contributor starts with a warm welcome.

At Lifehacker I learned something important about creating a productive online community: leaders set the tone by example. It's simple, really. When someone you don't know shows up on the mailing list or in IRC, you break out the welcome wagon, let them know you're happy they're here, show them around the place, help them with their question or problem, and let them know how they can give back to the community. Once you and your community leaders do that a few times, something magical happens: the newbie who you welcomed just a few weeks ago starts welcoming new folks, and the virtuous cycle continues.

We're still relatively small, but at ThinkUp we've done a good job of this so far. After two years, we pride ourselves on two things: 1. newbies are welcome, and 2. while we've had passionate conversations, we've never had a single flamewar or ego battle on our mailing lists.

Mentoring new contributors is also a powerful way to grow and diversify your community, and create long-term, loyal contributors. After last year's success in Google's Summer of Code mentoring program, we plan to do more mentoring/internship programs for new coders at ThinkUp. Creating bonds between new coders and veterans strengthens the community and attracts even more like-minded contributors who enjoy collaborative learning on a common project.

For coders, the path of promotion from user to contributor is clear-cut, but the on-ramp is not as obvious for non-developers. An early thread on ThinkUp's mailing list, subject line The frustration of a non-developer, began our community's clarification of what, exactly, constitutes a contribution to the software. Turns out, it's not just code.

Clarifying and Encouraging Non-Code Contributions

For programmers, the process of contributing to an open source project goes like this: you download the source code, you change the source code, and then you submit your changes to the project maintainers in the form of a patch, and if that patch gets accepted, your contribution shows up in the software. Done.

What's not clear is how people who don't code contribute their skills and expertise to making OSS software. Because it's not clear, they don't, and the software looks and feels like it was designed by engineers, for engineers—because it was.

At ThinkUp, there was a time that I was so focused on perfecting the right git branching strategy, I forgot that contribution does not always equal code. This is an area where we can still improve, because there are so many different ways non-coders can and should contribute to the project, including but not limited to:

• Showing up in the IRC channel and welcoming newcomers
• Offering tech support on the mailing list or in IRC
• Transferring knowledge shared on the mailing list or in IRC into the project wiki
• Following up on tech support questions on the mailing list or in IRC with further questions, links, or additional information
• Filing bugs in the issue tracker, or updating existing issues
• Taking screenshots and documenting details of confusing or clever bits of interface
• Recognizing good work by community members; discouraging unwanted behavior; acting like the kind of community member you want to work with
• Tweeting, blogging, or Facebooking about project news, developments, or features
• Hosting, showing up at, or blogging a project podcast
• Pairing up with a project "buddy" to work on an issue and brainstorm solutions
• Mocking up or wireframing interfaces for existing or desired features, even if it means using a tool as simple as Microsoft Paint

Sometimes turning a non-coder into a contributor is as easy as pointing them to a wiki page and asking them to add text about their experience using or troubleshooting the software, like Dan did here.

When an OSS community has a code-centric view of project contributions, not only does community, documentation, and technical support suffer—the software does as well.

Adjusting Community Values: Prioritizing Design and Usability

A well-built software application does more than just function: it's beautiful, frictionless, self-explanatory, and it performs a task and stays out of your way. Still, interface design doesn't get nearly the respect and prioritization it should by typical OSS engineers. (Myself included; this is another area where ThinkUp can improve.)

The solution isn't simply getting more designers and UX experts involved in open source, it's something much more difficult: changing community values around those skills. Miliano writes:

For a designer to contribute to an open source project, there would have to be developers committed to implementing the work, to work on “polish” and “froofy things” instead of “real features” and other “important things.” That’s a hard nut to swallow, and what volunteer project owner will ask all their volunteer contributors to, please, stop working on your pet projects within this codebase and let’s actually cut features and work on UI and usability and design?

When "polish" is a priority, when it's discussed, recognized, rewarded, solicited, and it's a required part of the patch acceptance process, programmers will be motivated to do the work to get it right. The key here is to prioritize design and usability upfront, rather than accept a mess of software with plans to slap a pretty veneer on afterwards. This is been the lesson I keep having to learn and re-learn: design and usability cannot be an afterthought.

Cutting features in the name of usability is an especially sticky wicket when those features were built by volunteers in their spare time, but this is where project leadership steps up.

Design by Committee and the Benevolent Dictator

Feature/option bloat is a common pitfall for all software, but it's especially so for open source software built by a democratic community of self-starting engineers for whom it's too easy to say "I'll just hack up a little button that adds my pet feature and stick it here." Every OSS project has a single committer or team of committers who have final say about what features and fixes get merged into the application. Some projects have a Benevolent Dictator, who has final say on decisions that the community can't reach consensus on. It's the committers' and the BD's role to ensure that end users come first and engineer's pet projects come second.

However, good project leaders don't rule with an iron fist; rather they sell a vision for the software and its priorities to the community so that the community comes to good decisions on its own. When it cannot reach consensus, the BD steps in. Karl Fogel explains:

Although "benevolent dictator" (or BD)is the standard term for this role, it would be better to think of it as "community-approved arbitrator" or "judge". Generally, benevolent dictators do not actually make all the decisions, or even most of the decisions. It's unlikely that one person could have enough expertise to make consistently good decisions across all areas of the project, and anyway, quality developers won't stay around unless they have some influence on the project's direction. Therefore, benevolent dictators commonly do not dictate much. Instead, they let things work themselves out through discussion and experimentation whenever possible. They participate in those discussions themselves, but as regular developers, often deferring to an area maintainer who has more expertise. Only when it is clear that no consensus can be reached, and that most of the group wants someone to guide the decision so that development can move on, do they put their foot down and say "This is the way it's going to be." Reluctance to make decisions by fiat is a trait shared by virtually all successful benevolent dictators; it is one of the reasons they manage to keep the role.

Because an OSS project's BD is not actually a dictator with swift and final say on all decisions, these community decision-making processes can take months and even years. After his logo design was rejected after a year of discussion by contributors to an open source project, Miliano says that on a non-OSS team, the contributors who spoke up wouldn't have had a say at all:

I would wager that as most of the developers of any given open source project are not representative of its end-users, the developers wouldn’t even be involved in the design process in the first place. You can’t design by committee, only take into account the needs of the stakeholders, and if you don’t actually use the software, you might not be at that table. The designer would, essentially, only be generating work for them.

I think there's an in-between here, and at ThinkUp, we're still finding it. We're working with Mule Design to redesign the app's look and feel and interface. While we're only at the beginning of that process, in the kickoff we decided that design by committee was not an option. The community will not vote on a list of design options. Instead, Mule will create a design and sell it to the community at large, citing what they learned about the app from its stakeholder and end-user research. To keep the community informed along the way and encourage buy-in on the process, they'll share what they learned and what they made as they reach milestones. Because Expert Labs funds ThinkUp development, contracted Mule, and acts as ThinkUp's benevolent dictator, there is no question: we will implement Mule's redesign with community buy-in—even if everyone doesn't agree on every single pixel.

Your Community Is Your Best Feature

On the modern web, where far-flung strangers collaborate on things like authoring an encyclopedia and overthrowing abusive governments, it's still too hard for most people to contribute to open source projects. It's ironic, too, because open source collaboration was happening on the internet way before tools like Facebook, wikis, Twitter, and Google Docs existed. It's not for lack of tools, it's because of broken culture. Miliano writes:

Open source platforms are a community in the traditional sense of something you pretty much have to be internally motivated to join. Joining an open source community is closer to joining a church or moving into a neighborhood, and, let’s be honest, these neighborhoods are sexist boy’s clubs with no facility for mentoring, no respect for design, and mailing lists that are 50% dick-measuring contests.

But that's not the way it has to be. If OSS projects do what it takes to welcome contributors of all stripes, not just the usual suspects, they'll produce better software. At least, that's our bet.

Expert Labs is offering a new iPad 2 (16GB, Wi-Fi only) to a community member who makes a significant contribution in the next month and a half. Here's how it will work:

• Developers get 4 weeks to issue a GitHub pull request for a new ThinkUp feature or fix of their choice (by April 6th); plus another 2 weeks (April 20) to get that code reviewed, accepted and merged into master. As always, tests must be included in your patch submissions, and all code must comply with our style guide.
• After all the submissions are in, the developer will post screenshots or a screencast plus an explanation of what the new feature/fix adds to the project on the mailing list. The community will then vote on what their favorite new feature or fix is. With the community's help, Expert Labs' employees (Gina, Anil, and Andy) will determine the iPad winner. 
• The developer who has the feature which was both merged and deemed most useful gets a brand spanking new iPad 2. Expert Labs will cover international shipping, and we'll do our best to order the iPad in your local Apple Store; if not, we'll ship you a U.S., WiFi-only version from the States.

What should you build? Here are a few ideas:

• Create a new new data visualization that displays post statistics, analysis, or information in a useful way
• Create a JSON API for ThinkUp post replies (Issue #565)
• Improve the ThinkUp Facebook plugin so it offers the same features as the Twitter plugin does
• Create a mobile CSS stylesheet to make ThinkUp easy to use on an iPhone or other smartphone
• Create a Bit.ly plugin which stores click count statistics in ThinkUp's link database, and add a list of most-clicked links for a ThinkUp account (Issue #354)
• Create an email invitation system so it's easy to invite people to register on a TU install without having to open registration to all (Issue #42)
• Redesign ThinkUp's user page to use the standard dashboard/post page template (Issue #256)
• Add the ability to see replies from multiple posts in one view (Issue #407)

These are just a few ideas. If there's something else you're inspired to work on, go with it. But remember, to win the iPad you've got to wow the community with your work and be able to sell use cases when you post your submission to the list.

Not a developer? Here are some ways you can get yourself that iPad:

• Make a killer screencast of ThinkUp features or use cases
• Draft new documentation or improve existing pages on the ThinkUp wiki with complete, well-annotated screenshots and clear, step-by-step instructions
• Mock up a new and improved thinkupapp.com which sells ThinkUp and makes it easier for visitors to understand and get started using
• Mock up a new visualization of ThinkUp data

This is our first time doing a bounty like this, so let us know if you have any questions on the ThinkUp mailing list. Can't wait to see April's submissions. Good luck!

Cross-posted to the Expert Labs blog

Watch as a modern PC gets Windows 1.0 installed, and upgraded through every major version up to Windows 7. Not sure what's more amazing; that this screencast is possible today in a VMware virtual machine, or that applications installed in Windows 3.1 still worked through every upgrade to Windows 7, representing nearly 20 years of compatibility. (via kottke)

In the new Google Profiles, I like that you can enter more information about yourself: work history, "words that describe you," brag-worthy facts, gender, relationship status. What I don't like is that a few of these fields have a limited range of possible values, defined in a drop-down list. Before I realized this was worthy of a full blog post, I had a bit of a rant about it last night, which went like this.

The screenshot above is Google Profiles' Relationship field drop-down of possible responses. For me, relationship status is a minefield of potential misunderstanding, because if I select "married," people often assume I'm heterosexually married. If I could answer this question in an open text field, I'd fill in "gay-married." That's how I want to characterize and specify my relationship status, not the overly cutesy and vague "it's complicated," or the doesn't-give-us-enough-credit-for-all-the-crap-we-went-through-to-get-legally-married "In a relationship."

"Why not just choose married?" a few people have asked. That's the response I ultimately (and begrudgingly) chose. Yes: married is married is married. But I like to be specific, because the majority of marriages are heterosexual, so when people know I'm female and find out I'm married, they assume I have a husband. My "married" identity can eclipse my "gay" identity. The fact that I'm legally gay-married in California, one of only 19,000 couples in the U.S., is something I'm proud of, and a way I like to identify myself and my relationship. Isn't Google Profiles' whole purpose to provide a way for me to publicly identify myself?

Same goes for gender, where the drop-down choices are Male, Female, and Other. ("Other" at least indicates that Google is aware gender is not a binary thing.) This should also be an open text field. Gender is not sex. I might list myself as a "tomboy," and I'm not that weird. Regarding the gender field, my friend Mitch Wagner, who is a "regular guy" by conventional definition, asks:

Does "gender" include a spot for: "Cisgendered male but nonetheless often feels alienated and constrained by traditional societal frat-boy/sitcom-dad notions of gender. AND mostly I connect better with women than with men."?

Some might argue that if Mitch entered that phrase into a gender text field it would make search results worse. In fact, it would make them better. That response says a hell of a lot more about Mitch than simply "Male" (and it also confirms to me why I like the guy so much).

Google Profiles (and Facebook) could learn from Diaspora's decision to make gender a text field.

Justifications for drop-down identities

Lots of techie types are quick to justify drop-down identities. Here are some comments I got last night on making gender and relationship status a text field:

As a programmer, I deeply understand the desire for and satisfaction of neatly structured data, and drop-downs make it easier on programmers to get that data. But you should design your product for humans, not databases. Making a great product is more important than making life easy on programmers or advertisers.

Thx, shangle

If there's any company who has the technology to map "garbage data" entered into an open text field to something advertisers can target, it's Google. There's plenty of precedence for this, too. At MetaFilter gender is a text field and its creators are able to determine male or female sex over 75% of the time using a crazy thing called technology. If a tiny indie startup can do that, Google could do the same. They just have to care enough about the users who don't want to choose the most common drop-down options to do it.

Why Google should care

Facebook is king of the social networking hill because Zuckerberg is a great editor with a sharp eye for product. When he was building Facebook, he looked at the leading social networks at the time—Friendster and MySpace—and purposefully exploited their weaknesses. Friendster was constantly down; MySpace was ugly. So Zuck made Facebook's design white and clean, launched it only at Harvard first, and scaled to other universities slowly to keep the site fast, stable, and reliable at all times.

Similarly, to beat Facebook at social you have to look at its faults, and capitalize on them. Facebook's Achilles heel is the how it imposes a certain worldview on its users. On Facebook, you can only "like" something. You can't love it, or hate it, or say it made you laugh, or made you sad or angry, or unequivocally recommend it to your friends, or recommend it with some caveats. You can only "friend" someone, you can't make someone's acquaintance, or say they're an old high school classmate, or the annoying guy who sat behind you in one lecture in college, or an ex-lover.

In her excellent review of the movie about Facebook, The Social Network, Zadie Smith makes the point:

Shouldn’t we struggle against Facebook? Everything in it is reduced to the size of its founder. Blue, because it turns out Zuckerberg is red-green color-blind. “Blue is the richest color for me—I can see all of blue.” Poking, because that’s what shy boys do to girls they are scared to talk to. Preoccupied with personal trivia, because Mark Zuckerberg thinks the exchange of personal trivia is what “friendship” is. A Mark Zuckerberg Production indeed! We were going to live online. It was going to be extraordinary. Yet what kind of living is this? Step back from your Facebook Wall for a moment: Doesn’t it, suddenly, look a little ridiculous? Your life in this format?

It should look less ridiculous.

The best way to innovate in social is make a product that helps people express themselves and identify themselves more freely and fully, to capture nuances in identity and relationships that other networks don't. The first step is admitting that making good social software is hard. In a recent interview, Gmail creator Paul Bucheit, who's now at Facebook, discussed Google's flippant attitude toward social:

Facebook is growing very fast, and obviously, Google would like to compete in the social-networking space. They have finally realized its importance, and they are finding themselves, maybe for the first time, with the realization that there is someone who is way, way ahead of them. There was a moment with Microsoft that they assumed, "Well, yeah, search isn't that important. And if it does become important, we'll just hire some people and we'll take over." They kind of thought it was something they could win really easily, and they underestimated the difficulty of it. I kind of feel like Google may have reached that same moment with social networking, where they realized, A, it's important, and B, it's really hard to win.

People are complex beings. Designing good software that describes them and their relationships is a hard problem to solve. When I saw that Google copied Facebook's and Friendster's "It's complicated" in the list of relationship drop-down options, my heart sank. Google should try to solve the hard problems of social, not just copy what the other products have.

None of the above: Let me explain

Back to drop-down identities, and one possible solution.

Usability is the most valid argument against replacing the gender and relationship status drop-downs with text fields. Male/Female or Single/In a Relationship/Engaged/Married/Divorced/Widowed may describe the majority of users' gender or relationship. Why make the majority stop and type into an open text field just so the minority of weird people like me can identify how they want?

Fair point. But we can have both, if we put a little thought into it. I like TheJeremyP's suggestion, which is a drop-down list that offers the most common choices as well as a "None of the above; Let me explain..." choice. When you click on "None of the above; Let me explain," you get a freeform text field to describe yourself in your own words, not the product's creators' words. This approach encourages use of stock responses for people who are comfortable with them, but gives those who are not the choice to define their own.

Social software should let you explain. But as the drop-down option says, it's complicated.

In terms of ThinkUp's codebase, in the past year:

• The source code changed 664 times, an average of about 1.8 commits per day. ¹
• 1,002 out of about 5,500 ² files in ThinkUp's codebase changed: specifically, there were 165,583 lines added and 29,904 lines deleted. ³
• ThinkUp had 16 releases: 8 alpha releases from February of 2010 until September, and 8 beta releases from September 2010 to February of 2011, which is an average of 1.3 releases per month.
• ThinkUp releases and related plugins have been downloaded almost 11,000 times. ⁴
• ThinkUp's automated test coverage skyrocketed to 3,485 passing tests.
• Out of 648 items in ThinkUp's issue tracker, 94 are open, and 554 are closed.
• ThinkUp has spawned two separate open source software projects which it uses: the GitHub pull request email bot by Sam Rose, and Mark Wilkie's Fixture Builder library.

Source code is one thing, but ThinkUp's best feature is its community. In the past year:

• 26 programmers made changes to ThinkUp's codebase. ⁵
• 42 community members helped write ThinkUp's documentation. ⁶
• The project's main hub, the ThinkUp general mailing list, grew to 483 subscribers.
• Community members discussed about 510 topics (not including replies) on that mailing list, an average of about 9.8 conversations per week.
• Of those 510 discussion threads, there were a total of 0 flame wars.
• On Twitter, @thinkupapp gained 2,944 followers. On Facebook, 143 people "liked" ThinkUp's page.
• Community members established the #thinkup IRC channel, in which developers and users are available to chat in realtime almost around the clock.
• Two episodes of the community-run ThinkUp podcast have been broadcast.
• Just this month, we established a brand new developer-specific ThinkUp mailing list. So far it has 24 subscribers and lots of high-quality, technical discussion.

We've also had some incredible users beta-test the ThinkUp application in the past year, from civic and government organizations to Hollywood celebrities and tech journalists. Take a look at the the White House's ThinkUp, Code for America's ThinkUp, Steve Martin's ThinkUp, Wil Wheaton's ThinkUp, and Leo Laporte's ThinkUp. (Are you running ThinkUp? Post a link to your installation in the comments.)

Building software and community around ThinkUp has been one of the most gratifying "jobs" I've ever had. Here's to an even better second year of ThinkUp releases.

1. At first ThinkUp's commit log was busier and messier than it should have been because we weren't "squashing" related commits into a single patch. Later in the year, when the community defined our git/GitHub process, the commit log became much cleaner, and commits to the master branch increased in quality but decreased in quantity. ↩
2. Counted using the command $ find "thinkup/" \! -name ".*" | wc -l ↩
3. Lines of code and number of commits are not indicators of software quality, but they are indicators of project activity. ↩
4. We're not tracking individual ThinkUp installations yet. This number is a total of GitHub's download counts. ↩
5. As per GitHub's comparison of alpha 1 and beta 8.1. ↩
6. Give or take a few authors due to multiple email addresses/GitHub accounts. ↩

Cross-posted to the Expert Labs blog.

Are you still standing at your desk?

Yes I am. I haven't mentioned it because I've kind of forgotten about it—once you get over the hump, it becomes the norm. I probably stand about 60-70 percent of my workday (generally 8am to 5pm), with many breaks for lunch, pacing, and meetings. I sit everywhere except in my office, and when I work/code/write at night I do it curled up on the couch. I lost three pounds in the first three weeks of standing (and watching what I eat), no gym.

Are you going to Google I/O? How'd you get in? It sold out in 59 minutes, during which time the registration site was mostly down.

I am going to Google I/O, and here's how I got in: a week before registration opened to everyone, Google opened registration to 2010 attendees, and I jumped on it. (Read: the event didn't really sell out in only 59 minutes.) Relatedly, Google offered me a free press pass, but I turned it down to pay the $450 to register as an attendee. It was a matter of identity (and giveaways).

I'm not speaking at Google I/O, but I am speaking at SXSW Interactive and at CodeConf. Here are all the when's and where's of the conferences I'm going to and speaking at this year.

How's that whole selling-an-app-in-the-Android-Market going?

Much better than I anticipated. I was hoping to sell 500 copies in the first month. Even with a free web download available, we've sold close to 2,000 copies of Todo.txt Touch in the Android Market and gotten an average 4.5 star rating from almost 150 user reviews in 2.5 weeks. Honestly I'm embarrassed that the app is so beta and rough around the edges. Then again, if you’re not embarrassed when you ship your first version you waited too long. We're iterating quickly, releasing an update every Sunday.

Overall, besides an initial hiccup or two, it's been a great experience. The Android Market let us release early, iterate often, gather feedback, and fund development without any delay inherent in an approval process. Speaking of approval, I submitted Todo.txt Touch for approval to the upcoming Amazon Appstore, and about 8 days later, I received notification that it has been approved. I have no idea when the Amazon Appstore will launch, or how it will work.

Are you making an iOS/WebOS/web-based/AIR version of Todo.txt tools?

The iOS native app is underway, which I'm committed to releasing because I want to learn iOS development. There's plenty of discussion about other versions. Thing is, I have a full-time job, and Todo.txt apps are spare-time projects. In other words, unless other developers step up to lead other versions, there are no guarantees.

Follow @todotxtapps on Twitter to keep up with news on the projects.

What iPhone dev books did you wind up getting?

I'm anxiously awaiting the arrival of my copy of the newly-published Beginning iPhone 4 Development, as well as the iPhone Programming: The Big Nerd Ranch Guide. I've watched the first two Stanford lectures and created and tinkered with a few "hello world"-level iOS apps so far.

Speaking of the full-time job, how's ThinkUp going?

Incredibly well. We're doing some neat stuff with conversation analysis, you can now embed conversations on any web page, and we're in the process of testing real-time Twitter support. Check out our latest beta release changelog—it's a long list of impressive work by a brilliant community.

Thanks for asking.