<p> Their assessment is a reasonable. Their staff have a lot of<br>
MS training and experience; there will be considerable<br>
expense and confusion for them should they move to MySQL.</p>
<p> Also, it is likely that Postgresql is actually a better fit for their<br>
needs so why not recommend that? MySQL has been lagging<br>
on core relational database features for quite some time.</p>
<p> Forcing technical decisions on technical people for political<br>
reasons is unfortunately all too common and leads to<br>
inefficiency, stagnation and poor morale. You've made your<br>
suggestion and they have rejected it; persisting would only<br>
recreate the kind of hierarchical vibe that is both contrary<br>
to open source and probably led to the choice of MSFT in<br>
the first place. Help them be free to choose open source.</p>
<p>--<br>
Jason Dusek<br>
</p>
<div class="gmail_quote">On May 23, 2011 8:02 PM, "Asa Dodsworth" <<a href="mailto:asa.dodsworth@gmail.com">asa.dodsworth@gmail.com</a>> wrote:<br type="attribution">> The City Of Berkeley IT staff say that Open Source Database software wold<br>
> not be desirable, would ya'll like to assess their assessment..<br>> I ask as I'm a rent board commissioner who has been trying to understand how<br>> opensource software can be used to address our software needs.<br>
> <br>> asa<br>> <br>> <br>> Hi, Jay. Here is a brief explanation of how Open Source would play into<br>> your project and why it wasn't considered.<br>> <br>> *Open Source would make the task of automating the Rent Board much more<br>
> simple.<br>> *The biggest challenge the Rent Board faces is converting a manual system<br>> that had loosely defined business rules that were not consistently applied<br>> into a software system that rigorously enforces business rules. We have<br>
> agreed that there is no off-the-shelf solution that can meet the Rent<br>> Board's needs. As we've seen over the past year, the process of formalizing<br>> business rules is a cultural problem rather than a technological one. Once<br>
> we have accurately and thoroughly defined the business rules, the software<br>> development process is essentially the same whether we choose Open Source or<br>> proprietary tools.<br>> *<br>> Open Source would require less of an investment for the Rent Board.<br>
> *Since we have determined that there is no readily available off-the-shelf<br>> solution to adequately fulfill the Rent Board's needs, the only software<br>> required is server, web server and database software. Since the City has an<br>
> existing Enterprise agreement with Microsoft and is using virtualization,<br>> there is no cost to the Rent Board for server and web server software. The<br>> City could choose to use MySQL for a database platform, but since Oracle<br>
> acquired Sun Microsystems, MySQL Enterprise edition (required for an<br>> enterprise application like RTS) would be roughly the same cost as SQL<br>> Server. Since our network engineers, database administrator and programmers<br>
> are all familiar with SQL Server and do not have MySQL experience, there<br>> would be an additional ongoing cost to train staff and keep them educated on<br>> two disparate database platforms.<br>> <br>> *Open Source prevents prevents price gouging and other predatory practices<br>
> by companies like Microsoft and Oracle.*<br>> In theory, this is correct. The source code for Open Source software like<br>> MySQL is published intermittently so that any developer can support the<br>> software should the vendor's business practices take an unattractive turn.<br>
> However, a customized version of MySQL, for instance, carries other risks.<br>> First, database design and coding is extremely specialized and not something<br>> most programmers are familiar with. It's possible that the 3rd party that<br>
> supports the product is not qualified to modify the code. Secondly,<br>> maintaining a customized version of the software is expensive and not most<br>> vendor's core business. It's unlikely a vendor would modify something like<br>
> a database engine or operating system unless they had very specialized needs<br>> and experience to address those needs. Once a vendor has modified the base<br>> code, it could become proprietary unless they turn around an publish it,<br>
> thereby counteracting the benefit of going with Open Source in the first<br>> place. In terms of City staff modifying Open Source software, the cost<br>> would be very high, we would need specialized, dedicated staff to maintain<br>
> and support the software, and the risk of the software becoming unstable<br>> would be very high. City programmers are competent at creating small,<br>> specialized applications for those needs that can't be filled by commercial<br>
> software -- customizing databases and operating systems exceeds their skill<br>> set.<br>> <br>> *Open Source is like alternative energy -- it's the right thing to do and we<br>> should support it or else it will never get a solid foothold.<br>
> *First acknowledging the points made above, this is a valid point. Open<br>> Source may be a viable option for the City in the future but it is not<br>> currently viable. Municipal governments typically let private enterprise<br>
> work out the kinks before taking risks on new technology. In the past 5<br>> years, we have slowly but steadily begun using cloud services for some<br>> applications -- when it made sense and we could justify the risk. If we are<br>
> to use Open Source in the future, we will approach it in the same,<br>> deliberate way and with adequate research and preparation.<br>> <br>> <br>> -- <br>> Keith Skinner<br>> Renegade Image <<a href="http://renegadeimage.wordpress.com/">http://renegadeimage.wordpress.com/</a>><br>
> Facebook <<a href="http://www.facebook.com/pages/Renegade-Image/150788618296324">http://www.facebook.com/pages/Renegade-Image/150788618296324</a>><br>> Berkeley Afoot <<a href="http://urbnwokker.wordpress.com">http://urbnwokker.wordpress.com</a>><br>
</div>