The power of "no"

I believe minimalist approach is wrong and right at the same time. Wrong in it's incarnation, right in it's philosophy.

1) Do one thing, do it REALLY REALLY well.

being open source, other projects can take parts of your project and build on top of it to create a different projects (say you create a widget, and widgets have utility functions which are useful for creating sprockets, so the sprocket project depends on the widget project, but still remains it's own thing.)

Often the mentioned above fact can go overlooked "I can do it better" vs "what can I take away from that project to make a better one for my needs"

2) We still need the overarching giant featureful project. So if you create a bunch of tools which when working together can make a web framework, why not put some effort to make a good web framework that borrows from multiple projects?

As a response to the article: Create the Django Complete project. In it you integrate Django, migration, DB2 support (say a new project that gets started), The Django bar, but in the end you don't actually get the feature creep going into Django EVER to incorporate everything period. Instead you have multiple specialized independent projects, all meeting together in one project to make it better for the community.

One might be able to defend the proposition that proprietary money-free software gets worse and worse over time, and open source money-free software gets better and better, as does commercial not-free software. That pattern seems to hold much better, though there are still some exceptions. The apps that give software a bad name are the stupid "free" antivirus apps and Adobe PDF reader and other things that eventually turn into everything but rootkits in a desperate attempt to monetize by any means necessary.

(I'm only covering the end-user experience, not the question of whether you have a problem with updating your own apps written against free software.)

That strongly depends on which open source community you are dealing with. For instance I know people running Perl applications that I developed a decade ago without any changes on current versions of Perl. On the other hand I've heard that migrating Drupal applications to a newer version can be fun.

However there is similar variation within closed source. For example the AS 400 remained binary compatible for 20 years across multiple CPUs and even a migration from 48-bit CPUs to 64-bit CPUs. (And your applications still run today on IBM hardware, but they've changed the name.) However if you developed an complex application in VB 5 a decade ago, have fun porting it to any language supported by Microsoft today!

So backwards compatibility is orthogonal to the question of open vs closed source software.

As the author notes, there are many exceptions on both sides, and he's not claiming that it's impossible for projects with closed development models to improve; he's merely indicating that the way in which their software is developed lends itself to a final product of lesser quality (because developers are rushed to meet expectations set by other groups, like sales or marketing).

I think the analogy is most relevant in the case of well-matured and widespread software. Microsoft has an incentive to continually release new versions of Office (namely, there will always be many people who will buy new versions of Office), and because people don't like to pay for bugfixes, there has to be new features to print on the box. Furthermore, these features must seem relevant to your average user.

"Mature" software almost by definition includes the standard featureset its users demand. As we all know, there's always something useful you can do to your project, but once your project hits a certain point, those useful, in-demand features apply to a narrower and narrower audience.

The lack of general applicability on the reasonable "New Features" list for the next release probably upsets marketers and others determined to milk more revenue from a successful franchise, so they go back and demand re-engineering of something that already works or the addition of bloat that nobody really wants or uses but that sounds good on the back of the box.

Open-source software has none of these woes. There are no constraints imposed by the uninformed or the ignorant and the BFDL, whom in all cases I'm aware is a technical person, has the last word on a feature's inclusion.

The difference is that in the commercial world, non-technical considerations and individuals generally mandate changes and unless something is just not possible, technical is rarely given a veto. In the open-source world, technical considerations and individuals generally mandate changes, and unless the project just can't continue without it, non-technical rarely gets a veto. One of these methods obviously leads to better software. Can you pick which one?

I am pining for the days of Office 95. The other two, though, not so much.

Its not about open source vs closed source, its about corporate development in which you are a developer with non-developers deciding what is important VS the developer has the last say.

There are times UI suffers from this, this is why we need some non-developers involved in these projects, we need to reach out to them.

However this is not just about "open source r0x0rs, close source s0x0rs" argument.

Propaganda certainly wasn't my goal; I'm sorry the post came across that way. It's a fact that open source consistently produces incredible software; I'm trying to feel my way towards some reasons why that might be. Thinking out loud is tough work; hope you'll cut me some slack.

Software that doesn't improve over time is generally forgotten and replaced by software that does. Given that, the software we are using at an arbitrary point in time is likely to be in the latter category.

Jacob didn't bring money into the equation.

His point was that the quality of open-source software tends to go up, while major closed-source projects' declines. Profit margin and quality don't always correlate, especially in software.

A perfect point:

Django is about you making a web framework that makes your/other's life easier. Also doing good stuff, being in control, getting recognition, and what better resume than "I am the lead developer on the Django project"?

In the corporate world its more about making money, not getting fired, people thinking up better ways to make money with what you already have, using your talent to make money, in fact the only reason to create anything in the corporate world is either to better make money or to save money on something that currently costs more money than building + using would cost.

Granted there are exceptions, like 37signals, but they got maaaaaaaaajor recognition for ruby on rails, and that is in itself making them money, or getting them tallent (which helps them make money).