Re: Long-term IETF evolution thoughts

[Dave Taht <[e-mail]>]

On Mon, Jun 13, 2016 at 11:36 AM, Rich Kulawiec <[e-mail]> wrote:
> On Sun, Jun 12, 2016 at 08:31:21AM -0600, Marc Petit-Huguenin wrote:
>> I understand that increasing of online collaboration, when applied to
>> the IETF, is in fact two different things.  The first one is replacing
>> good old email collaboration by web-based collaboration.

All the cool kids are using slack, and what matrix.org has pulled off
is quite impressive.

> I would use the
>> Linux kernel project, arguably one of the most successful collaborating
>> project, as a counter-example of that trend, as is entirely managed
>> through email, and seems to thrive is spite of having very little other
>> kind of online collaboration.

Um, er, ah, no - a HUGE amount of interaction also takes place,
invisibly, over irc. Email is where the work surfaces, but irc is
where the bits get polished.

Ironically the irc vs jabber gaps were never crossed in most
subprojects because most older open source development started in irc
and email, and jabber was not a significant enough  improvement. That
said, jabber is heavily used also. The output is mostly just not
logged - which is a good thing -

Much of the linux processes are migrating over to git's methods, but
each new wave of development tends to adopt new means of
communication. There was a skype generation... a jabber generation...

As an example where I was utterly shocked at suddenly becoming an old
fart  - every presenter at the recent distributed web conference used
a twitter handle, rather than an email address.

https://bitcoinmagazine.com/articles/decentralized-web-initiative-aims-to-reinvent-web-with-peer-to-peer-and-blockchain-technology-1465574954

>
> That's because email is STILL the very best collaboration tool available:
> nothing else even comes close.

Evaluate slack... pretend that you sit in front of a web browser all
day and your native language is node.js.....

> 1. It's low-bandwidth.
> 2. It can be utilized offline.
> 3. It's asynchronous.
> 4. It can be used with the UI (mail client) of the participant's choice,
>         as long as that mail client is reasonably well-behaved.
> 5. It automatically builds an archive.
> 6. Individual participants can build their own archives.
> 7. Which means that they can also search those archives with the
>         mechanism of THEIR choice rather than one forced on them.
> 8. Which means that (taken as an aggregate) there are numerous ways
>         to ensure the completeness and integrity of the archives.
> 9. It scales magnificently.
> 10. Privacy/security issues are minimized.
> 11. Attacks/abuse/etc. against it are well-understood and easy to handle.
> 12. It's extremely fault- and delay-tolerant.
> 13. It's push, not pull.
> 14. It's highly portable, e.g., list-rehosting and list software upgrading
>         or changing are all relatively painless processes.
> 15. There are some very good choices for well-supported, mature,
>         stable, open-source software to manage it.
> 16. (more which I'll omit for now)
>
> Moving to web-based collaboration would be a massive downgrade: it's
> a truly horrible idea.
>
> ---rsk
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org