[buug] Reviving CalLUG

[Rick Moen]

Quoting Mark Lu (excelblue at gmail.com):

> I'd agree, it is a huge risk and leap of faith to use such hosted services,
> but from my perspective, there's risks on both sides. The risks of running
> your own resources include losing control if you were to get into a major
> accident (eg. run over by a bus)

Category of risk exists for both alternatives.

> having inadequate resources to maintain the resources (eg. power surge
> at 2am)

Category of risk exists for both alternatives.

> or in the case of an organization, a member seizing control (eg.
> centos.org domain name incident).

Category of risk exists for both alternatives.  (Except you're more than
reaching, anyway, as the continuity of the CentOS Project does not
depend on ownership of a particular DNS domain -- obviously.)

So, you've just made a handwave where you've asserted that these risks
are distinctive to controlling your own data and code as opposed to
outsourcing it to strangers you have no reason to trust, _but_ it turns
out that this is not true, as those threat models aren't distinct to one
mode of operation.

I hope this doesn't sound irritable, but I hope you're aware that I've
been doing analysis on these problems for some decades.  It'd be really,
really cool if I learned something new about it from a GMail-using
undergrad.  I'd really enjoy that.  But I'm not holding my breath.


> While the consequences of the risks of losing control of data to an
> untrusted corporation is much greater, I personally feel that the
> actual risks are much less than the simple issues of running your own
> resources. 

Yeah?  Tell that to Geocities
(http://www.pcworld.com/article/163765/so_long_geocities_we_forgot_you_still_existed.html),
TypePad (http://www.theregister.co.uk/2005/12/16/typepad_titsup/),
MySpace
(http://www.theregister.co.uk/2005/10/17/web20_worm_knocks_out_myspaces/),
Flickr
(http://www.theregister.co.uk/2005/04/14/flakey_flickr_fckd_again/),
weblogs.com
(http://www.theregister.co.uk/2004/06/15/winer_weblog_wipeout/),
Facebook
(http://www.cbsnews.com/stories/2010/05/08/earlyshow/saturday/main6469373.shtml),
Plaxo (http://www.rogerclarke.com/DV/ContactPITs.html), Blackberry
(http://ask.slashdot.org/story/06/01/26/1949243/Blackberry-Blackout-Threat-to-Software-as-Service),
and Google Maps
(http://www.oreillynet.com/mac/blog/2005/10/web_20_and_the_driveby_upgrade.html)
users.


> My experience shows that it just happens less often with untrusted
> corporations.

In _your_ experience?  Hmm.

I don't want to wave my figurative cane at you and tell you to get a
haircut, get off my lawn, and get a job, but... let me put it this way:
While attending high school I was in a computer user group that met at
the Stanford Linear Accelerator Center Auditorium.  A couple'a guys
named Steve showed off breadboarded computers there that they were
starting to sell under a goofy 1970s corporate name borrowed from a
fruit with a rainbow logo.  And I've basically been doing software,
first on an all-consuming amateur basis and then for a living, since
before you were born, I'll reckon.

To set the period:  My freshman-year entertainment in high school, where
I was the only liberal Democrat in a sea of rich, spoiled Republican
future fratboys, was Watergate.  Nixon got re-elected in the fall and I
said 'You'll be sorry.'  The man's campaign slogan 'Nixon's the one!'
soon came back to haunt him.

At said SLAC-located user group, we got a letter, sent by a pushy little
partnership in Albuquerque called 'Micro-Soft', complaining about abuse
of their crappy proprietary BASIC interpreter, passed along to us by
David Bunnell.  I said 'You know what?  Why don't we consign this Gates
person and his dodgy BASIC interpreter to the obscurity he deserves.  We
have other BASIC toolchains.  _Don't_ copy his.  Deliberately ignore
it.'  If they'd listened to me, maybe we'd have gotten the open source
renaissance 20 years earlier.  

But I was just a kid.  In 1976.
http://linuxmafia.com/faq/Legacy_Microsoft/altair-basic.html

And like that.  You get the picture.  Old.  Been around the block of the
software industry a bunch of times.

No offence intended or taken.



> In short, it's just balancing something very risky with something more
> risky.

Except you really didn't show that.

> The bigger question is where to draw the line.

Here you go.  Enjoy.  (My view; yours for a small royalty fee, as the
old joke goes.)

http://linuxmafia.com/faq/Essays/winolj.html  (Make sure you read the
'And Yet...' section before commenting, please.)

> One of the reasons why I considered Google Groups is because the data
> on the mailing lists is public anyways, and we have no monetary
> interest.

Yeah, so-called 'free' hosted / SaaS / Web 2.0 services are always
defended in terms of 'monetary interest' only, as if control of your
data and code, your privacy, your ability to enforce your own policy,
your autonomy, had no value.


> As was mentioned earlier, the lack of public archiving in CalMail
> means that it isn't fulfilling the requirements. Hence, it's thrown
> out of the equation when comparing simplest solutions that do fulfill
> the requirements.

True, Google Groups does give you public archiving.

So, by the way (in addition to obvious direct implementation of standard
Linux software, already mentioned), does asking a nearby LUG with a
Mailman instance to add your mailing list to the ones they already run.
E.g., Smaug of Santa Cruz has its mailing list hosted on SVLUG's Mailman
instance.  SF-LUG has its mailing list hosted on CABAL's Mailman
instance.

Both of those are actually easier than migrating to Google Groups.  And
you don't have to submit to the privacy (um...) cavity search and
arbitrary corporate policies of being a Google product.  (I say Google
'product' to remind people that, if you're using a 'free' service such
as GMail or Google Groups, you are not their customer:  You are product,
i.e., a personal targeted-marketing data source and captive advertising
target, that Google sells to its _actual_ customers.)



> Balancing out the advantages and disadvantages is a difficult topic.

Indeed.