<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Do everything what can be done with given resources and replicate success stories which has proven results. </div>
<div> </div>
<div>We have given our inputs on stretegic plan and lets see action on it. We need not select one and leave one. </div>
<div> </div>
<div>Mike</div>
<div>
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Sent:</b> Wednesday, August 14, 2019 at 10:34 PM<br/>
<b>From:</b> "Mark W. Datysgeld" <mark@governanceprimer.com><br/>
<b>To:</b> "Marc Blanchet" <marc.blanchet@viagenie.ca>, "Vittorio Bertola" <vittorio.bertola@open-xchange.com><br/>
<b>Cc:</b> ua-discuss@icann.org<br/>
<b>Subject:</b> Re: [UA-discuss] Enabling factors for UA (was Re: [UA-EAI] [Ext] Re: UA-EAI WG charter)</div>
<div name="quoted-content">Everyone,<br/>
<br/>
one trend I am observing here is that we don't particularly have a consensus on what software should be tackled and in what order. I know we conceptually understand what needs to be done, but we don't have that list. We also don't know the split between open and closed source of our targets.<br/>
<br/>
The Measurement and Tech groups should collaborate to make such a list, even if it's a fast and loose one, so that we can look at it and say: "okay, these are the underlying coding languages we want to tackle, these are the libraries that exist, these are the libraries that do not exist, these are the end-user applications that are more relevant to us". At Measurement this has been started to some degree, but not with this focus.<br/>
<br/>
If we know this information, we can then actively challenge ICANN to create a working model in which directed outreach could be done and especially patches for open source software could be ordered. We would be more effective.<br/>
<br/>
I don't mind leading this, but I would defer to the more experienced members of the community who have a deeper inside into this.<br/>
<br/>
Regards,<br/>
--<br/>
Mark W. Datysgeld from Governance Primer [<a href="http://www.markwd.website" target="_blank">www.markwd.website</a>]<br/>
In partnership with AR-TARC and the Brazilian Association of Software Companies (ABES)<br/>
<div class="gmail_quote">On August 14, 2019 8:44:39 AM GMT-03:00, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
<blockquote class="gmail_quote" style="margin: 0.0pt 0.0pt 0.0pt 0.8ex;border-left: 1.0px solid rgb(204,204,204);padding-left: 1.0ex;">
<pre class="k9mail">On 14 Aug 2019, at 5:04, Vittorio Bertola via UA-discuss wrote:
</pre>
<blockquote class="gmail_quote" style="margin: 0.0pt 0.0pt 1.0ex 0.8ex;border-left: 1.0px solid rgb(114,159,207);padding-left: 1.0ex;">
<blockquote class="gmail_quote" style="margin: 0.0pt 0.0pt 1.0ex 0.8ex;border-left: 1.0px solid rgb(173,127,168);padding-left: 1.0ex;">Il 13 agosto 2019 20:25 Mark W. Datysgeld</blockquote>
<mark@governanceprimer.com> ha scritto:
<blockquote class="gmail_quote" style="margin: 0.0pt 0.0pt 1.0ex 0.8ex;border-left: 1.0px solid rgb(173,127,168);padding-left: 1.0ex;"><br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
While I agree with the focus on code, I have to insist that we need a<br/>
working model to do it. If there is not a consistent process, we<br/>
won't be able to advance.<br/>
<br/>
Over my time as an Ambassador, one thing that happens often is that<br/>
devs become convinced that UA is good and ask how they can solve<br/>
issues on their side. We can point them to the relevant RFCs, talk<br/>
about the available i18n libraries, show Case Studies and so on...<br/>
but that is the same as saying "you figure it out".<br/>
<br/>
We either need an A) team of paid UA coders that we can deploy to<br/>
solve the problems of target clients, B) a robust bug bounty system,<br/>
or C) develop a set of in-house fixes to common<br/>
languages/implementations that we can point to. We have none of<br/>
these.<br/>
<br/>
If we want to advance in this direction, this is what it takes.</blockquote>
<br/>
In my experience, however, convincing the developers is not enough.<br/>
Unless what you are targeting is a small scale free software project,<br/>
the developers will be part of a bigger organization in which what<br/>
goes into the product is not decided by them, but by a product<br/>
manager. The product manager will only let the developers work on<br/>
features that make business sense, i.e. that someone has asked for;<br/>
and that someone must be either a significant paying customer, or a<br/>
sufficient number of final users to make the product manager think<br/>
that this new feature is vital to the competitiveness of the product.<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
Having paid development resources to do the coding might help, but<br/>
still it is not enough. No professional software maker - even the open<br/>
source ones - will let external code into their product without going<br/>
through proper review and testing by internal resources, and this -<br/>
especially for changes distributed throughout several core parts of<br/>
the code - still takes some investment, which will not be approved if<br/>
the new feature does not meet the requirements above.<br/>
</blockquote>
<br/>
I agree with your assessment but not for all projects and and not for<br/>
all cases. Open source projects have a wide variety of governance<br/>
models, one is similar to what you describe, which is often the case of<br/>
a commercial offering with open source (often called community version)<br/>
version, often more limited in functionality. In this context, their<br/>
willingness to either fix an issue or to merge a PR that fixes the issue<br/>
may be low or depending on customer demand. However, even that, it might<br/>
also happen anyway, since there is also a gain for that<br/>
company/community to fix bugs or support new features. So even for those<br/>
kind of projects, it is very possible that the fix will be merged.<br/>
<br/>
Now, for other governance models, the likelihood to accept fixes or to<br/>
do it themselves is much higher.<br/>
<br/>
If we are smart, we could choose the projects that have most impacts,<br/>
that the fix is not too big, and that the fix is likely to be accepted<br/>
and merged.
<blockquote class="gmail_quote" style="margin: 0.0pt 0.0pt 1.0ex 0.8ex;border-left: 1.0px solid rgb(114,159,207);padding-left: 1.0ex;"><br/>
So, to make this happen, paid coding effort is fine but priority #1 is<br/>
creating strong and widespread demand for UA support. Again as an<br/>
example, I tried to exploit the fact that one of our customers has<br/>
recently made a big deployment of our software in India to suggest<br/>
that their final customers were likely to want EAI, at least in terms<br/>
of interoperating with external EAI addresses; the reply was "not a<br/>
single one of them ever asked for it or made a support call because<br/>
EAI was not working". This is the discouraging aspect and this is what<br/>
needs to be changed first - the rest will follow.</blockquote>
<br/>
I disagree with your conclusion. I think it is a mix of both (demand and<br/>
supply support). It is a typical chicken and egg situation, that happens<br/>
often in deploying new technologies that are « enhancements ».<br/>
Building strong demand for UA support costs 100 times more than fixing<br/>
the bugs. Marketing costs much more than development.<br/>
<br/>
But I would take your point and build on it. If we find some<br/>
organisations who have big impact and can convince them to create demand<br/>
for UA, then we could have what your are looking for. Maybe Google,<br/>
Facebook, Tencent, … are of those organisations that could have<br/>
impacts. ICANN do have links to these organisations, maybe not the exact<br/>
right contact, but an entry point. Maybe we can look from this point of<br/>
view. Cost (almost zero) and probably have much higher impact than a big<br/>
marketing campaign to create strong demand for UA support.<br/>
<br/>
At this time, given limited resources, I think we shall concentrate on<br/>
having languages, librairies, frameworks and various main opensource<br/>
apps that have most impact to fully support UA. This is achievable and<br/>
have impact. Then it will be easier to start building demand.<br/>
<br/>
Regards, Marc.<br/>
<blockquote class="gmail_quote" style="margin: 0.0pt 0.0pt 1.0ex 0.8ex;border-left: 1.0px solid rgb(114,159,207);padding-left: 1.0ex;"><br/>
<br/>
\--<br/>
<br/>
<br/>
<br/>
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange<br/>
[vittorio.bertola@open-xchange.com](<mailto:vittorio.bertola@open-xchange.com>)<br/>
Office @ Via Treviso 12, 10144 Torino, Italy</blockquote>
<blockquote class="gmail_quote" style="margin: 0.0pt 0.0pt 1.0ex 0.8ex;border-left: 1.0px solid rgb(114,159,207);padding-left: 1.0ex;">
<hr/>By submitting your personal data, you consent to the processing of<br/>
your personal data for purposes of subscribing to this mailing list<br/>
accordance with the ICANN Privacy Policy<br/>
(<a href="https://www.icann.org/privacy/policy)" target="_blank">https://www.icann.org/privacy/policy)</a> and the website Terms of<br/>
Service (<a href="https://www.icann.org/privacy/tos)." target="_blank">https://www.icann.org/privacy/tos).</a> You can visit the Mailman<br/>
link above to change your membership status or configuration,<br/>
including unsubscribing, setting digest-style delivery or disabling<br/>
delivery altogether (e.g., for a vacation), and so on.</blockquote>
</blockquote>
</div>
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy" target="_blank">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" target="_blank">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.</div>
</div>
</div></div></body></html>