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@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@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@open-xchange.com](<mailto:vittorio.bertola@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.