Plumbing is a service job. Service is the portion of the OSS software economy that IS charged for.
Proprietary software often attempts to treat software as though it is a manufactured product.
The OSS software economy model is analogous to giving away the pipes but still charging for labor. If pipes didn't have an intrinsic material cost, this might work. (Bear in mind that software is not a material thing you have to buy "raw materials" for.)
If you look at any kind of plumbing invoice you will find that the materials are a tiny amount of the total anyway.
Creating software in the first place takes time, yes, and the labor of a developer, but that labor can be paid for with service charges.
How about each customer pays for the amount of work which needs doing. If that's developing a whole new type of software it's expensive. But presumably the customer considers the money to be worth it. If all that's required is a minor modification to an existing program then less to pay.
Or, in the instance of buggy code, people are still going to be paying people money to fix them. The only difference is, in the brave new world of free software, the person with the problem can go to any of a thousand programmers to get the fix, rather than having to go to the owner of the source code.
The owner of the source code might pay "it's a feature, not a bug" or "we can't be bothered to fix it". In the open source senario it is likely to get fixed to the customer's satisfacton, because that is what they are paying for.
unless you work for MS, most programming jobs are related to customization and maintenance. With proprietary software, though, there IS no customization (unless you want to be sued)
Even leaving aside that aspect this would be a hard task since the first thing a programmer would have to do is reverse engineer the existing system.
For instance, my company was nearly a YEAR into writing financial reports for the company. All the software we were using was proprietary. Suddenly, towards the end of the project, it was discovered that the software could not combine the portrait and landscape types of sheets into one package on the company website. It would have been more cost efficient to pay a programmer 50k JUST to fix this one issue, but since it was proprietary software (and the of course the vendor didn't care), we had to switch proprietary software and start over!
Possibly the most important thing here is that it would have been worth your while to spend a substantial sum of money for a single change in a piece of software. Where that software was simply a tool, which was broken in a possibly minor way, but which resulted in expensive consequences.
The truth is EVERY software related project should employ a programmer because you never know what the limitations of the already available software will be until you are too deep into the project.
That limitation may well never have been relevent before even if it has been an issue in the past it may only have been a minor issue. Whereas at that time it could be an issue of losing lots of money, losing a lead on a competitor, etc. There is a question of if you need to employ a programmer or to have the ability to call one in at short notice if needed. But, assuming you have the ability to alter the code, this is the kind of decision which can be made on a case by case basis.
How do you figure that? All you're doing is moving the job, at best, from the vendor to the customer.
A vendor is likely to want something which is generically "good enough" to be able to sell lots of copies. A customer is likely to want a tool which will do what they want done the best possible way.
Imagine if all companies had their own couriers instead of using Fedex, or all companies generated their own electricity instead of buying it from the grid.
Plenty of companies do have the means to generate their own electricity. If having a reliable electricity supply is importent they won't trust a third party. Also it's hardly unknown for companies to courier information themselves, including having people who have vital information in their heads physically go somewhere.
There are a great many proprietary apps out there that various businesses wish they could customise feature X or add feature Y. Proprietary software means that those customizations are simply out of the question, so that's one less position for a programmer. The money to pay the programmer's salary will come out of the licensing costs no longer paid out and from the administrative costs of license compliance that is no longer necessary.
Don't forget the savings of not having to work around a sub optimal tool and from being able to do whatever tasks they want to perform more efficently.
I get paid to write software, these days I slap a GPL license onto everything I ship, but a great deal of this won't ever be seen by the public because its not generally useful and nobody would actually be interested. The stuff that is generally useful will eventually make its way into the wild, but its defaintely in the minority.
There is also a possible benefit to you. Since you are writing GPL code you are free to incorporate anyone else's GPL code in your project. No need to either "reinvent the wheel" or negotiate licencing with someone else.
I like getting paid to write software. If nobody bought software, I guess that programming would be a 'hobby' and not a 'profession'.
Most people paid to write software are doing so to perform a specific task, not to write some sort of generic program which can be sold in volume.
I think the free software people are idiots. Kinda the same if 1/2 the plumbers in the world went around doing the job for nothing- because 'everyone should have water'.
Actually free software enables coders to get paid the way plumbers get paid. For putting together or altering a system according to the customer's requirements. You don't have anyone thinking that plumbers should design and put together "off the shelf" plumbing systems which can be installed by non plumbers.
I like getting paid to write code. I'm pretty sure that a lot of other people do. If the companies don't sell the products,
For many companies software is exactly like plumbing. It's an infrastructure to enable them to provide products and/or services better. Just because a company is prepared to pay a plumber does not mean that their business is selling water pipes, why should the fact that they are prepared to pay someone install, configure and alter computer software mean that they must sell software?
Secretaries, "executive assistants" and data entry folks worldwide. And lots more too, but I think the above would make up the largest number of users, overall.
Do they care who makes the software though? Since, in the end, the real criteria is "does the tool do the job".
I've seen the same kinds of arguments from people arguing for Microsoft. For instance, I've seriously seen it argued that using Linux would require a company to release code to the public.
Which a) isn't the case b) wouldn't really matter even if it were the case anyway. Since most companies don't sell software in the first place.
Rather, they use it because the enterprises up the street and down the street use it. They use it because all their employees and prospective employees (who aren't computer illiterate) can use it.
Or possibly because they think their employees can use Microsoft and only Microsoft. With many of their employees thinking that. Plenty of situations where the myth of Microsoft's stuff being easy to use falls flat. As well as plenty of situations where no-one is using any OS at all. They are using a bespoke application, where the entire user interface and environment is the application.
If the music industry becomes obsolete, you will have no new music to download.
People were creating music long before the music industry existed and long before machines to record sound were invented.
Most musicians can not market themselves as successfully as record companies can.
So what, there are plenty of musicians who do it because they enjoy making music.
Also, because just about anybody record songs in their basements and put them on the internet, they lack credibility. ANYONE can do it.
No, since in order to make the music in the first place some level of ability is required.
This why we have professional organisations for doctors and engineers. We know we are getting a competent person if they are a professional (baring strange exceptions).
That's because the level of risk from an incompetant is high and most people cannot easily judge for themselves someone's competence. The consequences of a bad musician are simply annoyance, not mass destruction, serious injury and death.
You think it's OK for piracy (an illegal activity) to make a business pointless and obsolete!?
Is p2p a cause of the third party publisher business model becoming obsolete or is a symptom?
Remember that piracy is stealing and stealing is illegal everywhere in the world worth living.
Copyright infringement is defined differently from theft in just about every legal code on the planet. Also using the word "piracy" in the context of copyright infringement tends to draw attention away from it's meaning of "armed robbery on the high seas" which continues to be a very serious problem in some parts of the world.
However, while it's fun to point out the stereotypical geeks, most of the people I meet at cons, even the onse in the Klingon costumes barking Qapla'! at each other in the hallways are folks who do have a job, don't live in their parent's basement, and come to the con so they can just be geeky for a few days.
Yet no-one makes anything like as much fuss about sports fans enguaging in what is much the same behaviour. Including getting dressed up in fancy costumes, putting on makeup and singing in something that may as well be a foreign language.
And while we are on the topic, thos who think that forced signing of e-mail really works.
More useful to have a system where any mail sent to you must be encrypted with your public key. This dosn't actually stop spam, just makes it a lot more expensive for the spammer.
All I said is that every IP should have a reverse DNS entry and that your HELO information provide a FQDN which has a valid A record and/or MX record. I never said this had to _match_ the PTR and A records in DNS.
It probably wouldn't be a bad idea that if the FQDN given in the HELO command and that derived from doing a DNS lookup do not match to insert delays in the remainder of the transaction. Similarly if the domain in MAIL FROM is inconsistent with that from either a DNS lookup or the HELO command. Thus indicating that some form or relaying is likely to be going on.
Agreed on SSL. Why should a web credit card transaction be "more secure" than a telephone credit card transaction. The likelyhood that someone is listening to my web transaction is about as likely that someone is listening to my phone call, when I order Chinese, and writing down my credit card number.
Especially given that the most likely source of leaks isn't the transmission of your credit card details it's what happens to them after they reach the destination.
The only change to email I would support is to role in IM support to email, that way you could flag an email as an IM and then the client application could decide to display it differently than other email.
Something very like this was in the original SMTP spec.
However, the "interpreter" should be free to make their work. This issue highlights the entire POINT of copyright. Copyrights are meant to encourage people to create so that eventually others can base new work off of those results. It may be a derivative, a remake, or even a simple collage.
A copyright law which covered only copying, but didn't restrict using a work as source material could do this. Even were the copyright of infinite term. As could a very short term copyright law which also restricted "derived works". What we have now is very long term copyright with very stringent restrictions of the creation of derived works.
However, the whole idea should be to EMPOWER precisely this sort of use for older art.
Using older works as source material for new works is the way creative people have operated for thousands of years anyway.
The GPL offers pretty bleak options to the software business world: sell support and documentation. Cygnus couldn't make it work, and Red Hat isn't having much better luck.
The business model of selling software as an off the shelf commodity dosn't have much to offer many businesses either. Unless they have a clear niche market.
Bless them for trying, and I hope things improve, but other companies will not be lining up to enter that business niche.
Companies are unlikely to be lining up to enter the "software business" so long as there is a completly distorted market.
The World Intellectual Property Organisation (WIPO) has taken America's already stringent copyright, trademark, registration, and patent laws and forced them upon signing members in slightly revised format.
The whole process is called "harmonization". But only appears to involve creating new laws. The eventual result would be that everyone will end up more stringent IP laws. Assuming there is actually an "end" and not continual "feature creep". US laws are not the only contributions here, just so happens that the US was amongst the first to attempt to impliment the WIPO composite.
Yes, you need Windows XP (isn't that a shocker?). It is integrated into Windows XP.
In other words it dosn't integrate with anything else. e.g. a cellphone or PDA... Imagine how silly it would be if in order to add a new wing to a building you had to demolish and rebuild the entire system first.
It uses the Windows login for security rather than some kind of add-on homebrewed security of its own.
VNC, at least the unix version will do this quite trivially. Since Xvnc understands all of X, including XDCMP, as well as the VNC protocol.
It automatically brings up a login screen on the local machine.
As does Xvnc if you want it to do do so.
That allows a support person to work on the machine without the local user watching everything he/she does and without the local user interfering.
Wow, Windows XP has caught up with unix. How many years and versions of Windows did that take:) Just because the Windows version of VNC server emulates "RCONSOLE" does not imply that the unix version does this.
And with this case it's a calculable risk. They can look at the companies history, look at its business plan, value of stock, etc, etc.
With the way which stock markets currently operate anyone assuming that a stock price tells you anything about the state of financial health of a company is probably a fool. Especially where there are no dividends being paid whilst there are all sorts of stock options in place.
When it comes to Microsoft, IBM or Oracle, there's little doubt that the company will exist long enough to support the solution.
The company can still exist whilst completly pulling the rug from under you or playing the "it's a feature, not a bug" game.
Again, they CAN get a new version. It'll cost them, but compared to the cost of being completely dead in the water, it doesnt look so bad.
Maybe they are both "dead in the water" and need a new version. Because there is nothing which stops proprietary software from containing "logic bombs" to disable it whenever the publisher decides the licence is up.
A few hundred thousand dollars every decade or so (MS may release a new OS every 3 years, but real world people upgrade every 10 or so, most sites I visit still run NT 4.0) is nothing compared to "Oh Gee, we're out of business. The SAMBA team decided not to work on it anymore, they're writing a Pokemon clone now".
This dosn't really make much sense, if people can stick with NT4 they can just as easily stick with version whatever of SAMBA. The difference is that if Microsoft decide NT4 is "dead" then there is nothing which can be done about it. Nobody else can pick up the NT4 project and continue its development or provide support based on intimate knowlage of how it works. About the only senario which would get rid of both the SAMBA team and every copy of the SAMBA code is one which probably wouldn't leave any computers (or people to use them).
There may be one commercial software supplier (like MSFT), but there will be hundreds of firms willing to support it.
However willing they might be they are all handicapped by not knowing how the thing works.
Who exactly can you turn to when that code you
rely on is no longer supported because the
developer is no longer interested (or at
school, pregnant, etc.)
It's perfectly possible that the person who wrote some proprietary code is no longer with the company and no-one else can understand how it actually works. But you arn't going to know about that.
Let's say you maintain the code - now the
work your boss is paying you for belongs to
the world - you had better publish your
derivative works back to the community.
Your company might also have paid for the bildings it conducts business in. These could well be a matter of public record, especially if the public has access to them.
Many eyes makes for shallow problems, but
one mans hobby should never be another mans
mission critical infrastructure!
If someone or someones is being paid to ensure that a critical piece of infrastructure works then it is no longer a hobby.
Remind your management that closed source software, no matter how well supported by the vendor, by its nature *must* force you to rely on an outside organization for critical support.
Also no matter how badly their support you are still relient of them, even if you are dealing with a middle man. It isn't the same situation as using external pumbers, electricians, mechanics, lawyers, etc. Where you several independent alternative companies you could go to.
Open Source software gives you and your team the ability to fix the bugs that bother your organization. They could be insignificant to any other company, undetectable by most otheres, but killer bugs to your company - bugs that have to be fixed NOW!
Certainly no playing "it's a feature, not a bug". Regardless of if that team is "in house", an external contractor or some combination of both. It's definitly a "bug" because that's what the money being paid to fix it says it is.
The main disadvantage of going the open source route is you don't have anyone depending on your support $$, who will fix problems for you in a timely manner.
If it's that vital then you can contract someone to fix it for you. As opposed to paying as a sort of psudo-insurance policy or even paying someone to take your phone call.
You can write to the developers or enter a bug request, but this doesn't guarantee a fix within any particular timeframe, which can a substantial risk from a business point of view.
This is the option you have with proprietary software, through a rather indirect route, though no reason they should take any notice of your request. With open source software you have another option. The same option you have with other non-proprietary bits of business infrastructure. Which is to get someone competent into fix it.
Has anyone actually been happy with support from a closed source company that they were satisfied with?
The thing is that "support" can either mean identifying or even fixing what is wrong, in which case it dosn't matter if the information comes from a 24/7 telephone support line or looking at a set of tea leaves. Alternativly it can mean being able to "pass the buck", in which case having a "company behind it" matters a lot more than if anything actually gets fixed.
Slashdot Mirror
Plumbing is a service job. Service is the portion of the OSS software economy that IS charged for.
Proprietary software often attempts to treat software as though it is a manufactured product.
The OSS software economy model is analogous to giving away the pipes but still charging for labor. If pipes didn't have an intrinsic material cost, this might work. (Bear in mind that software is not a material thing you have to buy "raw materials" for.)
If you look at any kind of plumbing invoice you will find that the materials are a tiny amount of the total anyway.
Creating software in the first place takes time, yes, and the labor of a developer, but that labor can be paid for with service charges.
How about each customer pays for the amount of work which needs doing. If that's developing a whole new type of software it's expensive. But presumably the customer considers the money to be worth it. If all that's required is a minor modification to an existing program then less to pay.
Or, in the instance of buggy code, people are still going to be paying people money to fix them. The only difference is, in the brave new world of free software, the person with the problem can go to any of a thousand programmers to get the fix, rather than having to go to the owner of the source code.
The owner of the source code might pay "it's a feature, not a bug" or "we can't be bothered to fix it".
In the open source senario it is likely to get fixed to the customer's satisfacton, because that is what they are paying for.
unless you work for MS, most programming jobs are related to customization and maintenance. With proprietary software, though, there IS no customization (unless you want to be sued)
Even leaving aside that aspect this would be a hard task since the first thing a programmer would have to do is reverse engineer the existing system.
For instance, my company was nearly a YEAR into writing financial reports for the company. All the software we were using was proprietary. Suddenly, towards the end of the project, it was discovered that the software could not combine the portrait and landscape types of sheets into one package on the company website. It would have been more cost efficient to pay a programmer 50k JUST to fix this one issue, but since it was proprietary software (and the of course the vendor didn't care), we had to switch proprietary software and start over!
Possibly the most important thing here is that it would have been worth your while to spend a substantial sum of money for a single change in a piece of software. Where that software was simply a tool, which was broken in a possibly minor way, but which resulted in expensive consequences.
The truth is EVERY software related project should employ a programmer because you never know what the limitations of the already available software will be until you are too deep into the project.
That limitation may well never have been relevent before even if it has been an issue in the past it may only have been a minor issue. Whereas at that time it could be an issue of losing lots of money, losing a lead on a competitor, etc.
There is a question of if you need to employ a programmer or to have the ability to call one in at short notice if needed. But, assuming you have the ability to alter the code, this is the kind of decision which can be made on a case by case basis.
How do you figure that? All you're doing is moving the job, at best, from the vendor to the customer.
A vendor is likely to want something which is generically "good enough" to be able to sell lots of copies. A customer is likely to want a tool which will do what they want done the best possible way.
Imagine if all companies had their own couriers instead of using Fedex, or all companies generated their own electricity instead of buying it from the grid.
Plenty of companies do have the means to generate their own electricity. If having a reliable electricity supply is importent they won't trust a third party. Also it's hardly unknown for companies to courier information themselves, including having people who have vital information in their heads physically go somewhere.
There are a great many proprietary apps out there that various businesses wish they could customise feature X or add feature Y. Proprietary software means that those customizations are simply out of the question, so that's one less position for a programmer. The money to pay the programmer's salary will come out of the licensing costs no longer paid out and from the administrative costs of license compliance that is no longer necessary.
Don't forget the savings of not having to work around a sub optimal tool and from being able to do whatever tasks they want to perform more efficently.
I get paid to write software, these days I slap a GPL license onto everything I ship, but a great deal of this won't ever be seen by the public because its not generally useful and nobody would actually be interested. The stuff that is generally useful will eventually make its way into the wild, but its defaintely in the minority.
There is also a possible benefit to you. Since you are writing GPL code you are free to incorporate anyone else's GPL code in your project. No need to either "reinvent the wheel" or negotiate licencing with someone else.
I like getting paid to write software. If nobody bought software, I guess that programming would be a 'hobby' and not a 'profession'.
Most people paid to write software are doing so to perform a specific task, not to write some sort of generic program which can be sold in volume.
I think the free software people are idiots. Kinda the same if 1/2 the plumbers in the world went around doing the job for nothing- because 'everyone should have water'.
Actually free software enables coders to get paid the way plumbers get paid. For putting together or altering a system according to the customer's requirements.
You don't have anyone thinking that plumbers should design and put together "off the shelf" plumbing systems which can be installed by non plumbers.
I like getting paid to write code. I'm pretty sure that a lot of other people do. If the companies don't sell the products,
For many companies software is exactly like plumbing. It's an infrastructure to enable them to provide products and/or services better.
Just because a company is prepared to pay a plumber does not mean that their business is selling water pipes, why should the fact that they are prepared to pay someone install, configure and alter computer software mean that they must sell software?
Secretaries, "executive assistants" and data entry folks worldwide. And lots more too, but I think the above would make up the largest number of users, overall.
Do they care who makes the software though? Since, in the end, the real criteria is "does the tool do the job".
I've seen the same kinds of arguments from people arguing for Microsoft. For instance, I've seriously seen it argued that using Linux would require a company to release code to the public.
Which a) isn't the case b) wouldn't really matter even if it were the case anyway. Since most companies don't sell software in the first place.
Rather, they use it because the enterprises up the street and down the street use it. They use it because all their employees and prospective employees (who aren't computer illiterate) can use it.
Or possibly because they think their employees can use Microsoft and only Microsoft. With many of their employees thinking that.
Plenty of situations where the myth of Microsoft's stuff being easy to use falls flat. As well as plenty of situations where no-one is using any OS at all. They are using a bespoke application, where the entire user interface and environment is the application.
If the music industry becomes obsolete, you will have no new music to download.
People were creating music long before the music industry existed and long before machines to record sound were invented.
Most musicians can not market themselves as successfully as record companies can.
So what, there are plenty of musicians who do it because they enjoy making music.
Also, because just about anybody record songs in their basements and put them on the internet, they lack credibility. ANYONE can do it.
No, since in order to make the music in the first place some level of ability is required.
This why we have professional organisations for doctors and engineers. We know we are getting a competent person if they are a professional (baring strange exceptions).
That's because the level of risk from an incompetant is high and most people cannot easily judge for themselves someone's competence.
The consequences of a bad musician are simply annoyance, not mass destruction, serious injury and death.
You think it's OK for piracy (an illegal activity) to make a business pointless and obsolete!?
Is p2p a cause of the third party publisher business model becoming obsolete or is a symptom?
Remember that piracy is stealing and stealing is illegal everywhere in the world worth living.
Copyright infringement is defined differently from theft in just about every legal code on the planet. Also using the word "piracy" in the context of copyright infringement tends to draw attention away from it's meaning of "armed robbery on the high seas" which continues to be a very serious problem in some parts of the world.
However, while it's fun to point out the stereotypical geeks, most of the people I meet at cons, even the onse in the Klingon costumes barking Qapla'! at each other in the hallways are folks who do have a job, don't live in their parent's basement, and come to the con so they can just be geeky for a few days.
Yet no-one makes anything like as much fuss about sports fans enguaging in what is much the same behaviour. Including getting dressed up in fancy costumes, putting on makeup and singing in something that may as well be a foreign language.
And while we are on the topic, thos who think that forced signing of e-mail really works.
More useful to have a system where any mail sent to you must be encrypted with your public key. This dosn't actually stop spam, just makes it a lot more expensive for the spammer.
All I said is that every IP should have a reverse DNS entry and that your HELO information provide a FQDN which has a valid A record and/or MX record. I never said this had to _match_ the PTR and A records in DNS.
It probably wouldn't be a bad idea that if the FQDN given in the HELO command and that derived from doing a DNS lookup do not match to insert delays in the remainder of the transaction. Similarly if the domain in MAIL FROM is inconsistent with that from either a DNS lookup or the HELO command. Thus indicating that some form or relaying is likely to be going on.
Agreed on SSL. Why should a web credit card transaction be "more secure" than a telephone credit card transaction. The likelyhood that someone is listening to my web transaction is about as likely that someone is listening to my phone call, when I order Chinese, and writing down my credit card number.
Especially given that the most likely source of leaks isn't the transmission of your credit card details it's what happens to them after they reach the destination.
The only change to email I would support is to role in IM support to email, that way you could flag an email as an IM and then the client application could decide to display it differently than other email.
Something very like this was in the original SMTP spec.
However, the "interpreter" should be free to make their work. This issue highlights the entire POINT of copyright. Copyrights are meant to encourage people to create so that eventually others can base new work off of those results. It may be a derivative, a remake, or even a simple collage.
A copyright law which covered only copying, but didn't restrict using a work as source material could do this. Even were the copyright of infinite term. As could a very short term copyright law which also restricted "derived works".
What we have now is very long term copyright with very stringent restrictions of the creation of derived works.
However, the whole idea should be to EMPOWER precisely this sort of use for older art.
Using older works as source material for new works is the way creative people have operated for thousands of years anyway.
The GPL offers pretty bleak options to the software business world: sell support and documentation. Cygnus couldn't make it work, and Red Hat isn't having much better luck.
The business model of selling software as an off the shelf commodity dosn't have much to offer many businesses either. Unless they have a clear niche market.
Bless them for trying, and I hope things improve, but other companies will not be lining up to enter that business niche.
Companies are unlikely to be lining up to enter the "software business" so long as there is a completly distorted market.
The World Intellectual Property Organisation (WIPO) has taken America's already stringent copyright, trademark, registration, and patent laws and forced them upon signing members in slightly revised format.
The whole process is called "harmonization". But only appears to involve creating new laws. The eventual result would be that everyone will end up more stringent IP laws. Assuming there is actually an "end" and not continual "feature creep".
US laws are not the only contributions here, just so happens that the US was amongst the first to attempt to impliment the WIPO composite.
Yes, you need Windows XP (isn't that a shocker?). It is integrated into Windows XP.
:) Just because the Windows version of VNC server emulates "RCONSOLE" does not imply that the unix version does this.
In other words it dosn't integrate with anything else. e.g. a cellphone or PDA... Imagine how silly it would be if in order to add a new wing to a building you had to demolish and rebuild the entire system first.
It uses the Windows login for security rather than some kind of add-on homebrewed security of its own.
VNC, at least the unix version will do this quite trivially. Since Xvnc understands all of X, including XDCMP, as well as the VNC protocol.
It automatically brings up a login screen on the local machine.
As does Xvnc if you want it to do do so.
That allows a support person to work on the machine without the local user watching everything he/she does and without the local user interfering.
Wow, Windows XP has caught up with unix. How many years and versions of Windows did that take
And with this case it's a calculable risk. They can look at the companies history, look at its business plan, value of stock, etc, etc.
With the way which stock markets currently operate anyone assuming that a stock price tells you anything about the state of financial health of a company is probably a fool. Especially where there are no dividends being paid whilst there are all sorts of stock options in place.
When it comes to Microsoft, IBM or Oracle, there's little doubt that the company will exist long enough to support the solution.
The company can still exist whilst completly pulling the rug from under you or playing the "it's a feature, not a bug" game.
Again, they CAN get a new version. It'll cost them, but compared to the cost of being completely dead in the water, it doesnt look so bad.
Maybe they are both "dead in the water" and need a new version. Because there is nothing which stops proprietary software from containing "logic bombs" to disable it whenever the publisher decides the licence is up.
A few hundred thousand dollars every decade or so (MS may release a new OS every 3 years, but real world people upgrade every 10 or so, most sites I visit still run NT 4.0) is nothing compared to "Oh Gee, we're out of business. The SAMBA team decided not to work on it anymore, they're writing a Pokemon clone now".
This dosn't really make much sense, if people can stick with NT4 they can just as easily stick with version whatever of SAMBA. The difference is that if Microsoft decide NT4 is "dead" then there is nothing which can be done about it. Nobody else can pick up the NT4 project and continue its development or provide support based on intimate knowlage of how it works. About the only senario which would get rid of both the SAMBA team and every copy of the SAMBA code is one which probably wouldn't leave any computers (or people to use them).
There may be one commercial software supplier (like MSFT), but there will be hundreds of firms willing to support it.
However willing they might be they are all handicapped by not knowing how the thing works.
Who exactly can you turn to when that code you rely on is no longer supported because the developer is no longer interested (or at school, pregnant, etc.)
It's perfectly possible that the person who wrote some proprietary code is no longer with the company and no-one else can understand how it actually works. But you arn't going to know about that.
Let's say you maintain the code - now the work your boss is paying you for belongs to the world - you had better publish your derivative works back to the community.
Your company might also have paid for the bildings it conducts business in. These could well be a matter of public record, especially if the public has access to them.
Many eyes makes for shallow problems, but one mans hobby should never be another mans mission critical infrastructure!
If someone or someones is being paid to ensure that a critical piece of infrastructure works then it is no longer a hobby.
Remind your management that closed source software, no matter how well supported by the vendor, by its nature *must* force you to rely on an outside organization for critical support.
Also no matter how badly their support you are still relient of them, even if you are dealing with a middle man. It isn't the same situation as using external pumbers, electricians, mechanics, lawyers, etc. Where you several independent alternative companies you could go to.
Open Source software gives you and your team the ability to fix the bugs that bother your organization. They could be insignificant to any other company, undetectable by most otheres, but killer bugs to your company - bugs that have to be fixed NOW!
Certainly no playing "it's a feature, not a bug". Regardless of if that team is "in house", an external contractor or some combination of both. It's definitly a "bug" because that's what the money being paid to fix it says it is.
The main disadvantage of going the open source route is you don't have anyone depending on your support $$, who will fix problems for you in a timely manner.
If it's that vital then you can contract someone to fix it for you. As opposed to paying as a sort of psudo-insurance policy or even paying someone to take your phone call.
You can write to the developers or enter a bug request, but this doesn't guarantee a fix within any particular timeframe, which can a substantial risk from a business point of view.
This is the option you have with proprietary software, through a rather indirect route, though no reason they should take any notice of your request.
With open source software you have another option. The same option you have with other non-proprietary bits of business infrastructure. Which is to get someone competent into fix it.
Has anyone actually been happy with support from a closed source company that they were satisfied with?
The thing is that "support" can either mean identifying or even fixing what is wrong, in which case it dosn't matter if the information comes from a 24/7 telephone support line or looking at a set of tea leaves. Alternativly it can mean being able to "pass the buck", in which case having a "company behind it" matters a lot more than if anything actually gets fixed.