I'm looking at using some open source code in my ASP.NET web app (specifically dapper). Management is not a fan, because open source is seen as a risk that has bitten us before. Apparently previous developers have had to rewrite things after having open-source components fail.

The pros seem to be:

  • It does a lot of stuff for me that would otherwise involve either lots of boilerplate code or Microsoft's recommended but slower solution (Entity Framework).


  • It's complex enough that if it were to fail suddenly in production, I would be hard pressed to fix it. However, it's in use on a much higher-traffic site than mine, so I don't think it'll end up being a high risk portion of the project.

What is the consensus here? Is it unwise to use open source code in my project that I don't know/understand as well as I do my own code?

  • 15
    ASP.NET and it's stack is open sourced. May 30, 2012 at 2:10
  • 11
    "Is it unwise to use open source code in my project that I don't know/understand as well as I do my own code?" As opposed to closed-source libraries that are black boxes?
    – user16764
    May 30, 2012 at 5:15
  • 5
    @AndrewFinnell: Not by the FLOSS movement's own definition.
    – tdammers
    May 30, 2012 at 6:19
  • 6
    wrt the specific OS project you are thinking about, it may be of interest that Dapper is used by StackExchange... May 30, 2012 at 7:01
  • 4
    This is not a technical question, it is not about which is better. Which one will go wrong. MFC is dead, XP will be dead in less than 2 years etc. Free and opensource project won't die if they are any good, as you or someone else can take them over. This is about who will be blamed. If you choose Microsoft, if will be unforeseen, or Microsofts fault. If you go for Free/opensource it will be your fault. May 30, 2012 at 11:01

11 Answers 11


It's a choice that you'll have to make based on the specific circumstances. You can mitigate your risks by:

  • testing the framework thoroughly, avoiding the likelihood of nasty surprises biting you in a production environment, and
  • using loose coupling to minimize the amount of code that depends on the framework directly, so you can change to your own implementation if you have to without rewriting your entire product.

Ultimately, with a heavily-used open-source project you're likely to spend a lot more time writing your own than fixing the few issues you run into.


I'll go as far as to say that if your initial reaction is to write something yourself instead of seeing if someone else has written it, you're doomed to fail. Don't take lightly all the man hours and bug fixing that has gone into the mainstream open source projects.

Once you start getting into your business domain you'll be more hard pressed to find OSS that meets your needs. But there is no need to re-implement yet another ORM product. If dapper is complex enough that you wouldn't be able to debug and fix their code how would you justify spending all the man hours writing it from scratch? Besides, you could (should?) always look outside the box at NoSQL solutions while your at it.

Even Linus admitted he attempted to find a SCM solution that met all his criteria before developing Git. At least he was able to explain why none of the existing solutions were good enough.

At some point in my life I stopped wanting to rewrite everything myself and wanted to focus on solving real world problems. Most of the problems that need to be solved in a business are domain specific. Find ways to write less code not more.

  • 2
    +1 I agree with all of that except for where you say he “(should)” look at NoSQL; each NoSQL data storage solution — there are many — has a particular set of trade-offs w.r.t. a “standard” SQL relational database, so it's difficult to say “should” without a lot of information. Sometimes those are good trade-offs, and sometimes not, but you can't make blanket statements about it. “NoSQL” is just branding rubbish around a bunch of technologies with little in common other than not being the most common data storage scheme. May 30, 2012 at 12:53
  • But everything else you write, I definitely agree with. Good OSS takes a lot of effort off the ordinary working developer's shoulders (and who would want to use bad OSS?) May 30, 2012 at 12:54
  • Dapper is complex because it's generalized. If I were to write my own solution, I would do a lot of boilerplate dataset-to-objects conversion code (i.e. MyClass.Property = set.Tables[0].Rows[i]["Property"].ToString()). May 30, 2012 at 16:34
  • Once you start getting into your business domain you'll be more hard pressed to find --OSS-- anything that meets your needs. Unless Microsoft's business is your business. (but I like the rest of what you said.) May 31, 2012 at 11:38
  • @richard Some of my Answer may be unclear. Your statement is what I am also saying. Why focus on the pieces that have been solved time and time again like ORM. Focus on the Business Domain. ORM is not business domain unless you are selling a ORM product. May 31, 2012 at 12:27

Note: I am not Microsoft employee. The opinion is completely personal. Many thoughts are from last 5-7 years of using both open source in mix with large vendors as developer.

Monoculture is good: My personal rule for ASP.NET is to give preference to Microsoft and do not choose 3rd party code (open source or not) unless there is no other choice. Monoculture is rewarding, because you are being carried by big vendor, and quantity of users repeating the same experience is any time large enough to get help and find workaround.

Ghost towns: The problem with open source in 2012 is that it is not 2000 or 2005 anymore. Quantity of projects keeps growing, when quantity of users, adoptions, contributors is about the same as years ago. The audiences are stretched thin. Many interesting projects became stale, abandoned. There is no such thing as open source project budget. So when interest ends, there is nobody to honestly announce that support is over and shut the lights off. The projects never die to leave the public attention focus to something better and new. So open source will always keep growing and fragmenting. Having no feedback in form of monetary reward or financial death they are undying entities, existing for the sake of eternal glory.

20 degrees of separation: Every your adoption of new library separates you from mainstream, shifts you to minority of edge cases. After having 20 steps like choosing security configuration, using particular version, framework, plugin, etc. Your solution becomes a single globally unique combination of details. Googling will help only to proove how rare or unique the problem is. It is always some self serving problem, purely technical. Never even relevant to real business.

Quality comes from focus, money is irrelevant: There is no stand off of commercial software vs open source. Whole community of devellopers is just one community as it always was. Large vendors simply have an advantage of aging the code longer, in better conditions, with broader audiences than open source groups.

Consensus: You asking if there is consensus. Possibly not. Unfortunately large amount of open source users are way too politicized. After all the open source is a social movement. Open source is immune to critique, because very often negative opinion will be perceived as anti-technological, personal attack. My personal consensus: stick to Microsoft.

  • 3
    +1: I can't say I agree entirely, but its too well argued not to.....
    – mattnz
    May 30, 2012 at 5:10
  • 14
    "There is no such thing as open source project budget." is untrue. Google hás a budget for open-source projects, and Red Hat Inc. for example can't run their business if they don't put enough coders on their software. And what about this? microsoft.com/opensource/directory.aspx
    – ONOZ
    May 30, 2012 at 7:09
  • 14
    I don't agree with a single word that you have said.
    – Avio
    May 30, 2012 at 8:11
  • 11
    All of these points apply equally to closed source projects. Adding niche closed source libraries/frameworks adds diversity. Old proprietary tech is abandoned if it doesn't make them money. You can still configure IIS to be it's own unique butterfly. The quality comment ignores that open source project can be bigger than (some) vendors. And the business world is highly politicized, especially with Microsoft.
    – Philip
    May 30, 2012 at 14:12
  • 3
    I've had the opposite experience. We ported SQLite to a device and were able to get support directly from the guy who wrote most of it. There's no way we'd have gotten that level of service from closed-source company. Some open source projects are absolutely more robust and have better support than some closed source projects. I could tell a story about using the "industry standard" Microsoft C++ compiler for OS/2 and how the support for that went when Microsoft decided to bail on OS/2. May 30, 2012 at 19:51

I've worked on a number of successful projects for a large company that used substantial bits of open source software. In particular, I've used Curl, SQLite and Webkit all for a very large company on successful projects that shipped to end users. As others have said, it's just a matter of being careful about licenses and ideally having a lawyer look them over.

There are hundreds of open source licenses, but generally they fall into two categories, BSD style and GPL style. BSD style licenses don't require you to open source your own code, and generally just have some sort of attribution clause. GPL style licenses do require you to open source your own code. Most companies (including mine) generally look askance at that so you'll want to avoid GPL style. Dapper appears to use the Apache license, which is BSD style. Always figure out what the general license terms are before you start coding.

There's also the LGPL, which is an interesting border case in that you can use these while not opening your own code if you restrict access to a binary boundary. (I.e. access the library only as a dynamic library.) LGPL library usage is very doable, you just have to be more careful.

In my experience, open source code is no more likely to turn out to be buggy or fail than for-pay solutions, or, for that matter, roll-your-own solutions. If you look at some of the more prominent open source tools, the quality is very high.

You probably do want to avoid projects that are small, or not complete. It can be tempting to grab something that seems to meet your needs, but if they were something put together by a couple of people, never completed and unsupported, it is probably not worth the effort. (Unless you are willing to work on the code directly.)


Haven't you ever had proprietary components fail before? I've encountered plenty of bugs in software from companies big and small. This issue is not a problem with open source per se, rather it is more about project maturity.

It sounds like you want to use mature projects that offer support. Some open source projects offer paid support, or have a large enough community that you can get answers in a public forum. Maybe you should make maturity and support criteria priorities when choosing a library, whether it is closed or open source.

You need to acknowledge that you're taking on more risk if you decide to use an immature project, or one with limited support. As such you need to determine what your risk mitigation plan is. You might perform more testing on the third-party software, for example.


Assumed the licensing issues are no problem here: having a quick look at Dapper, I noticed it had just 2255 line of well-documented, readable code. That is

  • big enough that you can invest several days or weeks to produce code of comparable quality doing the same
  • small enough that you can understand what it does and fix any bugs in that code if they appear in production

If you are going to write something like that on your own and "reinvent the wheel", you have a much higher risk that your own code will show up bugs in production, and you will be really "hard pressed to fix them" either.

What you have to do here, however, if you introduce such a piece of open source into your project, then you have to take the full responsibility for that code, just as if you had written it by yourself. Make sure the code is in a state you can maintain it, if necessary. Don't blame "the authors" of that code if something does not work as expected.

In one of our projects, we, too, introduced some open source components, from sizes small as Dapper to libraries which had around 20K to 30K lines of code. We had always to make some changes, fix some bugs, downsize something etc., but that was ok, since we expected that. Even the time for the debugging included, using open source saved us a lot of work.

One thing to think about here: in your case you mention that there is a broadly accepted alternative from a big vendor available (MS Entity Framework, for which you don't have to pay any extra license fees!). You don't want to use it because of performance considerations. I seriously recommend not to let performance be the only or primary point to be considered. The questions you should ask here: has Dapper all the functionality you need now and for the expected lifetime of your software? Or can you foresee that you will reach the limits of Dapper quickly, and you will have to add a lot of missing functionality around it, what you probably would not have to if you had decided to use EF in the first place? If the latter is the case, I would recommend not to use Dapper. Also ask yourself: is EF really not fast enough for your application, whilst Dapper is?

  • 1
    +1 for licensing issues. Check carefully that using some open-source component won't force you to open-source your own code too. I don't believe this will be the case for most open-source, and if you're just using it to produce or host your code there will be more available, but worth checking nonetheless.
    – Lunivore
    May 30, 2012 at 13:35
  • Even if performance is less of a concern, the EF gives me less control. Introducing caching is a bit harder if it becomes necessary down the road; Dapper would be easier to fit into a more custom solution, in addition to pushing the necessity of caching further down the road in the first place. May 30, 2012 at 16:37
  • On the other hand, wanting a custom solution over the EF sounds a bit like NIHS. My data schema is quite complex with lots of relationships (foreign keys), and getting to the point where my custom solution manages those relationships as well as the EF would out-of-the-box would certainly take a while. May 30, 2012 at 16:45
  • @Mr.Jefferson: seriously, I cannot give you a good advice what is the better solution in your case, that is something you have to work out on your own. I was just trying to give you some hints what to consider.
    – Doc Brown
    May 30, 2012 at 16:59
  • +1. You brought up some very excellent points with this post. @Mr.Jefferson: I've been using Entity Framework for some time now, and have been fairly successful at managing performance via ad-hoc caching on specific repositories after finding where the bottlenecks are. Also, our product is pretty complex, but I still haven't had to resort to writing a single SQL query. I feel that EF has given me plenty of control. May 30, 2012 at 19:15

As I see it, it's a balancing act.

If you make yourself dependent on a vendor, it's almost certain that support will disappear before long

  • Because they have programmers to pay, so they need to keep making new versions and making sure the old ones are impossible to get and no longer work (on newer platforms) so the new ones will have a market.

  • If they can't sell enough to justify a business model, they pass it off from company A to company B to C, each of which changes it enough so again, you can't use the new one without reprogramming, and you can't get the old one that works.

  • They just decide they will no longer support it because it's too much trouble and there's no money in it. All the money's in new apps.

So if you want to build something that doesn't have to be continually rewritten every few years, open source can be your friend.


I think it wise if sufficient due diligence is done and it appears that you've already done some homework with respect to the history and activity of a particular project. The ability to extend/add features in the source code is also a big pro. With sufficient testing you can minimize the risk on the con side. It is hard to completely understand all dependencies in your code, but at least in that case you will be able to fully debug and view the code if necessary.

Ask the management why it had failed before, was sufficient due diligence done?

  • I don't know much about what happened. It was before I got here. May 30, 2012 at 16:31

jquery has the option to use MIT license, so many commercial and government websites also use jquery. Microsoft's website use jquery too! So the concern is licensing. Avoid using GPL/LGPL is enough.

"How long to get a fix to a reported defect?" After reporting the bug, it may get fixed within minutes, hours, or days. For urgent situation, the staff may simply "git pull" to get the source and compile it himself. He simply report the version like "v1.2.3-101-gd62fdae" to the management, which is traceable.


Open source is really about legalities, not code quality. There are good and bad open source products, just as there are good and bad closed source ones. I believe your dilemma is whether to use a project developed by a community of volunteers.


Are you sure that managements problem are technical concerns.

I say this as mixing OS and commercial activity is a legal mine field, and more than one manager has had a "Please Explain" from the legal team / CEO or worse, from another organization. Most managers I know, even those that actively embrace OS software, are (rightly) very cautious to fully understand the legal situations they are exposing the origination to. If you adopt OS software and make changes, you are obligated to return those changes to the community. In some cases, this obligation is legal, in others moral. In some OS licenses, everything you do becomes OS just by linking to them.

From a technical viewpoint, it's really just a decision between competing products - Ask some basic questions - Can you get the support you need for the package you choose?, How long to get a fix to a reported defect, how much will it cost per developer, per year or one off etc. OS has lots 0's in the $ column, but often has blanks in the others - only you and your boss can decide is the 0's out weight the blanks or not.

And one other point to remember - "No one ever got fired buying IBM". (i.e. management speak for "If you spend a lot of money it must be a better product than one that is free"

  • 5
    Ironic then that IBM is probably the worlds biggest seller of Open Source based software. Apache http server, Eclipse etc. etc. May 30, 2012 at 1:52
  • 7
    Selling OSS is not illegal. Why would it be?
    – tdammers
    May 30, 2012 at 6:23
  • 1
    IBMS httpServer is pure apache, it just comes with a support agreement. May 30, 2012 at 8:20
  • 2
    Things are changing. Now management starts thinking that if you make the company pay for a component that other companies had for free, you are a dumbass.
    – Avio
    May 30, 2012 at 8:23
  • 2
    The "other columns" are rarely blank for open-source. You can always get support from consultants or distribution vendors or somebody and you can also support yourself. More columns are often blank for the commercial software, because you don't know the quality of their support in advance and it's rarely as helpful as you'd need.
    – Jan Hudec
    May 30, 2012 at 13:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.