Date: Sun, 07 Oct 2007 14:27:06 -0500 From: leenix [email protected] Subject: FOSS Solutions 1. I agree with the philosophy behind FOSS 2. There are a plethora of plug-ins developed to help extend our infrastructure for our current (and future) needs 3. If we find that a piece of software we downloaded (or purchased) is broken, or doesn't do what we need it to do, we have the source code and (hopefully) the resources to fix/change it. 4. Not only are there several (competing) options for paid support, there are a ton of free message boards, mailing lists and IRC channels to get assistance from, making our virtual knowledge bank HUGE 5. Total cost of ownership is going to be a fraction of that of closed source products. 6. When needed, we can find closed source software to do what we need when we can't find a FOSS solution
7. Vendor lock in - Ensures greater access to the developers themselves as support contacts, if the need arises. Ensures that meaningful third party support will be available for mainstream products if abandoned or obsolesced by their original authors.
8: Tendencies towards standards compliance and openness in the FOSS community make it far more likely that related projects will be able to effectively and efficiently interact.
9: Simplifies license compliance - Closed-source shops have the added overhead of needing to account for licenses to proprietary products, the hassle and man-hours involved in paying license fees, etc. Applications for the operating systems used in these shops, be they Mac or Windows shops, are far more likely to be proprietary shareware or purchased software, adding to the transaction costs for adding new software.
10: (More a plus for *NIX than FOSS) Having more mature command line interfaces than are available in pre-Win2k7 builds of Windows Server substantially cut the amount of time needed to populate changes across multiple servers. Even after the adoption of the yet-to-be-market-tested server operating systems that ship with PowerShell, the size and maturity of the body of available code and documentation for shells used in UNIX and Linux administration will continue to vastly outweigh that available for Windows for some time. Note that O'Reilly books on the relatively young Bash shell have been through several revisions already.
That might help, Sean Crago
On 10/8/07, [email protected] [email protected] wrote: These two are related in the *NIX mentality that incubated the development of the BSDs and Linux:
8: Tendencies towards standards compliance and openness in the FOSS
community make it far more likely that related projects will be able to effectively and efficiently interact.
10: (More a plus for *NIX than FOSS) Having more mature command line
interfaces than are available in pre-Win2k7 builds of Windows Server substantially cut the amount of time needed to populate changes across multiple servers.
The Windows people have completely adopted the "GUI=User Friendly, CLI=Unfriendly" meme to the point where they don't recognize the power of the CLI and text files, which are at the heart of the Tao of Unix. I routinely compose "recipes" of Bourne shell commands that expedite configuring a *nix server in a certain way, and share them with my co-workers. With those recipes, they can quickly apply a fix to establish a consistent state on the target machine. Explaining how to do the same thing in a GUI can take several pages.
Given a system that can be configured entirely with text files and command lines, we can build "friendly" GUIs for the newbs, but it's not always so easy to go the other direction.
Just for an example, whenever I boot my laptop into Windows, the sound settings are not what I left them at when Windows last shut down. Every freaking time I have to open up the Control Panel Sounds and Audio applet, click on Advanced in the Device volume section, and re-adjust the sliders to what I want. This is going backwards. My very first sound card when I ran DOS had a command I could include in AUTOEXEC.BAT to set the card up the way I wanted, and I could also put commands in the batch files that launched various apps to reconfigure the thing to my preferences for that app.
The entire point of a computer is to automate repetitive tasks. "Point and grunt" is hardly as sophisticated as actual words.
First of all let me say thank you to everyone who shared ideas. it has been very helpful.
OK. Let me play Devil's Advocate for a minute. These are a couple of reasons I have actually heard for why it is better to use proprietary software:
1. I realize the source is available, but I want my developers developing OUR software not OS (Fill in your other FOSS software here) software.
2. If I buy a piece of software that is closed-source, the company selling it to me has to support it. If something is wrong with it, they'll fix it, because that's where they make their money.
3. If I buy [closed-source company]'s software I know it will work with their Database, Mail server, Office Suite, etc. because it is made by the same company. I'm not sure that we'll be able to get [open-source company]'s software to talk to our existing infrastructure, our to our partner's existing infrastructure.
Now I know what I think of these problems, but I am fairly new (less than 3 years of using *NIX) and I want to see what the community thinks. Thanks again for all the replies.
Cheers
On Mon, 2007-10-08 at 22:43 -0500, Monty J. Harder wrote:
On 10/8/07, [email protected] [email protected] wrote:
These two are related in the *NIX mentality that incubated the development of the BSDs and Linux:
8: Tendencies towards standards compliance and openness in the FOSS community make it far more likely that related projects will be able to effectively and efficiently interact. 10: (More a plus for *NIX than FOSS) Having more mature command line interfaces than are available in pre-Win2k7 builds of Windows Server substantially cut the amount of time needed to populate changes across multiple servers.The Windows people have completely adopted the "GUI=User Friendly, CLI=Unfriendly" meme to the point where they don't recognize the power of the CLI and text files, which are at the heart of the Tao of Unix. I routinely compose "recipes" of Bourne shell commands that expedite configuring a *nix server in a certain way, and share them with my co-workers. With those recipes, they can quickly apply a fix to establish a consistent state on the target machine. Explaining how to do the same thing in a GUI can take several pages.
Given a system that can be configured entirely with text files and command lines, we can build "friendly" GUIs for the newbs, but it's not always so easy to go the other direction.
Just for an example, whenever I boot my laptop into Windows, the sound settings are not what I left them at when Windows last shut down. Every freaking time I have to open up the Control Panel Sounds and Audio applet, click on Advanced in the Device volume section, and re-adjust the sliders to what I want. This is going backwards. My very first sound card when I ran DOS had a command I could include in AUTOEXEC.BAT to set the card up the way I wanted, and I could also put commands in the batch files that launched various apps to reconfigure the thing to my preferences for that app.
The entire point of a computer is to automate repetitive tasks. "Point and grunt" is hardly as sophisticated as actual words.
Kclug mailing list [email protected] http://kclug.org/mailman/listinfo/kclug
On 10/8/07, leenix [email protected] wrote:
First of all let me say thank you to everyone who shared ideas. it has been very helpful.
OK. Let me play Devil's Advocate for a minute.
1. I realize the source is available, but I want my developers
developing OUR software not OS (Fill in your other FOSS software here) software.
The value to you of having the source available is not just that your developers would rewrite the FOSS software itself. That can be done by others, although you'd be surprised how little of your devs' time it would take to patch FOSS projects, and be good citizens who submit them upstream. The time they don't spend trying to reverse-engineer some obscure bug in someone else's code will probably more than make up for it.
The big win is they'd understand exactly what the software is doing so that they can interoperate with it. Documentation tells you how the code is SUPPOSED to work, but the code tells you how it really works.
2. If I buy a piece of software that is closed-source, the company
selling it to me has to support it. If something is wrong with it, they'll fix it, because that's where they make their money.
No, they don't have to support the software. They can sell support contracts separately. Call a closed-source software company without that contract and see how much support you really get. And they don't make their money from fixing the software, they get it from SELLING the software. They already have your money. So unless they're going to CHARGE you for the new version that fixes the bug, they don't make money from the transaction. And if that's the case, you might be able to pay one of your developers to fix it NOW instead of waiting for them to even admit that the bug exists, much less fix it.
3. If I buy [closed-source company]'s software I know it will work with
their Database, Mail server, Office Suite, etc. because it is made by the same company. I'm not sure that we'll be able to get [open-source company]'s software to talk to our existing infrastructure, our to our partner's existing infrastructure.
Do they guarantee that it will work with that other stuff? In writing and everything? When you upgrade $foo, do you also have to upgrade $bar, $baz, etc. to maintain that interoperability? Even if you do get seamless integration between their software packages, do they provide any interfaces to let third-party apps work with them?
The thinking in #3 is an Unconditional Surrender to Lock In. It cedes all authority to this closed-source company to define your operations. Instead of adapting software to your business, you'll mold your entire organization to fit the tools they provide. "When the only tool you have is a hammer, everything looks like a nail." You'll turn perfectly good wood screws into nails. This is the first step in a downward epistemological slide. You'll declare that 1900 was a leap year, because Excel says it is. You'll insist that you got that black eye by falling down and hitting a doorknob; no, you're not a victim of domestic abuse; he's really not a bad guy...
On Monday 08 October 2007, leenix wrote:
- I realize the source is available, but I want my developers
developing OUR software not OS (Fill in your other FOSS software here) software.
The idea is that you have the OPTION to develop it if nobody else will. And quite frankly: who is going to add that occasional obscure feature that only you need?
- If I buy a piece of software that is closed-source, the company
selling it to me has to support it. If something is wrong with it, they'll fix it, because that's where they make their money.
Quite the contrary. They make their money selling the software, NOT supporting it. The people who make money providing support is the Open Source developers.
- If I buy [closed-source company]'s software I know it will work with
their Database, Mail server, Office Suite, etc. because it is made by the same company. I'm not sure that we'll be able to get [open-source company]'s software to talk to our existing infrastructure, our to our partner's existing infrastructure.
That's what standards are for. Get rid of non-compliant stuff every chance you get, and then you're not locked down to that one Database, Mail server, etc. Obviously nobody is 100% SQL compliant, but many Free offerings come close. Admittedly, most IMAP servers suck at some level, but I would argue that the non-compliant software sucks even more.
On Mon, 2007-10-08 at 23:09 -0500, leenix wrote:
- If I buy a piece of software that is closed-source, the company
selling it to me has to support it. If something is wrong with it, they'll fix it, because that's where they make their money.
I picked this up off /. just in time for this discussion:
http://arstechnica.com/news.ars/post/20071008-when-google-acquisitions-go-wr...
No need to answer question #2, just print off the article and hand it to the prospect.
Some companies make money off support, others do not. Selling support contracts is big business; it provides a steady revenue stream (since the revenue can be recognized over the life of the contract, unlike a software sale, which can only be recognized when the sale is made) that can complement the one-time payment for software. But a contract is only as good as the vendor offering it. Once the vendor no longer exists, the contract is useful only as confetti for someone's retirement party.
Even if the company stays in business, having a contract does not mean you will get support, as customers of Urchin found out in the article above. And if the company is a monolith like Google, who's going to have the resources to take them to court over it?
On Wed, 2007-10-10 at 11:03 -0500, Matthew Copple wrote:
On Mon, 2007-10-08 at 23:09 -0500, leenix wrote:
- If I buy a piece of software that is closed-source, the company
selling it to me has to support it. If something is wrong with it, they'll fix it, because that's where they make their money.
I picked this up off /. just in time for this discussion:
http://arstechnica.com/news.ars/post/20071008-when-google-acquisitions-go-wr...
In an ideal world, a discontinued product like this would open it's code with a FOSS license like the GPL. Unfortunately, even though google is a very FOSS friendly company, they don't want to have development continued on a competing product. It seems this is true even/especially if it's a product they now own. I've heard of several good products that ended this way.
On Wednesday 10 October 2007, Jestin Stoffel wrote:
google is a very FOSS friendly company,
Maybe in financial and service contributions, but what Google product has ever been itself open source? GTalk would be the most obvious one they should have released the code to...
On 10/10/07, Luke -Jr [email protected] wrote:
GTalk would be the most obvious one they should have released the code to...
better phrased in present tense -- they still can --
"GTalk is the most obvious one they should release the code to..."
Your editor at large,
DN
On Wed, 2007-10-10 at 16:24 -0500, Luke -Jr wrote:
On Wednesday 10 October 2007, Jestin Stoffel wrote:
google is a very FOSS friendly company,
Maybe in financial and service contributions, but what Google product has ever been itself open source?
None that I can think of, but I got to give them props for the Summer of Code. I suppose that falls more into the financial contribution category, but it's more than most companies their size do.
On 10/10/07, Jestin Stoffel [email protected] wrote:
On Wed, 2007-10-10 at 16:24 -0500, Luke -Jr wrote:
On Wednesday 10 October 2007, Jestin Stoffel wrote:
google is a very FOSS friendly company,
Maybe in financial and service contributions, but what Google product has ever been itself open source?
None that I can think of, but I got to give them props for the Summer of Code. I suppose that falls more into the financial contribution category, but it's more than most companies their size do.
This article might be interesting: http://www.theregister.co.uk/2007/08/21/microsoft_google_osi/
It's always nice to see that some people still believe in Google's myths, though.
On 10/8/07, Monty J. Harder [email protected] wrote:
[...] I routinely compose "recipes" of Bourne shell commands that expedite configuring a *nix server in a certain way, and share them with my co-workers. With those recipes, they can quickly apply a fix to establish a consistent state on the target machine. Explaining how to do the same thing in a GUI can take several pages.
Ah yes. But walking an illiterate through a GUI over the telephone is easier than walking the same illiterate through a CLI. There were people I remember talking with when I worked at GW2K, the letters of the alphabet were not their friends.
On Tue, October 9, 2007 16:43, David Nicol wrote:
Ah yes. But walking an illiterate through a GUI over the telephone is easier than walking the same illiterate through a CLI. There were people I remember talking with when I worked at GW2K, the letters of the alphabet were not their friends.
Ah yes, phone support.
"Ok, now hit 'Enter'."
"Ok" Clack. Clackity clackity clackity clackityclack
"Wait, what did you just do?"
A co-worker and I tried to do phone support for a woman in Cincinnati once for over a week. Finally had a techie go to her desk and do things for us like send a screen shot. Found out everything she said she was doing was a lie. Not even close!
Jonathan Hutchins [email protected] wrote: On Tue, October 9, 2007 16:43, David Nicol wrote:
Ah yes. But walking an illiterate through a GUI over the telephone is easier than walking the same illiterate through a CLI. There were people I remember talking with when I worked at GW2K, the letters of the alphabet were not their friends.
Ah yes, phone support.
"Ok, now hit 'Enter'."
"Ok" Clack. Clackity clackity clackity clackityclack
"Wait, what did you just do?"
Ah yes, phone support.
"Ok, now hit 'Enter'."
"Ok" Clack. Clackity clackity clackity clackityclack
"Wait, what did you just do?"
I had a guy that the technician had set his password to blank. Then about three months later he called support and said he couldn't remember his password. (Apparently he had never shutdown his computer and there was a power outage that shut it down for him.) After trying a number of standard passwords I told him to enter a blank password. His response was "Is that case sensitive?" Uhhhhh??? Yes? No? Just press the "enter" key without entering anything. It logged him in! Scary part was, he was an instructor at a college...
On 10/9/07, David Nicol [email protected] wrote:
On 10/8/07, Monty J. Harder [email protected] wrote: Ah yes. But walking an illiterate through a GUI over the telephone is easier than walking the same illiterate through a CLI. There were people I remember talking with when I worked at GW2K, the letters of the alphabet were not their friends.
So you're saying that Windows is designed for illiterates? I agree. But that's the problem with the GUI. It seduces people with the notion that clueless newbies can immediately do easy things, but it doesn't help more experienced users become masters, because true mastery inevitably requires combining things in ways the creators of the components didn't anticipate. And if neither the author of $foo nor the author of $bar knew you'd combine them this way, then there's no way they'd have built a GUI to let you do it. If you're lucky, someone else might do the job, but that only works if both pieces provide an API to facilitate it.
In the Tao of Unix, that API is the command line and the text file/stream.
Again, I'm not arguing for eliminating the GUI, simply subordinating it to the CLI. Give me the CLI and human-editable-text config and data files first, THEN build the GUI for the illiterates.
-
cragos＠gmail.com -
David Nicol -
Eric Johnson -
James Sissel -
Jestin Stoffel -
Jonathan Hutchins -
leenix -
Luke -Jr -
Matthew Copple -
Monty J. Harder -
Phil Thayer