Symphonious

Living in a state of accord.

Open Core, Open Development and Co-location

It would be hard to have not noticed the on-going debate around “open core”. From what I can tell, it largely, but not completely, boils down to concerns about a product being called “open source” if the core that’s open source is generally unusable without the commercial-only additions. Mostly, people are ok with there being separate commercial-only plugins or tools provided so long as the open source product can stand alone and be useful and effective. Dave Neary hits on what I think is a key warning sign that a product is using a damaging open-core model:

And that’s what I think gets people riled up – if you’re releasing something as free software, then there should at least be the pretence that you are giving the community the opportunity to fend for itself – even if that is by providing an “unofficial” git tree where the community can code up GPL features competing with your commercial offering, or a nice forum for people to share templates, themes and extensions and fend for themselves. But what gets people riled is hearing a company call themselves “an Open Source company” when most of the users of their “open source” product do not have software freedom.

The open source definition is all about what license is being used for the software, but the effectiveness of something being open source is at least equally affected by the development model in use. The ability for anyone to jump in and contribute to the project reasonably easily is what drives extra innovation and enables the development investment to be spread among many users of the software. Having access to the source code and the ability to modify it yourself is useful to avoid lock-in, but maintaining the entire software is generally too expensive to be worthwhile for users – it’s cheaper to incur the costs of switching to another product instead.

What Dave Neary’s paragraph above starts to move towards is looking for a product that uses open development rather than just open source. Bertrand Delacrétaz wrote up how we work at Apache recently and it’s a great model of things to look for in open development1. In particular Apache lives and dies by the first item: “All technical discussions and decisions on public mailing lists” or as I’ve often heard it put, “if it didn’t happen on the mailing list, it didn’t happen”. Unless all discussions wind up happening in a public forum, be it a mailing list, forum, wiki, wave or whatever, it’s unlikely that open development will be possible2.

So all of this leads me to a somewhat unexpected realisation: any open source company that insists on having all its developers colocated is failing to do open development effectively. If your employees can’t develop effectively from remote locations, how can you possibly expect to benefit from significant community contributions?

Anyone have examples of companies using exclusively co-located developers but still fostering an open development model?

1 – of course there are other approaches to open development, but few are as well articulated as the Apache way these days.

2 – Apache does use face to face meet-ups, but they make a point of keeping the mailing list in the loop about what was discussed there so everyone can still be involved

Category: OpenSource
  • Jeff Waugh says:

    This is one of the reasons Canonical (the company behind Ubuntu) was set up as a virtual company from the start. In job ads they now tend to specify optimal team timezone compatibility, but practically everyone with a technology role still works from home.

    July 21, 2010 at 12:59 pm
  • Yonas Yanfa says:

    Very interesting topic!

    The main question seems to be, how transparent do the walls of your
    “open source” company need to be to outsiders?

    I would argue that “absolutely everything must be discussed on the
    mailing list” is extreme and too inefficient for a smart company that
    focuses on their bottom line.

    I would also argue that Apache’s approach to open development may be
    great for open source communities, but not necessarily for profit
    seeking companies that want to freely share their source code.

    > So all of this leads me to a somewhat unexpected realisation: any open
    > source company that insists on having all its developers colocated is
    > failing to do open development effectively.

    The benefits for having the core contributors – your employees – in the
    same physical location are numerous.

    1. Natural, face-to-face communication
    2. Quick reply/answer
    3. Easier/more fun/more responsive brainstorming sessions
    4. Chance to quickly grow closer to each other
    5. …the list goes on :)

    I’ve read about FreeBSD core hackers that live in the same area meeting
    up to brainstorm and discuss over coffee/beer. This significantly
    reduces the amount of back-and-forth time wasted in mailing lists and
    emails. When they’re done, they write up about their new ideas,
    solutions, directions, etc.

    Even more time is saved when the core contributors (i.e. employees) are
    in the same building Monday-Friday, 9am-5pm.

    The main thing here is that

    - generally, not every discussion is important enough to be on a mailing
    list

    - for the important discussions, colocated employees can talk
    face-to-face about anything brought up in the mailing list, plus,
    brainstorm/create/consolidate easily, and naturally face-to-face.

    > If your employees can’t develop effectively from remote locations,
    > how can you possibly expect to benefit from significant
    > community contributions?

    Working effectively from remote locations doesn’t imply a greater
    capacity to benefit from community contributions.

    More generally, being co-located doesn’t imply a smaller capacity to
    benefit from community contributions.

    How transparent your company is to the open source community is, and
    should always be, a business decision.

    July 22, 2010 at 3:58 am
  • Adrian Sutton says:

    Interesting thoughts, but I can say from brutal experience that I disagree with:
    > Working effectively from remote locations doesn’t imply a greater capacity to benefit from community contributions.

    It is incredibly hard to get a team that works face to face to open up and remember to communicate properly with people who aren’t there. On the other hand, a team which deals with remote members all the time is forced to put in place all the mechanisms that enable community contributions – they just have to make sure they are public. As I noted, that doesn’t eliminate face to face meetings – Apache uses them just like the FreeBSD examples you mention, but the information and decisions are then posted back to the mailing list so that everyone knows what’s going on.

    There’s no doubt that there are a lot of benefits to co-location – it’s absolutely the way I’d set up a team for a non-opensource project if possible(1), but there are even more benefits to building a community of external contributors for your project. A really good, and surprising, example of this paying off is actually Apple with the WebKit project. I believe Apple’s developers are co-located and initially they made quite a mess of working with the open source community, but through some major efforts to open up the culture they fixed things and started to do everything in public – now they have Google, Nokia and other big companies contributing to the codebase. So far, this is the only example I can think of where a co-located team has actually managed to build a big, successful community like that. Since everything is now public though, it should be quite feasible for Apple to hire remote members of the WebKit team, who can be just as productive.

    I’m definitely not arguing that all companies should avoid co-location or that they should be working with open source, simply that if you’re claiming to be an “open source company”, you need to be working in a way that enables the open source community to participate and contribute, which requires supporting remote contributors. If you’re supporting remote contributors anyway, you may as well take advantage of the bigger talent pool and hire from anywhere.

    (1) Side note: Yonas is working with me on the TinyMCE stuff Ephox is doing -he’s in Canada and I’m in the UK. When he thinks about this some more, he may stop arguing that I should hire someone closer to me. :P

    July 22, 2010 at 8:31 am

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

*