" I can tell you this it's completely retarded to run your own email server. Costs and time spent maintain it is silly when you have 40 employees."
Do you really beat 5US$ per month per employee (for a total of 7200US$ over a three year period) I got on an exactly 40 employees company for their three-year running mail service with your Exchange plan? This included: * Hardware with three years warranty * Server OS configuration and maintenance for those three years * CALs for both remote access (secure POP and IMAP) and web mail * Antivirus and Antispam * Infinite accounts and domains (for 40 employees most were alias to some employee, but whatever) * Absolute configurability (on the mean time they chained their e-mail solution with fax, SMS, IM and groupware, but that's a different story) * 0 recorded malware incidents (either virus, worms or break incidents) * Firewall internet coverage for free
At least that client made its homework and its ROI and its TCO calculations and, know what? they are very happy with its Linux solution, thank you.
"please somebody tell me why.. oh why must software be written for free?"
Please tell me who.. oh who told software must (or should) be written for free?
Just some two hours ago I've been watching TV (something about a bad humored, drug addict doctor with almost magical diagnostic abilities). Do you know how much did it cost me? Zero, Null, Nada. Do you think all those actors, guionists, technicians... did it for free? I don't think so. Did you see me telling they should do it for free? Of course not.
Of course too, you are a troll, but that's quite a different story.
"I am sitting here just now contemplating should I go iSCSI over Ethernet or NFS (over the same gigabit Ethernet) for a small VMware Server (to cheap for ESX) deployment."
Then you should try a third way: ATAoE from Coraid. For your kind of deployment can be half the cost of iSCSI, outperforms NFS and it just works (and for a real cheap try you can go with your standard linux boxes first and, if convinced go then for a disk cabin and a gigabit switch for a SAN-only network).
"I don't think the ease of using a green phosphor screen is a consideration."
Did you lose where I talked about "history"?
"I'm having a hard time understanding how green intensities are the easiest to detect, but hues the hardest"
Look then at an oversimplification: How many photons do you need at a given wavelength to percieve ligth? How different must be the wavelength of two photons to be percieved to be different colors?
Now: green takes very few photons to be percieved, but two green photons slightly different in wavelength are not easily percieved as two different green tones. Did you get now?
"And not that is the end of the discussion, but: "A Night Vision Phosphor Screen is purposefully colored green because the human eye can differentiate more shades of green than other phosphor colors.""
I promise I'll won't make fun off of you by taking a marketing brochure as a scientific assertion.
"No, I believe he's right. We see more green hues than anything else."
Don't think so.
"Take a look at a color gamut table, which is a visual representation of visible color space. Note how the distance from the neutral point to the edge of the green portion is much bigger, and how small the blue part is."
Then, please, interprete it properly: as you can see, half the spectrum is green and you can't say one green from the other, which is exactly the point. Then look at http://handprint.com/HP/WCL/IMG/vizluv.jpg which is basically the same representation only it shows the perceived spacing of spectral hues as the radial distance between hue markers. See? Now it's the green zone the shortest and the blue the largest. (Have a look at http://handprint.com/HP/WCL/color2.html section "Hue Discrimination"). As a practical matter, you can see here (http://handprint.com/HP/WCL/cwheel06.html) a "practical artist's color wheel" and see again how the blue and red zones are the largest while green/purple are the shortest).
Just to through out the numbers, maximus hue perception are around the 480 (medium blue/cyan) and 570nm (yellow) zones while minima are at the far ends (obviously) and at 520nm (green). The overall graphic resembles somehow a "W" where lower points means higher hue discriminance. Talking about wavelenght, it takes in fact about double to distinguish two greens (more than 4nm) than two blues (about 2nm).
"No, the right to property is an inalienable right of a human being."
Sorrily enough there's no thing as an "inaliable right" (/me says on a sad, melancholic voice while stabbing electrictroy with an iron club and then taking out his pocket money with honest tears on face).
"You own your body."
Tell that to death sentenced
"You own the product of your body's labor"
Tell that to a slave. Heck, tell that to one paying a house mortage.
"If you build a chair, it's your chair"
If you build a chair it's a chair made by you. Nothing more, nothing less.
"If somebody else wants your chair, that is theft of your body's labor. That's a violation"
Can you spell "taxes"? And even if it is a violation, it *is*. No matter if I got it by means of a violation, now I own it.
"The state, aka government, only exists because the people created it."
Sure! who can deny that? But then, what? People created wars, robbery and slavery. You can word it the way it makes you feel the better but it doesn't matter a dime who made the chair: the chair is owned by the one that gets it and can sustain his position the strongest (just for the latest example, go ask Irak people who owns the oil *now*). People (well, not even people but Nature) created it that way.
"I have also read that we can detect green hues better than any other color. An engineer employed by the army told me this is one of the reasons that the pseudo-coloring is green for night-vision (IR detectors)."
Don't think so. In fact, it's the opposite: you can detect green hues the worst. I'd say IR detectors are green for a twofold reason: First, historically; since you can't see IR you needed a sensors to translate IR into something visible and that means phosphorus which produces green ligth the easiest (that's why first monochrome computer tubes were green on black too). Secondly green *is* what we are most sensible to so that means we can percieve shapes with less wattage (good for military gadgets that must last long and weigth low). As an added benefit low luminances means you can't see the scaping light from a night-vision device from afar thus revealing your position (on the other hand you can see somebody smoking a little cigarette -red/orange light, in the night from miles away).
"The distribution license is relevant because programmers are most likely to complete a project in a predictable manner when you pay them."
If you really think so, by all means, pay them. Still you haven't show any direct relationship between paychecks and distribution license while I already showed at least one case (Red Hat) where paychecks are layed around while distribution license of deliverables is GPL.
"Corporations only pay for things that show them a demonstrable return."
So being Red Hat a corporation there must be a way for GPL development to show demonstrable return.
"So far, -most- corporations still look askance at sinking money into code they're then going to open source."
Which mainly demonstrates the degree to which corporations tend to be conservative. Just to show you an example within the same IT environment but as oposite as possible, how do you think that Microsoft was able to reach its current position when other companies (say, IBM) were more than able to crush it with just their thumb? Well, maybe because they didn't think there were a real bussiness case on what Microsoft was trying: they were too much time looking askance at sinking money into IT products for SoHos and/or cheap end-user IT. But, hey, if most companies are unable to see the returns, it must be there are no returns, mustn't it?
"What I will say, though, is that I don't think the value proposition behind contributing to open source necessarily works for most companies."
Since most companies doesn't work in the IT field, I'd say it in fact does. It is not as if they weren't already contributing to software development: they do each time they pay for a license. It's only that, in such a case they are obviously paying too much (or else it would have been impossible for people like Bill Gates, Steve Jobs, Mark Shuttelworth or Larry Ellison to reach so high net benefit margins and become so terribly rich) to get products that so many times evidence they are developed much more in order to satisfy the vendor than the client. Since open source contribution offers for a change a clear opportunity for such companies to get into the driver's seat on such an strategic value as corporate information management, it becomes obvious that, at the very least, it's a very interesting proposition to consider.
"Again, it's case-by-case, but for most companies, the right answer will be paid support from someone else."
And you, again, fail to see the obvious: what the heck has to be paying and open source? What the heck is against a company getting payed support for SugarCRM, Apache, Compiere or whatever open source software they happen to use.
"That means either for-pay software development"
Which has nothing to be with such software being open sourced or not.
"or again, the very successful open source projects that attract commercialization. No QA, no support, no corporate interest."
Of course, it's impossible to get QA unless you pay for it. There's no other choice since, as everybody and his mother know, QA is not done by people but by 100US$ bank notes sitting on an array. On the other hand, who would expect say Mandriva, paying developers and doing QA to support their Mandriva Management Console, an open source product, or Red Hat paying developers and doing QA for their Cluster Management Tools, and open source project, or lots of companies paying internal developers for customizations for Compiere, Project Open, SugarCRM or a ton of other Open Source projects.
"That's just the way of it."
Yeah, don't let the fact the world shows you otherwise to undermine your clever and solidly built argument.
"Open-source isn't exactly what you'd call the fastest or most direct method to produce a product."
What the hell has to be the distribution license with the production methods?
"Nothing replaces real dedicated, paid resources."
Then why don't you have "real dedicated, paid resources" developing and/or hacking open source solutions for your company? You don't really think Red Hat's employees stay in the company for free, do you?
"Then imagine some people start working for you. You want to force them to use a Linux desktop?"
Of course yes. It's my company, isn't it?
"People are most productive with whatever they like to use"
Yes, true... for a while. Probably every and all bulldozer operators started firstly driving their cars. Why don't we give them cars instead of bulldozers? after all, people are most productive with whatever they like to use, don't they?
Jokes apart, since it's a company it's all about money and you will have to make your choices. It's just about not forgetting the hidden costs on the equation. Let's imagine you indeed start hiring people: well, probably the first one you'll contract won't be a senior systems administrator but someone nearer to the reveneue line and probably you'll be his or her systems administrator. Then you should consider the added time it will take *you* to administer his computer on an unfriendly (to you) operative system and the opportunity cost involved (a boss taking care of another's computer is not a boss making "bossian" things) versus the added benefit of your hired because he uses a computer he's more comfortable with the first few days. Or, providing there's enough choice you could just go from the beginning with somebody who already knows Linux as a user level or is willing to fastly learn.
And then you grow even more: you -again, will have to consider the average boxes per sysadmin on the Windows world vs the same numbers on the Linux world vs average wages for each other on your locality. And then, you'll have to consider ROI for niche solutions on one platform or the other; and then the opportunity costs when faced against one of those things that are undoable or costs tons on license cash on Windows while are doable for nuts on cheap hardware provided you hire the proper unix/linux guru. And then...
Overall I'd say you'll find easier to be more or less "average" going with Windows (after all, the average company *uses* Windows) but there will be exciting and truly valuable opportunities in using Linux, provided you are clever enough to see and go for them.
"And after you modify your source version of the code, congratulations, upgrading to the next version is at best case going to require careful thought and planning, and at worst case a lot of time and effort on your part."
And even then you end up on a wining position.
In the first case you would have a relaxed upgrade path (hey, we all know all privative-licensed programs are always a breeze to upgrade, don't we?) *but* the software *still* will have the bug: remember that the case was about a privative-licensed software whose owner didn't want to provide a bugfix vs. an open-licensed software whose primary provider didn't want to provide a bugfix.
In the second case you still would have two valuable options: 1) Provide the bugfix to the upstream vendor *even* if it didn't want to produce it itself. The upstream vendor might want to patch the main line after the hard work is done (after all, it will probably benefit their other clients). 2) Assess a cost-benefit analysis: is the bugfix valuable enough for all the hassle of patching new versions? If it is valuable enough, you still win versus the option of no bugfix at all, and if it isn't worth the effort you still are no *worse* than in the very begining.
So, again, even using arguments from closed-source minions open source arises as a win-win proposition.
"The danger of customizing your open source product is the same danger that companies face modifying products like SAP"
This is quite off-topic, but HA! is SAP what you are talking about? Is there any company that uses SAP as-is? Heck, is even SAP meant to be working out-of-the-box in any case? Of course upgrading will be expensive but in the case of SAP it is out from a well thougth strategy where SAP is more focused on SAP itself and its consultants, knowing they work by their side about getting enough gullible CxOs to make their day. SAP is *all* about being expensive and CxO marketable.
"Here you have greed working against you. Since it's OSS, you'd have to release the bugfix into the world"
No, you don't.
On one hand, not all OSS licenses are born equal (as privative licenses are not born equal, either). It's obvious that what it's true regarding BSD doesn't need to regarding GPL so please, refrain a bit about talking absolutes about OSS: to many of them won't hold water.
On the other hand, even talking about copyleft OSS, like GPL, it's untrue that you have to release the bugfix to the world. As long as you don't redistribute binaries you don't have to release the bugfix either. Please read the GPL and see it by yourself.
"how businesses usually think. Share their stuff with others? Give other companies an advantage that WE paid for?"
That clearly shows there's a bussiness case for Red Hat to go for it.
While most CxOs might say that they won't give other companies an advantage they paid for, the hard fact is that they already do it! Or do they really think that developing the bazillion of code lines from, say, their Oracle solution do in fact cost the meagre 10.000 they paid for it? Or are they so naive not to know that by paying Oracle those 10.000 with such draconian CLUF they are in fact making the case for their direct bussiness adversaries to be able to get Oracle by just 10.000 too?
It's everything about perception and as such, opened to change by means of marketing practices, like a CEO telling other CEOs that "there are other ways to make bussiness, and I'll show you".
"If the project is budgeted for 1000 hours and the goal is to build a blog that works just like Slashdot, what if he books 990 hours surfing for pr0n, downloads Slashcode and strolls in the door with an invoice?"
Yeah, so what?
The company wanted to pay 1000xhour rate in order to have a Slashdot-like blog and they ended with... what? A Slashdot-like blog that costed 1000xhour rate, so where's the problem? This case is not an academic one where "cheat is forbidden" but a results-oriented scenario. If someone can make 1000 for something that costed him 100, the better for him.
No: I think it's a clear incompetence case. The wanted to say "non-copyleft code allowed" (maybe because they didn't want to close the door for that software to be licensed to third-party clients) and ended up saying "non OSS allowed" out of ignorance of the differences between GPL-like and BSD-like licenses.
" A number of times I've pointed out to consulting firms I've worked for/with that they weren't compliant with GPL because they weren't putting their code improvements back into the wild"
And so you looked like an idiot whenever you faced someone that took the time to read the damn license.
"A frequent example that comes immediately to mind from a couple years back is Asterisk solution providers."
I worked with some of them on the past and I never had any problem to get a hand on their GPLed software upon request, so I can say that's not the general case.
"As a post-script, I think that developers have a certain amount of professional responsibility to point out the licensing model for any code they seek to build into their solution."
Whenever someone takes code from anyone else is their legal responsibility to have a look at the acompanying license. If he's a proffesional developer I'd say they have an ethical incumbement too.
"But if I'm already the Goliath that everyone is chasing, it is in my interest to keep barriers to entry into my market as high as possible"
That's true, and that' why nobody really expects Microsoft going truly on the open source wagon on the foreseeble future. Even if in a new niche it would cost them a hugh ammount of money the "do-it-yourself" way they surely would try as a means to monopolize it (after all they have hugh ammounts of money to spend anyway). Only when forced they'd do otherwise. On the other hand, Microsoft's main competency is not about making software, it's not even about selling software, it's about granting IP licenses: everything that goes against the mindshare that granting IP licenses is "the" proper valid way to make bussiness is clearly against their very bottomline, so no wonder they try to fight against that kind of idea with all their forces.
But look at your own company and you'll see that most of the software you use is now either commodity (e-mail readers or web browser, office suites, sysadmin tools and automation...) or generic/not directly related with your very company ("skeletal" ERP/CRM functionality, bussiness flow, legal/accountant...). Is *that* kind of software that any company can gain advantage from sharing. As I already told in another comment, companies already know that: after all they are more the ready to pay money to Microsoft, BEA, Oracle, SAP... for that kind of software; they are *already* sharing costs among them while it would be both more advantageable and probably cheaper to find a new way to make bussines where they, the "consumers" where in direct control of the development process instead of being reactive to the software companies actions.
Oracle or SAP are not in bussiness for the sake of you but to take out the most of you. That's true for any bussiness, Red Hat included. What Red Hat's CEO tries is to tell companies that there are ways of doing bussiness on the software world that can be better aligned with the client's needs than the "traditional" license-driven one and that Red Hat is wanting to pursue them. This is unknown to many CxO out there and makes perfect sense for a CEO of a company like Red Hat to "blow the whistle" about it.
"Now I am VERY curious to hear one of you pie-in-the-sky fossies explain how exactly we wouldn't get COMPLETELY and TOTALLY SCREWED by open-sourcing our software package?"
Of course you WOULD! You are missed the boat and you are talking about a very different bussiness case. You are already on the PRIVATIVE SOFTWARE boat: you (your company) put the money on the table *first* and now looks for a way to recover the inversion.
"Furthermore, our competitors also offer packages of their own to perform similiar functions, but (at least for now), our in-house developed package is considered the "best-of-breed" and is well-liked by our users. "
Now, from your own example, please think about the fact that your company is not the only one in the world. Now, think about all these "sencond rank" companies and how they would have an easier day to beat your company by opening their software, at least among them, as the cheaper way to make their software better and use it to help them to take you out of the market (specially in a case like yours were the software is not the main "money atractor" but "just" candy on top of the cake). Maybe those companies see that one of your bussiness advantage is your software (but the real money is in the selling of those hard-ware of yours). The fact that it doesn't make bussiness sense for YOU doesn't mean it won't for others.
"HTF does your "all software should be free" idiom have ANY application to us whatsoever?"
Don't you see the case that your own very software would have been cheaper 'a priori' and that specially in a growing market (where opening it is at least as important as getting a foot over your competition) your company might have been able to make more money even at the expense of "gifting" some of it to your direct competition? Maybe if your company wouldn't have to give all that money *in advance*, now it wouldn't have the need to recover it and maybe that money would have been better used improving your company directly where their major incoming factor is instead of diversing at a risk on the software manufacturing camp (after all you only NOW know that your software is a bussiness advantage; when the development started it was nothing but a corporate risk).
"That's physically impossible to be a positive financial move."
Tell that to Red Hat. Red Hat is your physical imposibility since they make positive financial move out of their own software initiatives.
"One company pays for initial development. That money is gone and spent. They're not getting it back, ever"
Unless, of course they *do* get it back as Red Hat does. That's the "coaxing" Red Hat's CEO states. There are vast amounts of GPL-ed code ten years ago were unthinkable. GPL is (somehow) viral, yes, and over certain "breaking" point it certainly makes very real financial sense move on board instead of going with your own internal development of buying a closed-source solution.
If Red Hat manages to properly be a real "strategic partner" for some big companies (after all, "strategic partnership" is already a warm buzzword -it's only it's false: all those "parterns" are not partners at all but "clients and providers") it would make it happen: instead of just pay me for my consulting work, "pay" us all by means of time-share of that C++ hacker you already have in your payroll. Or just don't pay me for "hacking" your internal "whatever" but allow me to "productivize" it and add it up to my services portfolio. Or... (well, no more ideas to Red Hat's CEO without a contract).
"No matter how much community help is provided, that company that gives away code ALWAYS spends more than competitors who get their hands on the code"
Maybe Sun, or IBM, or Red Hat think otherwise. Or do you think that they don't use their own products to their own benefit?
"Software is built in companies to make money."
Are you sure? I'd say most of them is developed to *save* money, not to directly make it. Maybe some of them would understand that they can save even more money by sharing common parts so instead of reinventing the whole wheel it's enough with a single radius and take the rest of the wheel from anyone else. Even now is a question of culture, since you hardly see any companies (even in the same niche) just partnering to share some "developer time" while they would gladly buy the same software from a third party vendor -on the vendor most favourable terms instead of theirs, that is. What's the real difference from, say, ten fortune 500 companies giving SAP two million dollars each or making a joint venture among them to build a customized ERP for 20 millions? But then while the former is "common practice" the latter, while obviously more advantageous for them seems to be an impossible dream.
"It's always a lose-lose situation for a company to open source their software."
Yes of course. And having a complex functional unix-like operative system free of license fees is a physical impossibility. Yeah, we all know that.
"Somehow, Spanish has managed to solve the problem."
I claim bullshit on this. That was Juan Ramón Jimenez's dream (1956 literature Nobel Prize), but we are not quite there.
While it's true you know for certain how to pronounce a word as soon as you see it written down, the reverse it's not: you can't always know how to write a word you heared (as it was the point from the previous poster): 'baca' and 'vaca' sound exactly the same as would do 'hueso' and 'ueso' (if the latter existed, which is not). You would write (relevant word remarked) "*tu* madre" but "*tú* eres", again same sound, different graphs.
Even then, there is an exception on the "phonetic rule": letter "x" changed its sound somewhere in between XVI and XVII centuries (I don't know when), so you have some "oldish" proper nouns written down with "x" (like México, Texas or Xavier) that are to be pronounced as "Méjico", "Tejas" or "Javier" instead (well, I don't know but these three exceptions).
"I'd really like to know how that came about."
Not too difficult: Spanish is a latin-based language, and the cute symbols you use to write down ideas are not called "latin alphabet" for nothing.
The phonetic problems come from the fact that there are "too many letters". Letter "b" and "v" became the same sound about the XVII century; letter "h" lost its sound (it's mute) about a century before. There are letters that have different sounds depending on context ("c" on "casa" sounds like "k"ilo, while on "cerilla" it sounds like in "c"entennial). To make things worse, two letters may overlap sounds ("z" always sounds like "c" on "cerilla", while "c" may sound different. Again, "j" has always a hard sound, non-existant in English -more or less like "aghhh" -listen to a mexican saying his country's name; remember that "x" became "j" afterwards), while "g" may sound like previous "j" i.e.: "gemido" or softer like in "guapo", more or less like "gas"). Then you have so-called diacritic rules about accents ('tu' is possesive while "tú" is a pronoun, but they both just sound the same).
And then, some syntactic sugar regarding irregular verbs (while past participle from "comer" -"to eat" is regular and comes as "comido", "poner" -"to put" is irregular and its participle forms as "puesto" instead of "ponido").
Of course every English-spoken people would find verbal forms quite cumbersome (six diferent persons -three singular and three plural, five modes and about four tenses per each mode, with simple and complex ways all of them... oh! and three regular conjugations depending on the verb ending on -ar, -er or -ir, and a plethora of irregular and defective verbs); not as bad as German, but quite there.
"Yes, and if they'd been busy, on vacation, or sick, you wouldn't have got a minute of help. That's not an acceptable mitigation strategy for the risks associated with using software for mission critical applications."
And what about having professional senior technicians in charge of such "mission critical applications" and then they themselves can boil the egg, so to say? From my experience it isn't an acceptable mitigaion strategy either, and the hell if I can imagine why (well, I *do* imagine why, but it certainly is not related at all with the actual ability to minimize production losses and maximize operation reliability).
"But a pre-paid fast response service for Sev 1 problems *is* an acceptable mitigation strategy"
Even when they know beyond all doubt that their "fast response service" is an automated e-mail or voice machine response and that you will have to fight with first tier "technicians" till monday morning (if you are lucky) anyway. The hell if I can imagine why (well, I *do* imagine why, but it certainly is not related at all with the actual ability to minimize production losses and maximize operation standards).
"Or would you call someone dying by driving into a bridge pillar at 120mph an engineering problem?"
Of course not. Because it's out of the problem realm disallow pillar crashing, not because "human stupidity is not an engineering problem".
When something is well within the problem realm (passwords are to allow for safe authentication), policies *are* part of the engineering problem, and bad policies so much so. Regarding the safe auth problem, not thinking about some nuts stablishing a nuts policy that ends up with passwords on post-its *is* an engineering problem. Engineering is not just about "hard stuff that melts and mechanizes"; it's about people and safe procedures too.
"In all three cases, people went outside the well known, well documented processes because "they knew better""
No. In all three cases people went outside the well known, well documented processes because *they could* when due to problem nature and environment was well within engineering specs that they shouldn't be able to do what they did. Even the Hyatt case would have been avoided with such a simple ingeneering practice as "the engineer should have been there" since, by definition, any singular building is a prototype.
"Edward Tufte has analyzed the Challenger and Columbia disasters and concluded that they largely occurred because critical information became obfuscated as it moved up the decision tree."
Every time you need to reduce a 300 pages technical review into ten powerpoint slides in order to "move it up the decision tree" you know some critical information will become obfuscated on the way.
"The following three I know were the result of human involvement and decisions, not engineering mistakes and are documented:"
Are you sure those are not engineering mistakes? If you ask a user to remember half a dozen, ten characters, unpronunciable password, they *will* stick them to a post-it on the monitor, and that's an engineering problem. If you burden field technicians with unproper unergonomic "safe" mechanisms you know they *will* find workarounds, and that's an engineering problem. If you leave out the project management cycle on-field implantation, there will appear on-field problems that *will* be managed out the project management cycle and that's an engineering problem too.
If you put the self-destruction device button just alongside the lights power switch, it won't be user's fault when he presses it by mistake: it's engineering at fault. If you design a safety system that *mustn't* be overriden in any circumnstance but you design it so it *can* be overriden, it's engineering at fault.
Slashdot Mirror
" I can tell you this it's completely retarded to run your own email server. Costs and time spent maintain it is silly when you have 40 employees."
Do you really beat 5US$ per month per employee (for a total of 7200US$ over a three year period) I got on an exactly 40 employees company for their three-year running mail service with your Exchange plan? This included:
* Hardware with three years warranty
* Server OS configuration and maintenance for those three years
* CALs for both remote access (secure POP and IMAP) and web mail
* Antivirus and Antispam
* Infinite accounts and domains (for 40 employees most were alias to some employee, but whatever)
* Absolute configurability (on the mean time they chained their e-mail solution with fax, SMS, IM and groupware, but that's a different story)
* 0 recorded malware incidents (either virus, worms or break incidents)
* Firewall internet coverage for free
At least that client made its homework and its ROI and its TCO calculations and, know what? they are very happy with its Linux solution, thank you.
"please somebody tell me why.. oh why must software be written for free?"
Please tell me who.. oh who told software must (or should) be written for free?
Just some two hours ago I've been watching TV (something about a bad humored, drug addict doctor with almost magical diagnostic abilities). Do you know how much did it cost me? Zero, Null, Nada. Do you think all those actors, guionists, technicians... did it for free? I don't think so. Did you see me telling they should do it for free? Of course not.
Of course too, you are a troll, but that's quite a different story.
"I am sitting here just now contemplating should I go iSCSI over Ethernet or NFS (over the same gigabit Ethernet) for a small VMware Server (to cheap for ESX) deployment."
Then you should try a third way: ATAoE from Coraid. For your kind of deployment can be half the cost of iSCSI, outperforms NFS and it just works (and for a real cheap try you can go with your standard linux boxes first and, if convinced go then for a disk cabin and a gigabit switch for a SAN-only network).
"I don't think the ease of using a green phosphor screen is a consideration."
Did you lose where I talked about "history"?
"I'm having a hard time understanding how green intensities are the easiest to detect, but hues the hardest"
Look then at an oversimplification: How many photons do you need at a given wavelength to percieve ligth? How different must be the wavelength of two photons to be percieved to be different colors?
Now: green takes very few photons to be percieved, but two green photons slightly different in wavelength are not easily percieved as two different green tones. Did you get now?
"And not that is the end of the discussion, but:
"A Night Vision Phosphor Screen is purposefully colored green because the human eye can differentiate more shades of green than other phosphor colors.""
I promise I'll won't make fun off of you by taking a marketing brochure as a scientific assertion.
"No, I believe he's right. We see more green hues than anything else."
Don't think so.
"Take a look at a color gamut table, which is a visual representation of visible color space. Note how the distance from the neutral point to the edge of the green portion is much bigger, and how small the blue part is."
Then, please, interprete it properly: as you can see, half the spectrum is green and you can't say one green from the other, which is exactly the point. Then look at http://handprint.com/HP/WCL/IMG/vizluv.jpg which is basically the same representation only it shows the perceived spacing of spectral hues as the radial distance between hue markers. See? Now it's the green zone the shortest and the blue the largest. (Have a look at http://handprint.com/HP/WCL/color2.html section "Hue Discrimination"). As a practical matter, you can see here (http://handprint.com/HP/WCL/cwheel06.html) a "practical artist's color wheel" and see again how the blue and red zones are the largest while green/purple are the shortest).
Just to through out the numbers, maximus hue perception are around the 480 (medium blue/cyan) and 570nm (yellow) zones while minima are at the far ends (obviously) and at 520nm (green). The overall graphic resembles somehow a "W" where lower points means higher hue discriminance. Talking about wavelenght, it takes in fact about double to distinguish two greens (more than 4nm) than two blues (about 2nm).
"No, the right to property is an inalienable right of a human being."
Sorrily enough there's no thing as an "inaliable right" (/me says on a sad, melancholic voice while stabbing electrictroy with an iron club and then taking out his pocket money with honest tears on face).
"You own your body."
Tell that to death sentenced
"You own the product of your body's labor"
Tell that to a slave. Heck, tell that to one paying a house mortage.
"If you build a chair, it's your chair"
If you build a chair it's a chair made by you. Nothing more, nothing less.
"If somebody else wants your chair, that is theft of your body's labor. That's a violation"
Can you spell "taxes"? And even if it is a violation, it *is*. No matter if I got it by means of a violation, now I own it.
"The state, aka government, only exists because the people created it."
Sure! who can deny that? But then, what? People created wars, robbery and slavery. You can word it the way it makes you feel the better but it doesn't matter a dime who made the chair: the chair is owned by the one that gets it and can sustain his position the strongest (just for the latest example, go ask Irak people who owns the oil *now*). People (well, not even people but Nature) created it that way.
"I have also read that we can detect green hues better than any other color. An engineer employed by the army told me this is one of the reasons that the pseudo-coloring is green for night-vision (IR detectors)."
Don't think so. In fact, it's the opposite: you can detect green hues the worst. I'd say IR detectors are green for a twofold reason: First, historically; since you can't see IR you needed a sensors to translate IR into something visible and that means phosphorus which produces green ligth the easiest (that's why first monochrome computer tubes were green on black too). Secondly green *is* what we are most sensible to so that means we can percieve shapes with less wattage (good for military gadgets that must last long and weigth low). As an added benefit low luminances means you can't see the scaping light from a night-vision device from afar thus revealing your position (on the other hand you can see somebody smoking a little cigarette -red/orange light, in the night from miles away).
"some women get 4 different variations, and can see 100s of millions of colors."
WHAT!!! You mean that when she starts talking about cucumber, magenta, fucsia, pistaccio, eggplant... they are *real* colors!!!???
"The distribution license is relevant because programmers are most likely to complete a project in a predictable manner when you pay them."
If you really think so, by all means, pay them. Still you haven't show any direct relationship between paychecks and distribution license while I already showed at least one case (Red Hat) where paychecks are layed around while distribution license of deliverables is GPL.
"Corporations only pay for things that show them a demonstrable return."
So being Red Hat a corporation there must be a way for GPL development to show demonstrable return.
"So far, -most- corporations still look askance at sinking money into code they're then going to open source."
Which mainly demonstrates the degree to which corporations tend to be conservative. Just to show you an example within the same IT environment but as oposite as possible, how do you think that Microsoft was able to reach its current position when other companies (say, IBM) were more than able to crush it with just their thumb? Well, maybe because they didn't think there were a real bussiness case on what Microsoft was trying: they were too much time looking askance at sinking money into IT products for SoHos and/or cheap end-user IT. But, hey, if most companies are unable to see the returns, it must be there are no returns, mustn't it?
"What I will say, though, is that I don't think the value proposition behind contributing to open source necessarily works for most companies."
Since most companies doesn't work in the IT field, I'd say it in fact does. It is not as if they weren't already contributing to software development: they do each time they pay for a license. It's only that, in such a case they are obviously paying too much (or else it would have been impossible for people like Bill Gates, Steve Jobs, Mark Shuttelworth or Larry Ellison to reach so high net benefit margins and become so terribly rich) to get products that so many times evidence they are developed much more in order to satisfy the vendor than the client. Since open source contribution offers for a change a clear opportunity for such companies to get into the driver's seat on such an strategic value as corporate information management, it becomes obvious that, at the very least, it's a very interesting proposition to consider.
"Again, it's case-by-case, but for most companies, the right answer will be paid support from someone else."
And you, again, fail to see the obvious: what the heck has to be paying and open source? What the heck is against a company getting payed support for SugarCRM, Apache, Compiere or whatever open source software they happen to use.
"That means either for-pay software development"
Which has nothing to be with such software being open sourced or not.
"or again, the very successful open source projects that attract commercialization. No QA, no support, no corporate interest."
Of course, it's impossible to get QA unless you pay for it. There's no other choice since, as everybody and his mother know, QA is not done by people but by 100US$ bank notes sitting on an array. On the other hand, who would expect say Mandriva, paying developers and doing QA to support their Mandriva Management Console, an open source product, or Red Hat paying developers and doing QA for their Cluster Management Tools, and open source project, or lots of companies paying internal developers for customizations for Compiere, Project Open, SugarCRM or a ton of other Open Source projects.
"That's just the way of it."
Yeah, don't let the fact the world shows you otherwise to undermine your clever and solidly built argument.
"Open-source isn't exactly what you'd call the fastest or most direct method to produce a product."
What the hell has to be the distribution license with the production methods?
"Nothing replaces real dedicated, paid resources."
Then why don't you have "real dedicated, paid resources" developing and/or hacking open source solutions for your company? You don't really think Red Hat's employees stay in the company for free, do you?
"Then imagine some people start working for you. You want to force them to use a Linux desktop?"
Of course yes. It's my company, isn't it?
"People are most productive with whatever they like to use"
Yes, true... for a while. Probably every and all bulldozer operators started firstly driving their cars. Why don't we give them cars instead of bulldozers? after all, people are most productive with whatever they like to use, don't they?
Jokes apart, since it's a company it's all about money and you will have to make your choices. It's just about not forgetting the hidden costs on the equation. Let's imagine you indeed start hiring people: well, probably the first one you'll contract won't be a senior systems administrator but someone nearer to the reveneue line and probably you'll be his or her systems administrator. Then you should consider the added time it will take *you* to administer his computer on an unfriendly (to you) operative system and the opportunity cost involved (a boss taking care of another's computer is not a boss making "bossian" things) versus the added benefit of your hired because he uses a computer he's more comfortable with the first few days. Or, providing there's enough choice you could just go from the beginning with somebody who already knows Linux as a user level or is willing to fastly learn.
And then you grow even more: you -again, will have to consider the average boxes per sysadmin on the Windows world vs the same numbers on the Linux world vs average wages for each other on your locality. And then, you'll have to consider ROI for niche solutions on one platform or the other; and then the opportunity costs when faced against one of those things that are undoable or costs tons on license cash on Windows while are doable for nuts on cheap hardware provided you hire the proper unix/linux guru. And then...
Overall I'd say you'll find easier to be more or less "average" going with Windows (after all, the average company *uses* Windows) but there will be exciting and truly valuable opportunities in using Linux, provided you are clever enough to see and go for them.
"And after you modify your source version of the code, congratulations, upgrading to the next version is at best case going to require careful thought and planning, and at worst case a lot of time and effort on your part."
And even then you end up on a wining position.
In the first case you would have a relaxed upgrade path (hey, we all know all privative-licensed programs are always a breeze to upgrade, don't we?) *but* the software *still* will have the bug: remember that the case was about a privative-licensed software whose owner didn't want to provide a bugfix vs. an open-licensed software whose primary provider didn't want to provide a bugfix.
In the second case you still would have two valuable options:
1) Provide the bugfix to the upstream vendor *even* if it didn't want to produce it itself. The upstream vendor might want to patch the main line after the hard work is done (after all, it will probably benefit their other clients).
2) Assess a cost-benefit analysis: is the bugfix valuable enough for all the hassle of patching new versions? If it is valuable enough, you still win versus the option of no bugfix at all, and if it isn't worth the effort you still are no *worse* than in the very begining.
So, again, even using arguments from closed-source minions open source arises as a win-win proposition.
"The danger of customizing your open source product is the same danger that companies face modifying products like SAP"
This is quite off-topic, but HA! is SAP what you are talking about? Is there any company that uses SAP as-is? Heck, is even SAP meant to be working out-of-the-box in any case? Of course upgrading will be expensive but in the case of SAP it is out from a well thougth strategy where SAP is more focused on SAP itself and its consultants, knowing they work by their side about getting enough gullible CxOs to make their day. SAP is *all* about being expensive and CxO marketable.
"Here you have greed working against you. Since it's OSS, you'd have to release the bugfix into the world"
No, you don't.
On one hand, not all OSS licenses are born equal (as privative licenses are not born equal, either). It's obvious that what it's true regarding BSD doesn't need to regarding GPL so please, refrain a bit about talking absolutes about OSS: to many of them won't hold water.
On the other hand, even talking about copyleft OSS, like GPL, it's untrue that you have to release the bugfix to the world. As long as you don't redistribute binaries you don't have to release the bugfix either. Please read the GPL and see it by yourself.
"how businesses usually think. Share their stuff with others? Give other companies an advantage that WE paid for?"
That clearly shows there's a bussiness case for Red Hat to go for it.
While most CxOs might say that they won't give other companies an advantage they paid for, the hard fact is that they already do it! Or do they really think that developing the bazillion of code lines from, say, their Oracle solution do in fact cost the meagre 10.000 they paid for it? Or are they so naive not to know that by paying Oracle those 10.000 with such draconian CLUF they are in fact making the case for their direct bussiness adversaries to be able to get Oracle by just 10.000 too?
It's everything about perception and as such, opened to change by means of marketing practices, like a CEO telling other CEOs that "there are other ways to make bussiness, and I'll show you".
"If the project is budgeted for 1000 hours and the goal is to build a blog that works just like Slashdot, what if he books 990 hours surfing for pr0n, downloads Slashcode and strolls in the door with an invoice?"
Yeah, so what?
The company wanted to pay 1000xhour rate in order to have a Slashdot-like blog and they ended with... what? A Slashdot-like blog that costed 1000xhour rate, so where's the problem? This case is not an academic one where "cheat is forbidden" but a results-oriented scenario. If someone can make 1000 for something that costed him 100, the better for him.
No: I think it's a clear incompetence case. The wanted to say "non-copyleft code allowed" (maybe because they didn't want to close the door for that software to be licensed to third-party clients) and ended up saying "non OSS allowed" out of ignorance of the differences between GPL-like and BSD-like licenses.
" A number of times I've pointed out to consulting firms I've worked for/with that they weren't compliant with GPL because they weren't putting their code improvements back into the wild"
And so you looked like an idiot whenever you faced someone that took the time to read the damn license.
"A frequent example that comes immediately to mind from a couple years back is Asterisk solution providers."
I worked with some of them on the past and I never had any problem to get a hand on their GPLed software upon request, so I can say that's not the general case.
"As a post-script, I think that developers have a certain amount of professional responsibility to point out the licensing model for any code they seek to build into their solution."
Whenever someone takes code from anyone else is their legal responsibility to have a look at the acompanying license. If he's a proffesional developer I'd say they have an ethical incumbement too.
"But if I'm already the Goliath that everyone is chasing, it is in my interest to keep barriers to entry into my market as high as possible"
That's true, and that' why nobody really expects Microsoft going truly on the open source wagon on the foreseeble future. Even if in a new niche it would cost them a hugh ammount of money the "do-it-yourself" way they surely would try as a means to monopolize it (after all they have hugh ammounts of money to spend anyway). Only when forced they'd do otherwise. On the other hand, Microsoft's main competency is not about making software, it's not even about selling software, it's about granting IP licenses: everything that goes against the mindshare that granting IP licenses is "the" proper valid way to make bussiness is clearly against their very bottomline, so no wonder they try to fight against that kind of idea with all their forces.
But look at your own company and you'll see that most of the software you use is now either commodity (e-mail readers or web browser, office suites, sysadmin tools and automation...) or generic/not directly related with your very company ("skeletal" ERP/CRM functionality, bussiness flow, legal/accountant...). Is *that* kind of software that any company can gain advantage from sharing. As I already told in another comment, companies already know that: after all they are more the ready to pay money to Microsoft, BEA, Oracle, SAP... for that kind of software; they are *already* sharing costs among them while it would be both more advantageable and probably cheaper to find a new way to make bussines where they, the "consumers" where in direct control of the development process instead of being reactive to the software companies actions.
Oracle or SAP are not in bussiness for the sake of you but to take out the most of you. That's true for any bussiness, Red Hat included. What Red Hat's CEO tries is to tell companies that there are ways of doing bussiness on the software world that can be better aligned with the client's needs than the "traditional" license-driven one and that Red Hat is wanting to pursue them. This is unknown to many CxO out there and makes perfect sense for a CEO of a company like Red Hat to "blow the whistle" about it.
"Now I am VERY curious to hear one of you pie-in-the-sky fossies explain how exactly we wouldn't get COMPLETELY and TOTALLY SCREWED by open-sourcing our software package?"
Of course you WOULD! You are missed the boat and you are talking about a very different bussiness case. You are already on the PRIVATIVE SOFTWARE boat: you (your company) put the money on the table *first* and now looks for a way to recover the inversion.
"Furthermore, our competitors also offer packages of their own to perform similiar functions, but (at least for now), our in-house developed package is considered the "best-of-breed" and is well-liked by our users. "
Now, from your own example, please think about the fact that your company is not the only one in the world. Now, think about all these "sencond rank" companies and how they would have an easier day to beat your company by opening their software, at least among them, as the cheaper way to make their software better and use it to help them to take you out of the market (specially in a case like yours were the software is not the main "money atractor" but "just" candy on top of the cake). Maybe those companies see that one of your bussiness advantage is your software (but the real money is in the selling of those hard-ware of yours). The fact that it doesn't make bussiness sense for YOU doesn't mean it won't for others.
"HTF does your "all software should be free" idiom have ANY application to us whatsoever?"
Don't you see the case that your own very software would have been cheaper 'a priori' and that specially in a growing market (where opening it is at least as important as getting a foot over your competition) your company might have been able to make more money even at the expense of "gifting" some of it to your direct competition? Maybe if your company wouldn't have to give all that money *in advance*, now it wouldn't have the need to recover it and maybe that money would have been better used improving your company directly where their major incoming factor is instead of diversing at a risk on the software manufacturing camp (after all you only NOW know that your software is a bussiness advantage; when the development started it was nothing but a corporate risk).
"That's physically impossible to be a positive financial move."
Tell that to Red Hat. Red Hat is your physical imposibility since they make positive financial move out of their own software initiatives.
"One company pays for initial development. That money is gone and spent. They're not getting it back, ever"
Unless, of course they *do* get it back as Red Hat does. That's the "coaxing" Red Hat's CEO states. There are vast amounts of GPL-ed code ten years ago were unthinkable. GPL is (somehow) viral, yes, and over certain "breaking" point it certainly makes very real financial sense move on board instead of going with your own internal development of buying a closed-source solution.
If Red Hat manages to properly be a real "strategic partner" for some big companies (after all, "strategic partnership" is already a warm buzzword -it's only it's false: all those "parterns" are not partners at all but "clients and providers") it would make it happen: instead of just pay me for my consulting work, "pay" us all by means of time-share of that C++ hacker you already have in your payroll. Or just don't pay me for "hacking" your internal "whatever" but allow me to "productivize" it and add it up to my services portfolio. Or... (well, no more ideas to Red Hat's CEO without a contract).
"No matter how much community help is provided, that company that gives away code ALWAYS spends more than competitors who get their hands on the code"
Maybe Sun, or IBM, or Red Hat think otherwise. Or do you think that they don't use their own products to their own benefit?
"Software is built in companies to make money."
Are you sure? I'd say most of them is developed to *save* money, not to directly make it. Maybe some of them would understand that they can save even more money by sharing common parts so instead of reinventing the whole wheel it's enough with a single radius and take the rest of the wheel from anyone else. Even now is a question of culture, since you hardly see any companies (even in the same niche) just partnering to share some "developer time" while they would gladly buy the same software from a third party vendor -on the vendor most favourable terms instead of theirs, that is. What's the real difference from, say, ten fortune 500 companies giving SAP two million dollars each or making a joint venture among them to build a customized ERP for 20 millions? But then while the former is "common practice" the latter, while obviously more advantageous for them seems to be an impossible dream.
"It's always a lose-lose situation for a company to open source their software."
Yes of course. And having a complex functional unix-like operative system free of license fees is a physical impossibility. Yeah, we all know that.
"show me a linux distro that compets on price with security updates for even 5 years, let alone 12."
The day this becomes an "apples-to-apples" comparation, I'll show you.
"Somehow, Spanish has managed to solve the problem."
I claim bullshit on this. That was Juan Ramón Jimenez's dream (1956 literature Nobel Prize), but we are not quite there.
While it's true you know for certain how to pronounce a word as soon as you see it written down, the reverse it's not: you can't always know how to write a word you heared (as it was the point from the previous poster): 'baca' and 'vaca' sound exactly the same as would do 'hueso' and 'ueso' (if the latter existed, which is not). You would write (relevant word remarked) "*tu* madre" but "*tú* eres", again same sound, different graphs.
Even then, there is an exception on the "phonetic rule": letter "x" changed its sound somewhere in between XVI and XVII centuries (I don't know when), so you have some "oldish" proper nouns written down with "x" (like México, Texas or Xavier) that are to be pronounced as "Méjico", "Tejas" or "Javier" instead (well, I don't know but these three exceptions).
"I'd really like to know how that came about."
Not too difficult: Spanish is a latin-based language, and the cute symbols you use to write down ideas are not called "latin alphabet" for nothing.
The phonetic problems come from the fact that there are "too many letters". Letter "b" and "v" became the same sound about the XVII century; letter "h" lost its sound (it's mute) about a century before. There are letters that have different sounds depending on context ("c" on "casa" sounds like "k"ilo, while on "cerilla" it sounds like in "c"entennial). To make things worse, two letters may overlap sounds ("z" always sounds like "c" on "cerilla", while "c" may sound different. Again, "j" has always a hard sound, non-existant in English -more or less like "aghhh" -listen to a mexican saying his country's name; remember that "x" became "j" afterwards), while "g" may sound like previous "j" i.e.: "gemido" or softer like in "guapo", more or less like "gas"). Then you have so-called diacritic rules about accents ('tu' is possesive while "tú" is a pronoun, but they both just sound the same).
And then, some syntactic sugar regarding irregular verbs (while past participle from "comer" -"to eat" is regular and comes as "comido", "poner" -"to put" is irregular and its participle forms as "puesto" instead of "ponido").
Of course every English-spoken people would find verbal forms quite cumbersome (six diferent persons -three singular and three plural, five modes and about four tenses per each mode, with simple and complex ways all of them... oh! and three regular conjugations depending on the verb ending on -ar, -er or -ir, and a plethora of irregular and defective verbs); not as bad as German, but quite there.
Yes, I'm Spanish.
"Yes, and if they'd been busy, on vacation, or sick, you wouldn't have got a minute of help. That's not an acceptable mitigation strategy for the risks associated with using software for mission critical applications."
And what about having professional senior technicians in charge of such "mission critical applications" and then they themselves can boil the egg, so to say? From my experience it isn't an acceptable mitigaion strategy either, and the hell if I can imagine why (well, I *do* imagine why, but it certainly is not related at all with the actual ability to minimize production losses and maximize operation reliability).
"But a pre-paid fast response service for Sev 1 problems *is* an acceptable mitigation strategy"
Even when they know beyond all doubt that their "fast response service" is an automated e-mail or voice machine response and that you will have to fight with first tier "technicians" till monday morning (if you are lucky) anyway. The hell if I can imagine why (well, I *do* imagine why, but it certainly is not related at all with the actual ability to minimize production losses and maximize operation standards).
"Or would you call someone dying by driving into a bridge pillar at 120mph an engineering problem?"
Of course not. Because it's out of the problem realm disallow pillar crashing, not because "human stupidity is not an engineering problem".
When something is well within the problem realm (passwords are to allow for safe authentication), policies *are* part of the engineering problem, and bad policies so much so. Regarding the safe auth problem, not thinking about some nuts stablishing a nuts policy that ends up with passwords on post-its *is* an engineering problem. Engineering is not just about "hard stuff that melts and mechanizes"; it's about people and safe procedures too.
"In all three cases, people went outside the well known, well documented processes because "they knew better""
No. In all three cases people went outside the well known, well documented processes because *they could* when due to problem nature and environment was well within engineering specs that they shouldn't be able to do what they did. Even the Hyatt case would have been avoided with such a simple ingeneering practice as "the engineer should have been there" since, by definition, any singular building is a prototype.
"Edward Tufte has analyzed the Challenger and Columbia disasters and concluded that they largely occurred because critical information became obfuscated as it moved up the decision tree."
Every time you need to reduce a 300 pages technical review into ten powerpoint slides in order to "move it up the decision tree" you know some critical information will become obfuscated on the way.
"The following three I know were the result of human involvement and decisions, not engineering mistakes and are documented:"
Are you sure those are not engineering mistakes? If you ask a user to remember half a dozen, ten characters, unpronunciable password, they *will* stick them to a post-it on the monitor, and that's an engineering problem. If you burden field technicians with unproper unergonomic "safe" mechanisms you know they *will* find workarounds, and that's an engineering problem. If you leave out the project management cycle on-field implantation, there will appear on-field problems that *will* be managed out the project management cycle and that's an engineering problem too.
If you put the self-destruction device button just alongside the lights power switch, it won't be user's fault when he presses it by mistake: it's engineering at fault. If you design a safety system that *mustn't* be overriden in any circumnstance but you design it so it *can* be overriden, it's engineering at fault.