I'm reading Robert Glass's "Facts and Fallacies of Software Engineering". He presents Fact 19:

Modification of reused code is particularly error-prone. If more than 20 to 25 percent of a component is to be revised, it is more efficient and effective to rewrite it from scratch.

Then in the discussion of that fact:

Note that this same problem has interesting ramifications for the open-source software movement. It is easy to access open-source code to modify it, but the wisdom of doing so is clearly questionable, unless the once-modified version of the open-source code is to become a new fork in the system's development, never to merge with the standard version again. I have never heard open-source advocates discuss this particular problem. (One solution, of course, would be for the key players for the open-source code in question to accept those in-house modifications as part of the standard version. But there is never any guarantee that they will choose to do that.)

Let me express that in bullet points, in a slightly snarky manner:

  • Open source gives you access to source.
  • Modifying that source is therefore easy.
  • This results in a fork that you have to maintain.
  • There is no guarantee upstream will accept the change.
  • Open source loses.

Well, duh. If you're going to be making modifications to upstream code, and upstream does not accept them, of course you're going have to maintain those changes yourself. It doesn't matter whether it's open source or not.

However, even though there is no guarantee, if the change is sensible, well made, and relevant to others than you, most upstream projects will accept the change.

In fact, the very reason open source flourishes is because upstream routinely, frequently, nay incessantly take changes others have made for their own purposes and incorporate them into the upstream code base.

It's not unheard of that a proprietary project will accept patches from its users, but since those patches are so hard to make, and all sorts of licensing issues and financial considerations come into play, it's hard, and therefore rare.

This sounds to me like Glass either does not really understand open source software development, or is spreading some FUD about it.

Update: In fact 34, in the context of using tools such as coverage testers, Glass discusses Linus's Law, "given enough eyeballs, all bugs are shallow", as follows:

Open sourcers expect that users of their software will read and analyze it, thus finding the errors themselves.

This is a subtle, but possibly poisonous distortion of the law. The poison is in the implication that every user of free software is expected to participate in code reviews and debugging, which is tedious and time-consuming. That is not at all the case. Instead, only if users want problems to be fixed are they expected to do anything, and the expectation is to report the probem, and provide sufficient information to find the cause.

It is entirely true that this only works for popular projects. Unpopular projects do not benefit from Linus's Law.