Related to this question

I'm meeting with management, trying to convince them that open-sourcing some pieces of our codebase would be beneficial to the company. On my part, this would become a part of my public portfolio in the future.

When briefly talked, the idea was not flat-out thrown out, and might be doable if my arguments can convince them.

Reasons i'm coming up with:

  • Good PR for company
  • Shows company is investing in code quality (thus product quality)
  • Might generate interest among possible new employees
  • Might result in contacts from other companies in the field

Is there something more I should note?

  • 1
    Your existing points are a bit dubious. Have you done any research on reasons to open source? Aug 13 '19 at 15:01
  • Are they? No, not from the business side, just utilized and participated in open source
    – tonsteri
    Aug 13 '19 at 15:07
  • Well, you haven't included the standard non-business reasons in your list. Aug 13 '19 at 15:08
  • Good point, I think i was too focused on the non-tech-savvy side of things. Do you have other points than the community maintenance / code review (although these are a bit dubious if project does not gather attention)
    – tonsteri
    Aug 13 '19 at 15:11
  • 2
    What happens if you get some crappy developers who submit a lot of crappy pull requests to your code base? Or just in general a lot of pull requests? Just because your code base is open source doesn't mean you don't have to deal with all the reviews and testing involved with making changes. In fact it may be more work as you will have to be concerned about what bad code may make it into the code base.
    – Joe W
    Aug 13 '19 at 15:12

Is there something more I should note?

Yes - you need to remember this will be a conversation, not just you throwing some advantages at them and then waiting for an answer. So you need to be ready to hear some criticisms of your approach, and defend it against them.

If you presented this to me then I'd probably be saying:

  • A lot of this code you're proposing to open source isn't of the best quality. Do you really think that will give us good PR? I'd say the opposite.
  • I'm not sure that code quality implies product quality at all. Have you got any proof of that?
  • Why do you think it would result in other contracts? Do you know of any companies who scour Github for some open source code as the basis of who to contract with? Me neither.
  • What if an employee accidentally commits some confidential company information into an open source repo? This wouldn't be fantastic at the moment of course, but at least the damage would be somewhat contained. That wouldn't be the case with an open source repo. How do you propose we mitigate against this?
  • How do you propose we manage new PRs from external contributors? This could cause an increased workload. Who should take this work on?
  • How do you propose we manage issues that only affect external users of this code, and don't affect us internally? If someone reports an issue and we say we won't fix it, this makes us look bad. If we do fix it, that's additional employee time and risk that we wouldn't have had before.

You need to expect these sorts of arguments, and more, and prepare clear, concise answers to them. As it stands at the moment, it sounds like you see that there's benefit to you, so you're picking out some random things you think might be benefits to the company to try and justify it. That won't wash in most places.

  • 1
    Thanks on the angle, I think those arguments at least can be somewhat countered. You're on point about the motives, although I still believe this could be good for the company too.
    – tonsteri
    Aug 13 '19 at 15:18
  • 1
    Perfect answer. Aug 13 '19 at 15:22
  • 2
    Very precise, my favourites are "What if an employee accidentally commits some confidential company information into an open source repo?" & "How do you propose we manage issues that only affect external users of this code, and don't affect us internally?"
    – iLuvLogix
    Aug 13 '19 at 15:43
  • Great answer. Just one suggestion to add: Managers tend to think in numbers. If you want to convince them, do so with numbers. How much profit will this generate in the long run, how much more man power will be needed. Can you find statistics about other companies that made the switch and how their revenue/value increased afterwards?
    – Dirk
    Aug 15 '19 at 6:22

Potentially lower maintenance costs of non-core source code.

If the pieces of code that you want your company to open source have general interest among developers then the open source project may attract code contributions and fixes from other developers thus lowering the maintenance costs for your company. But this is a fairly big if. Most open source projects don't attract much if any outside contributions, you'll need to work on getting the project noticed and you or other developers at your company will need to maintain and keep uptodate the project. External contributions will need to be reviewed and tested.

If where you live there are active developer meetups then you may want to informally float the idea and see if there is any interest in participating.

Your company will need to vet the source code to make sure it actually owns that IP. With regards to the project becoming part of your public portfolio, you should realize that the original copyright is still owned by the company - it is not yours.

  • Good point about the IP. For me, it's enough to have something online i can point to, and be able to prove it's my code
    – tonsteri
    Aug 13 '19 at 15:13

I find the premise itself to be a bit worrisome, and it comes down to one of your opening sentences:

"On my part, this would become a part of my public portfolio in the future."

The issue with this mindset is that you start treating the project less like a building block of your companies solution, and more like this pure expression of your programming ability. You have to reflect what will happen when you need to commit code that doesn't pass what you consider good enough for your portfolio. Or even if your coworkers do.

To be honest, if I'm looking at a candidates code, I want to see what they have coded outside of work, when they have freedom to express themselves, and not have potentially unknown factors influencing the code that I see. If a candidate cannot point to external projects, and can only point to code done between 9 - 5, that would reflect poorly on them.

There is a cost to open-sourcing. Some flexibility is removed. Risk is increased. You really need to ensure your suggestions include sections of code that actually would benefit the open source community. This means code that has a clear purpose, a clear scope, and applicability to other projects.

Your companies implementation of some miscellaneous business logic is quite different from a project which provides an easy to integrate solution to a problem that other entities have.

In addition, if your company creates a project with the same purpose as other popular open-source projects, it really has to be unique and compelling in some way. Otherwise it will just seem your company suffers from a bad case of NIH syndrome, which goes against many of the points you have raised.

  • on suitability: it's a client library for a 3rd party open api, and the are no open-source alternatives for targeted platform at this point. There is 0 business logic for our use cases inside that lib.
    – tonsteri
    Aug 13 '19 at 16:35
  • You raise good points. It's just hard to find time and a project that could be as useful to the community. I'm hoping polishing and maintaining this (maybe also out-of-office-hours) would show commitment as well as this "freedom of expression" to possible future interviewers
    – tonsteri
    Aug 13 '19 at 16:53

Not the answer you're looking for? Browse other questions tagged .