Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««1234»»»

The Build Buy Debate Expand / Collapse
Author
Message
Posted Tuesday, October 23, 2007 6:53 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 8:51 PM
Points: 33,266, Visits: 15,431
The problem with giving back to open source, in many cases, is that the competitive advantage you might gain from adding your own cool customization or bug fixes, is gone because you've now released that stuff to others. That ruins some of the advantage of going your own way.

And if you don't give code back, you've created a fork.

Personally I don't have a problem with someone using Open Source code or the MS platform, or anything else. Just pay for what you use, the base software. Give $50k to the open source project that you used as a license fee or so they can continue to develop more of the same type of software you used.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #413861
Posted Tuesday, October 23, 2007 7:07 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, September 8, 2014 6:39 AM
Points: 159, Visits: 430
Steve Jones - Editor (10/23/2007)The problem with giving back to open source, in many cases, is that the competitive advantage you might gain from adding your own cool customization or bug fixes, is gone because you've now released that stuff to others. That ruins some of the advantage of going your own way.


I accept this is the perception many businesses have - but it is generally fallacious. Taking your example of the forum software - do you really think it is the bells and whistles of the forums that draws people? I doubt it - I am sure you will find it is the content - so a competitor who ended up with any enhancements to an O/S forum solution would still need to get the content right to benefit. And most of the other users of the forum software would not be in competition anyway. Now there will be exceptions - I know of some examples of software that is truly unique to a business so would never be released as open source - but this sort of software is almost inevitably not bought in from outside anyway and so the open source solution would never be on the table.

The original topic was comparing the pros/cons of bought in versus self built solutions. If bought in was ever an option then you could not have been relying on customisation for competitive advantage anyway as the bought in software would be available to all you competitors.





James Horsley
Workflow Consulting Limited
Post #413879
Posted Tuesday, October 23, 2007 7:37 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 8:51 PM
Points: 33,266, Visits: 15,431
James,

I'd agree with you on something like the forums, but that's a very generic item. What about SugarCRM? I could easily add customizations, like phone/VOIP integration, automation to some customer process, links to something like Dynamics, etc. that would give me a competitive advantage. It would be up to me to decide to what extent that I'm helping competitors with that.

what about GIMP? Or some editing/rendering process. It might be that I gain some advantage I don't want to share.

I don't necessarily disagree that releasing back code is a bad idea. And lots of companies do release back stuff. But many are afraid and they're not sure they want to.

I can buy commerical software, like SAP, and customize it as well. That's more along the lines of what I was originally writing about. The forums might not have been a great example. They're somewhat open source. You can buy a license to get the code, but you can't freely release it.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #413910
Posted Tuesday, October 23, 2007 8:28 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Tuesday, March 29, 2011 2:59 PM
Points: 473, Visits: 606
There is another twist to this buy/build debate. I know of businesses that built there own software because they could not buy the software that would fit into their business model. Now they are in the software business. They realised the software they built was much more valuable as a product then the original business itself.

---------------------------------------------
Nothing is impossible.
It is just a matter of time and money.
Post #413950
Posted Tuesday, October 23, 2007 8:42 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, October 29, 2012 11:24 AM
Points: 22, Visits: 84
Two things to respond to:
Workflow I feel that the build vs buy decision (size and urgency plays a part as well) is really told in the process modelling. This is also something that is tragically missing from most vendors software documentation. The most difficult thing to do is not write software but change people habits. The cost of that should be added to the formula (intelligently - thumb suck guesses don't count) to make the BvsB decision. Every piece of business software has interaction and process assumptions built into it. If you can find software that matches your process (or desired processes) the buy decision is easy. I am currently assisting a company that is doing a large scale ERP upgrade. I was invited in after the crash was obvious to avert it (accomplished that) and one senior employ quit because she "couldn't go through this again." The chief pain point is none of this process work was done. The lesson here is that even when upgrading a current system B vs B uis a reasonable question. I had a sign on my office wall for a number of years that said "If you can't write it down, I can't build it." That includes processes. To paraphrase Joe Walsh "You can't know where you going if your don't know where you are"

Buying for Bells and Whistles - I must confess, I am not a pretty UI kind of guy. From years of working with marketing people, I find if someone is trying to impress me with features my instinctive response is to wonder what they are trying to cover up. Time always limits the final product. So if the vendor has invested in this what did they choose to leave behind. There are those vendors who, like street hucksters, like to do feature slight-of-hand. Thankfully I think they are few. However, a list of what it doesn't do is as important as a list of what it does when considering features.
Post #413959
Posted Tuesday, October 23, 2007 8:43 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, September 8, 2014 6:39 AM
Points: 159, Visits: 430
I do of course agree with you that you can't generalise - but many (most?) businesses do actually generalise by deciding they can't possibly share any changes they have made regardless.

As for SAP customisations - I am sure you will find these should in general be considered to be "content" rather than code - as I am quite sure you won't get you hands on SAP's source to make mods - customisations are generally rule-sets and are not really changing SAP per se.






James Horsley
Workflow Consulting Limited
Post #413961
Posted Tuesday, October 23, 2007 9:24 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Friday, September 12, 2014 7:21 AM
Points: 914, Visits: 1,721
There are several factors that came into play for us in this debate. Can we obtain and keep the developers needed to create and maintain this software? Are and will there be sufficient people who are knowledgeable about the tools used? Would this application give a significant advantage? Will there be asignificant advantage to tapping into the knowledge of the larger user base of the boughten software? Reviewing and modifying processes whichever the decision can have a significant impact, too.
Post #413989
Posted Tuesday, October 23, 2007 9:46 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, October 29, 2012 11:24 AM
Points: 22, Visits: 84
Julie,
I agree with the importance of all the things you mention. Some of them I like to put in the basket of company strategic plan. Maintaining an IT department that is development capable is a part of the total company plan and in some ways is larger than a build vs buy decision. Two companies I am working with have made the deliberate decision not to maintain an IT department. Good for me as this equals billable hours. Out of curiosity I discussed IT positioning with knowledgable people in both companies. While one wasn't "sure what we want to do in the future" so they do nothing - IT is not included in corporate planning - which seems flawed to me but it is is what they want. The other has made the decision to "trust the market" and hire people to modify the custom components as they are needed. They make a long term plan and when there are enough modifications required, contract the best talent they can and execute the plan. SInce they are big on documentation they have been able to maintain this for a couple of decades and have figures to back up their cost savings. I found it to ba a fascinating approach to this challenge made even more interesting due to their success.
Post #413999
Posted Tuesday, October 23, 2007 10:21 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, August 20, 2014 10:46 AM
Points: 13, Visits: 231
Great topic and good responses. I love reading these forums. (Steve you're awesome)

From a DBA perspective I am mostly concerned with the database when dealing with off the shelf solutions. Often times there isn't much a DBA can do to optimize or troubleshoot database issues with these apps. It can be very frustrating. Also, in some cases the data is locked in a proprietary system. Very sad indeed!

Whenever possible I'd rather build than buy - I like the flexibility of an in-house app. The ROI may take longer but in the long run, in many cases, I think it is the best approach.
Post #414017
Posted Tuesday, October 23, 2007 12:04 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, April 5, 2011 12:58 PM
Points: 230, Visits: 262
I started to write a reply but when the pop up ad with a picture of Hillary came up on my screen, it made me ill and I had to stop to clean my keyboard...

Sorry, off topic. But you should have warned me about pornography on this website.

We had our current ERP product customized by 3rd party. One day, that group went away and was eventually purchased by the ERP manufacturer themselves.

Due to our customizations, we could no longer get the updates/upgrades as they came out because of the unknown effect of the customizations. Our 3rd party vendor would first test those and then send us the update and any modifications needed. Worked well as updates only came out once or twice a year. Some of those same customizations that we developed later became incorporated in newer versions. Since we could not get the required support, we dropped paying the annual maintenance and have been trapped in a now older version with no upgrade path available.

So in this case, both the build and buy options were used and both came out bad in the long run. It did work very well in the beginning and was a cost effective solution. Building from scratch was not in the budget.

The problem is now resolving itself due to a buyout of our business and we are being forced to use their existing software, which is 10 years old, text based and runs on a Unix system. No more SQL.

Down the road, the larger parent is now developing a new CRM product which will be Oracle based.

Here we go again.
Post #414042
« Prev Topic | Next Topic »

Add to briefcase ««1234»»»

Permissions Expand / Collapse