[kwlug-disc] the intertoobz never forget

Khalid Baheyeldin kb at 2bits.com
Sat Oct 10 10:00:19 EDT 2009

On Fri, Oct 9, 2009 at 11:32 PM, Bob Jonkman <bjonkman at sobac.com> wrote:

> Chris Frey wrote:
>> Sharing changes back to the community is a cost cutting measure.
>> The more you use FOSS, and the more changes you make, the more
>> of a headache maintaining your own little version will be.
>> I think it's a self-correcting problem, in many ways.
>> - Chris
> 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?

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

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.

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.

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).
Khalid M. Baheyeldin
2bits.com, Inc.
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20091010/6e9de880/attachment.html>

More information about the kwlug-disc mailing list