This blog has a new home! You can now find it at: https://blog.steveendow.com/. Dynamics GP Land will no longer be updated.
Thank you!
By Steve Endow
Dynamics GP partners and clients often hire me to create custom Dynamics GP integrations, customizations, Visual Studio Tools AddIns, or even custom web APIs.
My development process usually involves using .NET. After that, I create a deployment guide and package that can be installed on the customer’s servers. Next, the solution undergoes testing, bug fixes, refinements, and new deployments until it’s ready for the customer to use.
Everyone’s happy, and my job is finished, right?
Well, there’s one crucial aspect missing.
Can you guess what it is?
What happens to the source code?
You might be wondering, “What about the source code?”
I meticulously keep my source code in Git and upload it to an online Git repository for security and accessibility. I also have multiple backups both locally and remotely. So, everything is taken care of, right?
Not quite.
Let’s say I vanish, win the lottery, or decide to live off the grid. What then?
In reality, I build long-term relationships with my customers, spanning years. I’ve witnessed their upgrades from GP 10 to 2010, 2013, and 2016. I’ve seen accounting departments and IT staff change. I’ve seen them switch Dynamics GP partners and even get acquired, go out of business, or migrate to different ERP systems.
While I have no plans to disappear, I’ve witnessed the challenges that arise when a Dynamics GP developer does. Sometimes they vanish without a trace, leaving customers stranded. More commonly, developers leave their Dynamics GP partner, and no one knows where to find the customer’s code.
Another frequent scenario involves customers who switch GP partners. Two years later, they realize they don’t have the source code for a GP customization or integration.
Therefore, I make it a practice to provide my customers with the source code. If I’m collaborating with a partner, I send the project manager the source code after each release. When working directly with a customer, I typically provide the source code to someone in IT.
Some might question this practice, exclaiming, “But it’s your intellectual property! You legally own the code! Why would you give it away?”
My customers are not paying me to simply type code into a development tool. They aren’t investing in my “priceless intellectual property” (which actually holds no real commercial value). And they’re certainly not hiring me to hold their systems hostage when they need to upgrade or switch partners and require an updated integration or customization.
I believe my customers hire me for the value I bring - a value that extends beyond a Git repository or a zip file of source code. While the code has value, my customers could easily find other skilled developers if that was all they needed.
So, what happens when I give my code to my customers? When I send that email with the download link to my “precious” source code?
Absolutely nothing. It’s a complete non-event.
Customers don’t suddenly replace me with cheaper developers. They continue to hire me. They don’t try to maintain the code themselves to avoid paying me. Sometimes they consider it, but then realize they would rather not take on the burden of managing another project. The last thing an overworked IT department needs is to inherit someone else’s code involving the ERP system and financial transactions – seriously!
But here’s what happens over time:
Issues related to code ownership and source code access vanish. Concerns about risks and critical dependencies disappear. Partners and customers feel more at ease. This transparency ultimately strengthens my client relationships.
Interestingly, when partners or customers encounter situations where other developers are hesitant to provide source code, they take notice. They recognize that I handle things differently.
The realization dawns on them: “Steve consistently provides his source code without any issues, yet this other developer is refusing to do the same.”
Such situations leave partners dissatisfied and customers feeling vulnerable. It strains the relationship.
Strangely enough, giving away my code has become a unique advantage. Potential clients often inquire about source code delivery, and I assure them that it’s included. Once I deliver the initial release, any concerns fade away.
While certain organizations or situations might have specific requirements, and lawyers are always ready to debate intellectual property and contracts, the mid-market companies I work with prioritize getting things done. No one wants to involve lawyers or deal with source code headaches. I’m not building the next big software application, after all.
So, when I hear about GP partners refusing to release source code to customers switching partners, I can’t help but wonder, “What are they thinking?”
In the end, I remain focused on customer satisfaction. And it seems to be working.
Steve Endow is a Microsoft MVP in Los Angeles. He is the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.
You can also find him on Twitter, YouTube, and Google+
http://www.precipioservices.com
