Revision as of 18:58, 29 October 2004

Some thoughts about "The Power of Openness" Article

[John Spaith:] The first few pages of "The Power of Openness" reminded me a lot about the Nation article on evoting. Both have their share of rhetorical flights of fancy and both have a left wing bias. However, despite some flaws this article got stronger the more I went into it. In particular, the guy was pretty honest in looking at open source's challenges and was practical and not ridulously optimistic about being able to solve them. If I were an open source guy (I'm not), I'm sure my heart would be pounding at the thought of a reasonable H20 center as he proposes.

None of the anti-Microsoft/anti-proprietary stuff really stood out (at least compared to the general Open Source party line) except for this little gem:

"Many feasible schemes are imaginable. James Love of the Consumer Project on Technology, the Nader affiliated group, has proposed a 1-2% vendor tax on commercial software that would be used to finance the development of GPL-licensed open code software at state universities... the public would get free software and new tools for combating anticompetitive practices in the marketplace."

Being a gentleman I won't record here the exact words I thought when seeing this. Sorry, I don't think Uncle Sam has any business openly competing with commercial operations like this. Don't get me wrong. I don't necessarily have a huge problem (how's that for legalese?) with innovations making it into Linux via gov't sponsored research. Let's say a PhD student figures out a smarter way to schedule threads, does his work on Linux since he thought it most convenient, ends up making their kernel %2 faster, and Linus thinks it was swell and puts it in the 3.0 kernel. Linux getting better is a side effect, not direct result. And this new thread scheduler (subject to the weird licensing office rules - ugh) will increase the state of the art and may ultimatly make Microsoft products better too.

What the author proposes here is the opposite of that. He wants to enlist an army of kids to do grunt work to try and commoditize software companies in general, Microsoft in particular. That does nothing to increase the state of the art. In fact it sucks brains away from helping on that new thread scheduler and puts it into non-researchy grunt stuff like chosing pretty pictures for icons or getting the font on some dialog just right.

A totally unrelated note - from the first pages of the article, I gathered that the author has a devotional shrine to Stallman. I said to myself, "I bet he doesn't call Linux 'Linux' but instead by the Stallmanesque 'GNU/Linux'". I wish I'd had someone to bet real $ against because of course I was proved right. Since I was right on that point, logically I must be right on all the other stuff I've argued here as well :).

TedZ: I'm about halfway through this article, and I've already rolled my eyes a few times at the anti-Microsoft rhetoric. He seems to take it as a given that Microsoft is guilty of all sorts of "market crimes."

TedZ: Another comment. The thing that seemed "wrong" about the 1-2% tax is the idea of taxing commercial software companies to fund open software development, in effect taxing the commercial software companies to fund a competitor. That struck me as very odd. Also, if you're going to pay some people at universities to develop OSS, who decides who gets paid? That seems even more fraught with peril.

Microsoft's take on Open Source Platform and Linux

winfredw: Here is a recent email from Bill Gates in which he compares Windows against Linux on several fronts, including TCO, security, Indemnification, and time-to-market. Interesting read.

http://www.microsoft.com/mscorp/execmail/

Open Source vs. Commercial -- biting the unpopular change bullet

Throughout last night's lecture on Open Source, I found myself thinking of what I see as one of the key differences between open source development and commercial development. In commercial development (the only arena in which I have experience), there are many outside factors that can force the development team along a path it might not choose by itself. For example:

1. Sales requirements
2. Marketing requirements
3. Top-down organizational decisions
4. Powerful architects zealous about a new technology

...

For example, recently in my division a mandate was given that all UI should be completely reimplemented on a new tech stack. Not all teams agreed with the choice, but we were forced to begin immediately on the reimplementation effort, abandoning other projects.

In general, the development team has no choice but to comply with these directional changes, which can force the expenditure of a great deal of effort from all developers on a project in ways that the developers might not agree with. In the end, for good or for ill, the effort is made and the product moves on with the changes incorporated.

It occurs to me that this kind of thing is only possible in a commercial environment because the developers have not only their emotional investment in the product on the line but also their jobs. It doesn't even occur to most developers to walk away from their job because of a mandated change, though of course when job satisfaction decreases people start looking elsewhere.

In open source, on the other hand, the choices for an individual developer are different. If a project no longer appeals to the developer technically, he or she can walk away more easily. Or, as discussed last night, he or she can attempt to fork the project and continue in a different direction.

This seems to be a pretty fundamental difference. In a fork, presumably a large number of developers would decide to pull away from the original project. This might be all right in the sense that there's now competition between two ways of building the product. But clearly it represents an enormous brain drain for both forks of the project, relative to the developer community that existed before the fork. And bugfix and enhancement effort would now be duplicated between the forks.

This is just my impression... does it bear out? Does anyone have any experience with this kind of fork? Are there well-known examples of such a schism either breaking or eventually improving an open-source project? The link I included above includes some relatively positive examples of forks... does anyone know of examples where a fork has destroyed a successful project? I'm not sure if the Unix wars count, since the battle there is between commercial versions of Unix.

Recommended: Steven Weber The Success of Open Source

cmbenner: This is a very recent book by a political scientist at UCB, the first social scientist, I believe, to look at OSS. He looks at the political economy of open source development, trying to explain why this model for producing intellectual goods works. He also traces the detailed history of the open source movement in at least a somewhat engaging style for those looking for background. I think there's a class project that may be looking at developer motivations in the open source community: You guys might want to take look as he spends some time on this.

On the transparency of Microsoft's Intermediate Language

cmbenner: Managed code is more transparent than unmanaged code. Microsoft wants to carefully control access to its source code, through Shared Source, etc. Yet the way the .Net platform was implemented means that Microsoft code is more transparent than before. On a transparency scale of 1 to 10, with machine language (or whatever the most non-transparent form of code is called) being a 1 and source code being a 10, developers have told me Microsoft's Intermediate Language is an 8. Is the higher transparency of its code of concern to Microsoft given its highly-controlled approach to open source: thoughts from Microsoft developers and others?

Disclaimers vs. Licenses

From: Bob Gomulkiewicz [1]

Sent: Friday, October 29, 2004 9:13 AM

To: Ed Lazowska; 'Stephen Mark Maurer'

Cc: 'Bob Gomulkiewicz'

Subject: RE: Tonight

Steve, in retrospect I wasn't very satisfied with my answer to your question "why can't you just put a disclaimer on the code, why do you need a license?" My explanation about implied warranties did not really get to the heart of the matter. I think the answer is that if you simply slap a warranty disclaimer on the code and that's it, you still have to ask the question "what rights does the user have?" in the transaction.

If the transaction is interpreted as a Copyright first sale, then the "disclaimer only" idea does not work because the user has no right to make copies or derivatives. If the transaction is interpreted as an implied license, then it's still a license and you might as well do the user a favor and explain the scope of license (especially because implied licenses often get construed narrowly). If the transaction is putting the work into the public domain, then the software publisher still needs to say something to dedicate the work to the public domain, so you're not really simplifying the transaction that much (because you either have to write a license grant or a dedication grant).

To put it another way, if the hacker does not choose a particular transaction model, the Copyright Act assigns one by default (either a first sale or implied license). In one case (first sale), the model will not grand sufficient rights for open source objectives, in the other case (implied license) there are practical reasons to use an explicit license instead.

On top of these issues dealing with the license grant, you face issues about whether a disclaimer slapped on a box without the user manifesting assent in some way is enforceable (sometimes yes, sometimes no), and the problem of how you get the user to pass the disclaimer on to other users downstream (which both the GPL and BSD licenses require). That's the point I was trying to make last night in class, but I think the one about the license grants goes more to the heart of the matter.

Bob