Open Season is a podcast about open source issues, weighted towards the practical rather than the philosophical, and as such I tune into it regularly. Some are better than others, but I found the latest Episode 13 quite interesting for a number of reasons. They had an analyst from RedMonk on board this time, which was fascinating - RedMonk are (AFAIK) the only research firm that release their results openly rather than charging a few thousand for detailed papers, so they’re quire interesting. They talked a little about the practicalities of the Microsoft ‘we’re open, honest’ announcement of course, and largely reinforced my own thoughts on it - that while you have the ‘non-commercial’ clause in there it’s nice to have, but not really a practical shifting in the overall commercial landscape. The Zuckerberg interview came up too, as did how Grandmas really can use Ubuntu.
I also enjoyed their musings on remote working too - since I’m now working almost 100% remotely myself. The open source movement has been a standard-bearer for how remote working can work really well when done right, and I do think that with the right organisation, and the right people, it can work just as well for many tasks as cramming everyone into an office. You do lose a certain amount of social contact, which is an adjustment for sure, but I think communicating effectively and team-building across remote links can definitely still be done, it just requires a different approach and a little more effort. Open source communities that work well (and I’ll venture that Ogre’s qualifies) have built up expertise in the mechanisms for doing this, and the same approach is slowly becoming more common in commercial environments too. I don’t think you can run all projects long-term with no personal contact, but you can certainly run many of them for a long time that way, provided you find the right people, and the organisation can cope with the logistics.
The main project I’m involved in right now is almost 100% remotely developed, for example, our team members are in 6 different locations in 4 countries, and it’s actually working really well. I think it helps a lot that everyone on the lead team is a remote worker, even the project manager - so there’s no feeling of a 2-tier system. Time zones can be a positive and negative thing - on the minus side you’ve got the fact that you might only sync up for maybe 4 hours a day on IM, but on the plus side different team members can be working on something while the others are away from work, meaning you can get into work the next day and find you don’t have to wait for whatever it was they were working on - so staggered effort has its advantages too. What’s most important is that each team member has specific areas of responsibility and are mostly autonomous, so cross-dependencies are minimised. It really requires that each team member is an experienced developer & team worker already - it really wouldn’t work with junior staff who might need more assistance, training and so forth. What you lose on the social end, you gain on the ‘uninterrupted concentration’ end - something which anyone who’s had to work in an open-plan office at some point will understand. With today’s technology you’re not entirely disconnected either - IM can in some ways be more productive than over-the-desk crosstalk, in that it a) doesn’t bother anyone else, and b) can be deferred & caught up with later if you’re in the middle of something. It’ll never be as good as a chat over the coffee machine of course, but nevertheless the detachment is not as total as one might imagine.
The boundaries that this arrangement breaks down are not to be underestimated either. It can’t work for a lot of businesses that need a critical mass of people in one place, but for discrete project work, being able to cherry-pick any talent at all no matter where they’re located is a very powerful model - in the past it’s just been the logistics that have proven difficult. It tends to require a more experienced and flexible workforce (freelancers / contractors rather than salaried), and it requires absolute buy-in from the project management, but for many situations it’s ideal.