On 23/04/2020 12:03, Keith Moore wrote:
On 4/23/20 10:49 AM, Fernando Frediani wrote:
Well, in order to show example and stick to values we have to get out
of our comfort zone and not always do everything as we would wish.
We're supposed to be an engineering group, and engineering is all
about pragmatism and compromise. IMO we should expeditiously
gravitate toward tools that best support our work, and that includes a
lot of considerations like supporting IPv6 and avoiding vendor
lockin. But we should not let that impede our work. It's a difficult
balance to maintain because inertia gets in the way. It's easy to get
stuck.
Sure Keith, fully agree.
That's why I asked on my first message "What unique feature does it have
that it has to be it?". With the other tools that have support will not
the meeting happen the same and the work get done pretty much with the
same efficiency? If so then it matches both criteria you just mentioned.
IMO any vendor-provided services that aren't well-defined by open
standards or maybe open source code are inherently suspect, because we
won't be able to easily modify such tools to suit our changing needs,
or migrate to other tools that support our needs better. Our
organization is dedicated to producing and promoting open standards,
so anything we use that isn't entirely or at least mostly specified by
open standards inherently puts us in a conflicted position and impedes
our work sooner or later. Lack of IPv6 support is only one example
of an issue that results from reliance on nonstandard tools.
You said well: not just producing but promoting as well. That's why
eating our own dog food is something pertinent here, specially when it
doesn't bring any losses to the work to get done at the end.
Regards
Fernando
