[Desktop_architects] Printing dialog and GNOME
Segedunum
segedunum at f2s.com
Mon Feb 26 15:18:23 PST 2007
On Thursday 22 February 2007 00:40, Thilo Pfennig wrote:
> Our problem is that today Microsoft still makes the rules and we follow. We
> copy (also MacOs) where we can: Samba, OpenOffice.org, File Managers, Mono,
> Deskbar Applet,... and this is ok - but as long as we just follow we will
> always just be second best.
This touches on some interesting, and very relevant, points. In order to
understand why this is the case, particularly for software such as Samba and
Open Office, we need to look at the way things are in the world today.
The problem is, when you're trying to exist in a world, particularly the
desktop one, where it is dominated by incumbent pieces of software such as
Windows and Microsoft Office then in order to get in and get a foothold you
have to exist in that world. You have to be able to manage Windows desktops
on a network if you want to use non-Windows servers, which is what killed
off, and is finishing off, Netware. Your office suite also has to be able to
read the format of the documents that most people in the world use, and it
also needs to be able to create them in that format as well until your own
format is more established. Interestingly, when Microsoft was fighting
against WordPerfect and Lotus 1-2-3 and they were behind, they had to do the
same thing. Netware was a slightly different kettle of fish, because it was a
server OS and was always going to be dealing with Windows desktops anyway,
which was its Achilles heel.
The process for getting a foothold in a software world dominated by someone
else, and getting it turned around, goes something like this. I'll focus on
the office suite world more here, but this also applies to other things such
as Samba:
1. Make sure that your software can exist in an alien world and that your
software can read and write in the dominant office document *format* (forget
the office suite - look at the format). This must happen to the point where
no one is the wiser.
2. Make sure that in dealing with point 1, you do not lose sight of the fact
that your own office suite has to save by default in its own format, and you
need to develop it, so that users are building up a collection of documents
that you know your software can open as you go. As this collection grows,
the older, incumbent format's hold starts to lose grip - assuming you can get
more people using your office suite of course. In the case of Samba this
means effectively managing Windows desktops through their protocols, but
coming up with your own direction when managing and dealing with non-Windows
desktops. Samba and Open Office then become direct conduits to another
world . One that is equal - to you.
Note that without point 2, point 1 can *never* be sustainable, and it is
something that the open source world, and Microsoft's rival companies, have
been so non-existant, and quite frankly, incompetent at. In fact, I doubt they
even know they need to really go out to achieve point 2. It's why many
people feel that open source software is stuck in limbo in a Windows
surrounded world and there seems to be no way out.
A good example of the poor direction of this is that of the building of Open
XML support into Open Office, and Mono itself as a means of moving people
over. I'm sure Novell and a few others touting Open XML support in Open
Office probably believe this is some sort of new dawn in getting
interoperable Microsoft formats they can actually use, but it does Open
Office, MS Office alternatives and open source software no good whatsoever.
The only incumbent format that matters here is the old Microsoft Office
binary format, simply because it's the most used. As long as you can read and
write that format reliably enough, and at the same time convert those
documents to ODF by default, that's all that matters. I'm sure Microsoft are
absolutely thrilled that people are wasting their time and effort ignoring
the binary MS Office format that actually matters, and then wandering off to
bolster support for a pointless new 'wheel re-invention' format that *no one*
currently uses.
In the case of Mono, again, interoperability and moving applications from
Windows to other platforms is touted, but again, .Net is a new Microsoft
environment which few people actually use in the grand scheme of things. The
bulk of the software written for Windows is still VC++/VB/COM, and there is a
huge amount of binary stuff that is not even going to be recompiled, let
alone have its code ported. That's where the effort needs to go, and where it
should have already gone, if you want to make an alternative OS environment
viable.
Quite frankly, I'm shocked that even now, many distributions still tout moving
from Windows to Linux to organisations, but they have never seen just how
relevant and important a piece of software like WINE is. Collectively, put
the effort in to making peoples' Windows applications and COM based stuff run
within a Linux environment, and then allow Linux desktop applications and
development tools to use COM components installed with WINE. This gives
people the ability to keep their existing applications running for as long as
they want (hey, it's open source!), and create new Linux based applications
that can still use the old software components they can't do anything with.
Yet, distributions have never done *anything* with WINE apart from package it
into a RPM or something.
Microsoft took a dump on VB developers whereby with .Net, for the first time,
you couldn't open your existing code in the new environment and have it work.
Also, given that COM support and backwards compatibility within Windows will
only get worse over the years, there's a distinct possibility that WINE could
give people better support for their existing applications - for as long as
they want! Bryce Harrington's 'freedom' point does actually have a business
benefit there, and I suspect many Windows users will feel it over the best
part of the next ten years. Therein lies a large opportunity, and it's been
there for some time.
Cheers,
David
More information about the Desktop_architects
mailing list