What are the costs/benifits of one method over the other?
However, as the diff becomes larger, the tradeoff shifts. I think we passed that point a while back but, since we were going to switch models anyway, I took some time to clean up some bits of the code too.
With your own patches you know exactly the reason and intent for each one - you wrote it! So you can rapidly figure out what to change to make them fit with the new release.
But in reverse you are going to have to grok every new change sent your way, and that it going to be a massive amount of work.
Some of it will be easy stuff: It's clear what they are doing, or it patches cleanly and you don't worry about it.
But then you'll run into more confusing changes and you're going to have a harder time. There is a human tendency to ignore that which you can not understand, and you'll have some of those, then a patch on top of them, and the final result is more work than you started with.
Are N+1 heads better then one?
The group is better then the average head.
Heads are worse then the best head.
I do not know however if Google makes reviewing the patches more time intensive then it should be, it all depends on the rate of progress, isn't it?
The downside is that you may miss some upstream changes that you do care about.
1. a lot of attention to its security
That doesn't help if bug reports rot in the tracker for years. The developers' attitude might have changed under the current media attention, but for how long will that last? I have yet to read a public statement by the OpenSSL team on how they plan to improve code quality and processes in the long run.
2. a not insignificant increase in much-needed financial support
Even before Heartbleed, OpenSSL might not have been as poor as often reported:
Again, I am too much of an outsider here to judge, I just want to add these points for consideration.
I realize LibreSSL is optimized for BSD and Google is primarily Linux, but it seems silly to fork the code in 2 different directions.
But we’ll also be more able to import changes from LibreSSL and they are welcome to take changes from us. We have already relicensed some of our prior contributions to OpenSSL under an ISC license at their request and completely new code that we write will also be so licensed.
What's great about this, though, is that Google's contributions are potentially helpful in LibreSSL's eventual cross-platform porting efforts; their willingness to adopt the ISC license for their contributions is already a promising sign of that collaborative potential.
It is a mix of code from OpenBSD, NetBSD, and FreeBSD 
"i maintain Android's C library which, as you may know, contains a lot of OpenBSD code. i've been working to clean up our mess and get us back in sync with upstream, and currently have 173 files that are exactly the same as current upstream OpenBSD. (more than we have from the other two BSDs put together.)"
I mean, it's not like Apple's going out of their way to make Aqua work on non-OSX unixen, or systemd's going out of its way to work on non-Linux unixen. Just like how those rely on features of their host platforms, LibreSSL currently relies heavily on OpenBSD-specific security features in the kernel and userland, and it'll take quite a bit more effort to port that to other platforms in a secure and correct way.
Now granted, I'm an OpenBSD user, so my opinion on this is biased. However, it's the same opinion that many Linux-specific or BSD-specific or OSX-specific or Solaris-specific or Windows-specific or VMS-specific or MULTICS-specific or what-have-you-specific projects seem to already have: focus on your primary target(s), then help with porting efforts to secondary targets when it works well on the primaries.
I think the "safe" (EC)DSA nonce implementation is interesting but could use some review, and I've communicated that to the author: it's not as good as the proposal in RFC6979 (which uses HMAC_DRBG - which is good - to generate a truly deterministic DSA nonce, with test vectors and everything!). In particular, BN_generate_dsa_nonce from these patches uses modular reduction down into the prime order, which has a small bias towards 0 of course. The NIST prime orders aren't as close to powers of two as you might like to get away with that, and if I'm being honest, I'm not sure you can get away with anything with (EC)DSA - it is extraordinarily fragile in a way I think was always deliberate. The practical impact is probably limited, but I really don't want to take any chances there. (Ideally I'd want Ed25519, or something very like it - there really ought to be some more discussion on CFRG about that - although it's going to be quite some time before anyone can roll it out in certificates widely.)
Right now, it's still lipstick on a pig. OpenSSL is hairy as fuck. Long-term, I think the LibReSSL cleanup-via-demolition approach and then carefully rebuilding what's left over is what's needed. But I'm not sure I'd want to run LibReSSL in the middle of such fundamental reworking - and in the meantime, some of these patches look quite familiar to me. :)
1. https://tools.ietf.org/html/rfc6979 - Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)