I said in a previous post that in my experience, the best opportunities often come along when you’re not looking for them, and that was certainly the case here. I wasn’t even thinking about looking for acquisition opportunities for SourceTree – sure, the idea had crossed my mind as something I might want to consider eventually, but it certainly wasn’t an active line of thought this early in the product lifecycle. SourceTree had grown to become a viable business for me, and I was very much enjoying the process of just creating a software product that I used every day myself too.

So, when the Atlassian opportunity came up, I wasn’t at all prepared for it, and I had to make some decisions. I was enjoying being master of my own destiny, and was managing just fine – so my initial knee-jerk reaction was to be very cautious. However, the more I thought about it, and the more I learned about Atlassian, the more I realised what a huge opportunity I’d be turning down, both personally and for SourceTree, if I said no.

Any acquisition kicks off with a financial offer (don’t expect details, they won’t be forthcoming ), but that’s far from the whole story. In my case I didn’t have any pressing need to sell, and I’ve learned from experience that being happy about what you do is extremely important. I also have a strong attachment to the products I create – that’s why I stayed with Ogre for 10 years and it was/is still a wrench to leave – and that’s the case with SourceTree too; not to mention that I’m a daily user of it myself. So if I was going to sell, it had to be to the right company who would look after it just as well, or better, than I did.

Luckily for me, I discovered that Atlassian was about as perfect a fit for SourceTree as I could have asked for. Atlassian lives and breathes developer tools – that’s their entire product focus, which in itself is a good start. They’re investing heavily in DVCS tools – hence the 2010 Bitbucket acquisition and its recent enhancement to handle Git as well as Mercurial (which of course SourceTree does too) – again spot-on on the compatibility chart. I learned, particularly when I visited their HQ in Sydney, that everyone at Atlassian really ‘gets’ developers (well, most of them are developers after all), and care a lot about giving them good products. Development tools permeate the entire company – the CEO is a regular user of SourceTree, and people in marketing understand when you talk about version control. Even though they’re quite a big company now, it retains a startup feel. Then there’s their corporate values, which are very much in evidence when you talk to people there – things like “no bullshit” and “don’t f**k the customer”. And it’s not just on the wall, it’s really how people in the company make decisions. These are the kind of people I can relate to, and definitely the kind of people who can add a lot to the future of SourceTree.

Another thing I found reassuring is that at no time was there any question that Atlassian would want to railroad developers into their own tools at the expense of others. Clearly Atlassian already owns Bitbucket, and SourceTree supports Bitbucket, GitHub and Kiln already. It was made abundantly clear to me that no-one at Atlassian took the view that restricting developer choice to favour Atlassian tools was a good idea. Their ideology is to make developer’s lives better by giving them choice, and of course they’re going to want to offer good Atlassian options in there, but if a developer wants to use an alternative, no-one is going to stop them.  The view I got from everyone was that giving developers a positive experience that reflects well on Atlassian, including giving them their own choice of integration, is far more valuable than artificially chaining them in. Obviously, I concur.

My final reason was that while I really, really enjoyed creating and supporting SourceTree myself, the workload is quite high, and was increasing. It’s not a continuous death-march, but the availability requirements are very high – since I was developer, webmaster, sales, customer support and everything else all rolled into one, taking a day off was basically impossible. Making sure the website was still up, and making sure customers got a quick response to support calls, was a 24/7 responsibility. After a while, that gets tiring, even just checking on things all the time means you never have ‘proper’ downtime. A big advantage of joining Atlassian is that I get some extra backup. That’s good for my health & mental wellbeing, and I’m sure that will be good for SourceTree too long-term. I really didn’t want to start resenting SourceTree for preventing me having a proper holiday occasionally

So based on all these factors, I decided that the future for both myself and SourceTree would be better within Atlassian than continuing alone. I learned a lot along the way to this acquisition – dotting all the i’s and crossing all the t’s turned out to be more time consuming and stressful than I expected, so I wouldn’t say it’s a process for the faint hearted, but if you’re as lucky as I was to be approached by the right company, it can lead to a really great outcome.

I’m still fully committed to developing SourceTree, like I was before, but now it has a more robust support structure around it. Taking things to the next level, both in terms of user base and features, is so much more practical now within Atlassian. I’m very confident that they’re the right company to take SourceTree forward – our thinking is very similar, I respect their values a great deal, and the people are great. My decision was a lot easier than it might have otherwise been because of this!

One term which was bandied around a lot in this environment was ‘software engineering‘. The implication of this term, and the expectation of many people using it, is that designing and creating software is very much like physical engineering disciplines, such as erecting a bridge or building a block of flats. When a software project starts to go off the rails, and fingers are starting to be pointed, a common question is why large physical engineering projects can come in on time an budget, when most software projects beyond a certain size don’t? Surely if the people who create software claim to be ‘engineers’, they should be able to adhere to the same standards of other engineering professions?

At face value it sounds like a fair argument, and I’ll be the first one to admit that software engineers are very often not as rigorous as others bearing the title. But there’s a good reason – the belief that software projects are akin to building bridges is completely misplaced, and it is a belief which too often leads people to think that software projects should be run using techniques such as fixed prices, up-front design, and waterfall life-cycles. This is despite decades of case studies indicating that such techniques rarely work, and are more often a collective delusion adopted because the reality – that you’re never going to be able to predict a large software project accurately up-front – is too terrifying to be contemplated. The term ‘software engineering’, while indicating some of the responsibilities of such a person, is an incomplete definition of what building software actually entails, and just reinforces these misconceptions.

So, why is making software so different to building a bridge?

1. Software is intangible.
   You can see and touch a bridge, it has a physical presence you can measure and its purpose is absolutely obvious to any observer, as are its success and failure conditions (getting people across a gap without falling down). Even though there are parts of the bridge the user will never see, their purpose can be easily unambiguously defined – carrying utility cables/pipes, providing maintenance access, etc. Software is intangible, and even the part that is seen by those defining its purpose is often hard to evaluate until it can be seen and used directly, never mind the internal working processes. Evaluating and defining software ahead of time is like trying to describe a dream seen through a keyhole – incomplete and everyone has a slightly different impression, and regardless of how much you try to write it down, you can’t capture or communicate its essence completely to others, or guarantee that they interpreted it the same way.
   People are just naturally very bad at defining and evaluating intangible things. There’s no point pretending they can with 300-page requirements documents, you’re just wasting everyone’s time – accept that people won’t know what they like until they can play with it – iterate!
2. Interaction complexity
   There’s only a small number of ways to use a bridge, and they’re each quite straight forward. Yes, there’s much complexity to the structure of the bridge itself, but that really doesn’t matter to a person driving or walking across it – that doesn’t need input or feedback from people except for whether they like the look of it.
   Software is basically defined by complex interaction, which is often context- and data-sensitive. The number of variations mean that even if every one is bug free (yeah, right), there’s the question of whether it’s solving the correct problem, which is a function of people and their interpretation / opinion. While building projects can be complex, those complexities are most often a function of the engineering challenge, whilst most complexity in a software project is a function of the involvement of people, which are far more difficult to pin down.
3. Change is a constant factor
   Change happens everywhere of course – maybe the bridge builder discovers that the ground isn’t as firm as they thought, or suddenly someone wants to make an extra deck available for trains. Big disruption, and an effect on time and budget – all understandable. The problem when it comes to software is that the perception of change is very different. If suddenly you have to sink massive extra foundations or double the amount of steel you need to use, people understand the magnitude of that intuitively and accept the effect on the schedule. Changes in a software project tend to be perceived as ‘just a little tweak’ by those requesting it, which tends to mean tolerance for schedule impact is lower, and indeed the potential for interaction between changes in unexpected ways is often overlooked. Now, I’m not for a second advocating that change should not be allowed, but often the mechanisms that have been established for managing a project – up-front estimation, fixed feature sets and so on – prevent the efficient integration of change, or at least obscure its impact to a point where things become critical. It’s important to appreciate that change is more common and expected in software projects, by nature of the issues raised in the previous points, and therefore setting your expectations based on a discipline where change is less common is not a smart move.
4. Lack of hard limits
   Building  a bridge involves respecting some hard, unchallengeable limits. As a wise man once said “You canna change the laws of physics, Cap’n!”. When you’re building software, however, there are very rarely any unbreakable limits, and even the soft limits that there are tend to be invalidated very regularly as new technology comes on stream. No-one can realistically stand up and say ‘this is impossible’ when faced with a request, because almost nothing is impossible. Hard limits in physical projects make all stakeholders ‘get real’ – you can’t use more land than you have, you can’t build a skyscraper out of paper, there are non-negotiable rules for safe load-bearing and so on. Barring some really crazy and ground-breaking structures (which BTW, rarely come in on time & budget), these limits ground everyone involved in the project to realistic expectations. In a software project, reining in those feature requests, or those ideas that the implementors have for a new tech they could use, is much more abstract affair, and everything is up for debate.

All these things put together mean that if you think you can use the same kinds of techniques to run a software project as you would use for a building project, you’re kidding yourself. They’re so very different in fundamental ways, it’s like trying to catch a shark with a shrimping net (because it’s just a fish, right?).

So please, stop with these delusions:

1. that estimating the cost of any non-trivial software project (that isn’t just a carbon copy of something else) is any more sophisticated than mildly informed guesswork.
2. that it’s reasonable to think that a fixed-price can be realistic for any software project longer than a couple of weeks
3. that ‘change control’ is the about exceptions, rather than the norm

Of course, agile approaches attack these particular delusions rather well. But try to get those adopted in very large organisations where the ‘software is like a bridge’ mentality still thrives

The SourceTree 1.2 launch sale is now over, and I thought I’d post some indicative results. I went for a fairly large discount of 40% over a full week, and some people I know commented to me along the lines of ‘what about all that money you’ll be losing on each sale?’.

I decided on a large discount because SourceTree 1.2 was a major update that I was actually quite proud of, so I wanted to get it in front of as many people as I could. I was also aware that there might be people who tried SourceTree before, but who decided it wasn’t for them, and I wanted to encourage these people to try it again, since I’d made pretty big strides in this version on the overall appearance of the app and the smoothness of the workflow, in addition to all the normal new features. The way to do this of course is to make it worth their while to do so, by offering a discount that really grabs their attention. A 20% discount probably wasn’t going to do that effectively, but 40%? That’s almost half price! It’s this sort of gut reaction I was looking to promote.

The other thing I was acutely aware of is that you have to be careful not to have too many sales. If you go on sale too often, people are going to start assuming that there’s a sale coming almost any time of year, so will avoid buying unless there’s a sale on. In my opinion, sales need to be infrequent, but big and attention-grabbing when they do happen.

So actually my goal for the sale wasn’t necessarily to make more money than usual, but to get more eyeballs on the new version, and more active users, which I hoped would then translate to more awareness and more sales further down the line, because satisfied customers are the best marketing resources you can ever have. Solid reasoning, but as it turned out, things went much better than I could have hoped, so in the end I actually achieved both at once.

So for those people who were wondering whether having a sale is worth it, my results are on the right, in fashionable infographic form

As I said above, what I was really looking for was to reach more people, and I certainly did that – with a 793% increase in units sold in the sale week, that’s about 2 months’ worth of new users in one week. And as you can see, in value terms it also ended up a considerable net positive even with the 40% discount – now of course I’m expecting sales to be more sluggish immediately following since the sale will have caused people to bring forward their purchase, but I’m pretty confident it’ll remain positive even with that compensating effect.

So why am I writing about this? Am I doing it to strut around flashing my ‘wad’ at people? No, and if I’d included the actual $ values you wouldn’t think that anyway – they’re fantastic news to me but they’re in the ‘I can keep doing this sort of thing for a living!’ range rather than the ‘I can buy a Ferrari tomorrow!’ range I’m writing it to hopefully provide a data point to other developers who, like me, are still learning about selling their wares online, and are wondering about what kind of affect a sale might have. I don’t know whether it will be exactly the same for you, and there are no doubt a number of variables involved, but this was my experience, and I’ve been very happy with it. Maybe it will help someone else pondering a similar decision…

Since I’m trying to spread this news as far and wide as I can, I might as well say it here too

Since the approval light just went green on the Mac App Store, I’m happy to announce the launch of SourceTree 1.2! In celebration, I’m having a crazy-bonkers 40% off sale just for one week, so get it while it’s hot!

There’s loads of things that are new or improved in this release, but here are the headlines:

• Support for GitHub, Bitbucket and Kiln APIs, so you can see your hosted projects inside SourceTree, clone from them, link them as remotes, and even create new projects if you want.
• Streamlined and polished user interface – I specifically dedicated a lot of extra time in this release on making SourceTree easier on the eyes, and to streamline the layout and workflows better.
• Performance - I thought SourceTree was already pretty fast, but I managed to find quite a few more places to trim the fat, and also parallelised more activities to make things feel more responsive. Everything feels snappier, and complex repositories benefit especially.
• New Sidebar - I had previously resisted the need to emulate iTunes here, but once I had implemented it, I had to admit that I was wrong, and in fact this worked great. Provides lots of shortcuts to navigating and operating on branches, tags and remotes.
• Stashing and Shelving - oft requested, now delivered
• Customise Git and Mercurial – you can now use your system Git / Mercurial instead of SourceTree’s standard versions (which have been updated), and enable additional Mercurial extensions (at your own risk).
• French and Japanese translations – local versions for our friends in far away (and not so far away) places, likely to be more to come in future. Big thanks to tuan_kuranes and mzch for their help with these two!
• And the rest – just lots of little refinements too numerous to list. Examples: copying text from the diff panel, ‘git commit –amend’ support, close branches in Mercurial, switch tracking branches in Git

It’s quite a big update – one user remarked to me that they’d normally expect developers to charge an upgrade fee for something like this, but like all other SourceTree updates this is free to existing customers. I have no plans for any paid upgrades for some time yet, I just want to keep making SourceTree better, and hope that more people come onboard. Maybe it’s my open source background, but I like to keep iterating and continually improving things, based on what I want to do (I’m a daily SourceTree user myself), and on what people tell me they’d like to see. SourceTree 1.2 certainly won’t be the last update by far

When I look back 6 months at SourceTree 1.0, it’s incredible how much better it is as a product now, both visually and functionally. I’ve learned a ton of things while I’ve been developing it, and I continue to learn more all the time, and I can’t think of anything I’d rather be doing right now. Also, my wife Marie re-designed many of the icons for 1.2 (and I think you’ll agree they’re a lot nicer) – that was fun to do as a joint project, even if I am a picky ‘customer’

I hope you enjoy the new release!

The thing is, in the developed world in particular, our options are almost limitless – in practice we have very few real constraints on what we choose to to, barring a few fairly sensible laws. Barring a small number of hard factors, such as poverty, discrimination, and oppression (which should be fought wherever they are found), the only limits to most people’s decision making are those which they impose on themselves, resulting in a large number of options. This is a good thing, but it does make decision making complicated. How on earth do you sift through all those alternatives?

Opportunity Cost

Understanding the concept of opportunity cost is vital to any decision making process. It’s just as important to consider what you won’t be doing as a result of a choice, as what you will be doing. Picking contract project A might mean you don’t have time for personal project B, taking that corporate job might mean you can’t dedicate time to developing that business idea you have, and so on. For a while, I tried to defy the reality of opportunity cost by ‘cheating’ – I would do multiple things at once, and just put in very long hours. I worked on projects in my spare time while being employed, I would multi-task between many projects (contract, open-source and personal). That works to a degree, but it’s important to realise two things:

1. There’s a limit on how long you can burn the candle at both ends.
   I speak from experience here, burn-out and work/stress related health problems are very real, whatever you might think as a young, healthy, workaholic programmer. You can work 12-16 hour days for a while, but eventually you’re going to have to stop, or something will make you stop. If you need to do it to bootstrap, fine, but always remember the clock is ticking – plan for that.
2. The more you divide your time, the less efficient / productive you will become.
   If you spend 10 hours a week on each of 4 projects, in 4 weeks you will have done a weeks worth of work on each, right? Wrong. In fact, you’d probably be lucky to get half that. The more you divide yourself, the less you’re going to get done on each thing, just because of a lack of focus and a need to keep context-switching.

So, my message here is that you can’t cheat opportunity cost – things conflict, and it’s best to not to pretend that they don’t. This should not only inform your decision process, but it should also bring it into sharper focus – accepting that you can’t have your cake and eat it means you’re less likely to let yourself wiggle out of making an actual either/or decision when really it’s there.

Evaluating the options

The logical person’s approach to evaluating their options tends be be analytical, gathering as much information about each option in front of them, and quantifying each of the pros and cons, risks and opportunities, and so on. This is fine, as a starting point, and teases out a lot of fundamental ‘hard’ information that you need to have available. But in my experience the best you can hope for from this kind of process is that you will eliminate the outliers; those cases which will never work, or which you definitely don’t want to do (although it’s of course worth making sure you understand your own assumptions and biases here), leaving you with a pool of ‘maybe’ options. It  won’t, in any non-trivial decision space, provide you with an absolute dead-cert answer; or if it does, you probably haven’t considered enough alternatives

The simple reason for this is that for any significant decision there are bound to be many factors and variables which are unknown, poorly quantifiable, subjective, or incomparable with each other. There won’t be some magical formula which you can plug all the variables into and come out with a single best answer, nor will the factors usually be clear enough even for you to rank them in any sort of objective order – or if you can establish a discrete ranking, it probably just means you’ve identified some more to discard, or you’re kidding yourself.

Making the decision

OK, so assuming you’re now left with a bunch of ‘maybe’ options, all of which have many uncertainties and incomparable pros and cons. How do you make that decision? You’re probably going to think this is a cop-out, but here’s my personal answer; sleep on it, and then follow your gut. Seriously, forget the analysis, and turn off your brain; it’s already contributed as much as it’s capable of doing in the previous step. Hard as it may be, particularly if you’re a naturally logical, analytical person, there are some things that simply cannot be analysed and quantified. Probably any of the remaining options in your list are good (or if this a case of choosing the lesser of N evils, equally bad) – so going with the one that you have an emotional attachment with is usually the right one, because that’s the one you’ll fight hardest for when things get tough. Which they probably will at some point, right? Never underestimate the power of emotional attachment and enthusiasm to the success of any endeavour when things get difficult. You can’t engineer this kind of affinity, and your gut will tell you when it’s there, more reliably than any checklist can ever hope to do.

Living with it

While it’s important to be nimble in many respects (in business, you can’t sit still and periodic course corrections are essential), you do need to give any decision a fighting chance to develop before you change tack. Try not to second-guess yourself too much in the early stages – it’s hard, and this is something I struggle with all the time, but it’s ultimately counter-productive in the shorter term. By all means it’s important to reflect periodically and learn from what worked and what didn’t, using that experience to influence your future decisions, but equally for your own sanity you have to be able to drive a metaphorical stake into the ground representing a decision you make, and only look forward from that point, for long enough to see what happens, for better or worse. Glancing over your shoulder from the outset wondering if you made the right decision is never helpful and is likely to undermine what you’re doing.

Conclusion

So, that’s my 2 cents on the decision making process. Thanks to @GeekAndDad for triggering me to finish the half-written post I had on this subject

Happily, things have turned out very well – SourceTree continues to sell, reassuring me that there’s enough interest out there for me to keep expanding and improving it (I’m looking forward to getting the next major release in people’s hands soon), and I’ve also been getting some Mac/Ogre-based contract work which I’ve enjoyed a great deal. In short, my Macbook Pro and I are now pretty inseparable, Windows 7 is powered off 99% of the time, and I saved hundreds of pounds by not upgrading to Visual Studio 2010

Out of interest, I thought I’d share some of my SourceTree sales information, in terms of the country distribution. Mac use is typically associated primarily with the USA, and while that’s certainly reflected in my absolute numbers, there’s some quite interesting figures revealed when you take into account population size. SourceTree is aimed at developers of course, so all numbers reflect this audience alone (and of course those that chose to buy it) but in practice I suspect that the proportions of developers to non-developers is fairly uniform in most developed countries.

So, firstly the absolute distribution:

No surprises there, the USA is the single largest source, followed by Germany and the UK (who are constantly scrapping over second place!). To me though, Switzerland stuck out as the most interesting, because it’s up there in 4th place yet has a relatively small population (under 8m). So I wondered – what would the chart look like if I scaled it by the population size? Here’s the result:

And there you go – as expected Switzerland jumps right to the top, and to my surprise Luxembourg and Denmark are up there too, beating the UK which I expected to come in second. Quite a lot of European countries are punching above their weight in per-capita Mac development, if SourceTree sales are any indication. In fact, on a per-capita basis, the USA is only just sneaking into the top 10, despite it being by far my best overall customer in sheer sales volume.

I’m aware that scaling by population isn’t all that scientific, since it is sensitive to the proportion of non-developers (and even non-computer users), but as I say, I think in developed countries at least, the comparisons are reasonably valid.

So the perception that Mac development is more popular in the USA than elsewhere may be inaccurate, based on my numbers at least (which of course are not massive in the grand scheme of things, but still a statistically relevant sample I think). Sure, simply because of the sheer population size of the USA it’s bound to dominate anyone’s sales numbers, but if you asked the question ‘of 1000 randomly selected developers in a country, what percentage are using a Mac?’, the result may not be skewed in the way you might expect. It was surprising to me, anyway.

I wonder if anyone else who has been doing this for longer has had similar results?

SourceTree is a user-friendly Mac OS X front-end for Mercurial and Git, the two most popular distributed version control systems used today. The goal was to create a single tool which could deal with both systems efficiently, and to give a developer quick and intuitive access to the things (s)he needs to just get on with building software.

I thought I’d answer a few background questions on this that I get asked on occasion:

Why Mercurial AND Git?

Other apps tend to concentrate on just one version control system, so why am I supporting two? Well, as a developer I’m regularly coming across projects from both sides of the fence, and in practice I find I need to use both fairly regularly. I personally chose Mercurial for my own projects (and discussed why here), but I still use Git when dealing with other projects, and spend a fair amount of time hopping between the two. It struck me that even though they have their differences, they are both based on the same distributed principles, so having to use two separate tools was just unnecessary. I wanted a single tool which provided a common interface where that made sense, while still exposing the things they do differently where that was useful too. SourceTree 1.0 is my first attempt at that.

Why only Mac OS X?

There were actually multiple reasons for this choice:

1. I wanted to learn Objective-C and Cocoa on a real project
2. I know from experience that designing for multiple platforms can be a distraction, with more time spent on compatibility issues, and less on functionality – and that’s before you even consider the compromises  you have to make, particularly on UI conventions which are far from uniform across platforms. I’ve been a multi-platform developer for more than 10 years, and for a change I just wanted to focus on the end user results and nothing else. I’m aware that schedules slip very easily when you overcomplicate, and I’m already supporting multiple DVCS systems (something I consider to be an important feature point), so I deliberately chose to keep this element simple.
3. Mac OS X has become my own platform of choice for most things now. The combination of stability, user-friendliness, Unix underpinnings and well designed hardware match my current needs perfectly. I’m done with the ‘some assembly required’ PCs that I loved tinkering with over the past 15 years

What about Subversion?

A few people have asked me if I plan to add Subversion support too. I actually did intend to originally, until I realised how much time it was going to take to just do a decent job on Mercurial and Git. Within the time constraints, I focussed on the subject areas that I felt I could contribute most to – there are already quite a few Subversion tools out there for Mac OS X, but Mercurial and Git are much less well served, so that’s where I focussed my efforts.

I still have Subversion support tentatively on my work plan, but it’s not top of the list. I think it’s better to do your most important features well before diversifying. Plus, there are problems with Subversion – it’s very, very slow compared to Mercurial and Git, so to match the performance in SourceTree of things like the interactive searches and dynamic refreshing / log population I’d probably have to do a ton of extra caching just so the user wasn’t sat tapping their fingers.

Edit: I made my decision on this: I don’t plan to support local Subversion, but to support operating with Subversion servers with Mercurial and Git locally via hgsvn and git-svn.

Why didn’t you make it open source?

Sorry folks, while I love contributing to open source (I’ve done a bit on SourceTree too, sending a patch back to BWToolkit), making it work as a business is very hard indeed. I half-killed myself trying to combine being an open source project leader and doing other commercial activities at the same time, so now I’m trying a more traditional approach. One thing I learned in the last few years is that there are some sectors & application types where being an open source maintainer is very compatible with also running a business based on that project, and there are others where you can really only do one or the other simultaneously without flaming out. Sucks, but there it is

What’s Next?

I have a public, official roadmap for SourceTree and encourage users to suggest things they think should be on there, via the support system. I learned from running an open source project for 10 years that being open about your plans can be a big benefit – users like to know where things are likely to be going, and often have better ideas than the developer on what could do with a bit more spit and polish. They can also tell you what’s important to them, which is crucial for prioritising – as developers we tend to get carried away with things we want to work on, but in the end, it’s scratching the customer’s itch that matters most.

And while I’m really quite proud of SourceTree 1.0, there are plenty of features I’d like to continue to add, and definitely more room for some totally unnecessary beautification which I didn’t have time for in the first release. Hey, this is OS X

SourceTree is available now on a 21-day trial license. Go get it already

What’s depressing is what’s happening to the ‘official’ download channels – which were a bastion of independent content a year or two ago, and now are turning more and more into just another channel for the same mainstream developers & publishers we see at retail. XBLA has been the trend maker here, it was first to really embrace and promote downloadable games to a ‘core’ market, and has done extremely well. Now, however, we have a limit of 2 games per week, and all too often those 2 slots are being assigned to either major developers (Shadow Complex, Alien Breed Evo) or shovelware ports with brand recognition but little quality or innovation (I’m looking at Taito in particular: Bubble Bobble and Qix remakes were incredibly lazy, uninspiring affairs). It’s very clear that the team behind choosing which developers are published in XBLA has changed in recent years, and not for the better from my perspective. That’s not to say there’s anything wrong with Shadow Complex and Alien Breed Evo, but if they’re using up the slots it means that publishing route is rapidly being cut off for small developers who are big on ideas and talent, but short on funds and established brands. Alien Breed Evo’s budget was supposedly around $2.5m for goodness sakes – although it’s looking like that’s going to backfire anyway since sales have been poor. Trials HD, ‘Splosion Man and Peggle are pretty much the only games from small studios with modest budgets that I can think of that made a splash on XBLA in 2009 – the rest just read like a whos who of regular retail channels. Indeed many developers who have had games published on XBLA are no longer welcome there, such as PomPom (interview) and Llamasoft. Clearly the message is ‘win big, or get your coat’. This isn’t the right environment for an indie scene to flourish, where experimentation and mistakes are part of the process.

Yes, I know there’s XBL ‘Indie Games’ but that’s the absolute opposite end of the spectrum, hobbled with a niche development environment that’s incompatible with the most established dev libraries and every other platform a developer might want to deploy on (barring PC), and so far almost totally lacking any way for a decent game to effectively ‘rise above the noise’, except via external review sites like XNPlay, which doesn’t work at all for targetting the majority of game players with information.  It’s just not a very good target for those I would call ‘serious indies’ and actually acts as a false argument for not opening primary download channels more; there’s nothing wrong with the concept, it’s just implemented completely wrong.

PSN got started later so has been earlier in the curve of promoting independent content, but they’re going that way too. I guess they’re all just ‘following the money’, and the games industry remains obsessed with hits because of its current top-heavy model. I’d hoped that the downloadable content channels would promote an equivalent to low-budget and art-house cinema, where content can survive and make a profit for the creators, without necessarily having to be the Biggest Thing Ever(tm), encouraging experimentation. But, the giant flaw in this plan is that independent cinema is able to be published and consumed anywhere – while most games consumers remain shackled to console platform holders, who just want to publish a limited number of the very biggest hits, everything else not being worth their time or risking ‘distracting’ the customer with choice. If you’ve read my blog before, you know my opinion of the effectiveness of closed platforms in the long term when it comes to broadening and deepening a medium, but I’ll say it again – closed platforms are bad for the industry in the grand scheme of things. Games will never be as big as film until this changes, they might compete on the blockbuster level, but that’s far, far from the whole story. But, until we’re further along the lifecycle of games when hardware and delivery becomes mostly invisible,  the vested interests aren’t going to allow that to change for a little while yet.

You really need to go to the iPhone/iPod Touch for more prolific indie content these days. But, how long will that last?

I honestly don’t know why platform holders find it so hard to manage an open publishing strategy. All you need is systems that:

• Allow users to rank content; and nominate ‘trusted reviewers’ such as those from major game review sites
• Allow wide marketing opportunities – both in-system and cross-site (such as to xbox.com, where you can buy in-browser too)
• Robust searching, on keywords, categories, user ratings, friends recommendations etc
• Cross-promotion, aka the ‘You might also like…’ lists

Hell, if Amazon can create a compelling buying experience with millions of products across a diverse range of departments, why on earth do platform holders think a console user can’t handle more than 2 game choices a week? It’s hugely patronising, and says more about the inadequacy of the platform to manage larger amounts of content effectively than about any limit on what consumers are willing to peruse. Saying “we can’t sell as effectively if we have more product available” actually means “we suck at organisation”. This argument stacks up at retail, where there’s a limited amount of shelf space, and customers don’t want to wander around a massive warehouse or to squint at shelves of tightly packed boxes looking for something, but not when you have unlimited shelf space and a cloud full of computers to index it in the blink of an eye for you (and make suggestions), and where a marketing campaign or friend recommendation can bring a customer instantly to the point of sale with the use of a simple link.

For Christ’s sakes platform holders, wake up to the opportunities of the channel. Stop being blinded by what works at physical retail, it’s really not the same. There are people out there already doing it leagues better than you (see pretty much any of the e-commerce leaders), and putting your fingers in your ears and saying it can’t possibly work  is both ignorant and doing a massive disservice to both customers and content creators.

Basically, as you may have gleaned from my previous post, I’ve been looking to make some significant changes to the way I do things in 2010. I spent 2009 reeling from a back injury and trying to figure out how to deal with that given that I’m self-employed (ie I don’t get paid when I’m not working, regardless of the reason), and a leader of an open source project (with the inherent time requirements that comes with). This meant working out on the fly how to stay afloat financially, and still keeping my own interests and open-source plates spinning, without slipping back into the ‘permanent voluntary crunch mode’ style which triggered my back problems. I can’t stress enough how difficult that transition has been for me – it’s not like anyone was forcing me to work/live that way, I did it because I wanted to, but then it suddenly had to stop. When you invest so much of your time and perceived identity in something, backing away from it is very, very hard.

Of course the economic climate wasn’t great either, meaning I spent a lot of time jumping around between many small projects, leading to more overhead dealing with admin & business relations. I ended up just going almost month-to-month on-demand, not  planning very much and just being grateful to be able to work a decent amount at all – which given how unwell I was at the start of the year was definitely something to be glad about. But, now I’m back on my feet and pretty confident of my future health again (within reason – I’m not going to be bungee jumping any time soon!), I’m ready to start being more pro-active again and to map out some plans.

One thing is for sure, there’s no going back to how I used to do things. My days of saying ‘yes’ to almost everything and being at the keyboard until past midnight most days, and most of the weekend, are gone forever. I don’t regret doing it, despite the pain it ended up causing me, because OGRE wouldn’t be here otherwise and I learned a vast amount and had a ton of fun – but I’ll leave that to the under-35s in future; have fun guys From now on, I’m being ruthless and somewhat selfish about what I work on, and concentrating on things that maximise my personal love-growth-cash triangle. It means I’m passing on a lot more projects, and concentrating far more on things that are strategically significant to me, rather than anyone else.

I’m still planning to lead OGRE, so long as the community is happy for me to do so, but by necessity I’m stepping back a bit to let other people take more responsibility where they want to, and to refocus my time on mentoring and advisory roles rather than trying to be everywhere at once. We have some great people in the team and in the wider community, and I hope our MIT license will foster even more in future. Both I and the community have gotten used to perceiving me as the ‘go to guy’ in the first instance, with responsibility for pretty much everything, but in practice for some time now it’s been very much a team & community effort, just one that I happen to lead (and financially support where needed). In fact one of the things I’m quite proud of is the way so many others have picked up on the way I do things, and taken things forward themselves in a way that I wholly approve of. That’s open source in action, and I’m glad to be part of it, even if I can no longer have my fingers in absolutely every pie with an OGRE symbol on it

Here’s to 2010 anyway. It’s going to be different, but change is good.

The best cases of companies funding open source are where they’re using it to deliver some other product or service which is directly monetised, therefore the open source development comes under their general R&D budget. Google, IBM and others fall firmly under this category, and you can bet that the largest open source software projects are funded this way – Apache, Eclipse, Firefox all pay their core developers like this. But, it requires a fairly significant level of scale to be able to do that, hence why it’s usually the giant corporations that do it rather than smaller companies.

The next favourite option is dual-licensing; the general set-up if you come at this with a commercial hat on, is that you pick a license that a lot of commercial entities will have a problem with extending from (ie GPL), then you sell them an alternative license; the idea being that you get the adoption via the open source license and make money from the commercial license. But, it can be controversial, as most recently discussed by Greg Stein in the Oracle / MySQL case.  The argument is that if your commercial license is just a proprietary license, and can be revoked and otherwise monkeyed with by the issuing company (or perhaps more importantly, its acquirers), you have actually been lured into a honey trap – the lure being that open source comes with certain protections, but that if you rely on the availability of the commercial license you actually have none of those and might as well have bought from a proprietary software vendor.

So, what to do? If you’re a small development company, open sourcing your product will definitely bring more people in, but if you’re not in the hosting / cloud business and don’t want to rely on services to earn your keep (who can blame you), what can you do to earn your keep except abandon open source for your main products (maybe splitting your time between proprietary and open source), or dual-license and face accusations that you’re fibbing about the true nature of your product for your commercial users?

Well, I’ve been wondering whether the problem is that dual-licensing typically falls back on traditional licensing concepts, ie that your commercial license looks very much like a normal proprietary license, which has all the problems of ‘what if my vendor changes the license conditions’ etc – when in fact it really needs to be more like a permissive open source license, with a payment condition. One of the great powers of open source is that it is ‘detached’ from the producer and compeltely predictable and immutable – once the software is out there, it can’t be taken away from the receiver and is always ‘whole’ in terms of the source code so no-one is tied in. There are also cast-iron source & binary redistribution clauses that are known up-front, and are again immutable, which mean everyone knows where they stand, forever. Why can’t the commercial side of a dual-license continue to do this, while at the same time generating a revennue stream for the company?

Maybe I’m being naive. But what about this sort of dual-license set-up for a library or toolset:

• Default is GPL (and obviously free)
• Commercial alternative license available, giving very permissive rights, but with these important rules:
  • The license is irrevocable once issued
  • The right to redistribute unlimited copies of derivative binary works is included with Apache-style conditions
  • The right to redistribute unlimited copies of derivative source to anyone under the GPL (for free) is included
  • The right to redistribute unlimited copies of derivative source under the permissive commercial license conditions is also included, provided the same original license fee is paid per receiver. Critically, the price and conditions surrounding redistribution may not be altered unilaterally by the licensor at any time after the license is issued (so once you’ve bought it once, the conditions and price for non-GPL redistribution are set in stone and cannot be altered unless both parties agree – say if the price is reduced later)
  • All software reverts to the Apache license if the company folds without selling the rights to someone else

This would mean that those choosing to opt for the commercial license would have the same kind of cast-iron guarantee an open source user has that once software is out in the wild and being used under some conditions, that the originator cannot possibly change that, ie take it away or change their right to modify and redistribute under conditions they agreed to at the start. To me, this seems to give the same kind of certainty over not being screwed over in the future as open source does, thus blunting the accusations of proprietary lock-in by the back door, but while generating some revenue for the developer too. It is, in effect, the same as a permissive open source license with the one addition that redistribution of the source to a new party requires either payment to the originator, or reverting to the GPL.

Now, of course there is still potential uncertainty around new versions of the software, but this is no different from open source, where your only guarantee is over what is published right now, not what might happen in future versions.

Does anyone know companies that use this model? My experience is that commercial dual licenses tend to be as restrictive as proprietary licenses, which then can justifiably lead to accusations that the open source license has been used as a shill to get people into a lock-in scenario. Is there really a ‘third way’ or am I missing the point?