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

Wed Aug 14 17:04:10 UTC 2019

Everyone,

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.

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.

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.

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.

Regards,
-- 
Mark W. Datysgeld from Governance Primer [www.markwd.website]
In partnership with AR-TARC and the Brazilian Association of Software Companies (ABES)

On August 14, 2019 8:44:39 AM GMT-03:00, Marc Blanchet <marc.blanchet at viagenie.ca> wrote:
>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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20190814/d064c2f8/attachment.html>