Parameters for success? (was Re: [Asrg] Re: [OffTopic - NNTP]

On Sunday, March 23, 2003, at 10:16  AM, Kee Hinckley wrote:

> I have never understood the resistance to using newsgroups.  Yet 
> customers choose web boards (which I despise) over them every time. I 
> think it's just a question of what people are used to.  The came to 
> the internet via the web and then discovered email (or vice versa). 
> Now you want to introduce a third piece of software, and they've 
> already got something that manages to do solve the problem so-so.
to some degree it's a generational gap (not necessarily by calendar 
age, but by how long you've been on the internet). you see these all 
over the place on the ent -- HTML email is another one folks fight 
over, coerced reply-tos on mail lists is a third, and increasingly, IM 
vs. email. the new generation of users is more of an IM first, e-mail 
as backup, where us old pharts tend to live in e-mail and remember 
fondly the days when NNTP was the primary dinosaur.
Which pointed out to me something I think this forum ought to be 
keeping in mind, the issue of parameters for (and barriers to) success. 
Whatever the solution(s) that we come up with, there are certain things 
that can keep any solution from succeeding, so I think perhaps it might 
be reasonable to think about what those parameters and barriers are.
Some of the most obvious things that come to mind for me are:

1) e-mail is easy to use. The more we complicate e-mail to solve this 
problem, the less chance joe typical user will agree to do it. If you 
don't make the benefits cleaerly visible to the user and the ease of 
use reasonable such that my mother and our aunt sally can (and will) 
accept the solution, it's a non-starter, the way PKI and S/MIME 
effectively are. Those things exist, but basically, nobody but geeks 
use it, and even most of them don't, because the hassles outweigh the 
benefits. (think of this as the 'seat belt' problem. almost everyone 
agrees we should wear our seat belts while driving. A good percentage 
of people don't anyway, even though the hassle of wearing one is 
generally trivial. That's a social issue that has to be dealt with of 
the solution won't succeed)
2) It has to save a person/company/ISP/organization/etc money, time, 
hassle. If it doesn't, it won't be implemented by that 
person/company/ISP/organization/etc. show me the money, basically. "for 
the good of the net" will get the EFF to install it. will sony? IBM?
3) If it requires implementation support from large organizations or 
ISPs, any solution that doesn't have buy-in and a hard date 
forimplementation from AOL is a non-starter. To a lesser degree also 
true of Yahoo, MSN/Hotmail, Earthlink, wannadoo, and maybe half a dozen 
of the larger international ISPs. You don't need ALL of those, but 
without AOL, you might as well go home, and until you get half a dozen 
of the top 12-15 ISPs or organizations, network providers, etc, you 
don't have a chance at building critical mass.
4) will it scale through organizations? I've seen a number of 
suggestions that really come across as if the proposer sees all e-mail 
environments as variations of THEIR environment. A solution that isn't 
tied to the individual (which arguably it can't be, since that solves 
none of the network bandwidth problems) has to scale from my site (a 
box on the end of a DSL line serving 6 users, 15 mail lists and a 
couple of hundred messages through those lists a day) to ibm.com or 
microsoft.com, to MSN, to yahoogroups, to hotmail, to AOL. If the 
solution can't scale up OR down to fit those needs, it's going to be a 
hard sell for success.
5) will the senders buy in? If not, isn't it a non-starter again? Not 
just mail list owners like me, or list sites like yahoogroups, but the 
large-volume mail senders, whether it's content (cnn.com) or 
e-marketing? How do you make it work without them? How do you convince 
them to join in?
Other thoughts?

I've found myself, as I've been watching stuff sent back and forth and 
discussed, asking myself things like "how would this affect my 
systems?" "Does it make my life easier or more of a pain?" "does it 
save or cost me money?" and the biggie: "How would we ever convince AOL 
to buy into this?"
think about AOL's position right now. Take, oh, e-stamps, or sender 
pays. how does AOL implement that on its environment? convince it's 
users to use it? migrate its users off of existing email? How long 
would that migration take? What if they weren't willing to change or 
don't upgrade their software? 25 million users, 3-5 billion pieces o' 
email a day, and users who haven't upgraded their software since they 
plugged in that windows machine 4 years ago, and won't upgrade any time 
soon. How do these plans work in THAT environment?
And if you don't get AOL bought into it, given their size adn volume, 
can you make it work without them?
I realize it's way early to get into too much detail on implementation 
issues -- but understanding certain necessary barriers to success will 
allow us to NOT go building things until we know those barriers are 
taken care of. If, for instance, it requires server upgrades by AOL or 
UI changes to the AOL client, for instance, I think it's silly to go 
beyond a certain level of discussion until someone finds out if AOL (or 
hotmail, or yahoogroups, or....) are willing to consider it. If they 
say no, it's better we consider lesser solutions that don't require 
their cooperation than building a better one that'll fail because we 
can't convince them to do it...
To me, that implies a hierarchy of solutions that can help us set 
priorities and understand the complexity and level of cooperation 
needed for success:
on the receiving end:

1) individual: build something an individual can download and 
implement. advantage: easy to do. disadvantage: limited ability to 
manage bandwidth issues, maintenance and user capability. (example: 
Apple's Mail.app junk mail filters)
2) site: things an admin can install to benefit the users of their 
machine. advantage: fewer people need to take the action, can affect 
network bandwidth issues as well as individual mail boxes. 
disadvantages: loss of user configurability (perhaps), loss of 
customization. (example: spamAssassin)
3) organization: things an organization can do to implement solutions. 
further down the scale of size from site, but effectively the same 
issue, scaled to multiple mail servers and a larger user population, 
plus perhaps issues of multiple locations and nationalities, meaning 
different parts of the system, might be regulated by different 
legislation.
4) ISP: seller of services and bandwidth to organizations. (for the 
purposes of what I'm saying, hotmail is a large organization, UUNET is 
an ISP, SpeakEasy is depending on which services you use, some of both)
5) infrastructure: making changes to the underlying structure of the 
internet (root name servers, protocols, etc) and the software that runs 
it. Basic, fundamental changes to how the net operates. (rDNS, new 
protocols for authentication, etc go here).
A) stuff that doesn't cleanly fit in the above, like yahoogroups, large 
volume senders, e-marketers, and stuff I'm forgetting off the top of my 
head...
The further you move from the individual level, the harder it'll be to 
convince everyone to implement, but the more chance you have of 
significant impact on the problems. So I think it's useful to at least 
casually keep in mind where specific proposals fall, so we can scope 
things like complexity of implementation and what buy-ins we need to 
get before we have a realistic chance of success.
(I think it also is a good visual reminder of why we need suites of 
solutions; indvidiual and site solutions to bridge us towards the 
longer-term, more strategic and structural ones -- and who needs to buy 
off on those solutions before we can hope for them to work)


--
Chuq Von Rospach, Architech
chuqui(_at_)plaidworks(_dot_)com -- http://www.plaidworks.com/chuqui/blog/


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg