Ben Scofield

I just read a post from Micah Baldwin that I found very interesting, so here’s a quick response:

Failure is bad.

Success is good.

Sure, failure can teach you valuable lessons – but so can success, and success has the added benefit of being success.

What the “failure is good” mentality misses is that failure is good only as a means to future success. Micah’s friend did exactly the right thing: he used his past failures to guide him to the choice that he perceives has a greater potential for success. In my book, that merits much more than a, “Fair enough.” Anything else would be actively courting failure – mistaking the process for the goal, and forgetting the lessons of follow-through.

Twitter’s lists are a fascinating new feature, and people are using them in a bewildering variety of ways. I think one of the most unexpected effects they’ve had, though, has been the exposure of yet another problem with Apple’s App Store approval process: it’s just not agile enough.

Say I was selling a Twitter client on the App Store. In an ideal world (read: the web), the primary bottleneck to delivering a new version of the product is the development time – Twitter releases lists, I burn the midnight oil a bit to incorporate them into my app, and I’m done.

When you’re developing for the iPhone, however, the main bottleneck isn’t the development time, but the approval process. Every update to the core functionality of the application has go through the approval queue just like a new application, which means that it can be weeks or months before it gets onto your customers’ phones. (Or never, as has been the case with a recently rejected app update.)

Similarly, entirely new applications face the same problem. Fred Wilson just posted a Twitter list-powered application idea, but there’s no way a native app could be released to the public quickly to take advantage of it.

This has always been something of a problem for desktop development, of course – particularly before online patch distribution – but the iPhone has taken it to new heights. Web clients were able to add support for lists as quickly as they could push their developers, but native applications are left to lose their audience until Apple deigns to approve their updates. I’m surprised that the effect isn’t greater, actually, since the web-based Twitter clients should be promoting the heck out of mobile-optimized views of their sites with list functionality. Scoble‘s favored way of interacting with Twitter is a web-based client, in part because of its list support (see the last paragraph).

This is just one more problem with the App Store approval process, but it has the potential to be one of the most serious. As more and more mobile applications rely on web services for their functionality, the mismatch in time-to-market between the moderated App Store market and the quick-as-you-can web ecosystem will cause more (and more serious) problems.

Rob Walling makes basically one very good point in his post “How to Compete Against Open Source Competition,” and that point is this:

Open source software is free if your time is worth nothing.

He illustrates this idea by pointing at the Gimp, Zen Cart, and contributed Perl and PHP modules (if I’m understanding his point about modules that don’t come “out of the box”). Each of these takes a long time to install or to learn, and can cause a ton of problems if you’re not careful. So, the crux of his argument is that open source products aren’t really free, in that they take time to learn or to customize (or make you want to burn your eyes out with lye, if we’re talking about the Gimp).

Sure, lots of open source projects aren’t set up to be friendly to new users – but commercial software isn’t intrinsically better. It just has more incentive to be better, since the developers get paid when it is. Even the profit motive doesn’t stop the flood of impossible-to-customize, hard-to-install, poorly-developed commercial software, though. That leads me to the following point:

The price on the box for commercial software is only the beginning of what you pay.

And at the same time, there can be just as many hidden costs (akin to open-source’s time cost) with commercial software. As I just mentioned, it can be hard to install and to customize – I’ve tried to use Expression Engine for some things that it wasn’t designed to handle, and it was a nightmare. There can also be costs for the community (supporting a harmful monopoly), to say nothing of the less-visible ongoing support and upgrade costs.

All that said, however, I find it interesting that his suggestions for how to compete with open-source work just as well going the other way:

1. Save your users time. The most joyful open source software experience I’ve had recently has been installing Phusion Passenger – it’s a one-step install, and it tells you what to do if you make a mistake (forgetting to use sudo, for instance).
2. Market hard. Sure, marketing budgets for open source don’t really … well, exist. Nevertheless, the web gives us plenty of free marketing options. Make something awesome, put it on GitHub, and tell everyone you know about it. Post to Reddit, to Hacker News, anywhere it might be relevant. More often than not, truly remarkable work will spread.
3. Focus on Features for Your Demographic. The best open source projects tend to rely on a small group of focused commiters, even if they accept contributions from a wide swath of developers. If the core team is afraid to say ‘no’ to features that don’t fit their vision – or if their vision is entirely abstract and divorced from real needs, you’re going to get a project that doesn’t work for anyone. Good open source work needs just as much focus on providing value as a successful startup does – which is to say, a lot.

The bottom line is that software needs to be better, regardless of whether it’s open source or commercial. Everything we install or use has costs, be they cash, time, or stress. The goal is to minimize those costs as a whole; the balancing act between the different types of cost is up to each of us.