<html><head></head><body>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 [www.markwd.website]<br>In partnership with AR-TARC and the Brazilian Association of Software Companies (ABES)<br><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: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On 14 Aug 2019, at 5:04, Vittorio Bertola via UA-discuss wrote:<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">Il 13 agosto 2019 20:25 Mark W. Datysgeld <br></blockquote><mark@governanceprimer.com> ha scritto:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"><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.<br></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><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.<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><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.<br></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><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><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<br></blockquote><br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><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)">https://www.icann.org/privacy/policy)</a> and the website Terms of <br> Service (<a href="https://www.icann.org/privacy/tos).">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.<br></blockquote></pre></blockquote></div></body></html>