[PLUG-Devel] Hi all

Sun Sep 9 23:44:14 MST 2007

Tim Heuer wrote:
> Okay, I'll be clear that I'm a technologist first :-).  I do want to say that I re-read the archives and saw Alan's post about my note to him being a PR move.  I respectfully disagree.  I was just being informative to something that I thought might be interesting to the broader Linux community.  Clearly to some (the following post after Alan's initial note) it is of no interest.  I want to respect those, and if this is just noise on the list, please let me know and I'll be happy to take offline conversations.  I joined at the request of at least 3 people on this list to participate in a discussion, but I want to be respectful of noise on lists (I'm on about 85 different ones so I feel the pain when there is too much of it).

I assumed that the motivation to discuss this with Linux developers was,
at least in part, based on the goals of your employment.  I appear to
have assumed too much, for which I apologize.  I am delighted that you
want to communicate with Linux developers in any case.

I don't see this discussion as noise, though some may not be interested.
 It is quite appropriate for this venue.  I appreciate that you joined
"yet another" email list.

>[timheuer]: to be clear, the agreement we announced the other day is for Moonlight, not Mono.  Patent coverage for Mono is covered under the PCA (http://www.microsoft.com/interop/msnovellcollab/patent_agreement.mspx).  The mono functionality necessary to enable the use of Moonlight is covered under pertinent MSFT patent claims under the moonlight agreement announced.

This cited patent covenant not to sue covers only Novell customers
"...for which Novell has received Revenue (directly or indirectly)..."
or those who have not provided revenue on a 180 day evaluation basis.
So, as a recipient of Mono tools or a developer that creates and
distributes a Mono based application, and has not paid anything to
Novell, this covenant not to sue does not cover me.  That is how I read
it, anyway.

Where are the "pertinent MSFT patent claims under the moonlight
agreement announced" found?

> [timheuer]: as for units of Moonlight shipped while agreements are in force, users are covered for their ongoing use of the product under the pertinent patent claims.

I understand that for units already shipped, agreements in force at the
time of shipment are in control.  But if the agreements are withdrawn,
how do I, a developer using Moonlight, keep up with new Silverlight
developments?  I can't.

> [timheuer]: why?  Why not applaud and support the efforts that seem to be accepted in the linux/mono developer community.  Would any implementation Microsoft provided be any better?  Is it convenient?  I guess, but I think it is great.  We'll continue to improve and innovate on Silverlight and the agreement with Novell also highlights their commitment to do the same with Moonlight (they've committed to shipping a v1.1 compat w/in 9 months of us shipping the next version of Silverlight).  The direction here is a positive and cooperative one.

- Because it allows MSFT to appear as a participant in the community
without actually participating.
- Because it allows MSFT to avoid releasing any Silverlight related code
under a FS/OSS license.
- Because it allows MSFT to more easily cut off the Moonlight project
when they feel it is no longer useful.

I must say that even as current constituted, this really is a big step
for MSFT toward a more open development model.  In part I see it as an
admission on their part that FS/OSS is not going to go away.  It is an
admission that if they want Silverlight to dominate over Flash, they
cannot ignore the other operating systems.

If this "toe in the water" leads to MSFT wading further into the FS/OSS
stream, then I will applaud it in retrospect.

> [timheuer]: Miguel has commented on the whole full spec debate (http://developers.slashdot.org/comments.pl?sid=288641&cid=20481353).  He's gotten what he needs through raw specs and cooperative support with the appropriate people.  I think his team is satisfied, and if they aren't, they will let us know and I'm confident that division (run by Scott Guthrie) will work with him to ensure he has understandings he needs for his team.

I read Miguel's comments.  They sound very good.  In a year or so we
will see if Miguel and the Moonlight team really did get all the
information they needed.

> [timheuer]: let's be realistic here.  First, we are continuing to develop office for the mac, so I'm not sure what the issue is there.  Mac Office 2008 is in beta right now.

I'm not going to take the time to research the Office for Mac history
tonight.  It is a well known anecdote that Office for Mac always
significantly trails the capabilities and features of Office for
Windows.  Some say this is on purpose, to make the Mac harder to
integrate into a MSFT based business environment.  It may be that or it
may be the development for the Mac is just not as high a priority for
MSFT, which makes sense from a purely business point of view.

Since I am not a Mac user, I should just be quiet on this point.  All I
can say about it is hear-say from others and what I have read.

> [timheuer]: With regard to IE, hey, let's be real, the innovation/dev didn't just stop on IE for mac, it stopped on IE for windows!  It took Firefox to kick that team in the arse and make some changes.  By that time the mac platform had moved on to safari as a standard and IE on the mac was far behind.  I personally NEVER liked the IE implementation on the mac and clearly neither did a lot of customers...so in that case, I think the right decision is being made.  I'm not aware of IE development for mac (not to say that there isn't, I'm just not aware of it, but I'd be surprised if there was).

This is my point, exactly!  Two histories, one real from the past, one
hypothetical from the future.

IE History:
- Netscape is THE browser of choice.
- MSFT finally catches on that the Internet is a big deal.
- MSFT pours money and brains into making a better browser than Netscape.
- MSFT gives their better browser away and integrates it into their OS.
- Netscape becomes largely irrelevant with their business model undercut
and IE installed by default on everyone's computer.
- MSFT, seeing that there is no competition, drops active development on
IE while enjoying de facto standard browser status.
- Browser innovation is largely stagnant for years but IE continues to
drive sales of their OS.

Flash/Silverlight/Moonlight "History":
- Flash is THE interactive media tool of choice.
- MSFT finally catches on that interactive media is a big deal.
- MSFT pours money and brains into making a better interactive media
solution and development tool suite than Flash.
- MSFT gives their better interactive media solution away (Moonlight)
and integrates it into their OS.
- Flash becomes largely irrelevant with their business model undercut
and Silverlight/Moonlight installed by default on everyone's computer.
- MSFT, seeing that there is no competition, drops active development on
Silverlight/Moonlight while enjoying de facto standard browser status.
- Interactive media innovation is largely stagnant for years.

You could argue that the second "history" will not come about because
MSFT has changed their behavior in this case.  And, maybe because
Moonlight is already FS/OSS, years of domination, as in the browser
case, is not as easy.  We shall see.

> [timheuer]: Incompatibilities in software: welcome to software...again, let's be realistic here.  Software vendors regardless of platform have this problem and make business choices based on the needs of their majority customers.  OSX itself completely abandoned OS9 users with a "well, you have to buy the upgrade" messaging that left some with a foul taste for Apple.  But for apple, for their platform to progress and innovate they clearly felt that break was necessary.  That happens with some Microsoft software too I think.  Is the version of Outlook 97 going to be parity with Outlook 2007, a product 10 years later?  Maybe not.  Innovation happened and decisions are made to support better features and the demands of customers.  I'm really just not sure that is a fair argument as it could be applied to any commercial software vendor, not just Microsoft.  Look at PHP even -- PHP5 broke some major things with PHP4...and it was necessary to advance the platform.

I recognize that sometimes backward compatibility must be sacrificed to
make significant improvements.  This is true for any software regardless
of license or development model.  However, MSFT breaks even the move
forward.  Examples from my recent experience:

- A calendar event created in Outlook 2000 is not fully readable in an
Outlook 2002 client.  Same for an event created in 2002 and read in 2003.
- A document created in Word 97 will, with surprising regularity, not be
correctly formated in Word 2000.  The same as you move up from Word 2000
to each successive version.
- Windows Server 2003 will not fully interoperate with Windows 2000
workstations.

I have yet to NOT have instances where an occasional data file from the
directly previous version of MSFT software is buloxed by the next
version.  And this is all FORWARD compatibility, not backward.  And I am
not citing jumping over 10 years from 97 to 2007.  This is from one
version to the next.

It is in MSFT interest and, by my perception, their standard business
practice to break compatibility between versions.  This forces lock-step
upgrades of the entire environment and more revenue to MSFT.  If they
will do such a thing with Silverlight/Moonlight I am not sure but my own
experience says that MSFT will find a way.

> [timheuer]: I'm not familiar with Windows for Pen Computing, but did ask a colleague about it and he said that platform was crap to begin with and it wasn't continued because the market was clear that it shouldn't.

This topic takes some research to get right.  Since we are talking about
the late '80s to mid '90s, there is not that much online about it.  The
computer magazines at the time were full of discussion on that matter.
My memory was wrong about the "Pen OS" name.  It was PenPoint OS from GO
Computing.  The time line is something like this:

- 1987 GO Computing founded
- PenPoint OS was created specifically for tablet computer applications
- "Byte magazine awarded PenPoint best Operating System in the 1992 Byte
Awards. PenPoint won in the Standards and Operating Systems category	
- Computers with PenPoint OS showing up in marketplace in early '90s
- MSFT announces Windows for Pen Computing
- GO Computing funding and market dries up, in part because everyone was
waiting for the MSFT solution
- GO Computing closes
- MSFT abruptly cancels Windows for Pen.

The book "Barbarians Led by Bill Gates"
(http://en.wikipedia.org/wiki/Barbarians_Led_by_Bill_Gates) which I have
read but do not own, documents how MSFT did not intend to ship Windows
for Pen Computing.  MSFT only wanted to prevent GO Computing from
dominating the tablet computer OS space.

The story from inside GO Computing is told in the book "Startup: A
Silicon Valley Adventure" (http://www.amazon.com/dp/0140257314/).  I
have not read it.

No doubt the PenPoint OS was ahead of it's time, meaning ahead of the
hardware capabilities, which contributed significantly it's demise.
It's problems with MSFT's dominance were also a contributing factor.

To bring this around to the current Silverlight discussion, I simply
point out that it is directly aimed as a competitor to Flash.
Competition is good.  I just worry that if Flash is beaten to "also ran"
status, MSFT will then stagnate this area of innovation as they have
done before in other areas.

This is just some of the details of my thinking and perceptions.  These
are the things that keeps me reluctant to use MSFT tools and
applications.  These are my worries about Silverlight/Moonlight on Linux.

Alan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.PLUG.phoenix.az.us/pipermail/plug-devel/attachments/20070909/e0a94594/attachment.pgp 