12 tips to getting things done in open source

Most people used to the proprietary software world, with no experience in open source software, are amazed that anything gets done. (And lots gets done in the open source, way more than in most proprietary software companies!) And people new to open source are usually at a loss as to where to start. Often they come with a great idea, tell a couple of people who confirm it’s a great idea, and then … well, and then they don’t know what to do and the great idea fades.

So here are some of my ideas on how to get things done in the open source world. And I am by no means the expert – I’m in awe of some of the people I work with on a daily basis.

To get things done in open source:

  1. Be prepared to do a lot. Somebody has to do it. And while you can convince others it’s fun and needed and great, if you aren’t willing to put time into it, why are they going to believe you?
  2. Believe you are empowered to do it. If you propose a new idea and everyone tells you it’s great, believe them. And just do it. Nobody is going to say “ok, now you can do it.” If people give you positive feedback, take that as an ok to go ahead.
  3. Recruit others early. The earlier you talk to others about your idea, the more likely they’ll be able to contribute to the idea and feel like it’s theirs. The more they feel like it’s theirs, the more likely they’ll contribute. Most people hate to share an idea until they are sure it’s a good idea that’s completely thought out. By that time, it’s your idea to be done your way and it’s too late for them.
  4. Don’t worry about getting credit. It’s all done publicly, on a mailing list that’s recorded for prosperity or on IRC in front of everyone. You’ll get your credit. Float your idea, encourage others, accept their feedback and ideas. Give more credit than you take. (And ask yourself if you want your idea to happen or if you want credit. Either answer is ok but only one can be your highest priority.)
  5. Join the conversation. Many people float an idea via email or maybe even on the mailing list. Where probably depends on the project but there are conversations happening some where. I think the one most missed by those new to open source software is IRC. I once heard a manager joke that nobody hangs out around the water cooler any more. Instantly someone mentioned (on IRC) that IRC is the new water cooler and he just didn’t know it.
  6. Get effective at monitoring lots of information. In my experience, people in the corporate world spend a lot of time talking about how they get too much email (I did) where as people in the open source world (at least GNOME) spend their time talking about methods for dealing with lots of email. It’s way cooler to be seen as someone who copes with tons of email than someone who gripes about tons of email.
  7. Reply to all. I worked on an open source like project with some people that weren’t familiar with open source. I got so frustrated with people that didn’t hit “reply to all”. I spent a lot of time recommunicating decisions and we didn’t have a lot of conversations that we should have had.The project had a lot less “team” because people didn’t reply to all. By “team” I mean people didn’t feel part of a team and they didn’t have all the information they needed. Also, one of the strengths of open source is that all of the history is in the mailing lists. If you don’t reply to all, your project will lose that advantage.
  8. Think the best of people. Things get lost in email. It’s much easier to misread an email or take offense at something in an email than it is in person. Remember this whenever you get upset at an someone because of an email.
  9. Meet people. Along the same lines as communicating well in email, meet as many of your fellow open source people in person. This is somewhat controversial as the open source model works really well in a virtual world. But I think that conferences like OSCON, GUADEC, SCALE and OpenSource World that get lots of open source people together, create stronger relationships and better projects. Personally I find that when I can read an email in someone’s voice, it makes a lot more sense. It’s often funnier and more relevant.
  10. Be yourself. Be yourself, add some personal notes, make sure your motivations are transparent. Anyone who is obviously acting with “ulterior” motives – like pushing their company’s policy without thinking about what it means to them and the project – is less trust worthy. Not because what they are doing is bad but because it’s hard to know what type of decisions they are going to make and carry through on.
  11. Ask for help. There are a lot of people in the open source community willing to help. Just make sure you share the whole plan and ask for specific help. If you don’t share the plan, they won’t know why they should help. If you don’t ask for specific help, they won’t know how to help.
  12. Show your passion. Excitement is contagious. Share why you are doing what you are doing and why it’s important or fun. (Be sure to temper the “because the alternative sucks” viewpoint.) Be positive and passionate!

What else would you add? What’s your best tip for getting things done in the open source world?

For more detailed ideas for how to actually get the work done, see 10 skills to master to get things done online.

14 Replies to “12 tips to getting things done in open source”

  1. 13. Late Nights (occasionally). When a project gets large enough your contributors come in from all over the world. If you are lucky enough to have a vibrant IRC channel, sometimes picking a couple nights a month to stay up and chat with those contributors on the other side of globe can lead to unexpected and positive results. It’s also nice to not force them to change their schedule all the time to get a person to person chat with you. In short, avoid the 24 hour email lag! It makes a big difference.

  2. Learn to use email. I mean *really* learn it. There are lots of old-fashioned ‘netiquette’ rules that will serve you in good stead as you interact with communities (or try to grow your own) via email mailing lists. Things like setting your email client to send out plain text and not HTML, or not top posting, or getting into the habit of trimming quoted material.
    And when replying to an email from a mailing list, do *not* use Reply-All. Use Reply-To-List instead. If your email client does not have a Reply-To-List option, get a real email client.

  3. @Micheal: Reply-to-all vs Reply-to-list tends to be different between different projects. In general on GNOME lists, AFACT the general accepted behavior is to reply to all, and mailing list users expect to have a mail sent directly to them if they are specifically expected to reply. In Debian, as a counter example, reply-to-all is not acceptable.

  4. 15. If you are a maintainer or in some sort of leader role – be sure to encourage and be grateful about contributions from others. This is especially important for new contributors so that they see that the patch they did is appreciated.
    Do this even if the patch in question isn’t solving the problem in an optimal way, or if it’s lousy written. A contribution is (almost?) always a good thing and more may follow if you treat them good

  5. I guess the short version is that open source development is inherently collaborative – it’s not enough to just be a good coder, you also need to be able to work with others, to keep a wider view of how the things you’re doing fit in with what everyone else is doing. People working in isolation is a bad idea in any development model, but especially so in open-source.

  6. Stormy,
    Thank you for #4. That was gorgeous (as were the rest).
    Regarding Reply-to-all / Reply-to-list, I’m on a bunch of mailing lists (e.g. debian-publicity and fd.o) which have a lot of chatter about preparing documents (e.g. newsletters and specs, respectfully), and I wonder why more is not done on collaborative documents with feed subscriptions for changes. It seems that the process hasn’t changed much in twenty years. What’s your opinion on he reason for that?
    Thanks for your time and for the insightful article,

  7. Thanks!
    I think one of the reasons documents are hard is because you don’t add to the bottom, you add and change throughout the document, which can be confusing when transmitted via rss.
    I do think wiki’s have really enabled collaborative documentation in the last couple of years. Much of the GNOME website information is maintained via wiki.

  8. GTD is a great concept! As far as outlook, Outlook Track-It has been very cool too. It’s a small toolbar in the form of a plugin/addon. Actually flags emails for you and reminds you to follow up. Great for that function of Outlook.

Comments are closed.