Tuesday, July 07, 2009

Why you would want access to the sourcecode for custom developed SharePoint solutions

So why do you need to get access to source code of custom built SharePoint components? What about 3d party ISVs versus System Integrators?

One thing to note is that I make a distinction between system integrators/consultancy firms and firms whose main target is to build specific SharePoint products. I do not expect that 3d party SharePoint ISV’s will release source code but I also think this is not that much of a problem since their products are widely deployed (ask for references!!!) and they know that a bad rep would kill their business. Therefore they probably have a stringent quality process for building SharePoint addons.

If your custom built solution is procured as a product purchase it is very rare that you get access to the source code and even if you do – you have to make sure that he source code does not get into the wrong hands.

If the custom built solution is procured as part of a works made for hire or services engagement (which is mostly the case with system integrators or consultancy firms), the source code is mostly provided – but not always.

Sourcecode keeps SI’s honest

Access to source code gives you additional flexiblity. If you need a change to your custom built solution you might have the option to do it yourself instead of reverting back to the System Integration.  If you have access to the source code, then any SI can make the change.  It keeps everyone honest… and it is better from a business continuity perspective. You probably want to protect your investments.

It probably is very disturbing when you notice that you can’t upgrade your platform since you have a lock-in from a custom built solution tied to a specific system integrator or consultancy firm.

Review deployed sourcecode

A custom build solution deployed on SharePoint can have the ability to impersonate to any other account without their passwords – take a look at Elevation of Privilege for some background info. You cannot be absolutely sure that they are not doing this, unless you have the ability to review the source code from a technical perspective.

If you have access to the code it is  also easier to validate the deliverable (the code) in terms of what you have agreed upon – this is what I call review source code from a functional perspective.

If you do not care if SharePoint code runs as fully trusted and you do not attempt to enforce partially trusted scenario’s – you probably don’t need the source code. Reviewing source code (and this is certainly the case for SharePoint) is not for the faint of heart and requires a lot of effort.

Best practice – do your own builds

If you are planning to run business critical applications on top of SharePoint make sure that you actually do the builds of the source code yourself. You might be in for a surprise when you notice that the source code built does not equal the deployed assmemblies because some extra code was added in the dll’s which are deployed on your server.

If you are a customer who works with a system integrator or consultancy firm you might even ask access to parts of their code repository. This way you can use this code directly and even see actual progress of your project at any time without the delay of having to send an e-mail every time. Take for example a look at Using Team Foundation Server to develop Custom SharePoint Products and Technologies applications

Look at the contract

Common sense dictates that you have to look at contracts that you sign – and this is also the case for software project contracts. Make sure that you look at the small print of a contract. Look if it is not explicitly stated that you do NOT get access to the source code. Most of the time, the SI will give you  a non-exclusive license to use the source code internally. You get access but you do not own the code. The SI will probably retain the rights to reuse, package, deploy, sell, etc… the source code and all derivative works. 

Some SI’s work with  third party source code escrow agents where the source code is kept (under escrow) and is only released under certain conditions – for example when the supplier goes out of business (One of the players is Escrow Europe which also has an affiliate in Belgium  - another one is Merak)

Remark: The views expressed here are personal and do not necessarily reflect the views of my employer.

3 comments:

  1. YES! That's how it should be done, but sadly in my experience (working for an SI) most customers lack the expertise to review code. Building it - not a hope.

    I'd love to work with a customer who could actually do this; I like working with other devs, an it would force us to do things properly. Often, I find I'm fighting with my management (who're looking at absurd timelines) to do things properly - like not running under full trust 'cos a 3rd party doesn't get CAS policies.

    Sadly, though, I think if companies had the expertise to review code, then they'd probably just write it themselves. Worse, SharePoint promotes the idea that the organisation won't need developers or technical staff.

    But it's so nice to hear someone describing how things ought to be done.

    ReplyDelete
  2. the @SPDevWiki has something similar too which you may want to check out too
    Integrator Handover Checklist

    ReplyDelete
  3. Integrator Handover Checklist link is broken.

    Should be https://www.nothingbutsharepoint.com/sites/devwiki/Playbook/Pages/SharePoint%20Development%20Integrators%20-%20Handover%20Quality%20Checklist.aspx

    ReplyDelete