Vendor Lock-In Vs. Best Of Breed Tools

I posted the bulk of this on the Albacore group as a reason for my wanting to take Albacore down to it’s “core” as a suite of build related tasks (which I talked about in the Preview1 post). However, I thought the information was enough to warrant it’s own post on my blog… so here it is: why I think best-of-breed tools that you tie together yourself tend to be better than the all-in-one vendor lock-in approach.


As a .net developer, I’m used to seeing the "all in one" solutions being handed to us by various vendors. Microsoft gives us Visual Studio, they give of Office, they give us Team Foundation Server. Telerik gives us UI controls for WinForms, Web, WPF, and even an ORM and test framework. Oracle provides a database engine, business rules / erp system and much much more. It’s the nature of software-as-a-business model, to a certain extent – at least in the .NET world. Vendors want you to use their tools because they need to make money. So it makes sense for every vendor to offer complete solutions that work well with their own items. You see a lot of integration and interop between the products that one particular company produces.

Unfortunately, this has a ripple-effect into the open source efforts in .NET as well. There tend to be a lot of the same things being done by many different people because everyone expects to see a one-stop-shop for the things that go hand-in-hand.
In the ruby world (and in the *nix world in general), you don’t see this very often, if at all. You see many individual pieces being put together to create something that is larger than the sum of the individual parts. Many of the small pieces that one large system uses will be pulled from many different vendors, and each of them will do their one specific thing really really well. Look at Rails3 for example. There’s the core of Rails, but there’s also the direct use of Thor, the SQLite integration, the Test::Unit and RSpec integration, the Rake integration, etc. There are so many parts of what Rails is that most people outside of the ruby world tend to think that Rails is the only thing that ruby does (yes, I have heard people say things close to this).

Looking back at my development experience, I’ve been exposed to both worlds – the vendor lock-in world and the best-of-breed world. At this point in my career, I prefer the many-tools, best-of-breed approach. I’ve done the whole vendor-lockin thing with one stop shops and it has burned me more times than i can count. There are inevitably issues that I have with the toolset and/or things I want to do that the toolset just can’t do, and I’m stuck. I am using the tools that don’t do what I need and often can’t do anything about that. Having taken the other approach in the tools and vendors that i choose over the last 4 years or so, I find it to be overall better. Instead of locking me into VS+TFS and the "one microsoft way", for example, I found subversion + trac + apache. Later, trac no longer served my needs so i switched to redmine. When that no longer served, I dropped trac and apache and went to VersionOne (letting them host it). Now that subversion is no longer fitting my needs, I am in progress of dropping it for git.
The best-of-breed mentality and capabilities of many small pieces gives me flexibility and control in situations like this.

Now this doesn’t mean that I won’t choose a vendor simply because they are an all-in-one package. There are times when that package is going to be the right tool for the job at hand, and those tools should be consider and used when appropriate. The point I’m making is that when you do select a tool – any tool – be sure that you are selecting the tool that fits your needs for what they are, and be sure to find tools that allow you to change according to how you need to change. Chances are, the big all-in-one tool (like TFS) is not going to be sufficient for every one of your needs unless you are willing to bend your needs to what the tool can do. And that, quite frankly, is the wrong thing to do. A good selection of the best-of-breed tools may take a little more time to set up and learn, but it will likely pay for itself in the long run when you are able to replace one or more pieces to keep up with your team’s needs.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs - the amazingly awesome podcast audio hosting service that everyone should be using, and where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in Continuous Improvement, Pragmatism, Tools and Vendors. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Henning Anderssen


    To bad many companies don’t see it that way. My company is at a small crossroad now. Either pay for a TFS license or go for git. I fear they see git as being to complicated and hard to use. The “why chose git when I get everything from tfs” argument, except you don’t get everything or you get too much.

  • DaRage

    Best-Of-Breed gives you better tool but you will have to pay the cost of learning, customization and integration.

    I used CruiseControl/Nant/MSbuild for a build server and I found that I took me a lot of time to configure/tweek but I got it to do exactly what I want.

  • Alexander DiMauro

    I love Rails, and I tend to agree with you up to a point. But, what you say is changing. ASP.NET MVC locks you into nothing. It’s just as (if not more) extensible than Rails. The number of open source tools that you can use with it is growing at a rapid pace. I’ve even developed MVC apps on Linux with Mono.

    The whole VS+TFS all in one environment really targets enterprise apps, not day to day coding by OSS developers. That’s why the prices are so high. But, for the rest of us, Microsoft even has free versions of VS, you can use NHibernate, NUnit, Moq, StructureMap, Ninject, Caste Windsor, Rhino Mocks, MbUnit, XUnit, and on and on…and do it all on Linux, if you want.

    So, I think your argument is only valid on the enterprise level. Then again, enterprises probably appreciate more the all in one solution, because it makes getting support that much easier.

  • @Alenxander – i agree with your notes about mvc and the general list of OSS tools you listed.

    i don’t agree with your portrait of ‘enterprise’ development, though. i’ve done nothing but enterprise development for the last 10 years. multi-million dollar contracts for federal, state and local government, millitary contracts, large scale commercial work for top tier home loan / mortgage companies, logistics and asset tracking, etc. i’ve also done plenty of one-off, small scale apps for various needs, down to a few thousand dollars.

    my statements above reflect the needs that i’ve encountered in all of these efforts. of course, that’s only my experience and perception. i know a lot of people who wouldn’t use anything but TFS even for the smallest of projects they work on.

    @DaRange – agreed. the cost of learning is usually higher, but i believe it pays for itself in the long run.

    @Henning – good luck with that. i hope you are or have an influential person with the experience to back up the choice to use git on your team. :)

  • Alexander DiMauro

    At work we have TFS 2010, and it’s not so bad for the big projects. Of course, it would be overkill for my work at home, where I tend towards Hg. Yes, I agree that some people are scared to pry themselves away from their all-in-one environments. Especially companies, when the tech support comes bundled together. It’s kind of a safety net, psychologically at least.

    I’ve been trying to expand my horizons as much as possible, but there are only so many hours in the day. It takes time, and there can be some major stumbling blocks along the way. In the end, I know it is making me a better programmer. But, for a company, experimenting is not always an option. That’s why I’ve been using ASP.NET MVC at work. They get to keep their Microsoft stack, and I get to keep at least some of my sanity!

  • weijiajun

    @Alexander, I agree with some of the idea of Enterprise development. Larger companies with deep pockets like to go with the “known” way of doing things, and generally shy away from open source. Now this isn’t always the case, but in my experience this is commonly the way people do things.

    I also think that beside the company there is also the issue with developers who don’t really keep up or go out of their way to get better at what they do, they tend to “go with the flow”. In those places it is hard to use some of these ‘Best of Breed’ tools as they are only as successful as the developer who is willing to learn to use them correctly. And so tools that require the extra learning, which Best of Breed tend to, are usually quickly shunned from such environments.

    @Henning – I am also facing the same issue, we are using SVN right now, but some of the management wants to move to TFS for the integrated bug/feature tracking inside of VS. I was using git-svn for a while, and have since moved to hg, but am having a hard time getting any of the developers here to try it out. I don’t really know how to convince anyone this is a better way to go when I am the only one who is even trying it. If you end up being successful in getting your company to move to git, I would love to hear how you did it.

  • I like this article and I tend to agree that like using many individual pieces concept. There are many reason for this but I will only list two. For one using small pieces allows you to replace things easily. Using many pieces you rarely loose track of what the purpose of the tool is. This approach also allows us to experiment and play with the different pieces allowing us to discern some very important concepts about software development.
    I know things like using MVC have allowed to see all the separate pieces of an application – validation, data access, business logic – cleaarly. The way MVC allows you to plug in different tools and let those tools handle their own specific tasks such as data access, validation, testability, it furthers your understanding of the different aspects of the full system in isolation from the other areas. Same can be said of individual tools.