jdd wrote:
Dan Goodman a écrit :
My wife has prepared both individual and business taxes for clients for many years, both before and after she passed her CPA exam, and has tried many of the "industry standard" solutions, both those for professionals and those for the general public.
this simply shows how much proprietary programs are buggy.
This is true. However, unfortunately, it does not automatically follow
Brian K. White wrote: that open source is not. And the "target market" would not be committed believers in the concept, so their perceptions are often colored primarily by the cost issue, but with concerns about quality, whether founded or not. The barrier to adoption gets steep rather quickly, once we move beyond those who know and understand "the cathedral vs. the bazaar" (Tip of the hat to Randall Schwartz for the concept.)
Open source software have proven to be better (in the security and stability and exactness sense) than any proprietary one.
It is blanket statements like this that tend to make "outsiders" question the impartiality of the open source community's assertions in general. If you say "have *often* proven to be better" that is not as broad an assertion, but one that is more likely both to be true and to be believed.
However, when it's easy to make a lot of money from selling software, it may be difficult to find somebody to make it for free... for obvious reason.
And it is a "catch-22" ... that fact only makes potential users that much more skeptical.
Similarly, but with actual life & death consequences, where it's the commercial software that kills people. And no that's not just being melodramatic.
http://www.washingtonmonthly.com/features/2009/0907.longman.html
I was involved in a similar automation effort at a large urban teaching hospital. One thing that seemed to be obvious to me was that there was, and needed to be, a strong user-to-technician layer of implementation, with plenty of both hand-holding and requirements identification and tracking. This would probably be a necessary prerequisite regardless of the code's origin, and would be a major cost factor regardless of open or proprietary. And many proprietary systems allow for extensive customization, that is, the addition of user-provided source. And software used in most clinical type settings in the US require FDA-certification, an expensive and time-consuming process. The barriers to entry for open source are considerable. Not insurmountable, and I am thoroughly convinced that it can eventually be done, but that is one area where government intervention might be useful. Unfortunately, it sounds like it is more "business as usual" inside the Beltway (US's capital district, for those of you who might be unfamiliar with that term, or its related "beltway bandit", a.k.a vendors to the government.) However, let us hope that there are some vendors who are aligned with open source who might also have plans for this sector. Notice: This communication, including attachments, may contain confidential or proprietary information to be conveyed solely for the intended recipient(s). If you are not the intended recipient, or if you otherwise received this message in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments, without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is strictly prohibited and may be unlawful. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org