IT Commandment: Thou shalt give something back to the community

IT Commandment: Thou shalt give something back to the community

Summary: Giving back to the open source community can be a simple as reporting problems and helping answer questions, but the return on that investment will be far greater than you might expect.

TOPICS: Open Source

Following in the model of Paul Murphy and Dion Hinchcliffe, here's a commandment for anyone who uses open source software: Give something back.

IT Commandments Before I get into the why, I want to take a moment to discuss the what and the how. First, what exactly are you supposed to give back?

The most important contribution you can make to open source is you, i.e., your time and your expertise. Everyone who comes to the OSS table brings something unique. Perhaps it's a use case that you or your customers have run into. Or perhaps it's a bug that you found, or a trick you learned once that could improve the software. Whatever it is, you should share it.

How? The best way to get started is by stubbornly reporting every bug you encounter and every feature request you need. Be specific and clear in your reports, and include the steps to reproduce any problem. The second best way is to become a part of the community by helping others. If there's a mailing list or forum, read it and respond to questions if you know the answers. Ask questions of your own. If you have any patches or code to contribute that's great too, but you can help a lot by just doing these two things.

Finally, why? Someone is putting code out there for you to use, so why not just take it and use it and be done with it? All that other stuff, the sharing experiences, the reporting bugs, and so forth sounds like a lot of work so why bother? There are many reasons but generally they fall into two main categories: the altruistic and the pragmatic.

The altruistic reasons are usually the ones cited by free software advocates. Helping your fellow developer, doing something to help them in exchange for how much they helped you, blah blah blah. If these reasons do it for you, that's great, go make a contribution to Greenpeace or the FSF. I'm not trying to belittle these reasons because they can be powerful motivators, but they don't matter a whit to the managers looking at the bottom line. So that leaves the pragmatic reasons.

Basically, it's strongly in your best interest to do all these things. Look at what I've suggested here. Sharing your use cases will help make the software cover those cases better. Reporting bugs is the first step in getting them fixed. Hanging out on forums? Networking. Answering questions? Explaining something to other people is the best way to learn.

So contribute back as much as you can to open source. Not only will it give you a nice warm fuzzy feeling, but more importantly, you'll maximize the benefits you get from the software and the community by participating in it.

Our IT Commandments:
  1. Thou shalt not outsource mission critical functions
  2. Thou shalt not pretend
  3. Thou shalt honor and empower thy (Unix) sysadmins
  4. Thou shalt leave the ideology to someone else
  5. Thou shalt not condemn departments doing their own IT
  6. Thou shalt put thy users first, above all else
  7. Thou shalt give something back to the community
  8. Thou shalt not use nonsecure protocols on thy network
  9. Thou shalt free thy content
  10. Thou shalt not ignore security risks when choosing platforms
  11. Thou shalt not fear change
  12. Thou shalt document all thy works
  13. Thou shalt loosely couple

Topic: Open Source

Ed Burnette

About Ed Burnette

Ed Burnette is a software industry veteran with more than 25 years of experience as a programmer, author, and speaker. He has written numerous technical articles and books, most recently "Hello, Android: Introducing Google's Mobile Development Platform" from the Pragmatic Programmers.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • consulting

    When doing consulting work it can get more thorny, simply because you need to get sign-off from every client that its OK for you to put their code in the public domain.
    However I work for a small consulting company, and we typically work something out, however you do get me thinking, maybe we should make it a standard contract clause that we can commit bug fixed back to the source os project.....

    Thanks for the reminder of our duty.
  • "Open source" isn't "free"

    Open source software may be "free" on a monetary level, but the moment you start giving back to the community, it has a very real cost. If you were a manager of IT, ask yourself this simple question: would it be cheaper to pay $1,300 for a Microsoft Windows 2003 Server Enterprise Edition, or to have a sys admin or programmer (at $65,000 per year, plus benefits, plus the support costs) spend an hour a day at the workplace involved with the open source community? Unless that person is contributing to the bottom line like this (like maybe making eneded extensions to software, then kicking it back to the community), it is hard to see how this is justifiable. I am not down on OSS; I use it regularly and try to contribute where I can. But to make this a "requirement" is absured, it takes away one of the crucial reasons to go with OSS in the first place.

    Justin James
    • Contributing reduces the cost

      It might be counter-intuitive but I've found that contributing back reduces the cost and increases the value, not the opposite as you suggest in your reply.
      Ed Burnette
    • I have to disagree. It costs a lot more to work around than to fix.

      "Open source software may be "free" on a monetary level"

      Most of the time, yes, but it's not a requirement of Open Source. The purpose of Open Source is a philisophical one, not a financial one.

      "but the moment you start giving back to the community, it has a very real cost."

      Actually, no. You can contribute as much or as little as you wish, and there's no requirement that you pay employees specifically to contribute to a project. No such requirement at all.

      Chances are, contribution is going to be done by an employee that is already paid to maintain the software, so you really don't need to hire any more employees or add any more hours to their days.

      And while we're at it, their contributions will be for the [b]benefit[/b] of your company - any changes they make and bugs they find will help your business run more smoothly with that software - indeed, do you have any idea how much more money would be wasted trying to work around bugs and problems with software? I'm pretty sure it costs a lot less to fix it than to work around it!

      Personally, I think it costs a lot less to fix a couple of lines of code than it does to write a few hundered to work around the bug. Been there, done that.

      "would it be cheaper to pay $1,300 for a Microsoft Windows 2003 Server Enterprise Edition, or to have a sys admin or programmer (at $65,000 per year, plus benefits, plus the support costs) spend an hour a day at the workplace involved with the open source community?"

      Bad comparison. You can get Open Source server software without customizing it, if you wish. As I have said, this does not require you hire somebody specifically to contribute.

      I'm sure if you wanted to customize Windows, the costs would be at least as great.

      Besides, would you simply slap Microsoft Windows 2003 Server Enterprise Edition into a computer and let it run, or do you have somebody watching and maintaining the systems? It's not like Windows has no support costs at all!

      The fact is, you make a bad comparison. You don't slap an OS into a computer for $1,300 and then ignore the computer for the rest of the year. Your number is unrealistic.