On Fri, Oct 9, 2009 at 11:32 PM, Bob Jonkman <span dir="ltr"><<a href="mailto:bjonkman@sobac.com">bjonkman@sobac.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Chris Frey wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Sharing changes back to the community is a cost cutting measure.<br>
The more you use FOSS, and the more changes you make, the more<br>
of a headache maintaining your own little version will be.<br>
<br>
I think it's a self-correcting problem, in many ways.<br>
<br>
- Chris<br>
  <br>
</blockquote>
<br></div>
Do you mean that making and maintaining changes in isolation is expensive, but making changes, contributing them back and then having the community maintain the changes is less expensive? <br></blockquote><div><br>As an open source user, one is better off pushing their patches into the product, rather than keep maintaining patches that are specific to your installation across versions. This means with every new release, you have the work of re-integration, modification, testing and deployment of your changes.<br>
<br>For purely pragmatic reasons (scratching your own itch), you are better off having your patches be part of the product, since you do not have to re-do this every time a new release comes.<br><br>This is only practical if your changes are generic enough for everyone else, and not too specific for one use case. There is also effort involved in submitting the patch and pushing it through the tracking system, convincing the maintainers, re-rolling the patch as needed to keep up with changes in the dev version, ...etc. So it does take an effort to do this, and the effort of having your patch accept can be considerable. A vibrant community will rip your patch apart, be it for functionality, code style, perfectionism, in code comments, documentation ...etc. And if the project strives to be better, the more scrutiny there will be.<br>
<br>A good product will be designed to allow extensions to be integrated more seamlessly than others. An API that allows extensions or overriding the default behaviors will go a long way to avoiding the need to patch the core product for every imaginable change, which avoids bloat and provide extensibility. An example is loadable modules in the kernel for drivers, or the entire Drupal core API of "alters". Changes which would have been required to be in the core product for other projects now take the form of contributed modules, or site specific modules (too specific to be of any use to anyone other than a certain site and use case).<br>
</div></div>-- <br>Khalid M. Baheyeldin<br><a href="http://2bits.com">2bits.com</a>, Inc.<br><a href="http://2bits.com">http://2bits.com</a><br>Drupal optimization, development, customization and consulting.<br>Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra<br>
Simplicity is the ultimate sophistication. --   Leonardo da Vinci<br>