The point that struck me as the most insightful was the disconnect between the need of a company to ship a product on schedule, and the need/want to get code accepted upstream.
Some of this is unavoidable; development and research are essentially unpredictable, and the risks can be only reduced but not eliminated. But once shipped, the effort required to converge with upstream - a group that, as in the Android wakelock case, might insist on a completely different architecture - can become prohibitive, and only increases over time.
I have no solution, but I think its an important problem for the community to ponder.
Perhaps certain kinds of forks - "additive" forks that just keep adding code, but rebase periodically and are actively maintained locally - aren't as bad as others that truly and massively divide the community.
There was also the point of "toxic" individuals during code review phase, which can be off-putting. And, at least in discussion after the keynote, the observation that there is some nepotism at work, which reduces the efficacy of the meritocracy. Your humble commenter wonders if, similar to auditioning for many jobs or academic peer review, anonymizing the code submission and review phase would be worth considering.