Golden's Rules: How to modify SugarCRM safely

My recent work with a SugarCRM project shown me, once again, one great thing about open source software: You aren't limited to the functionality of a product as delivered.

This Content Component encountered an error

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.

Dig deeper on Open source databases

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchDataCenter

SearchServerVirtualization

SearchCloudComputing

SearchEnterpriseDesktop

Close