[Auth]Simplest design 1 last time (I promise :-)

[Ron Burk]

> > b) The security-lock-down issue. By this I mean all the computers (eg net
> > cafes, Universities, libraries, corporate environments) that don't let you
> > install plugins and/or don't have floppy drives
>
> I think that Ron's proposal was to deliberately make the
> decision to not address this issue in the first version.

True -- the simplest design that could possibly work goes
after the 80%, not the 20%.

a) Most users are not using locked-down computers.
b) Plugins that many web-page flunkies support get installed
    on most locked-down computers (I can't recall ever seeing
    a locked-down computer that does not have the huge and
    odiferous Adobe PDF plugin installed :-).

> > Who's going to write (and test and build) the plugins for all those
> > platforms? I mean, Flash isn't supported on half of them, and you think we
> > can get "significant maerketshare quickly."?

Hmmm. If you really think writing code that works with
80% of the browsers in use is more than a tiny fraction
of the total work contemplated for the dotGNU project
(CLR, distributed authorization, high availability, etc.),
then I'm just living on a different planet than you :-).

Also, I would like to reiterate that the key to getting clients
to use *any* form or version of dotGNU is to make it dead
easy for web page flunkies to adopt it with the absolute
smallest amount of work. The dotGNU project has no
levers for directly picking up a few million clients at a time
(unlike Microsoft). You do, however, have a reasonable
shot at enlisting web page flunkies. If you get lots of web
sites offering dotGNU support, you have a good shot
at getting the clients. There are also opportunities for
giving web page sites branding/customization options
with a plugin, which greatly increases their incentive
to ask their own customers to use it.

I have no great fondness for plugins (and I can happily
agree that they should not be required for the more
complex features that dotGNU will eventually support).
But I have not seen any other design mentioned that
I believe has the same shot at quick market penetration.
I have 5 web servers running a few feet away,
both Windows and Linux-based and *none* of them are
LAMP. Handing me PHP code is a waste of both my
time and yours if you're trying to sign me up for your
system. I would not support anybody's single logon system
on my computers unless it was just a matter of tweaking
some data files associated with URLs. Assuming that
the world is LAMP seems ironically equivalent to
Microsoft's assumption that the world is IIS and Windows.
There are a whooooole lot of IIS systems out there,
and a lot of web page designers who can't install
software or write code.

There are many other energy barriers for people who
manage web sites. One can blithely say "and the web
server will connect to the dotGNU server", but that
ignores the realities of the majority of corporate web
sites (and there are a whole lot of those). What is my
legal relationship with the "dotGNU server"? Will my
boss really let me introduce a scheme that breaks
when some third-party computer goes down? Or,
how enthusiastic will my boss be about me setting
up my own "dotGNU server", when Passport is
already working just fine? My guess is that
this is a real hard sell, and not something
that could possibly achieve market penetration that
competes with Passport in less than 4-6 years,
which gives Microsoft an awful lot of time
to react.

> > > But for programs which are used on many computers by many
> > > different people, there we have the advantage, because a
> > > significant percentage of the users help with making the program
> > > better - that's a power that Microsoft doesn't have.
> > >
> >
> > Show me a single example of an end user (non developer) open source product
> > where the users have helped with development.

When you make a chart of customers/suppliers,
competitors/allies for something like dotGNU, web page
flunkies  are a very important part of the "customer"
group. Presumably, you would agree that those "users"
contributed greatly to the success of projects like
Apache.

> I feel that what we need right now is proposals from people who
> are also capable of leading the process of implementing their
> proposal, and willing to do so.  I believe this is the case with
> Ron (am I right about this, Ron?) and on top of the fact that
> what he says makes sense IMHO, that is another reason why I am
> supporting his proposal.

I doubt I can lead the process, but I do want to see if the
idea can succeed. I suspect at this point that it cannot
garner enough support in this group to go forward (doesn't
need a lot, but it does need enough expertise to cover
crypto, cross-browser development, talking to W3C,
and it definitely needs the "dotGNU brand" to be worth doing).

That could be because it simply isn't a good enough idea, in
which case it deserves to die. Alternatively, it could be
that it's really an idea based on existing customer needs
and market forces -- not the sort of forces that typically
drive any open source development (but definitely important
if there's to be any hope of competing with .NET).

Just to restate one more time: the simplest possible
design is not a replacement for the "real" dotGNU.
It is a way for dotGNU to have an important presence
with web developers and end users *much* sooner
than the "real" dotGNU could ever hope to. It leads
the way, and it is so simple that it would be difficult
for it to be significantly incompatible with the "real"
dotGNU, no matter what architecture it arrives at.
To be honest, it is simply the technique that Microsoft
has used for years to crush competitors: you build
the "good enough" solution as fast as you can,
get it installed as widely as possible, and then
continually improve and enhance and PR until
your product's name is synonymous with the
market it's competing in. If you want to arrive
second to a market and displace Microsoft,
you better make technology take a back seat
to marketing, strategy, and serving customer
needs. Just like Microsoft, I don't really care
if "dotGNU v2.0" is technologically so different
than "dotGNU v1.0" that they are essentially
unrelated. If v1.0 gets the market share and
mindshare that makes it easier to sell v2.0,
then it's done it's job admirably.

Just to show that this is not really about technology,
some folks have mentioned existing "form filler"
products that offer a single logon solution. Those
are indeed simpler, in the sense that they don't
require the web site to actively participate.
From a technological viewpoint, they are "better".
But this is about marketing and customer needs,
not technology. Requiring minimal participation
from the web site developer both makes the
customer experience better (no half-ass "AI" or forcing
the customer to tell the program about the logon
form at each new web site), and gives marketing
a major leg up -- you've effectively enlisted the
web site to help market your brand name and
your product. Nothing to do with technology,
but everything to do with marketing (and making
sure that dotGNU makes a much bigger splash
than the typical form-filler app).

Other people believe other dotGNU designs are also simple
and can be sold as easily. I differ with that viewpoint.
You can't sell PHP to folks who use FrontPage and
IIS. You can't quickly sell usage of an intermediate server
to people who have corporate/legal guidelines for
web page development. You can't sell solutions that
require "only a little coding" to people who create
web pages, but don't know how to write code. The
end users will use what the web sites they are using
(or Microsoft or one of its minions, such as MSN)
push them to use. The web sites will use whatever
makes their life easier. Many web page flunkies
who cannot use Passport will be happy to support
an alternative that requires only slight tweaking of
their existing web pages (and absolutely no
programming or software installation). The web
page flunkies who can't install software or write
code are key to achieving exponential growth
and paving the way for adoption of more
compex systems.

But that's just me -- I could be wrong :-).

Ron Burk
Windows Developer's Journal, www.wdj.com