Iyfjky

Question

My particular case: The CEO and his parents are the owners of the software company I work for. None of them are highly-technical, and thus are unlikely to understand open source principles when I first bring it up.

There is a database tool I'm making as a solution to needing to roll back database changes between integration tests, which I know would solve a problem that other programmers have and for which there is no well-established existing solution. I would like to release just the database tool code as open-source, and the decision on whether or not I can do so lies with the owners.

How can I approach a non-technical boss about contributing to open source in a way that is likely to yield a positive result? What arguing points would be relevant to a non-technical boss when speaking in favor of contributing to open source? What arguing points should I avoid?

as a thought, "open source principles?" ~ it makes you sound like a software communist. The "unlikely to understand" comes off as patronising too, so consider the language you use when you approach them. finally, why do you want to release the tool for free to other people? why not charge for it? — Feb 7 '15 at 2:19
This is not a direct answer but an observation - are you sure that what you're doing isn't either already done by something like sqitch or something that could be a relatively simple add-on to that? Contibuting bugfixes to established open-source projects on which you depend will be a much easier sell because it's more likely that you'll get commits back. — Feb 7 '15 at 20:16
"If other people find it useful, they will work on it for free, and we can use their work" - make it into getting free work, not giving away free work. — Feb 7 '15 at 23:44
Are you yourself clear why you want to make the tool open-source? — Feb 8 '15 at 10:30
I'm voting to close this question as off-topic because it is not about navigating the workplace. — Feb 10 '15 at 4:39

score 9 · Accepted Answer · 2015-02-08 22:56:14Z

How can I approach a non-technical boss about contributing to open source in a way that is likely to yield a positive result?

What non-technical people hear when discussing contributing to open source is their time and money being given away free. They see your time and energy spent on promoting the open source product and dealing with the community instead of doing what you are paid for.

You need to focus on the cost/benefit of open source, specifically how they will make more money. You also need to dispel their fears about your attention and time.

What arguing points would be relevant to a non-technical boss when speaking in favor of contributing to open source? What arguing points should I avoid?

First, is this tool a competitive advantage? If your company's main business is around databases, testing or software development, the code will not be open sourced. If quality or release cycles are your competitive advantage, the answer will also be no.

Second, is it something others would pay for, given the additional time and resources for productization? In other words, if they can sell this now or in the future, the answer is also no. Many non-technical people would rather have the option to sell it in the future, too, making this argument difficult. They also may fear others selling it, so a restrictive license (e.g. GPL) may be worth mentioning.

Assuming neither of these questions poses a problem, think of the benefits contributing to open source would bring. For example, others could fix bugs or add features (examples of similar software would be useful here). It could spread the company name in technical circles, making hiring new developers easier (examples from other similar companies would be useful). It could increase morale inside the development team (get others' agreement on this).

Your management need assurance that you will focus on your main role and not the open source product. Perhaps agree on time commitments (e.g. 1 hour per week), how it will be distributed (e.g. if it is on github, who owns and pays for the account?) and what license it will use (e.g. MIT/BSD to limit liability and encourage use or GPL to ensure it remains open source?).

Contributing to open source is really a cultural question for an organization. This is much harder to quantify but developers are often motivated by respect of their peers as much (if not more so) then salary. If you use lots of open source it can be nice to give back, too. Unfortunately, this will not hold sway with more traditional management.

As a side note: GPLed software can be sold for money. There just isn't much incentive, because the person you sold a copy to can also sell it, for a fraction of the price (or no price at all). — Feb 8 '15 at 13:30

NotMe 20.9k55695 · Answer 2 · 2015-02-07 22:31:06Z

As a manager the first question that comes to mind in this - and, yes, I'm highly technical - is:

So are you planning to continue giving your work away for free to the
"open source" community? Work that I've payed you for?

Here's the clue bat: the company paid you for the work you've done. They own it. Unless they want to attempt to market, and make money off of, this project in an open source format then they have zero reason to open source it. More than that, if they do open source it then they'll likely end up paying you to continue making improvements that you give away. At minimum your attention will be split between their needs and the demands of the community that attempts to use your product.

In other words it's not just passing on a potential revenue source, it would be costing them real money to allow you to do this.

Now some businesses, especially large ones, can do this. However, just to be clear, it's a marketing tool. They aren't giving the software free out of the goodness of their hearts. Rather they are hoping to get some payback from it either through support licences or simply by flooding their brand name so that people think of them when they want to buy X. If you look around you'll see that the majority of successful open source projects have a paid for support option. There's a reason for that.

Also, you might be considering just throwing something up on github or whatever without intending to maintain it. There are a LOT of projects like that and there is zero value in them. Most of us have figured out that if there hasn't been a check in against a codebase in a year or so then the problems hiding in it are unlikely to ever be fixed and it's just not worth tracking them down when you can locate similar software that is actively maintained.

I wouldn't go so far as "zero reason to open source it." nor that the only reason to open-source anything is "to get some payback from it either through support licences or simply by flooding their brand name so that people think of them when they want to buy X." Where I work we (and our clients too) have open-source projects on GitHub. While some of them were open-sourced for the reasons you mention, some were open-sourced as investments in the technology/community (not necessarily technology X). — Feb 8 '15 at 10:21
@jcm: I think a business is unlikely to apply the resources necessary "invest" in a technology that is open for everyone unless it there are clear financial reasons - even if they are long term. A small business usually doesn't have the money to just "throw away" and a large business have investors that want dividends. Even calling it an "investment" implies you expect a return. Simply put open source is rarely altruistic. — Feb 9 '15 at 15:05
I'm not arguing about whether the reasons are altruistic or not. All I'm saying is there are other reasons than what you have in your answer that may not be as easily translatable into a dollar value. — Feb 9 '15 at 15:13
@ChrisLively: note that this company is already investing in development of the technology. It doesn't become more expensive if it becomes open source, nor does it become less useful to the company. By itself making it open doesn't change the financial evaluation unless this is something they plan on selling, and the customers will now download it instead. That's a pretty rare situation. — Feb 11 '15 at 11:23
@RemcoGerlich: The moment the developer works on a feature not needed by the company is the moment it becomes more expensive. Further if the developer refuses to work on anything other than what the company needs then the project would be forked and they would lose control for no benefit. — Feb 11 '15 at 15:33

score 3 · Answer 3 · 2015-02-11 11:30:13Z

The company I work at releases a lot of the software we make as open source (GPL). In the past, everything was open source, but it's become more nuanced over time. It's important to understand that there are many arguments both for and against it, but I think we would typically open source a tool like yours.

Not all arguments apply to your situation, but I'll just write down a few now and you can decide for yourself.

Pro:

Extremely rarely, someone will use your code and contribute some comment or improvement. Don't count on that happening.

It makes the software more valuable for a customer who's paying for its development -- and your company's copyright less valuable. Sometimes helps our bid to win.

We can freely use libraries that require code that uses it to use the same license (the GNU GPL, of course). Can be extremely relevant or not at all depending on the subject.

Strategy. Our customers are mostly governments, and some politicians and top government people argue for more open source software in government. We can stress that our competitors' software is not open source, and therefore we should be chosen.

Attracting programming talent. That you release software as open source gives street cred that may mean more people want to work for you. For programmers, their Github account is part of their CV and they get to improve it a bit during work.

It's the Right Thing To Do. If there is essentially zero cost involved in open sourcing some small library, then saving other people around the world some work is good for humanity. This counts double if you run a completely open source stack on your servers, so you benefit massively from this effect yourself.

IF the code is good and becomes popular, it can be good for the technical reputation of your company.

Con:

IF the code is bad, it can be bad for the technical reputation of your company.

A competitor may learn tricks from your code and be able to do the same thing with a smaller investment (it's really rare that they use the exact same stack and have the exact same requirements and get to use the thing as is)

Less vendor lock in, where you are the vendor. The customer may decide to have the next update or the hosting done by a second party. It shouldn't be that much of a practical concern, because you know all the ins and outs and should be able to do the work the cheapest by far, but customers don't always realize that.

You can not talk bullshit to some clients about some bug if they can just look up the actual commit on Github.

Sometimes the company invests a (possibly large) sum of money into something really new and better than everything else out there, and useful for everybody in the same business. Competitors would jump on the opportunity to get hold of it. Don't open source that.

Your case sounds like an internal library where customers don't directly enter into the picture, it's relevant to a broader audience not just the type of business your company is in, and it doesn't immediately give away huge benefit to competitors. We wouldn't be afraid of having this public.

Basically if you always have openings for programmers, then stress the 'attract programmers' angle, otherwise there may not be enough pro or con to get your manager interested.

user8365 · Answer 4 · 2015-02-08 15:16:08Z

Are there really any technical reasons for open sourcing your software? If you believe it is a mechanism that creates better software, who doesn't want better software? I agree people who are technical tend to embrace and understand how it works. Non-technical people who are in the software business should know more about all types of licensing than the average person. You can make a case from a business perspective.

It could attract better developers to your company without having to disproportionately pay them compared to other companies where their type of work isn't viewed as contributing to the greater good.

Outside developers will improve the software and you'll still get to use it.

score 9 · Accepted Answer · 2015-02-08 22:56:14Z

How can I approach a non-technical boss about contributing to open source in a way that is likely to yield a positive result?

What non-technical people hear when discussing contributing to open source is their time and money being given away free. They see your time and energy spent on promoting the open source product and dealing with the community instead of doing what you are paid for.

You need to focus on the cost/benefit of open source, specifically how they will make more money. You also need to dispel their fears about your attention and time.

What arguing points would be relevant to a non-technical boss when speaking in favor of contributing to open source? What arguing points should I avoid?

First, is this tool a competitive advantage? If your company's main business is around databases, testing or software development, the code will not be open sourced. If quality or release cycles are your competitive advantage, the answer will also be no.

Second, is it something others would pay for, given the additional time and resources for productization? In other words, if they can sell this now or in the future, the answer is also no. Many non-technical people would rather have the option to sell it in the future, too, making this argument difficult. They also may fear others selling it, so a restrictive license (e.g. GPL) may be worth mentioning.

Assuming neither of these questions poses a problem, think of the benefits contributing to open source would bring. For example, others could fix bugs or add features (examples of similar software would be useful here). It could spread the company name in technical circles, making hiring new developers easier (examples from other similar companies would be useful). It could increase morale inside the development team (get others' agreement on this).

Your management need assurance that you will focus on your main role and not the open source product. Perhaps agree on time commitments (e.g. 1 hour per week), how it will be distributed (e.g. if it is on github, who owns and pays for the account?) and what license it will use (e.g. MIT/BSD to limit liability and encourage use or GPL to ensure it remains open source?).

Contributing to open source is really a cultural question for an organization. This is much harder to quantify but developers are often motivated by respect of their peers as much (if not more so) then salary. If you use lots of open source it can be nice to give back, too. Unfortunately, this will not hold sway with more traditional management.

As a side note: GPLed software can be sold for money. There just isn't much incentive, because the person you sold a copy to can also sell it, for a fraction of the price (or no price at all). — Feb 8 '15 at 13:30

NotMe 20.9k55695 · Answer 6 · 2015-02-07 22:31:06Z

As a manager the first question that comes to mind in this - and, yes, I'm highly technical - is:

So are you planning to continue giving your work away for free to the
"open source" community? Work that I've payed you for?

Here's the clue bat: the company paid you for the work you've done. They own it. Unless they want to attempt to market, and make money off of, this project in an open source format then they have zero reason to open source it. More than that, if they do open source it then they'll likely end up paying you to continue making improvements that you give away. At minimum your attention will be split between their needs and the demands of the community that attempts to use your product.

In other words it's not just passing on a potential revenue source, it would be costing them real money to allow you to do this.

Now some businesses, especially large ones, can do this. However, just to be clear, it's a marketing tool. They aren't giving the software free out of the goodness of their hearts. Rather they are hoping to get some payback from it either through support licences or simply by flooding their brand name so that people think of them when they want to buy X. If you look around you'll see that the majority of successful open source projects have a paid for support option. There's a reason for that.

Also, you might be considering just throwing something up on github or whatever without intending to maintain it. There are a LOT of projects like that and there is zero value in them. Most of us have figured out that if there hasn't been a check in against a codebase in a year or so then the problems hiding in it are unlikely to ever be fixed and it's just not worth tracking them down when you can locate similar software that is actively maintained.

I wouldn't go so far as "zero reason to open source it." nor that the only reason to open-source anything is "to get some payback from it either through support licences or simply by flooding their brand name so that people think of them when they want to buy X." Where I work we (and our clients too) have open-source projects on GitHub. While some of them were open-sourced for the reasons you mention, some were open-sourced as investments in the technology/community (not necessarily technology X). — Feb 8 '15 at 10:21
@jcm: I think a business is unlikely to apply the resources necessary "invest" in a technology that is open for everyone unless it there are clear financial reasons - even if they are long term. A small business usually doesn't have the money to just "throw away" and a large business have investors that want dividends. Even calling it an "investment" implies you expect a return. Simply put open source is rarely altruistic. — Feb 9 '15 at 15:05
I'm not arguing about whether the reasons are altruistic or not. All I'm saying is there are other reasons than what you have in your answer that may not be as easily translatable into a dollar value. — Feb 9 '15 at 15:13
@ChrisLively: note that this company is already investing in development of the technology. It doesn't become more expensive if it becomes open source, nor does it become less useful to the company. By itself making it open doesn't change the financial evaluation unless this is something they plan on selling, and the customers will now download it instead. That's a pretty rare situation. — Feb 11 '15 at 11:23
@RemcoGerlich: The moment the developer works on a feature not needed by the company is the moment it becomes more expensive. Further if the developer refuses to work on anything other than what the company needs then the project would be forked and they would lose control for no benefit. — Feb 11 '15 at 15:33

score 3 · Answer 7 · 2015-02-11 11:30:13Z

The company I work at releases a lot of the software we make as open source (GPL). In the past, everything was open source, but it's become more nuanced over time. It's important to understand that there are many arguments both for and against it, but I think we would typically open source a tool like yours.

Not all arguments apply to your situation, but I'll just write down a few now and you can decide for yourself.

Pro:

Extremely rarely, someone will use your code and contribute some comment or improvement. Don't count on that happening.

It makes the software more valuable for a customer who's paying for its development -- and your company's copyright less valuable. Sometimes helps our bid to win.

We can freely use libraries that require code that uses it to use the same license (the GNU GPL, of course). Can be extremely relevant or not at all depending on the subject.

Strategy. Our customers are mostly governments, and some politicians and top government people argue for more open source software in government. We can stress that our competitors' software is not open source, and therefore we should be chosen.

Attracting programming talent. That you release software as open source gives street cred that may mean more people want to work for you. For programmers, their Github account is part of their CV and they get to improve it a bit during work.

It's the Right Thing To Do. If there is essentially zero cost involved in open sourcing some small library, then saving other people around the world some work is good for humanity. This counts double if you run a completely open source stack on your servers, so you benefit massively from this effect yourself.

IF the code is good and becomes popular, it can be good for the technical reputation of your company.

Con:

IF the code is bad, it can be bad for the technical reputation of your company.

A competitor may learn tricks from your code and be able to do the same thing with a smaller investment (it's really rare that they use the exact same stack and have the exact same requirements and get to use the thing as is)

Less vendor lock in, where you are the vendor. The customer may decide to have the next update or the hosting done by a second party. It shouldn't be that much of a practical concern, because you know all the ins and outs and should be able to do the work the cheapest by far, but customers don't always realize that.

You can not talk bullshit to some clients about some bug if they can just look up the actual commit on Github.

Sometimes the company invests a (possibly large) sum of money into something really new and better than everything else out there, and useful for everybody in the same business. Competitors would jump on the opportunity to get hold of it. Don't open source that.

Your case sounds like an internal library where customers don't directly enter into the picture, it's relevant to a broader audience not just the type of business your company is in, and it doesn't immediately give away huge benefit to competitors. We wouldn't be afraid of having this public.

Basically if you always have openings for programmers, then stress the 'attract programmers' angle, otherwise there may not be enough pro or con to get your manager interested.

user8365 · Answer 8 · 2015-02-08 15:16:08Z

Are there really any technical reasons for open sourcing your software? If you believe it is a mechanism that creates better software, who doesn't want better software? I agree people who are technical tend to embrace and understand how it works. Non-technical people who are in the software business should know more about all types of licensing than the average person. You can make a case from a business perspective.

It could attract better developers to your company without having to disproportionately pay them compared to other companies where their type of work isn't viewed as contributing to the greater good.

Outside developers will improve the software and you'll still get to use it.

Search This Blog

Iyfjky

How do I encourage a non-technical boss to contribute something open-source? [closed]

closed as off-topic by Jim G., gnat, Chris E, IDrinkandIKnowThings, Thomas Owens Feb 11 '15 at 11:54

closed as off-topic by Jim G., gnat, Chris E, IDrinkandIKnowThings, Thomas Owens Feb 11 '15 at 11:54

closed as off-topic by Jim G., gnat, Chris E, IDrinkandIKnowThings, Thomas Owens Feb 11 '15 at 11:54

closed as off-topic by Jim G., gnat, Chris E, IDrinkandIKnowThings, Thomas Owens Feb 11 '15 at 11:54

4 Answers
4

4 Answers
4

4 Answers
4

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

Category

Random preview

How do I encourage a non-technical boss to contribute something open-source? [closed]

closed as off-topic by Jim G., gnat, Chris E, IDrinkandIKnowThings, Thomas Owens Feb 11 '15 at 11:54

closed as off-topic by Jim G., gnat, Chris E, IDrinkandIKnowThings, Thomas Owens Feb 11 '15 at 11:54

closed as off-topic by Jim G., gnat, Chris E, IDrinkandIKnowThings, Thomas Owens Feb 11 '15 at 11:54

closed as off-topic by Jim G., gnat, Chris E, IDrinkandIKnowThings, Thomas Owens Feb 11 '15 at 11:54

4 Answers 4

4 Answers 4

4 Answers 4

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

4 Answers
4

4 Answers
4

4 Answers
4

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor