How to convince my boss that is good to open source our developments?

Question

Hi,

I'm not working for a software company but my company has a software development team. I think that is good for the company to open source our developments for some reasons like:

• We are contributing the community ;-)
• Is a good quality check. If it's useful for others, we are going on a right way
• We can benefit on others contributions

But my boss can say no because:

• We are giving clues to other companies about our work.
• We need to waste to much effort to maintain more detailed documentation, good code,...

More suggestions???

Answer 1

We need to waste to much effort to maintain more detailed documentation, good code,...

Wouldn't this be a positive? Increasing the quality of your code and documentation would surely be a huge net positive for the company in the short and long term.

Other things to think about:

• Good will created in the community by releasing as open source. This can create a substantial amount of grassroots positive advertising, which can lead to
• Developers recommending the commercial/paid support version of open source software to their employers.

Answer 2

I don't know your business line, but your boss is probably right (sometimes they do know more than us).

In any event, you can still get your way. Make him commit to the reasons he doesn't like the idea and then find a mutually beneficial outcome.

So...

• only open source very specific sections of code that are approved by him
• provide metrics showing that the overhead of documentation, clean good code, is worth it in and of itself
• suggest that doing open source can make your organization a progressive leader in your market.

It sounds like he is rational, so rationalize with him.

Answer 3

Unless you can start with a bunch of open source code already available and have good expectation that you can attract useful developers and have the resources to test and inspect the code that is submitted I would not go with open source. It sounds good on paper (to have other people do your work for you) but it is not so easy.

What is the software you are writing going to do?

What platforms does it run on? Who are the consumers of the software?

What code is already written?

I would not open my development efforts.

Bottom line - it is a lot of work to manage other developers who are not getting paid for their efforts.

Answer 4

I have worked for a 30 person company, a 5000 person company and a 400K person company. This has ALWAYS been difficult, in my experience. I have never been successful, unfortunately.

Bosses are either worried about:

• A possible edge against a competitor
• Possible legal issues
• Fear of IP leaks

I can't give you any answers, but these might be some things to think about?

Answer 5

Perhaps you should start by finding out whether it actually is good for your company to open source your work.

It may be, but there are also a lot of businesses and business models that are better suited for closed source. So find out if it is better, and if it is, you've already solved the problem of what to tell your boss, because in finding this out, you learned all the arguments for why it is better. ;)

Answer 6

The only way you can get your boss on board with open sourcing your company's software is by showing them a monetary return greater than the costs of the issues he raises. Given that his chief concerns are competition and needing to write better code and docs I'd say this is an impossible sell.

Answer 7

Personally, I think open source only works for applications that are good for the mass market. Operating systems, Office Suites, Browsers, IDEs, Graphic Editing. If you are doing inhouse development for internal business projects, the code you produce probably won't be beneficial to the community at large. You will probably find that preparing your code for release into the wild is a lot of work, and that you probably won't get much interest in your code anyway.

Answer 8

Open source can be viewed as one approach to outsourcing: inviting others to look, use, and extend your code. It's a common piece of advice that a business should do its core business functions in house and should (or at least can) outsource anything that isn't one of its core business functions. If you apply this business advice to software development, this means that even if you decide (or your boss decides) not to open source the core functionality of your software, you can open source some or all of its infrastructure - logging, unit testing extensions, other support routines, what have you - to get some of the advantages of open sourcing without giving any (significant) advantage to your competitors. (Sure, they might be able to use your support routines, but if you successfully build a community around your software, then advantage of getting contributions from non-competitors will outweigh the disadvantage of competitors being able to use the routines.)

If you're currently using or building on any open source libraries (and there's a lot of good stuff to build on!), then the case for open sourcing your support routines that build on those libraries becomes stronger. By doing so, you can become a recognized contributor to the community and can help influence the future direction of that software in ways that help your company. (This isn't to say that you should exploit the open source community, it's just recognizing that software evolves to meet the needs of its users, so the more you're recognized as a user, the more directly that evolution benefits you.)