When given the option of using a third party/open source application in a web development project rather than build some functionality from scratch, what considerations should influence your decision?
Good Answers (3)
When I am approaching a software problem and the issue of build-or-bring-in comes up, I double-check myself to see if I am working on 'solved' problem. In my opinion, 'solved' problems are problems that every web developer has seen a million times and experts in that domain have tackled and put out a working solution for it. This includes things like Javascript libraries (jQuery, Prototype, mooTools, etc) and CMSes (Drupal, Joomla, Typo, Wordpress, etc), for two of the main examples. It seems almost a write of passage for web developers to write a CMS or a Javascript library.
Any good web developer could probably write their own Javascript library, e-commerce solution, and CMS, but, often, the question should be "why should he"? These types of software projects collect bugs like a picnic because it is the nature of web development where there are so many different ways for software to break. With grabbing a third-party app, especially with open source projects, you are leveraging the expertise and testing abilities of people that you don't have to pay. And with popular open-source projects, you probably have had hundreds to thousands of people testing the software and fixing bugs. That's huge.
Another big issue is maintenance. Building the software may only take a month, but you're going to support it for much longer. So whenever discussions arise about building software the phrase should always be turned into 'building and maintaining' software. That almost always puts the software in a different light. If it's proprietary and you have a bug, you have to fix it. If you have want a new feature, you have to build it. If a client has a question, you have to answer it. Also, you have the ominous software "bus factor." What if your lead developer got hit by a bus, or more likely, changed jobs?
Of course, there are instances where building your own makes sense. If you have very specific needs from the software or if the tool is one of your selling points, then obviously building and maintaining your own makes sense. But more than likely, the tools you use in your project are not your direct source of revenue. It's like when you are having a house built: You don't really care what nailgun the carpenter used, as long as the house looks good and is built to the blueprint. In this instance, "how to get the nail into the wood" is a solved problem. The same goes for web development. As much as web developers love to debate about what language/framework/CMS/OS is the best, the only thing that truly matters is that the client gets a website that works and is easy to use as that's what the developer is getting paid to deliver.
Links:
Kathy K
CTO, Technical Architect, Founder
Best Answers in: Web Development (5), Planning (2), Mentoring (1), Graphic Design (1), Customer Relationship Management (1), Business Analytics (1), Organizational Development (1), Biotech (1), Enterprise Software (1), Software Development (1)
Does the 3rd party/open source application provide the functionality you need? Is the company or developer base stable? Is it an active product that is releasing new revisions? Is the product widely adopted in the market place? Are a lot of other companies using it?
If you can answer "yes" to all these questions, then you would want to calculate the "buy versus build" costs. When you build software from scratch, then someone has to design and build all that functionality. The costs to build are not cheap. For example, if you tried to build a replica of Joomla CMS (a popular active open source application) you would be looking at 1000+ hours of development time to replicate what you can get off the shelf and install in less than 20 minutes.
Also, you have to integrate into your cost estimates how much time and staff you will need to maintain the application after it's built. Every time you want a new feature, you will need to have someone on your staff implement it. 3rd party/open source platforms typically have large staffs to build and test these applications to ensure they are stable. When you built it yourself, you would take on that responsibility and need to allocate the staff appropriately.
Don't forget the costs of security. For example, if you decide to build your own home-grown e-commerce cart you then take on all the responsibility for PCI-compliance with Visa and Mastercard. You have to get your own servers, you have to get your own staff to manage it. However, if you select and use a 3rd party platform, you push all these responsibilities onto the vendor. Yes, you spend a monthly fee for the 3rd party service, but you would save thousands of dollars because you're not dealing with PCI-compliance audits and additional staff.
Determine the cost/benefit of each approach and then decide.
BTW, I face the build vs. buy decision with my clients every day. Sometimes we decide "build" is the right choice. However, most often we decide to select a stable, reliable open source solution (or solutions) and build the rest of the functionality around those solutions.
Also, much of the time I find that the top open source applications are more stable and more fully functional than their for-pay counterparts. Don't always assume that the best platform is one that you have to pay for. Developers across the world contribute to the development of open-source platforms because they can't get or find something stable to meet their needs for a reasonable cost.
Claudio Luís V
Creative director, community builder, social architect, information designer, environmentalist, Drupal expert
We're very biased in favor of going third party or open source -- it takes the burden of maintenance off our backs. We're also keenly aware that we're a service company, and not a software company.
In reviewing our options, we usually use the following criteria:
1) How healthy is the organization putting out this product? I'd measure this in terms of the numbers of contributors, and how recently the application has been updated. You can smell an abandoned or poorly-maintained product pretty quickly.
2) How popular is the product? You're best off if you place your bets on a product that's going to be in the mainstream a few years from now.
3) How well does it work in your environment? Does it take a huge configuration effort, and does it place nicely with others? This aspect (sadly) takes longer to figure out.
We're finding that we're rarely the first running into a problem or wishing for a new feature, especially in the open source community.
Often, finding the right solution is mostly a matter of coming up with the right search string. It really does pay to spend the extra time searching and being *very* creative with your search terms. An extra 5 minutes of searching can save you hours or days of development.
More Answers (4)
It's important to weigh the age and reliability of the application against how dependent your company is on it. You wouldn't want your business to depend on a product that may not work or be around very long.
In my opinion, very important is the amount of active users/developers/bugfixe(r)s on the dev list of the opensource project you want to use. The same counts for the speedrate/quality of updates & bugfixes.
Hi Smith,
I usually check the following list:
1. Is it fulfilling all my requirements.
2. How active is the development, how often they are updating, providing bug fixes, releasing new versions etc.
3. Is the product is well maintained.
4. How much active is the community/ popularity of the product.
5. How much effort is required to integrate it with my project (It can include analysis, development, training, maybe recruiting new staff, maintenance etc).
6. If it is a third party service then will the service be able to handle all the traffic/requests made to them.
7. If it is a third party service then what is the uptime or is there any downtime involved.
Regards,
Gaurav
Clarification added December 3, 2008:
Hi Christopher, Sorry for the first line. By mistake I have used the incorrect name.
David K
Java/J2EE Principal Software Engineer at Litle & Co.
Best Answers in: Software Development (3), Starting Up (2), Business Development (1), Business Plans (1), Enterprise Software (1), Web Development (1)
You have to consider the licenses of the acceptable options. There's a vast array (over 100) popular open source licenses, each one having an interesting twist that can make your use of the software smooth as silk, or mired in legal issues. The wrong decision limit the deployment possibilities of your application.
How much this matters to you is partly dependent on the nature of the transaction between you and your customer. If you must had over all source code, you better be using a license like BSD.
I'm not sure if this was mentioned yet (since i can'
