Actually,.NET deals with components in multiple languages on the same system. It has classes that deal with SOAP, but they are just a library.
CORBA is a sweet, sweet solution. Most people who don't like it haven't actually used it. I was able to teach C++ students how to code CORBA apps in less than an hour. It's really pretty sweet. You only have to mess with the complicated stuff when you do complicated things. Otherwise, it's totally transparent.
The fact that it's a marketing bullet point means nothing. When I talk to people actively using it and it making sense and working for them, I'll believe it.
What you miss is that you are only obligated to follow the GPL if you redistribute code outside of your organization. Period. If you don't redistribute code outside of your organization, you don't have to pay ANY attention to the GPL at all.
With other software licenses, you have to accept them to _use_ the software. With the GPL, you can use it without accepting the license agreement. The GPL _broadens_ your rights, it doesn't restrict them.
This is what proprietary companies don't want you to know, because then it shows that _proprietary_ software is what you need legal departments for, while open-source only requires one for redistribution outside of your organization.
Actually, I've found that fixing bugs in large projects is about the same whether or not you are familiar with the project, provided that the author was no smoking crack at the time he wrote it.
For example, I managed to code, test, and patch a "fix" for PostgreSQL this weekend in under 2 hours, having never seen the code before.
The "fix" wasn't a bug, per se, i't just that the output of pg_dump wasn't optimal in my usage for dumping the schema for CVS revision control. I added two flags, -m -M, which molded the output to my liking.
If you haven't seen your code in two months, you and an outsider have about the same chance at finding and detecting bugs/misfeatures.
" Well, Yes and No. The problem is that there may be no logical way that the pointer may be NULL today. But tomorrow, a new coder will add something that modifies the preconditions and suddenly that pointer can indeed be NULL. "
Unless there's documentation saying that it shouldn't be null. If there isn't, it's a bug in the present code. If there is, it's a bug in the future code.
Documentation really is a part of the code, even though many people treat it as a side-issue.
The only barrier for installing the applications is a good program like Wise or InstallShield. Really the dependency mechanisms in Linux is excellent, it's just that noone builds self-installing packages.
Most patches (especially the kernel patches) are only needed if you have servers with local, untrusted users.
The "not needing patching" comes from Postfix - the external interface - which really doesn't. Wietse Venema is an absolute genius when it comes to security and software design, and I'm not aware of any exploitable security holes in Postfix even before it was officially released.
None of the security exploits you mention are Internet-accessible. In fact, the SMB _protocol_ (even with a perfect implementation) has enough security holes as to not be trusted on an external network.
Anyway, I understand the sentiment, but really, it's not as big of a deal as you make it out to be (granted, the OSS community often exaggerates the impact of MS flaws initially, but we usually come to reason fairly soon).
There _are_, they just aren't Outlook-compatible. PHPGroupware is what my company uses - it goes far beyond what Exchange/Outlook provides. However, it doesn't use Outlook itself, and thus many corporate types won't touch it. Yes, that's stupid, but that's where we live.
Yes, but my version is the condensed version of "You could keep them to yourselves, but then if you get out of sync with the mainline tree you have then degenerated into a full-fledged software development project which will do nothing but increase your costs through the roof, so it's best just to contribute the changes back to the community."
I think my original version is better for explaining to PHBs.
The amazing thing is that people will complain about "OpenOffice incompatibility" when OO won't open up their Word97 documents exactly right, but won't bat an eye to upgrade to Office 2000, even if they have to retouch every document they have.
WHAT IS WRONG WITH THE WORLD THESE DAYS???????????????
If you look at what it takes to maintain most systems out there - it's usually a lot more than one developer of YOURS, even if you have a support contract from them.
In addition, if you know of a company where I can work and get $80,000 a year, let me know. I'm working for half of that right now.
In addition, many of the Oracle packages take many, many months just to install. The SUPER_QUICK_NOONE_IS_ACTUALLY_THIS_FAST Oracle install time is 3 months. This is if you have 0 customizations and no legacy data.
Another problem is that many features don't belong in the application, they belong in another one. But in order to sell more widgets, the put in a sucky version of that app and use it as a marketing point, when really it's a reason why you should avoid software houses that have no focus.
Yes, it's more complex, but, for most cases, needlessly so. Oracle Applications comes suited for multinational, multi-industry companies. Most people who _use_ it don't actually fit that, and would be better off developing something customized to their needs.
As for the year, in my experience it takes 9 months for a small company (~300 employees) to do a full install of Oracle. Larger companies can take longer.
I agree with your points. However, one point you mentioned "But there are a lot of complicated systems that 2 people could never pull off without so much time that the technology moves before you get the app out the door." My company did an Oracle Applications install. We used 11.0.3. when it first came out. By the time we had it running they had _finished_ 11i, and had committed their development resources to building 12 and bugfixing 11i. They refused to offer us any decent level of support on 11.0.3. We either had to upgrade to 11i (which basically meant going through the same hell that it took to get here - no company at that time had successfully done an upgrade - some had managed it with a full reinstall/reimplementation) or do with broken software. I left around that time to move closer to home, so I don't know what the decision was.
"That sounds like a business plan. If it's so easy to do, why not hire two developers yourself, build the software and then sell it at half price of the competition to ten companies."
You miss the point. The point is that each company is different. Packaged software will NOT do EXACTLY what the user wants, simply because it was not developed with that user in mind.
However, the method you state does work magnificently with Niche products. It only works with Niche products because, as mentioned previously, it is a _custom_ job.
I've done work on an Oracle Applications project. The problem is that in order to make it have "broad appeal" they had to make it so overwhelming and overcustomizable as to have every option anyone might ever want in any kind of business. Yuck! It takes _longer_ to configure the existing functionality in Oracle Applications than it does to build it in most other ones.
Now, don't get me wrong. There are some companies who NEED Oracle Applications. Like multinational firms dealing in multiple currencies and multiple languages who have to have a very rigid security structure for the 100,000 employees they have in the 10 different industries they are involved in.
However, for companies of less than about 5,000 people (i.e. - most of the people buying Oracle Applications), it is much, much cheaper to build the functionality yourself - you can make it work EXACTLY like you want, and not require $80,000 worth of server equipment to run on.
To understand the problem - a company I worked for had a small accounting system, to which we had built some customized applications on top of. These applications were text-interface, but worked very well. The database ran on an old Sparc that our developers refused to use because it was too old.
We switched to Oracle Applications to modernize our system (whatever that means). The same amount of functionality, but required a Sun E450 and 2 Sun E250s. In addition, the GUI made it take 4 times as long to enter an order - so we had to add extra customer service reps! Anyway, my point is that the reason that it now takes a network of enterprise sun machines to do what a sub-par workstation used to do is that there are so many tables in the Oracle system that deal with OTHER PEOPLES business. Not yours, someone else's. However, they slow you down, introduce bugs for you, and make it difficult for you to customize. If you had written it yourself, then you have two advantages:
a) You don't have to fit yourself into their model
b) You don't have to have the overhead of a multinational, multilingual, multiindustrial corporation.
That overhead is not just in computer cycles. It's also in manpower - you have to manage your company as if it was this huge powerhouse. Thus, management of the system is dreadful.
In addition, the many features interact in wierd ways to produce wierd bugs. If you happen to be one of the few people who use that feature, don't count on them to help you out. They've got larger companies to keep happy...
The problem comes in the area where the person listening doesn't have any experience. If the PHB says, "is it secure?" do you say "yes", or do you explain to him how security is not any one thing, show him the different types of security mechanisms available, talk to him about the different security/convenience tradeoffs, and the like?
I guarantee that if your response is anything but "yes" that the rest of your speech will be thought to be weaseling rather than truth.
So, do you give the overly simplified answers to the overly simplified questions, or do you lose the sale to someone who will?
Sadly, this is the state of the industry. It comes because, no matter how much candy you put on it, computers ARE complicated. System-building is a complicated process. However, the higher-ups are unwilling to learn new things, so anytime someone tells them something is "automatic" or "easy", that's the option they choose because they don't want to have to think about it.
I understand the sentiment, but it's simply trying to wish reality away. If you want the benefits of technology, you have to take the problems as well. That includes additional complexity AND additional rigidness. People too often forget that computer systems are VERY rigid. They do only what they are programmed to do, and every feature costs money. Therefore, they are very, very rigid compared to the paper/pencil approach. However, their rigidity can lead to many benefits, especially in overall efficiency.
But you can't pretend the problems don't exist and believe everything anyone tells you.
I'm very good at dragging real requirements out of customers, and, believe me, it's still a nightmare. User's minds change all of the time. If you ask continually, "do the various options have _any_ effect on price for _any_ item whatsoever", you may get a "no" response every time. However, when they finally start putting data in, lo and behold, they have options with prices.
Doh!
Obviously, it would be nice if we had access to all of the existing data to start with, but we don't. And when customer specifications are completely against what is in their data, the whole thing goes to heck! It's especially bad when customers continually change their mind - especially when you tell them "you'll hate this when we actually implement it" "Do it anyway". Then, later "I hate this, get rid of it, and do it for free".
In addition, usually when you negotiate the contract you haven't done a full analysis, because that would cost too much up-front money to risk. Therefore, you have to have a generally-specified contract. Then, when they come in later demanding features that they never mentioned, it becomes a nightmare of negotiations.
For example, an equipment company wanted to sell a lot of its wares. Great! They give me catalogs of what they sell. AFTER the contract, they ask about where their customer product Y is. It turns out, product Y is not in their normal catalogues, because it requires twenty pages of instructions on how to configure all the options! They want the software to guide the user through all of the configuration steps for all of the options, for each model!
The user really has no idea what they want, because then they get mad that they actually have to enter, update, and maintain the data. For example, many users are upset that we have to import photographs of their products into their website. They want it to do it "automatically" (meaning that they don't want to have to submit a photo either to us or to a custom page on the website). How does a website automatically know what something looks like? Please someone tell me?
I would also say that a lot of small tools often work better than the one big tool. Especially since people will start using the small tools anyway once they see how poorly the big one works.
The problem is that they are not educated enough to make a purchasing decision. Sure, they'd _like_ software that works. However, they are not qualified to make that decision on a large scale. Computer people know how to break things, but a regular user would need to pore through manuals and use it for several weeks before the problems of the system are obvious.
In addition, users don't understand jack squat about security, customizations, management, etc. For example, if you were selling an e-commerce product, and someone asked you about whether or not your system was "secure", what would you say?
You could explain to them how security is never 100%, that it involves both the user and the developer, the difference between secure communications, secure storage, and access control, and discuss with them what the tradeoff they would like to make between security and convenience is.
Or you could just say "yes, it's secure." You haven't lied - it's just that their question presumes a simplicity that doesn't exist.
I guarantee you that the customer will go with vendor 2. If you try to explain why you are more honest, they will think that you are just trying to weasel them - you had a complicated answer while the other guy got right to the point.
This is what is screwing over the industry. The users have no idea what really works and what doesn't, and with the dumbing down of the industry, fewer and fewer "technical" people are qualified to make that call, either.
So, whoever has the best BS marketing wins. Anyone can put on an amazing demo. The consumers don't know anything but to trust you're opinion.
One time my Dad was looking into a service. He told me that they said it was secure. I asked him how he knew it was secure. "They told me it was."
Slashdot Mirror
Actually, .NET deals with components in multiple languages on the same system. It has classes that deal with SOAP, but they are just a library.
CORBA is a sweet, sweet solution. Most people who don't like it haven't actually used it. I was able to teach C++ students how to code CORBA apps in less than an hour. It's really pretty sweet. You only have to mess with the complicated stuff when you do complicated things. Otherwise, it's totally transparent.
The fact that it's a marketing bullet point means nothing. When I talk to people actively using it and it making sense and working for them, I'll believe it.
Actually, ActiveX is a self-registering COM object. Notice how a slight variation gets a whole new market-drive name!
What you miss is that you are only obligated to follow the GPL if you redistribute code outside of your organization. Period. If you don't redistribute code outside of your organization, you don't have to pay ANY attention to the GPL at all.
With other software licenses, you have to accept them to _use_ the software. With the GPL, you can use it without accepting the license agreement. The GPL _broadens_ your rights, it doesn't restrict them.
This is what proprietary companies don't want you to know, because then it shows that _proprietary_ software is what you need legal departments for, while open-source only requires one for redistribution outside of your organization.
No, they can put any license they want on their binary-only drivers.
Actually, I've found that fixing bugs in large projects is about the same whether or not you are familiar with the project, provided that the author was no smoking crack at the time he wrote it.
For example, I managed to code, test, and patch a "fix" for PostgreSQL this weekend in under 2 hours, having never seen the code before.
The "fix" wasn't a bug, per se, i't just that the output of pg_dump wasn't optimal in my usage for dumping the schema for CVS revision control. I added two flags, -m -M, which molded the output to my liking.
If you haven't seen your code in two months, you and an outsider have about the same chance at finding and detecting bugs/misfeatures.
" Well, Yes and No. The problem is that there may be no logical way that the pointer may be NULL today. But tomorrow, a new coder will add something that modifies the preconditions and suddenly that pointer can indeed be NULL. "
Unless there's documentation saying that it shouldn't be null. If there isn't, it's a bug in the present code. If there is, it's a bug in the future code.
Documentation really is a part of the code, even though many people treat it as a side-issue.
The only barrier for installing the applications is a good program like Wise or InstallShield. Really the dependency mechanisms in Linux is excellent, it's just that noone builds self-installing packages.
Were you using Postgresql 7.3? A lot of things were problematic in 7.3 have been fixed in the devel release, which my company is using in production.
Most patches (especially the kernel patches) are only needed if you have servers with local, untrusted users.
The "not needing patching" comes from Postfix - the external interface - which really doesn't. Wietse Venema is an absolute genius when it comes to security and software design, and I'm not aware of any exploitable security holes in Postfix even before it was officially released.
None of the security exploits you mention are Internet-accessible. In fact, the SMB _protocol_ (even with a perfect implementation) has enough security holes as to not be trusted on an external network.
Anyway, I understand the sentiment, but really, it's not as big of a deal as you make it out to be (granted, the OSS community often exaggerates the impact of MS flaws initially, but we usually come to reason fairly soon).
There _are_, they just aren't Outlook-compatible. PHPGroupware is what my company uses - it goes far beyond what Exchange/Outlook provides. However, it doesn't use Outlook itself, and thus many corporate types won't touch it. Yes, that's stupid, but that's where we live.
Yes, but my version is the condensed version of "You could keep them to yourselves, but then if you get out of sync with the mainline tree you have then degenerated into a full-fledged software development project which will do nothing but increase your costs through the roof, so it's best just to contribute the changes back to the community."
I think my original version is better for explaining to PHBs.
The amazing thing is that people will complain about "OpenOffice incompatibility" when OO won't open up their Word97 documents exactly right, but won't bat an eye to upgrade to Office 2000, even if they have to retouch every document they have.
WHAT IS WRONG WITH THE WORLD THESE DAYS???????????????
If you look at what it takes to maintain most systems out there - it's usually a lot more than one developer of YOURS, even if you have a support contract from them.
In addition, if you know of a company where I can work and get $80,000 a year, let me know. I'm working for half of that right now.
In addition, many of the Oracle packages take many, many months just to install. The SUPER_QUICK_NOONE_IS_ACTUALLY_THIS_FAST Oracle install time is 3 months. This is if you have 0 customizations and no legacy data.
Another problem is that many features don't belong in the application, they belong in another one. But in order to sell more widgets, the put in a sucky version of that app and use it as a marketing point, when really it's a reason why you should avoid software houses that have no focus.
Yes, it's more complex, but, for most cases, needlessly so. Oracle Applications comes suited for multinational, multi-industry companies. Most people who _use_ it don't actually fit that, and would be better off developing something customized to their needs.
As for the year, in my experience it takes 9 months for a small company (~300 employees) to do a full install of Oracle. Larger companies can take longer.
I agree with your points. However, one point you mentioned "But there are a lot of complicated systems that 2 people could never pull off without so much time that the technology moves before you get the app out the door." My company did an Oracle Applications install. We used 11.0.3. when it first came out. By the time we had it running they had _finished_ 11i, and had committed their development resources to building 12 and bugfixing 11i. They refused to offer us any decent level of support on 11.0.3. We either had to upgrade to 11i (which basically meant going through the same hell that it took to get here - no company at that time had successfully done an upgrade - some had managed it with a full reinstall/reimplementation) or do with broken software. I left around that time to move closer to home, so I don't know what the decision was.
"That sounds like a business plan. If it's so easy to do, why not hire two developers yourself, build the software and then sell it at half price of the competition to ten companies."
You miss the point. The point is that each company is different. Packaged software will NOT do EXACTLY what the user wants, simply because it was not developed with that user in mind.
However, the method you state does work magnificently with Niche products. It only works with Niche products because, as mentioned previously, it is a _custom_ job.
I've done work on an Oracle Applications project. The problem is that in order to make it have "broad appeal" they had to make it so overwhelming and overcustomizable as to have every option anyone might ever want in any kind of business. Yuck! It takes _longer_ to configure the existing functionality in Oracle Applications than it does to build it in most other ones.
Now, don't get me wrong. There are some companies who NEED Oracle Applications. Like multinational firms dealing in multiple currencies and multiple languages who have to have a very rigid security structure for the 100,000 employees they have in the 10 different industries they are involved in.
However, for companies of less than about 5,000 people (i.e. - most of the people buying Oracle Applications), it is much, much cheaper to build the functionality yourself - you can make it work EXACTLY like you want, and not require $80,000 worth of server equipment to run on.
To understand the problem - a company I worked for had a small accounting system, to which we had built some customized applications on top of. These applications were text-interface, but worked very well. The database ran on an old Sparc that our developers refused to use because it was too old.
We switched to Oracle Applications to modernize our system (whatever that means). The same amount of functionality, but required a Sun E450 and 2 Sun E250s. In addition, the GUI made it take 4 times as long to enter an order - so we had to add extra customer service reps! Anyway, my point is that the reason that it now takes a network of enterprise sun machines to do what a sub-par workstation used to do is that there are so many tables in the Oracle system that deal with OTHER PEOPLES business. Not yours, someone else's. However, they slow you down, introduce bugs for you, and make it difficult for you to customize. If you had written it yourself, then you have two advantages:
a) You don't have to fit yourself into their model
b) You don't have to have the overhead of a multinational, multilingual, multiindustrial corporation.
That overhead is not just in computer cycles. It's also in manpower - you have to manage your company as if it was this huge powerhouse. Thus, management of the system is dreadful.
In addition, the many features interact in wierd ways to produce wierd bugs. If you happen to be one of the few people who use that feature, don't count on them to help you out. They've got larger companies to keep happy...
"With your argument, any company would be allowed to make unlimited copies of MS Office as long as they don't "distribute it outside itself""
Incorrect. If you look at the GPL, it says this explicitly, while the Microsoft EULA does not.
Amen to that!
Software development will be considerably better when they start teaching logic in MBA school and public speaking and social conduct in CS programs.
The problem comes in the area where the person listening doesn't have any experience. If the PHB says, "is it secure?" do you say "yes", or do you explain to him how security is not any one thing, show him the different types of security mechanisms available, talk to him about the different security/convenience tradeoffs, and the like?
I guarantee that if your response is anything but "yes" that the rest of your speech will be thought to be weaseling rather than truth.
So, do you give the overly simplified answers to the overly simplified questions, or do you lose the sale to someone who will?
Sadly, this is the state of the industry. It comes because, no matter how much candy you put on it, computers ARE complicated. System-building is a complicated process. However, the higher-ups are unwilling to learn new things, so anytime someone tells them something is "automatic" or "easy", that's the option they choose because they don't want to have to think about it.
I understand the sentiment, but it's simply trying to wish reality away. If you want the benefits of technology, you have to take the problems as well. That includes additional complexity AND additional rigidness. People too often forget that computer systems are VERY rigid. They do only what they are programmed to do, and every feature costs money. Therefore, they are very, very rigid compared to the paper/pencil approach. However, their rigidity can lead to many benefits, especially in overall efficiency.
But you can't pretend the problems don't exist and believe everything anyone tells you.
I'm very good at dragging real requirements out of customers, and, believe me, it's still a nightmare. User's minds change all of the time. If you ask continually, "do the various options have _any_ effect on price for _any_ item whatsoever", you may get a "no" response every time. However, when they finally start putting data in, lo and behold, they have options with prices.
Doh!
Obviously, it would be nice if we had access to all of the existing data to start with, but we don't. And when customer specifications are completely against what is in their data, the whole thing goes to heck! It's especially bad when customers continually change their mind - especially when you tell them "you'll hate this when we actually implement it" "Do it anyway". Then, later "I hate this, get rid of it, and do it for free".
In addition, usually when you negotiate the contract you haven't done a full analysis, because that would cost too much up-front money to risk. Therefore, you have to have a generally-specified contract. Then, when they come in later demanding features that they never mentioned, it becomes a nightmare of negotiations.
For example, an equipment company wanted to sell a lot of its wares. Great! They give me catalogs of what they sell. AFTER the contract, they ask about where their customer product Y is. It turns out, product Y is not in their normal catalogues, because it requires twenty pages of instructions on how to configure all the options! They want the software to guide the user through all of the configuration steps for all of the options, for each model!
The user really has no idea what they want, because then they get mad that they actually have to enter, update, and maintain the data. For example, many users are upset that we have to import photographs of their products into their website. They want it to do it "automatically" (meaning that they don't want to have to submit a photo either to us or to a custom page on the website). How does a website automatically know what something looks like? Please someone tell me?
I would also say that a lot of small tools often work better than the one big tool. Especially since people will start using the small tools anyway once they see how poorly the big one works.
The problem is that they are not educated enough to make a purchasing decision. Sure, they'd _like_ software that works. However, they are not qualified to make that decision on a large scale. Computer people know how to break things, but a regular user would need to pore through manuals and use it for several weeks before the problems of the system are obvious.
In addition, users don't understand jack squat about security, customizations, management, etc. For example, if you were selling an e-commerce product, and someone asked you about whether or not your system was "secure", what would you say?
You could explain to them how security is never 100%, that it involves both the user and the developer, the difference between secure communications, secure storage, and access control, and discuss with them what the tradeoff they would like to make between security and convenience is.
Or you could just say "yes, it's secure." You haven't lied - it's just that their question presumes a simplicity that doesn't exist.
I guarantee you that the customer will go with vendor 2. If you try to explain why you are more honest, they will think that you are just trying to weasel them - you had a complicated answer while the other guy got right to the point.
This is what is screwing over the industry. The users have no idea what really works and what doesn't, and with the dumbing down of the industry, fewer and fewer "technical" people are qualified to make that call, either.
So, whoever has the best BS marketing wins. Anyone can put on an amazing demo. The consumers don't know anything but to trust you're opinion.
One time my Dad was looking into a service. He told me that they said it was secure. I asked him how he knew it was secure. "They told me it was."