How to modify SugarCRM safely

My recent work with a SugarCRM project showed me, once
again, one great thing about open source software: You aren't limited
to the functionality of a product as delivered.
In contrast to proprietary software packages,
open source products include the source code, giving you the freedom to
modify the code to better fit your requirements. Yes, having the source
code available moves open source products from off-the-rack to custom
fit, and that works for me just fine.
My firm, Navicasoft Inc., having recently
completed an implementation of SugarCRM, a popular open source customer
relationship management (CRM) product, gives me the opportunity to
share the experience with you. So, let's look at that project and
explore some things to keep in mind when modifying an open source
product's code base.
SugarCRM is written in PHP, a user friendly
language that makes customizing SugarCRM easy. This ease of
customization is extremely valuable, as CRM products are used to
support one of the most critical functions in any business: customer
interaction. Every business addresses customer interaction differently,
and SugarCRM's source code availability makes it possible to get a
bespoke solution at off-the-rack prices.
Decide what really needs to be customized
After being stuck with inflexible proprietary
products, having the freedom to tweak a product seems like a luxury
cruise. Be careful not to go overboard with your changes, though.
Often, people modify open source products and
submit those changes to that product's open source development team.
Sometimes, those changes are put into the product's mainline code base.
In this case, the changes become part of the product and are addressed
in product updates.
With CRM, the whole point of code modification
is to make the product perfect for your business processes. It's
unlikely that your customizations are going to apply to enough users'
needs to be included in the product's mainline core base. So, you're
probably going to have to carry your code changes and apply them to
ongoing updates of the SugarCRM product. That means you need to think
hard about what really needs to be customized and what's a nice-to-have
customization, because there will be an ongoing cost for updating each
customization.
In our SugarCRM project, for example, the
company's project manager wanted a change made to the searching
algorithm. We pointed out that the same functionality could be achieved
through a minor change to the search string, and they decided to solve
the problem that way. This, along with several other tradeoff options,
reduced the total number of code touch points for their project.
Architect your changes to reduce ongoing work
Once you've chosen your desired product changes,
it's time to think about how to implement them. At this point, it
becomes important to think about minimizing your code changes and doing
what you can to group them together. It's easy to modify pieces of
source code; just remember that you will be applying those changes
repeatedly in the future.
By carefully designing your code changes and
grouping them in the source code, you can reduce the number of files
you'll have to modify in each update. You can also localize the changes
into certain parts of the files, further reducing your code touch
points.
We really focused on that, and we were able to
minimize the modifications we made to SugarCRM, thereby reducing the
cost per update. Done right, thoughtful architecting can reduce the
cost per update by up to 50%.
Choose your product update points carefully
A common complaint about proprietary software is
how slowly its development moves. Massive updates are released so
rarely that you think you're witnessing the birth of an elephant. Open
source, in contrast, goes by the mantra "release early, release often,"
and that makes each update less stressful and also higher quality.
The downside of "release early, release often"
can be "work hard, update often" if you have source code modifications
that you must apply to the baseline open source product. It's darn
expensive to repeatedly apply the same changes to a series of minor
point releases of a product. Consequently, think hard about which
releases you want to install.
The first rule of updating modified products is
don't turn on automatic update. That's asking for trouble, since an
automatic update could overwrite your code modifications and break your
product's functionality.
It's easy to get bitten by this one. An update
may be described as pertaining to just one area, but it can also
include code changes in parts of the product seemingly unrelated to the
description.
The second rule is to carefully assess which updates
to manually apply. Oftentimes, minor product releases fix or improve
parts of a product you aren't using, so it probably isn't necessary to
install those releases.
On the other hand, if a release significantly
changes a feature that's important to the way you use the product, that
is a release you'll probably want to install. Major product releases
with new functionality or significantly changed user interaction will
almost certainly be important to install. And, of course, releases that
fix important security vulnerabilities almost demand quick
installation.
The rule of thumb for all product update
decisions is "install as late as possible." Defer product
installations, whenever possible, until just before the next major
release. That way, you'll install the most stable release of the
existing version. You also avoid multiple updates that buy you very
little in terms of functionality and you will keep your maintenance
costs as low as practicable.
Installing as late as possible is a practice that captures the decision tree in a brief and memorable phrase.
Use a good process for installing product updates
It is inevitable that you will have to install
product updates. After all, you don't want to be stranded with an old,
un-maintained, buggy product. If you wanted that, you could have stayed
with proprietary software, right?
Here is the process we used to update SugarCRM baseline products with modified source code:

• First, we installed the new version of the product
  in a brand new, separate install location. In SugarCRM's case, this
  meant a fresh directory underneath the Web server.
  
• Next, we used a tool -- diff -- to identify the differences between each existing modified source file and the new SugarCRM source file.
  
• Once we identified source differences, we began to apply our source modifications to the new files.

Usually this is a fairly mechanical process,
although it requires a high degree of attention. It's easy to overlook
what seems unimportant only to find out down the road that part of the
product no longer works properly. These kinds of minor code issues can
be an enormous pain to solve, so pay attention while applying code
changes to new files.
Occasionally, a code application to a source
file is not mechanical; if the product functionality has been
significantly changed or the code re-factored, there's more to the
process than cutting and pasting.
In these situations, the code modification
process is very similar to the original process, when the code change
was first introduced into the source base. You need to analyze the
baseline product's functionality, after which you can create a design
to update the particular function, resulting in specific code changes
that are applied to the baseline code.
Once this process is finished, subsequent
updates of the baseline product will probably go back to the easier,
fairly mechanical process described in the previous paragraph.
Of course, once you apply all the code changes,
it's time to update any necessary configurations (e.g., environment
variables, database locations and names, etc.) and test the newly
modified product. Testing may require end user interaction to ensure
everything is working properly.
Assuming the testing goes well, it's time to
move the new installation into production. With SugarCRM, this is
usually as easy as renaming the directory to the name of the previous
release's directory. Other products may, of course, be more challenging
to move to production.
Golden's Rule
Just because the source code is free doesn't
mean the overall cost of the product is nothing. The freedom to modify
a software product offers fantastic benefits, but also imposes ongoing
costs. If you decide to modify a product, be sure to recognize the
additional work you'll be taking on and plan to minimize that work as
much as possible.