149 lines
5.2 KiB
HTML
149 lines
5.2 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
|
|
<TITLE>Commercial Port Advocacy mini-HOWTO: Other efforts</TITLE>
|
|
<LINK HREF="Commercial-Port-Advocacy-4.html" REL=next>
|
|
<LINK HREF="Commercial-Port-Advocacy-2.html" REL=previous>
|
|
<LINK HREF="Commercial-Port-Advocacy.html#toc3" REL=contents>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="Commercial-Port-Advocacy-4.html">Next</A>
|
|
<A HREF="Commercial-Port-Advocacy-2.html">Previous</A>
|
|
<A HREF="Commercial-Port-Advocacy.html#toc3">Contents</A>
|
|
<HR>
|
|
<H2><A NAME="s3">3. Other efforts</A></H2>
|
|
|
|
<P>There are other groups and individuals doing their parts in
|
|
trying to get various software and hardware vendors to support
|
|
Linux. Norman Jacobowitz is a consultant working with SSC, Inc.
|
|
on an advocacy project that approaches the same problem I'm
|
|
addressing here, although from a different direction. Here's
|
|
what he told me about his efforts:
|
|
<P>
|
|
<BLOCKQUOTE>
|
|
SSC, Inc, publishers of Linux Journal, maintain a
|
|
"software wish list"
|
|
at <http://www.linuxresources.com/wish>. They are
|
|
currently paying an
|
|
outside consultant to use these results and other data to lobby
|
|
marketing managers at ISVs to port their products to Linux. This
|
|
is an
|
|
effective, on going project to bring more native software to
|
|
Linux; so
|
|
please drop by the wish list and vote for your favorite
|
|
software.
|
|
</BLOCKQUOTE>
|
|
<P>Andrew Mayhew has been trying to convince hardware vendors
|
|
that making Linux drivers, or at least releasing the
|
|
specifications so the Linux community can write the drivers, is a
|
|
good idea. Here are his thoughts:
|
|
<P>
|
|
<BLOCKQUOTE>
|
|
I go to conferences. I was most recently at
|
|
Networld-Interop in Atlanta (which was shortly followed by the
|
|
Atlanta
|
|
Linux Expo). There at Interop I went to many of the vendors with
|
|
two
|
|
agendas. First, I was there as a respresentative of the ISP that
|
|
I work
|
|
for and was looking for solutions. But secondly, I was there
|
|
find out who
|
|
currently had Linux support and if they didn't have Linux
|
|
support, why
|
|
they didn't and was the company considering it. It is
|
|
interesting to
|
|
note, that in the large Novell section, there were actually two
|
|
Linux
|
|
related sub-booths. Additionally, Cobalt Micro was there with
|
|
their thin
|
|
server, along with RedHat and Caldera. Fairly small showings in
|
|
a nearly
|
|
completely non-Unix related conference, but a showing none the
|
|
less.
|
|
</BLOCKQUOTE>
|
|
<P>
|
|
<BLOCKQUOTE>
|
|
Most of the companies that I was talking to are primarily
|
|
hardware
|
|
vendors. They already don't make any money off of their drivers.
|
|
They
|
|
just need to develop the drivers so that people will use their
|
|
hardware.
|
|
My typical approach to one of these companies was to first ask
|
|
about the
|
|
product in general, so that they could get through their
|
|
marketing routine
|
|
quickly, and then ask about driver support. When the only words
|
|
out of
|
|
their mouths would be Windows 95, 98, and NT, I would ask about
|
|
other
|
|
platforms explaining that I run in a multiplatform environment
|
|
and would
|
|
need interoperability between these platforms. In introducing
|
|
the idea
|
|
that they should support other platforms I would only slowly work
|
|
in the
|
|
idea of Linux as one of them. I found that introducing the idea
|
|
that I
|
|
wanted driver support for Linux right off typically got me a
|
|
knee-jerk
|
|
reaction which would basically have the person shutdown and try
|
|
to find a
|
|
way to get out of the conversation. But if you can get their
|
|
defenses down then you can explain to them how, in
|
|
general, all they would need to invest to get Linux drivers would
|
|
be to
|
|
openly publish the specifications for talking to whatever
|
|
hardware and
|
|
possibly providing hardware to key developers. The biggest
|
|
argument to
|
|
this, is typically, "We have some proprietary ways of doing X and
|
|
don't
|
|
want to have that information out in the open." The usual way
|
|
around this
|
|
problem is to explain that being able to talk and use a device
|
|
does not
|
|
normally mean having to know what proprietary tricks they are
|
|
pulling. At
|
|
least this fits with the wireless LAN and the Fibre Channel IP
|
|
people that
|
|
I was dealing with.
|
|
</BLOCKQUOTE>
|
|
<P>
|
|
<BLOCKQUOTE>
|
|
One smaller company, which I think may attempt to find
|
|
someone in the community to help develop a driver for them came
|
|
up with an interesting
|
|
solution around the proprietary issues as well. This being that
|
|
they
|
|
would have the initial developers sign NDAs for the hardware
|
|
documentation, but the source code could be open source so long
|
|
as the
|
|
documentation in the source was not just a copy of what the
|
|
company
|
|
provided the developer.
|
|
</BLOCKQUOTE>
|
|
<P>
|
|
<BLOCKQUOTE>
|
|
For software companies, I think it is a very good idea to
|
|
point out that
|
|
there is nothing or very little available of their kind of
|
|
software;
|
|
whatever that area of software is. But it probably should also
|
|
be noted
|
|
what does exist. Of particular interest would be the development
|
|
tools,
|
|
the development support available, and possibly information about
|
|
other
|
|
porting projects. In terms of these other projects they would be
|
|
interested in the porting problems that they have solved or would
|
|
similarly be tackling.
|
|
</BLOCKQUOTE>
|
|
<HR>
|
|
<A HREF="Commercial-Port-Advocacy-4.html">Next</A>
|
|
<A HREF="Commercial-Port-Advocacy-2.html">Previous</A>
|
|
<A HREF="Commercial-Port-Advocacy.html#toc3">Contents</A>
|
|
</BODY>
|
|
</HTML>
|