13

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).

Cons:

  • 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?

Mr. Jefferson
  • 1,361
  • 1
  • 11
  • 19
  • 15
    ASP.NET and it's stack is open sourced. – Andrew T Finnell May 30 '12 at 02: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 '12 at 05:15
  • 5
    @AndrewFinnell: Not by the FLOSS movement's own definition. – tdammers May 30 '12 at 06:19
  • 6
    wrt the specific OS project you are thinking about, it may be of interest that Dapper is used by StackExchange... – Marjan Venema May 30 '12 at 07:01
  • 1
    [Here](http://forums.asp.net/t/1792276.aspx/1) a few useful comments about Dapper and Entity. – Avio May 30 '12 at 08:29
  • 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. – ctrl-alt-delor May 30 '12 at 11:01
  • 1
    @AndrewFinnell, tdammers: That is why the term Free Software is easier to understand. Free as in freedom. Freedom to run, study, distribute, modify. Open Source is basically the same, but harder to understand or explain. – ctrl-alt-delor May 30 '12 at 11:13
  • @richard I originally said OS not FOS. Even that definition has issues though. The Mono team has been able to easily and legally take the ASP.NET stack and use it in Mono. – Andrew T Finnell May 30 '12 at 11:29
  • 2
    @richard - MFC is still very much part of the Microsoft universe - http://blogs.msdn.com/b/vcblog/archive/2012/03/05/10278210.aspx. Hardly dead. It's actually a good example of how a sensible public company can keep supporting an old, closed-source, non-free, and by many analyses "bad" technology if the demand is still there. – Joris Timmermans May 30 '12 at 12:18
  • 1
    @AndrewFinnell, not all of ASP.NET is open source. According to [asp.net/open-source](http://www.asp.net/open-source), only ASP.NET MVC, ASP.NET Web API, and Razor are. – Matthew Flaschen May 30 '12 at 22:53
  • 3
    I don't have an answer here except for a small bit of advice: Just because Site XYZ is using a particular piece of software to run their site successfully, it doesn't mean they haven't had to tack on bits and pieces here and there to keep that piece of software from working incorrectly. –  Jun 04 '12 at 17:45

11 Answers11

20

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.

StriplingWarrior
  • 2,407
  • 1
  • 16
  • 21
16

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.

Andrew T Finnell
  • 3,112
  • 17
  • 18
  • 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. – Donal Fellows May 30 '12 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?) – Donal Fellows May 30 '12 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()`). – Mr. Jefferson May 30 '12 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.) – ctrl-alt-delor May 31 '12 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. – Andrew T Finnell May 31 '12 at 12:27
14

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 '12 at 05: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? http://www.microsoft.com/opensource/directory.aspx – ONOZ May 30 '12 at 07:09
  • +1. I tend to agree to many of that arguments. However, I think one should not overgeneralize this to "every open source project". Using a specific open source component can save you a whole lot of time and money, if you accept that you might have to do some maintainance on your own. Especially when there are no closed-source alternatives available, affordable, or the alternatives are from a small vendor from which you don't know if he still exists in 2013. – Doc Brown May 30 '12 at 07:29
  • 14
    I don't agree with a single word that you have said. – Avio May 30 '12 at 08:11
  • 1
    …Using a specific open source component can save you a whole lot of time and money, if you accept that you **can** do some maintainance on your own… – ctrl-alt-delor May 30 '12 at 11:05
  • @richard: yes, you are right. I should have written "that you most probably **must** do some maintenance ..." ;-) See my answer below. – Doc Brown May 30 '12 at 12:26
  • +1 You make good points and you're arguments are valid. However you should have put the qualities of Open Source for you to be partial. But the last sentence says it all : My personal consensus: stick to Microsoft. – lollancf37 May 30 '12 at 12:40
  • Everything you say is very compelling and convincing, but says nothing whatsoever about Microsoft. What about Apache Software Foundation projects? – Mitch May 30 '12 at 13:54
  • 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 '12 at 14:12
  • 2
    IMHO, the fact that Microsoft maintains many open source projects (including some widely used and high quality ones, like ASP.NET MVC) weakens your argument. – user16764 May 30 '12 at 14:27
  • 1
    This answer is (somewhat) applicable for the .NET realm, but quite false in almost all others. – Nate May 30 '12 at 15:31
  • 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. – Gort the Robot May 30 '12 at 19:51
  • 3
    I think the important thing is this - if you use 3rd party code, either commercial or open source, then ensure that it has the _appropriate_ level of support for your application before you come to rely on it. – JohnB May 31 '12 at 08:31
  • 1
    I don't really agree, while a very convincing argument, it is based on the assumption that if you choose a commercial software technology you will be given support by the company selling the software. Well companies can go away - the mainframe companies like DEC are a prime example. They can also simply stop supporting the software like Microsoft with IronRuby or even Silverlight. Ultimately the only maintenance and support you can trust is your own ability to fix issues and that's easier with open source IMO. – Nikhil Jun 05 '12 at 09:29
  • And this is good. If software is bad, the company risks to disappear. Bad sotware must die. Even more often, company survives, but closes particular software projects, or sells the ownership, to it is going to escrow company. If software is good, the company can be taken over by larger company in hostile way. And so on. It is all good. And again, bad software - must die. It is less happening in open source, and I am trying to explain why. –  Jun 05 '12 at 11:24
  • Did you know you can still buy Word Perfect? Lotus Notes? That AOL's Instant Messenger uses proprietary protocols and someone is out there developing it for ipads? Old IP never dies, it merely gets sold off. Bad, unused, open source software likewise gets abandoned, but you can still get it. – Philip Jun 14 '12 at 17:01
7

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.)

Gort the Robot
  • 14,733
  • 4
  • 51
  • 60
7

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.

sourcenouveau
  • 6,460
  • 4
  • 29
  • 44
6

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?

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
  • 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 '12 at 13:35
  • Even if performance is less of a concern, the EF gives me less control. Introducing caching [is a bit harder](http://stackoverflow.com/questions/1147681/how-to-make-entity-framework-cache-some-objects) 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. – Mr. Jefferson May 30 '12 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. – Mr. Jefferson May 30 '12 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 '12 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. – StriplingWarrior May 30 '12 at 19:15
2

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.

Mike Dunlavey
  • 12,815
  • 2
  • 35
  • 58
1

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?

Turnkey
  • 1,697
  • 9
  • 10
0

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.

linquize
  • 1,150
  • 1
  • 11
  • 20
0

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.

Nemanja Trifunovic
  • 6,815
  • 1
  • 26
  • 34
-1

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"

mattnz
  • 21,315
  • 5
  • 54
  • 83
  • 5
    Ironic then that IBM is probably the worlds biggest seller of Open Source based software. Apache http server, Eclipse etc. etc. – James Anderson May 30 '12 at 01:52
  • IBM does not sell open source software (that would be illegal). It sells software products build on open source programs. Take Redhat - you can get exactly the same software as Redhat for free, but many people buy Redhat Linux -Why - because Redhat Linux consists of a software product consisting of a Linux distro, a support package, a hardware and software validation service etc.... – mattnz May 30 '12 at 05:04
  • 7
    Selling OSS is not illegal. Why would it be? – tdammers May 30 '12 at 06:23
  • 1
    IBMS httpServer is pure apache, it just comes with a support agreement. – James Anderson May 30 '12 at 08: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 '12 at 08: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 '12 at 13:37
  • Some people would agree that there is always a "moral" obligation to contribute back to the community. But some communities like BSD reject this idea (even as a moral concept) and leave it up to the reuser. Anyway, companies tend to be more concerned with the law. As you noted, some licenses are *legally* copyleft; others aren't. – Matthew Flaschen May 31 '12 at 16:03