Over the years quite a few folks - representing businesses and organisations - have asked: "give me some reasons why we should be open sourcing our code". In many cases, the person asking the question has the desire to open their code, but they're looking for reasons they can use to convince a decision-maker in their organisation. I was asked this again just a few days ago, and thought I'd take the opportunity to publish my suggested reasons here in case they're useful for anyone else who might discover them...
Reasons why you might want to open source your organisation's code
1. Goodwill - releasing your software as open source demonstrates good will to your customers, collaborators, and even competition. It's "pay it forward" in action. It shows you're confident, too. "Open source" is now definitely a marketing bandwagon - companies all over the place (even those who aren't software focused) are trying to claim to be "open source" or open source friendly (whatever that means)... I encourage you to hold your marketing people to a high standard of integrity (there's a lot of "fauxpen source" out there thanks to overzealous marketers who don't really know what "open source" means) and ensure they're not overselling it - this is a hard thing to measure, so it's difficult to know if you've benefited. In the end, I suppose it just needs to feel like the right thing for you to do.
2. Confidence for users - by open sourcing your code, you give confidence to those using (or building other software that depends on) your software, knowing that if your business fails (it happens!) or changes direction and discontinues the software, they can carry on using it and supporting it themselves if need be.
3. Recruiting and retaining good staff - if you're finding it hard to attract good, knowledgeable software developers to work for you - or keeping those you have - making your code available is a good way to give prospects a chance to do due diligence on your company. Note, this can cut both ways (particularly if your code is either doing really dull things or is of a low standard). You may find, though, that people who have an interest in your code might end up learning it and make themselves apparent to you... it's a very good filtering mechanism for identifying good (lower risk because they're "pre-qualified") prospects who "come out of the woodwork" to whom you can offer roles.
4. Reducing maintenance overheads - this is probably the main financial justification: maintaining software is expensive and difficult. Making it open source, and managing the open source development well (like having a responsive policy for adopting improvements/enhancements - this is crucial!), gives confidence to others that the software is worth them investigating and perhaps investing in learning themselves (for their own purposes)... they then have an interest in ensuring it's a) reliable, b) secure, c) up-to-date (with the state of the art), d) and constantly improving. This can result in distribution of maintenance costs, which can mean substantial life cycle savings. But you shouldn't underestimate the need to manage the open sourcing well - it's not just a question of "throwing the code over the fence" and hoping for the best. Realise, too, that running a your development as an open source project is also great practice for your internal team, and is likely to raise the standard of their work (as it's all on show) and their motivation to ensure robust processes (because otherwise it reflects poorly on them).
5. Benefiting from community contributions - in some cases, open sourced code will meet a real need in the software community, and a strong, diverse development community will develop around it - if it's well managed, you may find that others contribute to the software in ways that you, too, want to use. This means getting valuable software capabilities at no cost to you (beyond helping to support/facilitate the community). It's best to view this as pure icing-on-the-cake, as (realistically) it doesn't often happen... but if it does: wow.
All of this is, of course, completely dependent on the interest people have in your software... it also depends on how you plan to make people aware that it's available, and how you make it available. You have to see open sourcing software as an ongoing practice, not a one-off. Think of it like a product launch, including relevant investment in marketing.
I think it makes a HUGE difference in your internal staff's impression of their company if they see their software being made available to people outside the company - in most cases, where the team is competent, they're very excited and enthusiastic about the profile of their software being raised. If the team isn't competent, this might be a good way to improve that.
I'd recommend publicising open sourcing software by getting staff to present on it at relevant tech conferences. You could make it available on a centralised code repository (like Github or Bitbucket, or, if you're local to NZ, we'd be happy for you to use our Gitlab instance if you prefer it to have a more local focus (or both)) and perhaps announce it through other marketing channels and on local "community of interest" mailing lists or forums.
Remember, there's no guarantee that your software will capture the imagination of other developers out there... but then again, it might be the next RubyOnRails, jQuery, or Node.JS. It's a long game, and you shouldn't be looking for direct returns immediately. But, if it feels right to you, then I certainly encourage you to help enrich the software commons, and exercise your enlightened self-interest. I expect you'll likely find that your generosity is repaid many times over, but (if my experience is any guide) in ways you'd never have expected.
Add new comment