[UA-discuss] Enabling factors for UA (was Re: [UA-EAI] [Ext] Re: UA-EAI WG charter)

Roberto Gaetano roberto_gaetano at hotmail.com
Wed Aug 14 09:07:13 UTC 2019


On 14.08.2019, at 11:04, Vittorio Bertola via UA-discuss <ua-discuss at icann.org<mailto:ua-discuss at icann.org>> wrote:

Il 13 agosto 2019 20:25 Mark W. Datysgeld <mark at governanceprimer.com<mailto:mark at governanceprimer.com>> ha scritto:

While I agree with the focus on code, I have to insist that we need a working model to do it. If there is not a consistent process, we won't be able to advance.

Over my time as an Ambassador, one thing that happens often is that devs become convinced that UA is good and ask how they can solve issues on their side. We can point them to the relevant RFCs, talk about the available i18n libraries, show Case Studies and so on... but that is the same as saying "you figure it out".

We either need an A) team of paid UA coders that we can deploy to solve the problems of target clients, B) a robust bug bounty system, or C) develop a set of in-house fixes to common languages/implementations that we can point to. We have none of these.

If we want to advance in this direction, this is what it takes.
In my experience, however, convincing the developers is not enough. Unless what you are targeting is a small scale free software project, the developers will be part of a bigger organization in which what goes into the product is not decided by them, but by a product manager. The product manager will only let the developers work on features that make business sense, i.e. that someone has asked for; and that someone must be either a significant paying customer, or a sufficient number of final users to make the product manager think that this new feature is vital to the competitiveness of the product.

Having paid development resources to do the coding might help, but still it is not enough. No professional software maker - even the open source ones - will let external code into their product without going through proper review and testing by internal resources, and this - especially for changes distributed throughout several core parts of the code - still takes some investment, which will not be approved if the new feature does not meet the requirements above.

So, to make this happen, paid coding effort is fine but priority #1 is creating strong and widespread demand for UA support. Again as an example, I tried to exploit the fact that one of our customers has recently made a big deployment of our software in India to suggest that their final customers were likely to want EAI, at least in terms of interoperating with external EAI addresses; the reply was "not a single one of them ever asked for it or made a support call because EAI was not working". This is the discouraging aspect and this is what needs to be changed first - the rest will follow.


Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola at open-xchange.com<mailto:vittorio.bertola at open-xchange.com>
Office @ Via Treviso 12, 10144 Torino, Italy

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 (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20190814/3db9fc9f/attachment.html>

More information about the UA-discuss mailing list