Does all 'Collaboration' Have to be Face-to-Face?

Eugenia Loli-Queru just wrote an interesting blog post on why Linux will never be as good as OS X from a desktop user experience perspective. I’m not 100% sure I agree with her (even though I’m a Mac user), but I certainly see her point. However, she lost me when she made the somewhat overarching claim that Open Source projects cannot be effective unless everyone is ‘on the same campus’. I consider Eugenia a friend, and I know she was specifically referring to the desktop experience in this case, but her point about face-to-face collaboration being necessary for success needs some closer examination.

I think we have plenty of examples to the contrary, such as the Linux kernel itself, SVN, Firefox, GIMP, etc. In a perfect world, you would be able to have everyone sitting right down the hall from each other, but in today’s global economy, that isn’t always feasible for Open Source, or businesses for that matter. I think a larger factor in success of collaboration is the ‘culture’ that is involved. In successful Open Source projects, as Jack Repenning noted earlier today, there is true community based on meritocracy. I’d like to think that the results speak for themselves in successful projects that have remote collaborators. I will grant Eugenia this: in the Open Source world (or the business world for that matter), projects that don’t foster this sense of collaboration/community/common goals often end up devolving into chaos.

Despite what some might think, my choice to come to CollabNet was less about the tools themselves (which I believe in 100% as a former customer) and more about what I hope that we as a company can do when talking to clients about collaboration and how to do a better job of it. I believe strongly in what Jack has said about ‘innersourcing‘, because I saw that work in the pockets that my former team at Motorola pushed it in.

Selling a toolset like ours to improve interactions and project management is only 50% of the equation. If we cannot help our clients build collaborative communities (local and remote) that use our toolset, I think we are missing a significant part of what differentiates us and makes us successful. That is the reason I wanted to take on the challenge of ‘Community Management’ for our clients – there is a lot of value (and excitement) in applying the lessons of successful Open Source projects to corporate projects.

I’d love to hear opinions from folks reading this – in your experience, does collaboration always require face-to-face interactions? What tools or processes have you or your teams used to bridge the geographic ‘project gap’?

Tagged with: , ,
Posted in TeamForge
3 comments on “Does all 'Collaboration' Have to be Face-to-Face?
  1. Dr K says:

    I’m 100% with you, Guy (as you may have guessed). I would have to add that it is not just the tools that foster this ‘distributed collaboration’ but also the communication skillset of the team members involved. I would say that the base essential tools for us have been IM, SMS (texting for you youngins), and Wiki. One might also put desktop sharing (VNC) in that list as well. The problem is that you can have that same toolset work wonderfully for a certain talented group of distributed individuals (ahem) but have it fail miserably with another. Some people’s brains, habits, socialization skills, or whatever are barriers to this working for them at all. How can this be overcome? Darn good question.
    Members of the open source community generally possess this communication/collaboration skillset to work in a distributed team. After all, it is pretty much a base requirement for being a useful contributor to an open source project. But how can that be learned? Can you teach an old dog new tricks? A lot of people in the corporate world are young enough that these methods of distributed collaboration are second nature. There’s also a lot of people that aren’t comfortable with communicating electronically at all. Can an old dog be taught new tricks?

  2. Eugenia says:

    Both of you are under-playing the importance of being physically close to develop something that’s COHERENT. Especially something as complex as a desktop OS, it requires different teams to collaborate in the extreme to create a platform that makes sense. For example, if the kernel guys where just on a different floor than the glibc guys, there would not be any glibc problems between distros.
    It was not just a few months ago when I wanted my TIFF files properly recognized by Gnome (these were Kodak RAW files that simply used the TIFF container, and I needed them loading by an app that could read RAW files rather than a generic graphics app that simply supported the TIFF container but not necessarily the internal format). And guess what: fixing that problem required the collaboration of: Nautilus, Eye of Gnome, DCRaw, Freedesktop.org, libtiff. FIVE different projects where ONLY two of them shared the same bugzilla. DCRAW and libtiff didn’t even have a bugzilla. And freedesktop’s project that needed fixing is maintained by a guy who does a release of that package whenever he has the free time.
    So that’s the point you are missing. You are missing the point of in order to get a cohesive OS, it’s the DETAILS that need fixing. And to fix these REMAINING details, it requires the kind of collaboration that it is NOT humanly possible to be done via the internet bugzillas and mailing lists. It requires people sitting their a$$ down and talk about these problems and finding a solution right here, right now.
    And look at what are the best OSS projects out there: SVN, PostgreSQL, Apache, Firefox. All projects that their development is defined within a few people who work closely together rather than just random hackers from their bedrooms.
    I also would like to bring to your attention BeOS. BeOS might not have had great hardware compatibility or software availability (as it was a small player), but it is one of the most cohesive, clear, easy to use, never-striking-back-to-your-ass OS. I have asked three different Be engineers HOW their small team was able to create such a feel-good OS, and GNU/Linux distros can’t after all these years. And the reply was always the same: “because when we had a problem, we could just walk to the next cubicle and resolve it in no time”.
    So guys, don’t evangelize too much about the strengths of OSS, when you are missing such a glaring point. Being physically together, is much, much, much more important than you think. If you still believe that you can create an Apple-licking-alike product just with collaborating over the internet, you really need to rethink the industry you are in.

  3. Marcos Alves says:

    Eugenia… I’m with what you said at 101%.

Leave a Reply

Your email address will not be published. Required fields are marked *

*