Forums

I work as a software developer for a large software development company and have been told that I can't use opensource software anymore.  I currently use opensource for 90% of the work I do and the tools I use are also used by the rest of my team, my boss and the general development community (Eclipse, Maven, MySQL, etc..)

Has anyone been in a similar situation and effected a change in policy?

Recently, the company issued security guidelines to the entire company.  These are mostly pretty normal, like you have to run corporate anti-virus, can't install pirated software, and don't download audio/video files.

However, they also mandated that no open source software would be allowed. 

My boss wants to justify not only specific pieces of software, for which we could get business justification, but wants to try and convince senior leadership that open source is a valuable part of what we do and that we, as software developers, need to have more latitude about what we can install on our own computers.

Again, I know we can get justification for most of what we need; but the nature of our work is that tomorrow I might run across some useful tool that can help me execute a certain task and it's unreasonable to expect that we'd have to go through the justification process for that on an ad hoc basis.  

Any help is much appreciated.

 

 

melissas's picture

So, what your company is saying is that instead of using free tools that have a world-wide community based contribution, they would rather pay money for tools developed by a single contributor or small group.

No, really, I get it – there are security risks in using software written and offered by a bunch of amateurs (who are not really amateurs). The irony is that open source is much more open about bugs, whereas private pay tools tend to be more private about bugs. But here, I see I am preaching to the choir.

Having written and enforced security policies that inevitably seemed arbitrary to at least one person somewhere, the only advice I have is to follow the rules - Go through the motions and get permission for the open source tools when you can, and find a paid alternative when you can’t.

With time and practice, the company may come to understand such an over-simplified policy costs more than they realize (in administration hours, productivity and money). If the company prefers to spend its resources on the process and the tools, then that is their decision to make.

sorry ...

 

 

Mark's picture

This happens all the time, and now the open-source world feels that suddenly they're being picked on.  They're not...this is just like every other corporate software tools change - it makes it harder for the installed skill base.

Agree or disagree with the change (and you might be surprised that I would probably disagree) you are where you are.

The wrong approach is trying to change the policy.  First, you don't have the standing.  Second, senior people aren't idiots and I suspect they had their reasons.  (Sometimes, it's a COO saying about ONE piece of software, too risky, get rid of anything like it.  These things happen.)  Three, it's likely to get watered down anyway.  

MOST IMPORTANT is delivering on your commitments NOW.  Come up with a plan for changing the software you use for projects you're working on, factoring in the time of adapting to new software and tools.  I SUSPECT your boss will work to get exemptions once the effect on timing of the new tools is more clear.

BE CAREFUL of talking down the change.  Stuff happens.  nobody above likes someone who tells them they're stupid.  Stay focused on delivering results with your work, and new tools take time, and you have to communicate that.

It will work out.

Merry Christmas all,

Mark

jhack's picture

First, get clarity on whether you cannot use open source tools, or if the rule is specific to shipping open source code (compiled or otherwise) with your product.  

Aside from security, legal issues can arise from charging customers for code you did not develop (indemnification, for example, or issues arising from authorship claims). 

As others point out, cheerful compliance is your first responsibility.  So is making clear to your organization the impact that these changes will have on your team and your product. 

Final point:  those who wish to change the rules need to understand them, and their rationale, better than anyone else.  So if you do wish to make changes, you must understand them really well. 

John Hack

RichRuh's picture

I'm going to make the risky move of slightly disagreeing with Mark...  ;-)

As a software development manager, I understand that switching to stop using Open Source could be potentially devastating to the business.  You can't just switch from MySQL, Java, Apache, and Linux overnight- changing your use of this software could easily take a year or more.  And that's a year that you're not meeting other commitments, adding other functionality to your products, and so forth.

This is what I would do:

1. Build a project plan and budget for migrating off of Open Source software, including hard costs (software licenses) and labor costs.

2. Bring this plan to your boss and help him make the case to upper management that the policy should be changed.  Your boss might find that there are good and valid reasons for this change (e.g., your management is in strategic talks with Microsoft and wants to start pushing SQL Server rather than MySQL), or it may be that a lawyer panicked.  

Above all, listen to the advice above about cheerful compliance.  If you haven't already, listen to the excellent (and just-released) podcasts on Professional Subordination.  While you're quietly providing information to your boss to help her make the case to higher-levels (politely and professionally), you must be publicly and privately working to implement this change.  No grumbling! :-)

It's ALWAYS worth remembering that upper management is NEVER stupid.  They have different motivation and goals than you do.  They will almost certainly know things that do you not.  There are certainly times when you will know more than them about a particular subject, but that doesn't make them stupid.

johnleitelt's picture

RICHRUH-

Your answer is thought out and very well worded. Thank you.

John

SamBeroz's picture

We faced a similar challenge a while ago at my workplace.  The concern is that allowing open-source code on our LAN would leave us open to a security risk.  We sat down with the security folks and worked out a well defined process that was streamlined for respected sites (apache, eclipse, etc).  This didn't solve everything, as each eclipse plugin would require a separate security / license form.  To work around that we found a vendor who (for $5000?) would package up the latest eclipse distribution along with most available plugins. This counts as a single open-source code instead of a collection of codes which reduces the paperwork to a manageable level.

It could be worse. We were asked why we needed the internet (another security risk) as we'd been able to live without it for the past 60 years.

- Sam

akinsgre's picture

Thanks everyone... As I mentioned in my original post, it's an emotional topic for me, but I won't be posting here if I wasn't looking to correct my own opinions with more rational ones. 

Sam.. your suggestion is interesting; I facetiously suggested doing just this thing.  I could "re-brand" all the opensource software and resell it to my employer as a "suite".

Can't believe the last comment about the Internet.  Except our network folks want to know why we need dual monitors, since Software Development had occurred for 50 years without. 

stephenbooth_uk's picture

I think the answer to that is that software development also occurred for a similar period without the need for networks and network folks.  Are they advocating a return to that? :-)

Stephen 

--

Skype: stephenbooth_uk  | DiSC: 6137

Experience is how you avoid failure, failure is what gives you experience.

 

mtietel's picture

Software development happened for a long time without any monitors at all...

Rich Ruh has the right approach.  Especially that you need to find out what's driving the policy change.  We successfully modified a new policy so that it reasonably protected the company's position, while allowing for use of Open Source Software.  The new, modified policy does involve additional work for a number of groups and it is working effectively.For example:

- legal examines the license for the OSS package and provides guidance for it's use

- we use a product that periodically scans our code looking for "unapproved" OSS code so we don't lose control of our IP

mtietel's picture

deleted duplicate post