External Risk which could affect Leshan Project about leshan

[sbernard31]

For me, all three looks very similar; mainly one person does the job ;-).

Leshan is a bit out of scope here as this is about external risk.
Potential lack of contributor/committer for Leshan is an internal issue and there is effort made to involved new contributors.

For java-coap, according to main committer there are few guys who work on it but yes as often there is one committer more active than other.

And if you look at last year contribution you can see a bit more differences :

• java-coap
• leshan
• californium

Anyway, one big difference is that, for now, Leshan and java-coap main committers do that in their paid time and companies which paid them include the component in their platform.

So, cross the fingers, that I'm the only one, who needs to reduce the time.

I can not tell the future, I just tried to identify potential risk based on several hints and see if we can mitigate it.

[sbernard31]

@JaroslawLegierski, @mgdlkundera, @cyril2maq maybe this could interest you ?

[JaroslawLegierski]

Super analysis - Thank You. I was aware of the issues with OSCORE but lacked knowledge regarding the status of Californium and others libraries 😕 .

[sbernard31]

(After some discussion with main java-coap maintainer, I updated the page with more pro about java-coap and mbedtls binding)

[boaks]

Just for those, who want to get their own impressions about contributions:

java-coap

leshan

californium

For me, all three looks very similar; mainly one person does the job ;-).

So, cross the fingers, that I'm the only one, who needs to reduce the time.

[boaks]

I guess, for quite a lot of users it doesn't make a too big difference, if a risk is external or internal to a project.

For Californium it's not a risk, your point is fact.
For the other project it's only a risk, but I guess, everyone who has concerns about that, knows the situation in her/his own company. Even with Top Priority: Connectivity (see page 17), quite a lot of companies don't invest in it. For me that causes to "reduce things to a sustainable core", we will see, how that affects the IoT landscape.

Let's see, what the future brings.

[jvermillard]

Maybe it's time to put in place some actions to attract contributors and/or funding?

[sbernard31]

For Californium it's not a risk, your point is fact.

In the present, it's a fact. but for the future this is just a hint. Nothing sure, maybe unexpectedly in 1 year, a company will be involved in the project bringing new active contributor or your will be hire again to work on it. 🤷

Maybe it's time to put in place some actions to attract contributors and/or funding?

Is it about Leshan or Californium ?
If this is about Californium maybe better to create a dedicated issue.
If this is about Leshan, ideas are welcome 🙂 (but also maybe in another issue 🤔)

[jvermillard]

Is it about Leshan or Californium ?

I mean Leshan, I created issues for Cf in the past

[boaks]

About support of OSCORE:

There are currently some comments on OSCORE/EDHOC in LinkedIn mentioning implementations.
Maybe it's worth for you to ask there.

[sbernard31]

I mean Leshan, I created issues for Cf in the past

Totally forgot to work on that. I will create an issue about that (If I don't forget again 😅)

There are currently some comments on OSCORE/EDHOC in LinkedIn mentioning implementations.

Thx, For now I didn't have LinkedIn account and your link required an account 😬 .

[boaks]

Thx, For now I didn't have LinkedIn account and your link required an account 😬 .

Maybe Julien jumps in and ask there about these implementations.

[jvermillard]

looks like the java implementation they are referring to is https://github.com/rikard-sics/californium/tree/edhoc/cf-edhoc

[boaks]

Thanks, I wasn't clear, which implementation they refer to.

[sbernard31]

Maybe it's time to put in place some actions to attract contributors

A first try or at least a place to discuss about it : #1626