The original piece is a mixed bag. Some points are very sensible, such as valuing coding-focused and non-coding contributors equally, and not concentrating on market share to the point of taking share away from other FOSS projects. The author takes a puzzling dislike to time-based releases, though (release schedules where a release is made after a fixed time span, every 6 or 12 or 18 months):
But, for whatever reason, increasingly, large FOSS projects are acting more like commercial software houses. Fixed release schedules, for example, have become the norm for many projects, including GNOME, Ubuntu, and Fedora -- regardless of whether a new release is needed. ...In some cases, borrowing ideas from commercial development may be useful. Yet it should never be forgotten that, while FOSS can work with commercial development, its goals are different. What happens, for instance, to the open source idea of only releasing software when it is ready when a project commits to regular releases? Sooner or later, problems in quality control will be inescapable.
I don't see why time-based releases necessarily entail a decrease in quality. Yes, the development team might be sloppy or unlucky, but it seems unlikely the pressure to issue a release on time would cause too many corners to be cut.
FOSS projects can delay their release much more easily than a commercial project can, because the commercial project is constrained by external forces: marketing plans, the need to have a final release by Christmas or by a tradeshow, the company's burn rate, etc. FOSS projects can be driven by external deadlines too, such as a distribution's release plans or a conference, but most of the time free software projects can delay release as long as they like.
For large projects, I think time-based releases become an utter necessity. When a project is new and relatively small, you can make a new release once a particular set of features has been completed, and can even draw up a roadmap of planned releases that maps to the new features in each release. But when a project gets larger, there are more possible things that people can work on, and people won't do them in sync; instead one project will be starting while another is wrapping up.
Without drawing a line and setting a target date, the natural pace of development will never converge to a stable state. Scheduled releases force the developers to stop introducing new things and to stabilize the existing code.
For example, in Python there are many standard library modules that can be worked on, and getting one of them to a releasable state will take a certain span of time. I think many large projects, such as GNOME, KDE, and Ubuntu, must use time-based releases. There are many individual GNOME and KDE applications, and it's impossible for a large developer group to agree upon which applications are "significant" and worth delaying a release, which ones are unstable or not, etc. Consensus on when to release would be impossible. A schedule forces you to release something. There will always be bugfixes and new features that just miss the release window, but that's all right, since there's another release just down the road.