Only very partly true

Story: Timing release schedules to maximize publicityTotal Replies: 1
Author Content
mvermeer

Feb 28, 2005
10:27 AM EDT
There are some good ideas in this article. The writer is absolutely spot-on that a great many free software projects are lousy in their PR. (I know some of my favourite projects are :-) Roblimo's "PR Howto" is still very worthwhile reading.

But when this author suggests to tweak release times for propaganda effect, I think he got it wrong: this is simply not compatible with "release it when it's ready". He sort-of realizes this, it appears, and talks around it, which doesn't make his argument stronger.

The big flaw in the argument however, is the premise that free software would need end users in order to be successful. Of course in a trivially obvious way that is the case; but if by successful we mean: successful as a development effort, we have an essential difference between free and non-free software. The latter is critically dependent on paying users -- most of which are completely uninterested in software development and couldn't write a bug report if their life depended on it -- but getting developers is non-critical: you just hire them. Free software on the other hand is critically dependent on motivating -- not non-contributing end users, but user-contributors.

The reason, I think, why Firefox has taken the unusual approach of a massive drive to get large numbers of end users is a bit perverse, and has to do with the unusual near-monopolized market situation we live in: the aim is puncturing the monopoly of the enemies of free software and a free Internet. This is not a normal competitive situation, but rather a case for the Sun Tzu manual. I think it is important to be aware of this distinction.

In this modified form, the presented argument makes some sense. Still I don't see tweaking release times. But PR certainly matters -- a lot.
hkwint

Mar 01, 2005
11:48 AM EDT
Well, I can agree to that. I think it has mainly to do with the 'continue gliding scale' of version numbers for open source, and the decentralized structure of GNU and Linux-developers. Because, in more centralized open source projects like FreeBSD, with a new version, indeed much things are renewed, not only the kernel or some apps. About the 'gliding schale': MS Windows, for example, only has new releases once in a year or so, because it's not possible to update to the latest version (current) in between the releases, but the characteristic thing about open source software is, you can always get the current-source of the program (especially *BSD). Maybe it's just a renaming-of-version-numbers thing. So, let's say, -Gnome releases version 2.8.3.2 -OpenOffice releases version 2.0 Gnomes version must just be renamed version no 3. But that doesn't take the actual changes in account, and normally, only big changes makes an excuse for a new major version number.

So, what I mean to say is, the only possible way to reach what this writer suggest, is close cooperation between open-source projects, and I won't see that happen soon, because developers normally aren't really looking at other projects and their numbering schemes, and it would be too artificial to establish a 'general open source numering organization'.

Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]

Becoming a member of LXer is easy and free. Join Us!