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

[Marc Blanchet]

On 14 Aug 2019, at 5:04, Vittorio Bertola via UA-discuss wrote:

> > Il 13 agosto 2019 20:25 Mark W. Datysgeld 
> <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.
>

I agree with your assessment but not for all projects and and not for 
all cases. Open source projects have a wide variety of governance 
models, one is similar to what you describe, which is often the case of 
a commercial offering with open source (often called community version) 
version, often more limited in functionality. In this context, their 
willingness to either fix an issue or to merge a PR that fixes the issue 
may be low or depending on customer demand. However, even that, it might 
also happen anyway, since there is also a gain for that 
company/community to fix bugs or support new features. So even for those 
kind of projects, it is very possible that the fix will be merged.

Now, for other governance models, the likelihood to accept fixes or to 
do it themselves is much higher.

If we are smart, we could choose the projects that have most impacts, 
that the fix is not too big, and that the fix is likely to be accepted 
and merged.
>
> 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.

I disagree with your conclusion. I think it is a mix of both (demand and 
supply support). It is a typical chicken and egg situation, that happens 
often in deploying new technologies that are « enhancements ».  
Building strong demand for UA support costs 100 times more than fixing 
the bugs. Marketing costs much more than development.

But I would take your point and build on it. If we find some 
organisations who have big impact and can convince them to create demand 
for UA, then we could have what your are looking for. Maybe Google, 
Facebook, Tencent, … are of those organisations that could have 
impacts. ICANN do have links to these organisations, maybe not the exact 
right contact, but an entry point. Maybe we can look from this point of 
view. Cost (almost zero) and probably have much higher impact than a big 
marketing campaign to create strong demand for UA support.

At this time, given limited resources, I think we shall concentrate on 
having languages, librairies, frameworks and various main opensource 
apps that have most impact to fully support UA. This is achievable and 
have impact. Then it will be easier to start building demand.

Regards, Marc.

>
>
> \--
>
>
>
>     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.