SteveStreeting.com

Before 2009, I’d never set foot in Germany before; not for any particular reason, I just hadn’t gotten around to it yet. However, thanks to gracious invitations to conferences I’ve now been twice. In May I went to Stuttgart for FMX, and last week I went to Munich for Qt Developer Days.

It was an enjoyable conference, as always the best part is just meeting other delegates, the sessions themselves are merely the icing on the cake. I shared my presenting slot (in which I showed a couple of applications that use Qt and Ogre together) with two other open source veterans from projects which I have a huge amount of respect for: Bill Hoffman, CTO at Kitware and the founder of CMake (which of course we use in Ogre now, so it was great that I had chance to have quite a few discussions with Bill), and Jean-Baptiste Kempf, Chairman of VideoLAN which is of course in charge of the excellent VLC.

It was also nice (not to mention flattering and somewhat humbling) to have random people I’ve never met before spontaneously say nice things about Ogre. One of the major curiosities of open source is that you never really know quite how many people have encountered & used your software; you get a sampling of that through your community forums etc, but it’s also clear that that only represents a portion of your user base. On the day I was wearing my Ogre T-shirt I had a number of people who were more peripherally involved in the community but who had had a good experience with Ogre, and were more than happy to tell me about it. Definitely a good feeling.

Perhaps most surprising of all though was getting a sizable donation to Ogre in person from a community member while I was there (I won’t mention who just in case he’d rather not be identified, he can post in the comments if he’s happy to). We had what I thought was a theoretical discussion at one of the dinners about how much we get charged by PayPal for donations, and I’d said that although it’s undesirable, any kind of electronic payment mechanism has a cost (merchant accounts, bank transfers all come with some kind of charge). I jokingly said that the way you’d avoid the most charges would be mailing cash in an envelope, although that had it’s own risks. I thought nothing more of it, until I saw him the next day when he presented me with an envelope with a donation in it! Way more than I expected too, enough to push him straight to a Platinum sponsor. Turns out he’d just got his deposit back on a flat he had been renting, and decided to donate that to us in the absence of any code contributions, since Ogre had helped him at university and subsequently in getting a job. I have to admit, I was a little lost for words at that! His donation will definitely help cover the server running costs in the coming few months.

Back to the conference subject, Qt, the conference reinforced my opinion that it’s the best cross-platform UI system out there for C++ developers. It was great to see the range of applications that were being developed on it these days, including a coffee machine which was serving custom beverages in the dining area via a Qt interface. Obviously the Nokia acquisition has meant that they’re keen to move into more dynamic, touch-based interfaces too now, which will obviously power new phones in more interesting ways, but it was clear that they remained committed to a huge range of application targets. Well, except iPhone anyway, that was definitely the elephant in the room – occasionally mentioned but mostly avoided

Obviously Qt’s switch to LGPL this year will have a huge impact on adoption rates. One of the things that had concerned me though is that there’s a clause in the commercial license for Qt that requires you to decide between using the commercial license and the LGPL before you start developing. The reason given for this is that Qt is licensed on a per-developer basis, so if you could wait until deployment to choose the commercial license, you could scale back your team and pay less than you really should have done, which is why you have to decide up-front. I could understand this argument, but in my experience, perfect foresight is impractical and conditions can often change, so making a once-and-for-all choice before a line of code is written did not seem realistic in some cases. Also since the principle was that the entire team must use the same license, I was wondering about the practical implications of say, a commercial outfit leveraging some pre-written code by people using the LGPL version (such as QtOgre). Qt want to encourage greater community involvement (which was the reason for me being invited to the conference after all), so not allowing this seemed to go against the kind of broader adoption they were chasing.

To try to answer these questions, I went to the legal presentation and put this question to the speaker afterwards. Luckily, she mostly allayed my fears on these two issues. On the ‘circumstances change’ issue, the principle must remain that, because of the per-developer licensing, you should make your decision up-front, but if for whatever reason, and in good faith, conditions change (such as suddenly having to target a platform where LGPL is not practical), then some kind of agreement can be reached, such as by paying commercial fees for all developers historically on that project so it comes out the same as if you had opted for the commercial license originally. In addition, she didn’t think there would be a problem with community code re-use for commercial licensees provided this was mentioned during the commercial licensing process; she accepted that greater adoption is what they want, and community development inherently complicates the previous assumption that one team will be responsible for absolutely every aspect end-to-end.

So, a good conference overall. Now, I’m back to continue work on Ogre 1.7.

I’ve been involved in open source for a long time – probably what might be considered a ‘generation’ in this industry. I was a fan of open source before I even knew the term existed – during my formative coding years in the early 90′s I was always releasing code for free and encouraging people to tell me why it sucked, and doing the same for them. Of course, most of the discussion went on over FidoNet, BBS-relayed emails, the very early (pre-WWW) internet and code on FTP sites, but the principle was much the same.

It was only when I needed a host for an increasingly large 3D engine I’d been writing in 2000 (which later became the earliest version of OGRE) that I discovered Sourceforge and open-source licenses. At that stage, I didn’t really care much about the minutae and just went with what seemed the most popular choice – the GPL. Fairly soon after this was revised to LGPL because it was clear GPL wasn’t a flexible choice for a library. Over the years I formed the opinion that the LGPL was a good balance for what I was doing – it allowed use in proprietary applications but required that modifications to the open-source part were passed on; and this also, I thought, encouraged contributions back to the core since it’s simpler to have your changes promoted. The downside was that the license is pretty long and full of legalese, and frequently needed explaining & clarifying. Still, I considered that a necessary cost of a license that ‘protected the interests’ of the open source project. I had considered more permissive licenses like zlib and MIT to be too weak -  giving everything away with no conditions encouraging reciprocal contributions or participation.

I only really started to seriously question this long-held opinion recently, shortly after I had to deal with a license violation issue. The details of this are irrelevant (and will not be discussed here), the important thing is that after all the dust had settled, it really made me sit down and take a long, hard look at what open source licenses actually achieve in practice, and which bits I felt were the most important for sustaining my projects.

Purist free software advocates subscribe to the view that all software should be ‘free’ (as in speech), which is, when you boil it down, a philosophical principle. While the intention is often genuinely altruistic – enablement for all developers and users of software – in a practical sense it is also a highly prescriptive, black-and-white approach. Free software licenses like the GPL restrict as much as they enable, on the basis that not to do so would deny future users of the flexibility to alter the software. It’s an understandable point of view, if very hacker-oriented, but it’s not one that I personally sign up to. I’m not involved in open source as a ‘movement’, in order to ensure that all users have access to all the source code of every application they use. Instead, I’m involved in open source because I think it’s a damn good way to get good software written for the benefit of the many, particularly infrastructural elements that can then be used to innovate faster, by smaller teams, to challenge incumbents, and generally shake things up. I’m a firm believer that open source and proprietary software can be good bedfellows, and that each can benefit the other – open source providing solid foundations for proprietary innovation, and proprietary software contributing to the open source projects underpinning it, in terms of code and funds. In that context, the restrictive elements of the LGPL seemed well-placed – the LGPL allows proprietary use, but modifications had to be passed on.

But, after much consideration and hard self-questioning in recent weeks I realised something important. Of all the people that have contributed to OGRE over the years, I can’t think of a single good code contribution that has come about because the license conditions encouraged it. All of the people who have made a significant positive contribution to OGRE have done so because they chose to do so. Either because they wanted to do it for fun, or because they saw that it was in their own interests as users, they sent patches in, created new add-ons, joined the team etc. None of these people required any coersion from a license to do what they did, and all the better for it – because they chose to do it, they tended to be more forthcoming in terms of adhering to standards, answering questions about their contribution, and generally participating in the community rather than just doing a minimal code-dump.

The other thing I considered was the impact of someone modifying OGRE and not publishing their changes. On the one hand, this is a potential for a lost contribution, but in practice the LGPL conditions are only to pass on the source to others, not to contribute back to the core project (which requires a contributor agreement anyway), and as mentioned we’ve already established that the best contributions are from willing sources anyway. Then comes the principle of whether it matters that the end user is not guaranteed to see the modified source of OGRE – free software principles say this is not right, but I have to say that in practice, most end users don’t care and in practice it’s of little consequence for OGRE. Obviously many people in the free software camp would disagree strongly with this. It’s more of an issue in enterprise apps where a customer who receives a significantly customised application from a vendor, and needs to keep maintenance in mind; IMO regardless of whether the software is based on open source the customer should be insisting their vendor delivers source anyway – that’s what contracts are for. But I digress.

So, after much thought I concluded that the most useful pay-backs to an open source project, and thus its community, from a user (in my opinion) were:

1. Code & documentation contributions – which based on my experience come from voluntary sources
2. Community participation – forum support, bug reports etc
3. Publicity.

The ‘restrictive’ elements of the LGPL (and GPL), to which so much confusing license text is dedicated, didn’t seem to contribute to any of those except number 3, and then really just as a side-effect.

It was at this point that I realised that my previous opinions about permissive licenses not providing enough safeguards against exploitation for an open source project were off-base. In practice, open source projects don’t really need protection, because their best contributors are going to be there regardless (yes, I realise the GPL provides more protection to end users who want to get at the source code, that’s not what I’m considering here). ‘Freeloaders’ – people who use or modify the open source project for their own ends but give no code or community contribution back – are always going to exist; even under the GPL it’s easy to freeload, if you make your money from hosting services for example, and thus license choice has little impact on the scale (if not the nature) of the freeloading. Besides the annoyance of ‘that guy took my work and made some money out of it’ – which you have to accept as an inevitable outcome of going open source, so stick to making proprietary software if that bugs you – freeloaders have little negative effect on an open source project, and actually their use can contribute positively to item 3 (publicity). The key is to recognise that in practice you can really just ignore freeloaders, and instead concentrate on maximising the positive contributors in your community.

So, if we acknowledge that the people whose contributions we actually want are those who contribute voluntarily, regardless of license, we quickly come to the conclusion that all that really matters is the size of the community. It’s a fair assumption that for a given project there is a relatively stable percentage of users who will choose to contribute back (the percentage itself varies per project, but is fairly stable per project in my experience), therefore the easiest way to increase your contributors is to just increase your user base. Forget about trying to coerce people into being ‘good’ members of the community, just trust that the percentage will be there and will track your overall numbers.

One way in which to attract more users is to make the licensing simpler and more easier to understand. Programmers hate legalese, and a simple, clear license is bound to be more attractive than our LGPL (with static link exclusion), plus OUL option. It’s for this reason that from OGRE 1.7 we’re switching to the MIT License.

I’d like to thank Matt Asay for his post on the subject, which really jump-started my thought processes on this subject in the last few weeks. This whole process has been a reminder to me that it’s always good to re-examine your previous assumptions and opinions in the light of practical experience, and to be prepared to reach different conclusions than you did before. The whole open source landscape is constantly changing and maturing, why should those of us immersed in it be any different?

Ok, so I’ve posted my initial feelings about tinkering with Mercurial and Git, and that seems to have generated some interest. It’s time to get a bit more formal about how I’m going to evaluate them against each other, to decide which one I like to use most in real, practical scenarios. So, I decided to come up with a list of use cases for the things that I typically have to deal with when managing the repositories for a software project (open source and otherwise), so that I can methodically test them out and see how I feel about each system. I’ve tried to deliberately include use cases for things that you can’treally do on a centralised system, but that I’d want to make use of, as well as the usual nonsense that happens day-to-day on a typical project

I’ve presented my work-in-progress list below, feel free to suggest more use cases I can test. I really want to see what these things are like in practice in the kinds of situations I encounter in real projects, without actually risking a real project in the process! Like a backup / restore strategy, it’s no good doing it for the first time when the sh*t has already hit the fan.

Oh, and for fun, allegedly Git is MacGyver and Mercurial is James Bond .

Due to the nature of a DVCS, all these use cases must be tested both in isolation, and  after pushing those changes to another potentially ‘superset’ repository.

1. General
   1. Commit a few changes to local repository ‘A’ but don’t push to central yet. Push a number of different changes to the central repository from a different repository ‘B’. Then, pull ‘B’s changes from the central repos to local repository ‘A’  to bring it up to date, again without pushing A’s outstanding changes yet. This is equivalent to doing an ‘svn update’ while you have local uncommitted changes in Subversion, but while using the local commit features of the DVCS. How does this work in practice? [Suggested by Arseny Kapoulkine]
2. Branching
   1. Create a new public, official branch (stable branch)
   2. Create a new long-term feature branch which is intended for public consumption / collaboration
   3. Create lots of short-term development branches (or equivalent structures) intended for local consumption only
      1. What are the size overheads? (Git claims superiority here)
      2. Does this excessively clutter the public repository when pushed?
      3. Is there a better way of handling multiple local changesets which you may or may not decide to push individually, such as testing many patches (Mercurial queues seem very interesting, Git equivalent?)
      4. . Rename a branch? (optional)
3. Merging
   1. Merge changes unidirectionally from one branch to another, without having to manually pick revisions. Make more changes in the source branch and repeat.
   2. Bidirectional merge – a feature branch which is not yet ready to be merged into the trunk wants to resynchronise from the trunk and continue branched development. Merge of this branch into the trunk must be tested later after further changes
4. Tagging
   1. Create a tag against a specific branch; probably at the HEAD but look for the option to specify a revision
   2. Correct / modify / move a tag following a mistake or last-minute revision (pre-release) without having to make duplicate commits or other such spurious activity
5. Firefighting
   1. Screw-up: developer commits change to trunk instead of stable branch. Merge / move it to the stable instead – change can be left in the trunk or can be removed for re-merging, so long as the procedure is clear.
   2. Screw-up: developer commits change to stable branch that is interface-breaking, must be removed and moved to the trunk. Must be removed from the stable branch and moved.
   3. Screw-up: Revert a single change from the repository, that is not at the HEAD
6. External patch submission tests:
   1. Patch file from same branch, no conflicts
   2. Patch file from same branch, with conflicts
   3. Patch file generated on a different branch to the one we want to apply it to (include conflicts)
   4. Pull from third-party repository, entire branch
   5. Pull from third-party respository, specific changes
   6. Patch file generated from non-repository source copy
7. Backup multiple work-in-progress changes on a local machine that are not ready for public consumption; approaches:
   1. Store a patch per local branch (this is how it’s done with SVN, but too much hassle if you use lightweight local branching, DVCSs can do better)
   2. Push to a backup repository on another machine across existing protocols – ssh, https, Samba share (Git can’t do the latter?)
   3. Push to a backup respository on a USB stick (Git can’t do this?)
8. Binary files
   1. Revise a binary file over a few versions, test storage efficiency
   2. Binary file conflict resolution
9. Conversion from Subversion
   1. Import retaining history
   2. Import multiple branches
   3. Import tags
10. Integration
    1. Mailing list / RSS notifications of commits on official repository
    2. Bugtrackers
    3. CIA.vc et al?
    4. Good free & open source GUI clients for all platforms
    5. Line ending conversions between platforms

I’ve been interested in DVCS for a while; having done my fair share of branch management, something which makes that process easier and more transparent is definitely very attractive. I particularly like the way a DVCS makes it easier for people to collaborate in pockets of their own, away from the centralised environment, and track other repositories and keep their local mods up to date more easily – public-branch-on-demand if you will. However, I’m yet to be convinced by Git for everyday use. As noted, I love the idea, but Git comes across as – and this is an ironic thing for me to say – excessively geeky. At one time I might have believed there was no such thing as a plethora of geekery, but I like to think I’m a more rounded individual now

Don’t get me wrong, I’m sure Git is technically excellent. But a number of things about it remind me of the somewhat stubborn purisms of  ‘old Linux’, such as:

• The documentation is hugely daunting. Whenever anyone tried to convince me why Git is amazing, they point me at documentation that just makes me not want to touch it for anything important. The impression I get is akin to some Linux forums: – this thing is powerful, but it gives you plenty of rope to if not hang yourself, then to tie yourself in knots if you don’t know what you’re doing.
• It requires a Unix back end, to the extent that you have to run it under Cygwin on Windows, and its rigid filesystem requirements mean it won’t work on FAT or Windows network drives. I get the impression there’s something rather aloof about the fact that the core team don’t consider it an issue that Git won’t run on native Windows environments. There are external projects working on that, but the fact that it’s not core is a concern, since I prefer all my 3 platforms to be supported equally.
• The UIs still don’t seem very user-friendly, and most responses I see to the question of why that is boil down to “Git is too powerful to be captured in a GUI”. Sorry, but I don’t buy that – no system is too complex to be captured in a user-friendly tool, it just takes the will to do it, and like ‘old Linux’, there seems to be little will to make Git more approachable.

So, I’ve never had great vibes from Git, despite it’s doubtless technical merits. So, I decided to check out Mercurial instead – from what I read, Git is the fashionable DVCS that all the cool kids want to be seen using, but when it comes down to it Mercurial does exactly the same thing – except that it has native support for all platforms out of the box and TortoiseHg is looking pretty mature. I also read that it handles binary files better than Git too, since it does binary diffs everywhere. The documentation seemed much more approachable too, so I figured I’d have a play.

My first impressions are incredibly positive. The most impressive thing of all is that I imported a (relatively small- about 100 revisions) Subversion repository, with all the history intact, about 5 minutes after installing it, and was bouncing that across Linux and Windows immediately afterwards (haven’t tried OS X yet). TortoiseHg is instantly familiar, and despite the fact that the concepts are the same as Git, the presence of some familiarity, together with some distinctly less intimidating documentation, has me feeling far happier than the times I’ve dipped into the Git docs. Mercurial’s approachability is a positive contrast to Git’s Unix-purist, RTFM style I think. I know which I prefer so far.

Edit: this script is deprecated in favour of a rewritten version 2.

I use Amazon S3 to host large media files which I want cheap scalable bandwidth on, and for expandable offsite storage of important backups. I used to have some simple incremental tar scripts to do my offsite backups, but since I moved to Bacula, I’ve just established an alternative schedule and file set definition for my offsite backups, the critical subset of data I couldn’t possibly stand to lose (like company documents). Since I was refreshing all my procedures and tarring the Bacula volumes no longer made any sense, I rewrote my script for putting the resulting backup data on S3.

The prerequisite in all cases is s3cmd, which is pretty mature now and available on most distros (“apt-get install s3cmd” and you’re done on Ubuntu). s3cmd actually has a ‘sync’ command, but firstly that tries to sync in both directions, which I don’t want (I know in theory it should never overwrite any local version so long as I don’t update the remote copies from somewhere else, but I’m paranoid when it comes to my backups and prefer to be explicit), and secondly it obviously has to connect to S3 to determine the sync status, wheras I always know whether I need to upload new files just from my local environment (and S3 charges per request – not much, but it’s not zero and it’s the principle of the thing). So, I decided not to use the ‘sync’ command, and just determine locally what new files I needed to ‘put’ on the server.

Secondly, encryption is a must, since some of the data is sensitive and I don’t want to trust anyone else with it. I used to manually GPG my tarballs before uploading them, but I noticed that s3cmd supports an encryption option too. It just uses GPG anyway, just in symmetric form rather than asymmetric like my version did (translation: you use the same passphrase for encryption and decryption; a little less secure than using generated public/private keys but still ok so long as you pick a good passphrase and look after it). The default symmetric algorithm in gpg is CAST5 which seems pretty good, although you can change it if you want by editing your s3cmd config file. So, I decided to give it a try – after you configure s3cmd to use encryption, it actually automatically decrypts too when you pull the data back (symmetric key, remember) – being distrustful, I pulled the data back from S3 in a different environment and examined it, and it was indeed complete gibberish, but decipherable with the passphrase. Good stuff.

So, here’s my little script which will upload the encrypted contents of a folder to S3 – just the contents that have been added or updated since the last sync of that folder, and will encrypt them by default. I just run this on a cron schedule now and it seems to work fine. License is MIT, use at your own risk, no warranty is given that it won’t destroy every file on your machine or eat your children. Usage is like this:

s3putsecurefolder /my/source/folder my.s3.bucket

Edit: it was brought to my attention that Amazon have made it easier to create pseudo-folder structures in S3 buckets since I last tried to do it (I swear it used to throw out keys with forward slashes in them, I had to mangle my names last time I did this), so I’ve updated the script to allow nested folders too.

Quick check – ok, the sun is in fact not as black as sackcloth. But today, something earth-shattering happened – Microsoft has contributed code to Linux.

I’m sure I’m not alone in thinking that I’d never live to see the day this happened. It’s 20,000 lines of driver code to make Linux run better under Hyper-V, which is of course in their interest (since you have to buy a copy of Windows Server 2008 as the host) , but that’s par for the course for open source contribution (you scratch your own itch!), and it’s a massive watershed regardless. From what I hear there’s still a lot of concern at Microsoft about how to manage contributions across the company boundary (in both directions), so I’m not sure what extra procedures they would have put in place for the developers involved in this process to keep the corporate legal army satisfied – perhaps pre- and post-project selective mind-wipes – but the fact that they managed to make it happen is a big deal.

Microsoft has wielded by far the most acrid rhetoric about open source in the past – we all hear that it’s changing, and I know particularly of specific people at Microsoft (mostly developers) who take a much more open view, but it’s hard to escape the feeling that while the top brass who set the ‘old’ policies remain in situ, substantive change will be difficult. But this move is one of many lately that make me think that just maybe, people higher up the chain are starting to get it. Or at least, they’re starting to defer to people who know better.

I’d argue that very few people in the open source community are inherently anti-Microsoft, they’re just a little more free-thinking when it comes to technology choices, a little more honest with their opinions, and have come to view MS as ‘the enemy’ primarily because of the old rhethoric the company used to use on a regular basis to attack them (and some parts of the company still don’t seem to be getting the ‘openness’ memo – as TomTom found to their detriment). Microsoft, or rather, Mr Gates and Mr Ballmer specifically, effectively made themselves the enemy of the open source community with their often ill-conceived tirades, and that’s something that will take a long time to heal. But, as we all know, actions speak louder than words – and if the company continues to make these kinds of conciliatory moves, they will start to win people in the open source community back, at least those people that judge on facts rather than old predjudices.

Trust takes a long time to be earned, particularly from where MS started from, so it’ll be a long road – but if this is how things are going to develop in future, then bon voyage, MS.

So, after much initial confusion, sabre-rattling, dispair and finally acceptance (sometimes grudging), the world now pretty much groks open source. In addition, we’re all getting better at doing open source – it’s increasingly obvious what the best practices are in terms of growing and developing an open source project, and of how businesses as well as hippie coders can use and produce it effectively. Increasingly, open source is a known beast, and those that don’t embrace it in some fashion are increasingly looking hopelessly luddite. It’s all a far cry from 10 years ago when merely suggesting open source in a serious environment would get you some curious looks  – having been the recipient of many of those looks over the years, it’s satisfying to be able to pull out the ‘I told you so’ line now and again

So, open source is mainstream – that’s good. So, apart from gradually filtering into the last few bastions of old-skool thinking (console vendors, I’m looking at you – how about returning my calls sometime, mm?) , where do we go next, besides more of the same? A wild-eyed revolutionary could get bored with all this mainstream acceptance, after all

I think Matt Asay nailed it in his post today. Open source only works at optimum efficiency when you’re accepting of outside contributors, and the worldwide melting pot / distillery is on full, mixing up and crystallising the best the community has to offer. But, due to the nature of this, all the people involved by nature tend to be technicians – programmers, sysadmins, people with a technical bent with a problem to solve, and some time to contribute to help make it happen. As Matt says (and as I’ve said here before), it’s why Linux is hugely successful on the server and with device builders, but less so on the desktop with real people. He says this:

But the real goldmine is broadening the definition of “developer” to include lay users of your software. The day that I, as a nontechnical software user, can meaningfully participate in an open-source project is the day that open source will truly have won

This is dead-on. There’s a perception that only developers and techs like to contribute to projects like open source, but that’s not true at all. There’s a certain cache of people from all walks of life that like to contribute to creative endeavours, who have ideas and the ability to express them, and their abilities are entirely complimentary to a technical team creating a product. Hell, I’d go as far to say as they are absolutely essential to the construction of any product that’s aimed outside of the technical user market. Anyone who has been involved in a large software project, and who isn’t an elitist prig, will know that you need your ‘lead users’, really, really badly. These are the people that aren’t usually technically minded beyond being a user of technology, and being open to change, but who are smart enough, and experienced enough in the domain, to know what needs to be be built, how things can be improved, and how a wider population will perceive it. They will regularly come up with points that you, as a developer, would never have remotely considered, and will make what you produce far better than it ever would have been without their input.

In large commercial projects these people are usually on the payroll as analysts, liasons, testers, technical writers, and other roles. Yet in open source, they are vastly underrepresented, because open source typically starts with a developer scratching their own itch, then attracting like-minded individuals. There’s a chicken-and-egg issue around getting non-technical people involved – they won’t necessarily be interested unless there’s something they want to use, but the product may not exhibit those aspects in the first place without input from like-minded people. As a developer it’s easy to get on board and complete the value-circuit quickly with a couple of patches, but it’s much trickier for other roles outside of a long-term project arrangement.

I’ve been lucky enough to be involved in projects working alongside really excellent lead users in the past, and I make a point of calling out developers who talk about ‘users’ in derogatory terms. Smart, experienced but non-technical users are like gold dust, you want to hang onto them with both hands, even if they do give you feedback you don’t always want to hear. If, somehow, we could encourage greater participation from these kinds of people in open source, I know things would be the better for it. How? I have no idea yet

There have been cries of joy on the intertubes recently from people who like .Net but who like using it on non-Windows platforms (or believing they have the option to do so), in that Microsoft has extended their Community Promise to Mono, meaning they won’t sue over uses of it. Or so it’s been rather shallowly reported in some circles, more on this below. Firstly I’ll just say that no matter what, this is a positive step. I’ve long thought of Mono as a technically excellent project which an awful lot of uncertainty and legal confusion around it, which was only really made worse by the highly specific arrangement that Novell and Microsoft brokered a while ago.

What this announcement does is bring some clarity to the situation, which is good. However, I think people should hold off putting the bunting out just yet, because as ever the devil is in the detail, and the promise only in fact covers ECMA standards 334 and 335 – that is, C# and the CLI. As anyone who has used .Net knows, there’s an awful lot more to it than that, and this promise is currently equivalent insuring the wiring and plumbing in your house, but none of the contents. So it’s nice that these standards are now explicitly covered, meaning that projects that solely rely on C# and the CLI plus other completely independent components are safe. But if you’ve used anything else, such as any of the recreations of the rest of the .Net framework, you’re still on very uncertain territory, and in some ways you could say it’s even more uncertain, since clearly Microsoft omitted those from this promise for a reason (which may be a deliberate, strategic position, or it might be that they’re just not ready to take that more significant step yet – we don’t know).

Mono intends to cope with this by providing clear dividing lines between what’s covered and what’s not, which is very sensible. However, I do suspect that will result in the vast majority of the stuff that developers actually need to rely on when writing what are generally considered ‘.Net systems’ (such as implementations of core components of the .Net framework) will still be in no-mans land. Thus, while this promise does move things on in a positive way, in many ways it again casts light on how uncertain the legal position of the other elements is. Personally, my position is pretty much unchanged from before – if you’re writing ‘.Net applications’, that is, using the .Net frameworks, then you’re targetting Windows, don’t fool  yourself into thinking otherwise. There’s certainly scope for using C# and CLI in cross-platform scenarios (which was the safest course even before this announcement, since those were the only standardised parts), but on the basis of both legality and conformance I’d say it’s best to stay away from any .Net framework components if you intend to be cross-platform.

Maybe MS will extend this promise to the older .Net framework versions later on; that would seem a smart move, get people on the ladder but keep all the new stuff to yourself?

Guitar Hero and Rock Band have been derided by some, with extensive cries of ‘learn a real instrument!’; however it’s my experience that by making simulated instrument playing more accessible to the masses, these games are responsible for many taking up an instrument for the first time, or reconnecting with a previously abandoned musical hobby.

It’s the latter for me – I was heavily involved in music throughout my school days, until an overly pushy music teacher sucked all the joy out of it (what, you have a free evening / weekend that you’re not playing music in? Heresy!), to the extent that I did the typical ‘teenage overreaction’ and quit every school orchestra, band, choir (yeah, I know, deeply uncool), music exam (I quit part way through grade 7), and extra-curricular musical activity (and there were many) all at once. It drove her nuts, which was highly satisfying, and was a wonderful release for me to go do other things, like learning how to code. For years I didn’t look back.

Rhythm-action games re-awakened something in me that I’d forgotten was there – a love of participation in music. I think I had a long-established psychological block that associated playing music with something that was all hard work and no fun, because that’s what my experience had turned into. Sure, the games highly simplify the process, but that’s the point; by hiding the ‘work’ part away for a while, for me they reconnected a mental circuit between ‘playing music’ and ‘fun’ again which had long been broken. It’s been highly theraupeutic, and considerably cheaper than a shrink

So, I’ve picked up playing the guitar, and I’m getting along fairly well I think, but most importantly I’m enjoying it. I’ve also discovered via Rock Band that I find drums very satisfying, and I seem to have a fair amount of natural ability there – maybe not compared to some people online, but I’m competent enough to enjoy playing some of the moderately complex tracks the most (Keith Moon, you really were unique).

So, I’ve decided to buy a real drum-kit later in the year and see if I can learn to play for real. I’m going to wait a few more months, because I still have some problems with my back which disrupted my ability to play even simulated drums for a while, but as I’ve recovered I’ve been able to play more and more comfortably again. I’m not going to risk practice-related injuries before we go on holiday in August/September, so I’ll probably look to start in the autumn. I’ve pretty much decided what practice kit to get: the Roland TD-4k, which seems like a good starting point. I don’t really have room for a full acoustic kit, and an electronic one will be a little easier on everyone else Plus, the Roland’s sound really good these days, and I’ll be able to plug it into Rock Band if I want as an added bonus via a converter. Edit: slight issue with the TD4 though, you can’t individually map the MIDI codes for the open and closed hi-hat pedal (you can map open, and closed is assumed to be open-4 which won’t map to blue/yellow) – for that you have to go to the TD9 (more expensive) or the Yahama DTXpress IV (same price or cheaper but the pads & sounds are not as nice). Hmm.

I think it’ll be fun to learn anyway. I’ll probably never get as good as the guy below (acoustic cover of one of my favourite drum tracks in Rock Band), but as something to do away from the PC it’s a little more productive than just watching TV or playing games, and a nice bit of variety combined with the guitar. And it probably counts as a work out

I can’t remember who made the assertion / joke that if you looked through an infinitely powerful telescope you’d end up seeing the back of of your own head, but I was reminded of that by a certain event today. In the last couple of years I’ve often Googled for a particular subject and ended up with the top hits pointing me back at one of my own posts in the OGRE Forum or on my blog, in a weird self-citing manner. In the worst cases, these posts answer or clarify my own current question, because a thought process I’d had a few years before, and then forgotten about, can often be useful. It’s like having a stack of your old notebooks in the cloud! Or an archived clone of yourself pointing out how age is making you stupid.

The other weird experience is when you download or otherwise get hold of a piece of software, and unexpectedly find that it uses your own code. I’m sure this is common in open source circles, because users of open source don’t have to tell you when they use your code, but nevertheless it’s still an odd experience. It’s especially nice when you like that piece of software – this happened to me today with PixPlant 2.

As I mentioned yesterday, I was reviewing tools for normal/displacement/specular map generation from reference sources, and I’d been evaluating CrazyBump and ShaderMap Pro. Evak in the OGRE Forums suggested I try PixPlant2 because he liked it. So I did, and I was impressed – the texture generation seemed as good as CrazyBump, but it’s cheaper ($175 rather than $299), and it also includes tools for creating tileable textures from original sources, detecting repeating patterns, straightening things, and blending the edges for you.

So, I was already leaning towards this purchasing PixPlant2, but then as I was browsing for textures, I noticed that the PixPlant2 application folder had some familiar files in it – such as OgreMain.dll, and rather familiar material files in the media folders! Checking the docs, sure enough OGRE was credited as a dependency. The application I ended up gravitating towards included software that I wrote!

To cap it all off, they’ve been very nice and offered me a free copy, so my normal map generation needs are entirely satisfied, for far less than I was expecting to pay. It’s not often things work out quite so well!