Archive for May, 2007


Source code access for your offshore team or not?

Comments (0)

For many companies, the question that stands before them is not whether outsourcing is for them or not, they already know they need it. But rather the question is whether or not to give access to a remote team located in another country. The question may come up whether or not the team is internal or outsourced, but can be more complicated if the team is outsourced. Complicating it further can be when the organization has to follow Sarbanes-Oxley Act (SOX) security requirements. In these cases access to internal resources (including internal servers containing source code) needs to meet certain requirements. So the question is, is there a way that outsourcing software development can work without giving direct access to your onshore servers, to an offshore team.

As usual the answer is always “yes”, there are ways to still accomplish outsourced software development offshore. But, what needs to be decided is which option works best for your company. Below I describe a few possible options:

Option 1: Offshore location merges changes in to the source code With this option, your development team finishes a project in their offshore location. When they are done, your company provides to them a copy of the latest source code to which they then merge in their latest changes and provide back to you. With this type of a solution, it usually means your company has someone who is dedicated to working with the offshore team and eliminating obstacles for them which may be impeding their work and productivity. This includes wrapping up the latest sources that the offshore team or persons may have touched and getting it to them in a timely manner so they can do the final merge. With this type of a process, depending on the extent of the project or fixes that the offshore team worked on, the team may or may not need to receive all of your source code every time in order to do the merge. Also, depending on the number of software developers your company also has onshore, the person interfacing with the offshore team could be the person responsible for tracking all changes and all merges, and doing all builds for all team members regardless of where the team members are located; onshore or offshore. Or this may be another person within your company. A variant to this option could include the outsourcing provider running their own server, located in your country, containing the source code library that they give your company access to. Then periodically both sides can “synch” up the source code. 

Option 2: Onshore persons from the Outsourcing company merge changes in to the source code – Is the access issue mostly a matter of not giving server access or source code access to a team located in a particular offshore country that your legal department is not sure about? If that is the case, an option for handling merges could be to have engage an onshore person who works for your outsourcing partner, to complete this work. Depending on the size of the offshore team, the amount of work they are putting out, this person does not have to be engaged full time, but only for so many hours a week a month. Obtaining access to a source code library for a person located in your same country is usually much easier than giving access to person/s located in an offshore location.

Option 3: Your company merges changes in to the source code – If the concern of your company is not just about offshore access to your servers, but about opening up all of your source code to an offshore team or to an outsourced team at all, then the solution may be to have one of your own employees merge the changes back in to the latest version of the source code. This could be the same person who interfaces with the offshore team daily, or it could be the person in your company who is responsible for new software builds. By doing the merge internally it does give your company a measure of control, just make sure that there is a designated person within your company do to this work. If it is not someone’s assigned work, or it ends up to be the work of one of your internal developers, they are most likely not going to like and will hold off on doing; reducing the productivity of your offshore team.

The following chart summarizes the options:

Options: Offshore Onshore Internal External



Offshore location merges changes in to the source code x     x
  • Merge can be done cost effectively
  • Do not have to use internal resources for this work
  • Still need an internal person to respond to the offshore team and package up the latest source code and make it available for download by the offshore team.
  • Depending on how much source the offshore project touched, you may end up providing all source to the offshore team.
Onshore persons from the Outsourcing company merge changes in to the source code   x   x
  • Provides a level of security if required by your company, that all source code is not accessible to the offshore location
  • Still more of a cost effective solution usually than having an internal person do the work
  • Additional outsourcing expense
Your company merges changes in to the source code   x x  
  • Limits outside access to most current source code.
  • Do not have to get access approval for an outsourced team
  • Have to have a person available to do this work
  • Can be seen as low-level work by internal staff, especially if the person also does development, thus merge may not get done on a timely basis.

It doesn’t matter so much which option you choose, that depends on what is right for your organization and how you need to work. The only invalid option is to give up and say it can’t be done.

Categories: Outsourcing Offshore |