Difference between revisions of "Talk:Lecture 5"

From CSEP590TU
Jump to: navigation, search
m (Open Source vs. Commercial -- biting the tech stack change bullet)
(Open Source vs. Commercial -- biting the tech stack change bullet)
Line 39: Line 39:
 
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.   
 
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.   
+
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 [http://encyclopedia.thefreedictionary.com/Fork%20(Open%20Source) 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 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?
 
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?

Revision as of 16:02, 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 tech stack 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?