Symphonious

Daniel Jalkut has an interesting piece on the perception people have that simple software should be free. It's a perception that I actually share - it annoys me when people ask for money in exchange for really simple applications. It's not that I don't appreciate the effort that goes into software, it's just that I'm a make the world a better place kind of guy. I believe simple things, which cost effectively nothing to reproduce, should be released for free on the basis that you both give and take from such a system.

To give an example, I've recently given my old computer to my father in law and spent quite a bit of time setting it up so it works the way he wants, has all his applications and documents etc. He's happy with the result and I'm happy to help, not least of all because before my wife and I moved in together I spent pretty much every night at their place and they happily fed me without asking for anything in return. Of course, I know him and it's pretty much a given that we'll do things to help each other - that's what friends and family do.

The same idea applies on a wider scale though. If I see someone looking lost I ask if they want directions and help them out. I'll never see them again, but it's a nice thing to do. Turns out that recently I was lost and someone was nice enough to ask if I wanted help, pointed out that I was in fact heading in completely the opposite direction and set me straight. Karma. We all do nice things and we all make the world a better place.

The key thing to note in these examples is that being generous or helpful isn't costing me my livelihood or really costing me all that much at all. Certainly setting up the computer cost both time and money (or at least the potential of it if I'd sold the computer instead of giving it away) but it's insignificant compared to what I have so I can afford to share it. This of course leads in to the argument that always comes up about why you should pay for simple software. As Daniel says it:

Software costs money, time, and resources to develop, just like many of the other products in our lives. And just like those peanuts on the bar, many companies with other things to sell you are in a good position to give away freebies that help to promote their business; to encourage you and your friends to give them money for different reasons.

But smaller companies don’t often have the variety of products and sevices that lends itself to such a complex strategy. Given a good product idea and a market to sell to, they’re forced to adopt the simplest of all strategies: pure payment. Build something brilliant, and be rewarded with money. This money translates into a great motivation for the developer, which in turn translates back into product greatness. It’s easy to understand why the majority of great products in this world do cost money to obtain.

This argument makes the assumption that there is a viable business model around making really simple software and expecting people to pay for it. If you can't make your livelihood doing something you wouldn't do it at all and so the software wouldn't exist or wouldn't be as good. The trouble with this logic is that most of these really simple products are created as a hobby in people's spare time rather than as some grand business plan to put food on the table. How many of these developers quit their day job to write a utility to make it easy to add things to delicious? If they created it in their spare time, you don't need to pay for it to support their livelihood - their day job does that so earning a living doesn't come into it and you need to find a better argument.

Of course, that doesn't mean that it's wrong for people to charge money for simple software, if they can make it work then good for them, but it does help to explain why people don't like it. To a lot of people it comes across as a little bit selfish or greedy, like not wanting to share your toys. The reality is that it's just a different view on the world and I'm sure they're very nice people who are generous in a whole range of other areas, but that's the perception. It's like charging 10 cents to help an old lady across the street - it might be how you make your living (however unlikely that is) or you might give all the proceeds to charity but it still seems like you're being really cheap.

We've found a cheap little NetGear router that can roughly load balance and fail-over between our two internet connections to hopefully get a little bit more speed. Of course, the simplest thing to do is to set it up so that from the inside it looks just like the old modem and then on the WAN side set it up to look like a client using that old modem as it's router. Of course, that means that the inside and outside of the router are in the same subnet (192.168.0.0) in this case and the new router's internal IP is also the IP of the WAN router it forwards on to.

If your mind can't handle that, don't worry - neither could the NetGear router's.  Shame though, it was such a simple way to configure things. Now I either have to change all the internal IPs and find anywhere they happen to have been hard coded and update them, or get the ISP that manages the modem to change it's internal IP. We've sent the word to the ISP but it's filtering its way up the chain of suppliers to the real ISP that actually runs things. Oh and of course since last time we called our ISPs been bought out by someone else again.

If only we were big enough that the top level provider considered us worth dealing with…. Sigh.

For some time, we've had an Arabic translation in EditLive! and the editor pane itself fully supports bidirectional text, but we've never updated the UI to flip over to a mirror image when a right to left language is in use. Java actually has pretty reasonable support for this via the ComponentOrientation property in AWT (and inherited through to Swing) but there are a couple of annoying limitations:

1. It applies on a per component basis, so there isn't a single place you can apply the orientation and be done with it.
2. Various components still don't flip, eg JSplitPane.
3. The Aqua L&F on OS X has some annoying bugs when in right to left mode.

For the first issue, you can use applyComponentOrientation which will automatically traverse the component hierarchy and make the changes but it still misses things like combo box renderers, dialogs or components that are generated later. For an application that loads its UI incrementally instead of blocking the swing thread while it loads in one go this is a significant annoyance. Even beyond that, all the dialogs need to be updated as well. While it is good that you can override the orientation on a per-component basis, it seems more intelligent to have a simple way to change the default value in one place without all the work.

The second issue really just means more special case code to deal with which is a shame. In some cases you just need to change the way you use the classes like using LINE_START and LINE_END instead of EAST and WEST with BorderLayout, in others you really need special case code.

The bugs in the Aqua L&F are annoying - editable JComboBoxes are probably the worst, the text field winds up aligned right but the combo drop down button stays on the right so they overlap. The new capsule button styles that are applied by client properties don't handle right to left either so you have to manually track the component orientation and flip the "first" to "last" and visa versa.

All that said, supporting right to left languages is never just a flick of the switch and I'm yet to really get into the details of how it all should work (this was just an afternoon's investigation) so Java's done a pretty good job at supporting it and getting things this far. It will be interesting to hear from people who actually speak Arabic and get their feedback about how it should work and where all the little details we need to take care of are. If you happen to be an Arabic EditLive! user, please get in touch, it would be great to get some individual feedback before we roll out an update to everyone.

So the iPhone roadmap looks very promising. The enterprise functionality is really impressive and places the iPhone extremely well as a mobile device for corporations. The SDK has a lot of power and seems to have access to pretty much everything you'd need (there's already an SDK for access to the dock connector). Even things like instant messaging and VOIP will be allowed, though obviously the carriers don't want to deal with all the traffic from VOIP so it's just wireless but that seems quite reasonable to me. I'm not sure I'd want to try VOIP over an edge network anyway…

The biggest problem I see with the SDK is the $99 entry fee. $99 is nothing to anyone with a decent idea for an iPhone app and the skills to develop it. Heck, if you don't have $99 to spare how the heck did you manage to afford an iPhone?? Still, once you plonk down that money you're very unlikely to release your application for free which means just about all the iPhone software is going to be payware. I like the concept of selling software and thus paying developers, I earn my living that way, but it's just so nice to have a bunch of freeware or opensource that you can just grab and try out and maybe it'll be great maybe not. Little ideas released for free make an awful lot of sense and make the world a better place (in a very techno-geek way). That's unlikely to happen with the iPhone.

That said, how hard would it be to set up a donation pot to buy access to the iPhone SDK for open source projects? Not sure how it would all work but it would be a great idea and if you don't donate enough the software really does go away so there's more than just altruistic incentive.

Bottom line for me, I can't wait to get the exchange functionality because I've been wondering what the best way to get my exchange calendar synced with my iPhone (I use exchange for work and iCal for home but iPhone for both) and I'm really keen to get an instant messaging client on the iPhone as well. I can live with AIM if that's all I get though most of the people I know are on MSN. Beyond that it's just a bonus so I'm really quite happy with what's come out.

All the hubbub about flash support on the iPhone highlights an interesting "gotcha" that many people fall into: there's a world of difference between having something running and having something you can actually ship. The funny thing about software development is that it is generally much quicker and easier to solve all the "hard" problems and create the software you need than it is to polish off all the little loose ends that turn code into an actual product. It's also surprising how many ideas that sound really good on paper turn out to actually make things worse.

For example, recently I spent an evening and developed a fairly basic image editor that could plug into EditLive!  Just the basic operations like crop and resize that people want to quickly do without switching to a separate program. It took all of about 3 hours work and dealt with error conditions, was well coded etc etc etc. Of course, the UI was hideously ugly because I didn't have any icons to use and it wasn't my primary focus but it was an impressive, if ugly, little program. The trouble is, it will take a month or two of full time effort to bring that program to a point where it can really be shipped to our clients. There are just so many little details you need to consider that aren't obvious until you've gone through the process a few times.

There are also times when you develop something, sort out all the loose ends and are really ready to send it out to the market, until you realize it sucks. I spent some time a while back improving the standards compliance of the caching we do in EditLive! It basically cached everything and ignored even the basic Pragma: No-Cache directive which does cause issues for a number of our clients so it seemed like a no-brainer to fix. The trouble is, far too many servers and developers default to disallowing caching even when the content isn't going to change. This has a fairly minimal effect on browsers because you don't go back and forward through pages all that often so the site feels a bit more sluggish but it's not too distracting. In a HTML editor, you want the images to be cached, no question. The number of times the document changes around, when you cut and paste that image etc etc you really don't want to have to download the entire image again - even more so if the image size isn't specified in the HTML since then the document content jumps around when the image finally does download. It turns out you have to be pretty clever in how you apply the caching standards in a HTML editor - they do work, it's not that the standard is wrong, it's just that it takes a lot of careful thought to get it all right.

So how does this relate to Flash and the iPhone? There's a couple of ways - firstly, let's say Apple has the full Flash running on the iPhone with no bugs etc. How fast is it? If it's too slow, users might be better off with the non-flash version that any decent site should provide. How much battery power does it drain? This is your phone we're talking about, having it run out of battery during a day is a major inconvenience. How well does it interact with the iPhone's touch screen input method and the on-screen keyboard? I keep hearing people argue that the iPhone needs flash so it has access to all those little flash games around the internet. You know, the ones where you move with the arrow keys…. oh wait. Sometimes things aren't as straight forward or as cool as you think and you probably won't know until you've actually tried it.

The second question is whether these rumours of Apple having flash running on the iPhone are actually people seeing the mobile version of flash which Jobs mentioned and discarded as too simple for the iPhone. Mobile flash isn't being kept off the iPhone because of technical limitations, but because, at least according to Jobs, it's simply not good enough to handle the real internet. It's also not necessarily a step forward to add mobile flash, even if it can't handle everything. All those sites that do the right thing and provide fall back content automatically if flash isn't available work just fine on the iPhone right now. If you have mobile flash though, suddenly they'll be showing you the flash content and if mobile flash isn't up to scratch it just won't work. Sometimes adding features winds up making things worse.

What's the bottom line? Whenever you hear someone talk about how easy it would be to do something, ask them if they've actually done it. If not, there's a very good chance they're wrong, regardless of their qualifications and experience. Really, really smart people hit unexpected roadblocks every day so unless you've actually achieved something you should be expecting unexpected trouble. Secondly, even if they have proven it can be done, check that it actually works out as well as you'd expect in real world testing. The real world is full of surprises and some of them will almost certainly apply to what you're working on so be prepared.

Of course, this doesn't just apply to flash or the iPhone, it applies to all engineering work that tries to achieve something new. Just remember, if it were simple, someone else would have done it by now.