Management 'Scared' by Open Source 373
A discussion panel at EclipseCon exposed how managers are freaking out over open source. Apparently a disconnect exists between managers who set corporate open source policies and developers supposed to follow them, but who end up covering their tracks to make it seem like they are not using open source. Developers, though, end up using open source because of its ubiquity and not using it 'puts them at a competitive disadvantage because their competitors are.' And the Lawyers are in a panic.
Heard that (Score:5, Interesting)
It's like a fiver you leave on a bus for anyone to have, people are always skeptical if they can in fact take it.
On the plus side, it's fun explaining the public domain to folk
Tom
Re:The main reason is lack of clear knowledge (Score:4, Interesting)
Tom
Strange conceptions indeed (Score:5, Interesting)
On the other hand the leaking of GPL code is a reasonable concern. It happens all to often with common software such as MySQL. And you here statements such as "but if we use Perl, we are not linking against the MySQL code", which are dubious at best. Or "if the customer downloads the library himself, we are not responsible".
Of course banning open source is not the solution. Actually most commercial software packages have some content of open source code (Windows has the BSD network stack, Matlab has BLAS, Adobe uses the JPEG library...). And even if you ban all open source software, you can still violate the license of a commercial package
Re:The license issues (Score:3, Interesting)
I'm sorry. What did you just write? Give me one example of a company being forced to release previously proprietary software under the GNU GPL. One. I dare you.
FUD (Score:2, Interesting)
If the company policy is closed source that is it. Managers are absolutely right to make sure that nobody uses open source in company products, because if somebody sneaks in snippets of GPL-protected code into their applications, that might have big legal ramifications.
Said that, the company policy to use open source in their productsor not is another issue. That is up to particular company, particular circumstances. For some it is better, for some it is not.
Best Buy (Score:3, Interesting)
Re:The main reason is lack of clear knowledge (Score:3, Interesting)
Managers are under the mistaken impression that if i just use spring or Jakarta Commons, the company MUST open up the whole project in which it is used (like a proprietrary trading system) to Open Source.
Use how? What if one of the engineers needs a snippet of code, copies it from Spring, and incorporates it into their product without attribution? Suddenly, that company is legally vulnerable.
You only need to open up if and when you modify Spring framework with your own code
No, that is not correct - the Spring framework does not require you to distribute your changes. You just proved the point: licensing mistakes are easy to make. If you were developing a program that incorporated Spring, and mistakenly believed that it required you to license your source, you would cost your company a great deal of money by doing so. That is why the fear is legitimate.
Open source hacks is another fear they have: the fear that somehow using open source tools will make their client sue them.
And that's a reasonable fear. If I sell code that violates a license to a client, that client becomes legally vulnerable and might sue me. Because open source software is so accessible, it becomes easier to inadvertently violate a license.
Leak Back: Managers fear developers, in their zeal to promote open source, will incorporate company's code into open source for 'benefitting' others.
I doubt very much that's a concern. No developer is going to risk their job for open source warm fuzzies, and conversely, no open source project is going to accept leaked patches. Any project that did would open itself up to huge legal liability. Corporate espionage and bribery is a much bigger worry.
You mentioned maturity, but I think you have it backwards - corporations have developed strict, mature processes for keeping themselves on firm legal footing, and licenses are reviewed and vetted by the legal teams. The wide availability of license-encumbered code means that engineers have the opportunity to play lawyer. That's bad, and if you're a manager, you should be scared by that.
disempowerment (Score:5, Interesting)
Free software is also not advertised unlike commercial products, which means that managers can't even communciate, what is going on, to their kin.
Compare: "I recently negotiated a licencing deal with <known software company> for <known software product>, which i deemed to be the best solution because of <list of buzzwords>"
To: "Well, my IT guys implemented a working system on their own, using some software I can't pronounce and really don't understand."
Re:The license issues (Score:4, Interesting)
How is that semantics? I thought that was the whole point - PHB's are afraid of having to release all or part of their precious proprietary software. But that's not what happened with Linksys/Cisco and the WRT54G routers. It was a striped down Linux distro. Ok, they had to put it together, perhaps write some shell scripts. I'm not sure where the web interface came from. But did they have to release any super-secret proprietary source code? I doubt it.
So really, has there been any actual cases of a manager's worst nightmare, the scenario that Microsoft has been FUD'ing us with for years - having to "open source" their internally developed software because a developer in some way used Open Source Software? That's what I'm after. And I don't believe it's ever happened. It's just FUD but the managers don't know any better.
Re:Heard that (Score:3, Interesting)
I think I understand their concern. Technically you still have copyright over your works, as copyright is automatic, but it's what you do with that copyright subsequently that makes it de-facto public domain work.
Also, it's not strictly true that you're passing it on without licence - you are entering into a verbal contract with your clients (which I believe is binding in most legal systems, but don't quote me on that) which gives them certain rights over your copyrighted work. A good lawyer would probably prefer a written contract, so that they have some form of proof in the event of a dispute.
Re:Heard that (Score:5, Interesting)
I've actually *sold* a few of licenses to the public domain SQLite [sqlite.org] library. Companies call me up and say they want to license the product. I carefully explain that no license is necessary and that they can use it forever for free for anything they want. But they still want a license. So I sell them one. So far, I've sold them cheap. Maybe I should charge more....
This appears to be more of an issue in Europe where, apparently, the concept of "public domain" is less well defined than in the US.
Re:Of course they're scared (Score:3, Interesting)
In my experience managers can actually be educated quite fast/well on open source if you know how to sell it to them. The main keywords are 'cost savings', 'reliability', 'significantly less downtime', 'scalability', 'flexibility', 'performance'.
And big company's like Novell, IBM and RedHat selling opensource/linux make a very strong case.
Actually, in my experience management doesn't care what is running on the servers as long as it -just works 24/7 and saves them money-. It's not like they will actually have to fix it should any problem arise. Please note that you will have to take full responsibility for the product your are recommending, anyone will back out immediately when you have any doubt. In contrast to commercial software, 'finger pointing' games cannot be played with open source, so if anything goes wrong you'll be shot on the spot. But in my experience everything will go just fine and expectations will often be exceeded.
If you take the time to make an alternative cost calculation for the next project and invite a company that can sell it to you, chances are good a manager will change his mind.
Also, make it very clear that it's the manager's budget and you are just trying to make their life easier. In the long run, your manager will become your friend.
The main problem are engineers without any Linux/Unix experience fearing for their jobs, they will do anything to sabotage the whole thing and start shouting like the world is coming to an end.
Re:The main reason is lack of clear knowledge (Score:4, Interesting)
In a manager's budget, developers time are free (Score:2, Interesting)
See the problem here? Using open source give an advantage in the minds of the developers, but not the managers? Why? Because developers' time are free for managers of most in-house IT dept! Developers' salary is fixed cost in the budget, once hired, a manager rarely have to justify it every year. On the contrary, developers viewed as having little to do would have caused more problems for their manager!
So for a manager, a developer's time is a free resource that happens to have a "use it or lose it" property.
Now, give him a choice of (1) buying a piece of software for a given price, (2) use a comparable open source software with a license he do not understand so he can (2a) try to understand it himself and thus open himself to any future problems or (2b) send the license to legal dept and gets charged to his budget, or (3) tell his developer to re-implement the software themselves, no further expense claim or budgeting needed. Guess what a lazy manager will do?
So when the manager chooses option (3), and the developers see months and months of unpaid overtime and endless bug fix headaches coming from re-inventing the wheel, they covertly downloads an open source library and plug it in, with a custom wrapper to hide their tracks. Is that a surprise?
No amount of education will not cause a manager to take any amount of risk choosing open source instead of using a "free" resource to achieve the same thing (a resource that cannot be saved and use later in any case). The developer's time and effort is an externality in the manager's consideration.
The only way you can bring the manager to use open source is to add the developer's time into the manager's accounting, either when developers are "pooled" and any effort spent will be charged to the manager's budget, or when the developers have other things to do so there is an opportunity cost to have them do other things.
Because of code exposure (Score:1, Interesting)
I myself though once that one of them was good, because I heard he did some cool stuff and because I saw with my one eyes some good coded stuff referencing its name as the author. But once, I had to work directly with him, and then I was, to say the least, disappointed by its desgin skills, the guy simply didn't understand basics of middleware design. How could it be that he really designed and coded the previous piece of code I saw? Simple and straight: he didn't. Later, I encountered the real author of the work which impressed me, and this guy had the required skills, what our first intervenant did was simply to steal the original code, jumping from one company to another, working on the almost same subject and re-writting the stolen code in a very directly inspired way, when it wasn't litteral copy.
The fact is that this is not a so uncommon behavior, in some compagnies I have been considered as dumb when I say that no, I didn't leave my previous work stealling confidential or proprietary stuff like code, document templates or process definition,
and many managers are pefectly aware of the situation. Using free software code may lead a compagny to expose the code of its products, and they fear that another concurrent compagny read their disclosed code and say "hey, this is our original code".
If you want to make money with free software:
1- take well-working implementation of something under BSD license,
2- adapt it to embbeded software, rougly test it,
3- (usualy ???) build a compagny and sell your library only to big or medium-sized entreprise, presenting you comagny as owning copyrights for the work,
4- profit!
This way, you will seduce managers who will be using free software without nowing it, ignorance is a bless, and with a legal fuse in case of problem. In case of problem, just give up your compagny, which, as a moral person, will endorse all the blame, and just build another one.
This makes perfect sense. (Score:3, Interesting)
Another problem with open source software is that patent liability is placed on the user of the software, not the creator. The SCO/IBM lawsuit shows that. License a piece of Microsoft software, and the patent trolls go after Microsoft. Use a piece of open source software created by Ted in his garage, and the patent trolls go after you.
IBM is VERY strict with open source now. Nobody is allowed to use open source or public domain code in their projects unless it's gone through a very rigorous screening method to make sure there isn't any copyrighted code in there. And they provide a 'whitelist' of software that has been prescreened and is allowed to be used by developers. This list is rather small though. It requires alot of effort to remain safe from a legal perspective, and I doubt that few companies outside of IBM have the resources or expertise to do it.
Re:The main reason is lack of clear knowledge (Score:2, Interesting)
drsmithy wrote
IANAL and it has been a while since I even read the GPL, But IIRC I am free to use / modify any GPL program completely unrestricted up to the point I redistribute, because really, who would care whose programs I use privately (assuming I am not pirating a proprietary code)?
So as I understand it Spacely Sprockets can build whatever system using Spring or whatever, modify it so that it works the best (for them!) and can only redistribute the modified code under GPL. What is less clear (to me) is what if they only wanted to distribute patches of their own code without distributing the Spring source. I suspect that the same rules apply, but again IANAL.Re:FUD (Score:3, Interesting)
There are lots of places where you can legally use open source and Free software in a closed source environment. To cut that out of your arsenal is cutting off your nose to spite your face. Of course it depends on the license and what you are willing to give up. But as previous posters have said, you can use public domain software anywhere. You can use BSD licensed software almost everywhere as long as you don't mind telling people that's what it is. You can use LGPL software as long as you don't mind distributing the source for the LGPL software. You can use GPL software as long as you don't mind distributing the source for the GPL software and you have a good separation between the GPL software and your closed sourced software.
I've worked primarily in closed source companies. I should be clear that I think such business practices are stupid. They hurt the customer and they hurt the competitiveness of the company using them. I can't tell you the number of times I've spent a company's money writing features that help achieve lock in without giving the user anything in return (or even make the customer's experience worse). I think that's dumb. It pisses off the customer and wastes money.
Management (and legal) tend to have this idea that they *must* "control" the market otherwise they will lose. They optimize their strategies into tricking customers into locking-in rather than focusing on executing better than their competition. A typical closed source software company does speculative development, spending money up front and then trying to sell what they have already built to customers. In such a company, R&D makes up 10-15% of costs while Management, Sales/Marketing and legal make up the other 85-90%. *This* is why they get freaked out over using open source or Free software.
Their entire focus is on bamboozling and coercing their customers. Saving even 25% of R&D costs (4-6% of total expenses) is not worth it if they have even a small chance of "losing control" of their market. They basically don't care if the solution will be better. Even an "advertising" clause is usually unacceptable since it shows the user that the company's precious "IP" is actually partially derived from something that anyone can acquire at zero cost. It destroys the illusion that one *must* buy from that proprietary company.
It's strange to be a Free software advocate working in the "closed software" world. I've mostly spent my time just trying to understand what makes "closed software" tick. In the end, these companies are trying to win the lottery (and if they already have, they are trying to turn the lottery into their own private mint that churns out tonnes of cash on demand). They spend money up front and are looking for a return down the other side. Generally speaking they aren't particularly interested in "building a business" -- i.e. creating a stable revenue flow and making a living off of it.
Especially with small companies, there is a need to generate some "worth" in the non-people aspects of a company. After investing $2-10 million up front, they are looking to sell the company (not the software) for $100 million to $1 billion. You can't sell a team of people for that kind of money (or so they think -- in other industries people pay significantly more for a portfolio of satisfied customers). "Owning" all the non-people assets of the company is paramount to their strategy. Using open source or Free software to reduce costs is not an attractive position for them.
However, I've noticed as more and more "up front payment" companies have started to chip away at the "back end payment" companies' market. Instead of selling software as a "fait accompli product", these "up front payment" people sell customization to an organization. They offer the customer more choice at the same price. Slowly, this business model is starting to make an impact (although the potential market
OpenOffice (Score:2, Interesting)
My employer refused to use it, because as a free piece of software, it would not have enough features, would be insecure, etc.
Well, I decided to repackage it as OfficeLite, I told them it'd cost an extra $15 dollars to install per machine (I did NOT say it cost this per license), and now they love it! They checked it out and thought it was a brilliant piece of software. I have since told them how I duped them, but eh, I get to keep the first 120 I made from it.
Re:The main reason is lack of clear knowledge (Score:3, Interesting)
Developers are not legal experts either. "Who retains what rights to which code" can become a sufficiently complicated question without bringing the umpteen F/OSS licenses out there into the mix. If the developers can duplicate what already exists in F/OSSland for less money than the legal team can unravel the rights, then staying proprietary is the right decision.
Along the lines of #1, most folk I meet are fearful of the license issues in terms of "do we owe royalties or something?"
Exactly. The trouble is that answering their question can cost more than what incorporating F/OSS will save.
Re:The main reason is lack of clear knowledge (Score:3, Interesting)
Even professors don't always get it. (Score:2, Interesting)
Involuntarily, I screamed "WHAT?!" He paused and gave me a chance to speak, my response was to take the example of OpenBSD, it's Open Source too(different license, I know but that's not the point) and in the previous 8 years there had been exactly one remote exploit on a default install. Microsoft dreams of that kind of security.
He really had no response for that. What bother me though is how many times did he give that exact same speech to students who didn't know any better and just assumed that it was true because a high ranking professor had said it? So as these people leave college and become managers in IT, they'll carry the misconceptions that Professor Dvorak had placed in their heads.
LK
Re:Heard that (Score:1, Interesting)
Actually, it is much more well defined than in the US.
For example, at least here in Germany, works only become public domain when the copyright term runs out (i.e. 70 years after the author's death); this means you cannot put it into the public domain while you live.
Thus, writing a piece of software and then saying "this is in the public domain" is not legally valid, you'd need to write up a license specificially for that, otherwise you can sue for copyright infringement.
To summarize: Over here we take the distinction between "owner makes the source available" and "owner is deceased" somewhat more seriously.
Re:The license issues (Score:3, Interesting)
So, some of Linux's success was timing, and BSD being held back by fear of lawyers. Had Linus waiting another year or two to make his public release, you might all be running *BSD on your home machines, and arguing why it hadn't taken over the desktop yet. You'll also notice that the early user environment wrapped around the Linux kernel was heavily BSD flavored, which made an easy transition from the other cheap Unix of the day, SunOS.
Nice one, Bill (Score:4, Interesting)
Re:NMAP (Score:3, Interesting)
Are you sure? Because it seems to me that you would have a tougher row to hoe to get a court to agree that they are forced to use the terms of the GPL itself rather than the terms that they explicitly laid out for their product.
Are their terms 90% GPL? Yes. Did they add/modify/clarify (depending on your view) a term? Also yes. What makes you think the court's going to say "no no no, this is GPL and you're wrong, sorry" and not "they created their own license, what makes you think the condition is not valid?"