<br><br><div class="gmail_quote">On Fri, Dec 26, 2008 at 5:43 PM, unsolicited <span dir="ltr"><<a href="mailto:unsolicited@swiz.ca">unsolicited@swiz.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The market has always been there. I can only imagine the benefits, let<br>
alone cost savings, if all medical practices were on the same system.<br>
Just imagine if Oscar became the Microsoft Word of medical offices.<br>
</blockquote><div><br> That would be wonderful!<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
 From this thread, it seems there are at least 3 basic problems:<br>
- the package is not easily implementable. Likely, aside from saying<br>
'install', the problems include documentation and surrounding files.<br>
- however good or bad the actual software, the FOSS packaging,<br>
including surrounding bits that make a package get from programmer's<br>
hands to nurse's keyboard, appears to be outside of the developer's<br>
world view. Given it's McMaster, it carries a fair bit of credibility<br>
of having appropriate functionality, it's just getting it into the<br>
user's hands, and afterwards.</blockquote><div>Well, unfortunately it's not executed well at all. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
- getting it in front of, and into, an office. Marketing. User<br>
acceptance, and critical mass. Changing your prime business software<br>
is a daunting idea in the first place - going with "What the heck's an<br>
Oscar?" is still a leap of faith. The poor packaging making the leap<br>
look farther. It needs to be plug and play, which is still a far<br>
fetched concept for most when everyone still thinks they have unique<br>
needs and requirements. This niche is application driven - hardware,<br>
let alone OS, becomes an issue.<br>
<br>
It's all these things that made me ask the question earlier in the<br>
thread: Are there any good references to this stuff? Coding is one<br>
thing - there are a LOT of other fiddly bits to take care of before<br>
code becomes a 'successful' package.</blockquote><div><br>Having been around some successful packages, I would say that the biggest thing is attention to users bugs/requests. This is something that is very difficult for one person to do.<br>
<br><br></div></div><br>