Private disagreement (email and such) is good, and a useful thing, but it doesn't get the issues out in front of people who may not have thought them through yet.
The problem is that, all too often, the people bringing their concerns public haven't thought them through yet either.
Public discussion is a waste of time if the discussion is based on a misunderstanding. What is accomplished by arguing about an illusion?
Private discussion should be used first to clear up any and all misunderstandings. Once they are gone, only then can any effective discussion take place.
There's a time for taking things in the open, and there's a time for talking person-to-person.
Consider this: The open letter approach is often used as a rebuke against those who are otherwise unresponsive.
That's not a very good way of starting a discussion. Don't bring out the big guns without reason.
For one thing, it's not useful to start out from a position of conflict.
Second, there is no need to use a public forum for the correction of a few peoples' private, personal misperceptions. Take it open if there appears to be ample evidence of a willful attempt to mislead or betray the public. Simple misunderstandings or disagreements don't count. A person's confusion is not adequate cause to call for the Bright Light Of Open Truth To Rain Down.
Further, taking things public tends to bring out the ego. Rather than a civil discussion between colleagues ("Hey mack, what's this thing mean?"), each party tries to out-rhetoric the other with pompous verbiage ("We the undersigned believe that Slim Goodbody has overstepped the bounds of his role, and grossly mispresented the goals of the MP3 Player GUI Widget Association"). Before even trying to clear things up, the parties have fortified their positions.
A lot of companies spend massive amounts of money writing software from the ground up.
This is because a lot of software simply isn't available commercially. And if it is available, you might not want to use it, because writing your own may provide a competitive advantage.
This is especially true in financial services. Financial software isn't all simple beancounting, which is why investment banks tend to be very early adopters of high tech. Everything from old Lisp machines to SGI visualization tools. It's not all 3870 terminals and mainframes.
Next time you're in a Borders or Barnes & Noble, look for a magazine called 'Wall Street & Technology'.
I would guess that the bank I work for has significantly more non-mainframe programmers than most shrinkwrap software companies.
These financial companies do buy shrinkwrap, where it makes sense. In that case, it's rarely modified. They also buy development tools (components, objects, libraries) which can aid their custom development projects.
The problem with this is that it demonstrates the technical bias of the OpenSource community. It's easy to charge for service related to software that is useful to business, which has the money and incentive to hire consultants. Compilers, developer tools, web servers, perl scripting, etc. Marketable skills all.
But this only covers a small portion of the software market. A lot of software is designed for users who simply are not going to pay you $200/hour for services.
Take, for example, educational software. Do you expect parents will pay $200/hour for services related to a first-grade reading program?
Of Course They Won't! They already complain about paying for tech support!
Slashdot Mirror
The problem is that, all too often, the people bringing their concerns public haven't thought them through yet either.
Public discussion is a waste of time if the discussion is based on a misunderstanding. What is accomplished by arguing about an illusion?
Private discussion should be used first to clear up any and all misunderstandings. Once they are gone, only then can any effective discussion take place.
Regarding slashdot kiddies:
Yes, there are some quality comments. However, the ranking system is an obvious admission that there's an enormous amount of noise.
There's a time for taking things in the open, and there's a time for talking person-to-person.
Consider this: The open letter approach is often used as a rebuke against those who are otherwise unresponsive.
That's not a very good way of starting a discussion. Don't bring out the big guns without reason.
For one thing, it's not useful to start out from a position of conflict.
Second, there is no need to use a public forum for the correction of a few peoples' private, personal misperceptions. Take it open if there appears to be ample evidence of a willful attempt to mislead or betray the public. Simple misunderstandings or disagreements don't count. A person's confusion is not adequate cause to call for the Bright Light Of Open Truth To Rain Down.
Further, taking things public tends to bring out the ego. Rather than a civil discussion between colleagues ("Hey mack, what's this thing mean?"), each party tries to out-rhetoric the other with pompous verbiage ("We the undersigned believe that Slim Goodbody has overstepped the bounds of his role, and grossly mispresented the goals of the MP3 Player GUI Widget Association"). Before even trying to clear things up, the parties have fortified their positions.
This is not the way to progress.
A lot of companies spend massive amounts
of money writing software from the ground up.
This is because a lot of software simply
isn't available commercially. And if it
is available, you might not want to use it,
because writing your own may provide a
competitive advantage.
This is especially true in financial services.
Financial software isn't all simple beancounting,
which is why investment banks tend to be very
early adopters of high tech. Everything from
old Lisp machines to SGI visualization tools.
It's not all 3870 terminals and mainframes.
Next time you're in a Borders or Barnes & Noble,
look for a magazine called 'Wall Street & Technology'.
I would guess that the bank I work for has
significantly more non-mainframe programmers
than most shrinkwrap software companies.
These financial companies do buy shrinkwrap,
where it makes sense. In that case, it's
rarely modified. They also buy development
tools (components, objects, libraries) which
can aid their custom development projects.
The problem with this is that it demonstrates
the technical bias of the OpenSource community.
It's easy to charge for service related to software that is
useful to business, which has the money and
incentive to hire consultants. Compilers, developer
tools, web servers, perl scripting, etc.
Marketable skills all.
But this only covers a small portion of the
software market. A lot of software is designed
for users who simply are not going to
pay you $200/hour for services.
Take, for example, educational software. Do
you expect parents will pay $200/hour for
services related to a first-grade reading
program?
Of Course They Won't!
They already complain about paying for tech support!