To all involved in this discussion, and especially to Joe, as a "systems" person who spent more than five years in a museum setting developing a system, and has also worked in traditional business settings, i.e. large insurance companies, accounting firms, etc., I'd like to say that while your ideals and position have merit, reality prevails! The paramount thing is always the data, and as long as you can get at it, export it, and also implement proper vocabulary controls and oversight for data collection, then at least the databases you develop make the effort worthwhile. After my many years evaluating various collection management softwares/companies, and trying to guide development of same with consulting programmers and thorough analysis in-house, I have come to believe that using a product developed "commercially' is probably the best approach, as long as 1) the foundation for the product is an industry standard, i.e. SNAP for Windows is based on Access, and 2) careful checking indicates the company is stable, and has a good reputation for support and delivery of product. Why? Because software development is complicated, time-consuming and expensive. The best products are usually produced by teams of people, and most museums do not have the staff, time and expertise to support this type of effort. It is true that the solution is not one guy with a laptop, but I don't think it is in-house development either, unless some spectacular person is able to rally a team of volunteer programmers from someplace like the giant insurance company where I worked for a year and a half. In addition, there is another important economic foundation for using one of the good products being developed for the museum community -- the benefits of economies of scale -- a company selling a large number of systems to many museums can offer the consistency and quality of a team product and a better price. It is a tragedy to see data trapped in a lousy expensive, outdated, proprietary product from a vendor who has gone under, but it is equally sad to think of all the dollars wasted on in-house development of systems that are similarly flawed or non-functional. In the large museums that have the time, staff and money to develop their own systems I have seen some impressive work, but I believe we should not delude ourselves about the true costs of software development versus the ease and affordability of selecting a vendor product.