D1.7: Innovation Management Plan v2

[minrk]

• WP1: Project Management
• Lead Institution: Université Paris-Sud
• Due: 2019-05-31 (month 45)
• Nature: Report
• Task: T1.3 (#16) Innovation Management
• Proposal: p. 33
• Final report (sources)

In the first version of the Innovation Management Plan for OpenDreamKit D1.4 (#20), we reviewed some context about the Virtual Research Environment and the end-user / developer relation, described transversal innovations OpenDreamKit is pushing for, provided notes on open source (mathematical) software development processes, with a focus on some systems the VRE is developing, and presented elements of strategy for reaching out for a wide range of end-users.

This second version complements this with two sections. In the first one, we review the choice and impact of open licenses in the context of OpenDreamKit, exemplifying potential issues with concrete examples where the project was actually impacted. Indeed, if most of the usual Intellectual Property issues were easily taken care of in this project thanks to the systematic use of open licenses, a few caveats exist nevertheless. In the second section, we review the different types of outcome of the project and discuss their respective sustainability.

This second version also includes minor updates to the earlier sections, notably to reflect the work plan revisions that occurred after Reporting Period 1.

[nthiery]

So we have to deliver a second innovation management plan, as a follow up to our first one was D1.4 #20.

Brief reminder from our discussion for the last time:

Reference: http://www.innovationmanagement.se/imtool-articles/a-process-for-innovation-planning/

Executive summary of the above: the Innovation Management Plan is not so much about what kind of innovation will be undertaken in our project, but the steps we take to foster innovation, from creative thinking to selection of the good ideas and actual implementation of them. In this case, innovation management is just what we do everyday as researchers :-) So it's a bit verbose to rant about it.

In D1.4, we provided:

• Some context about the Virtual Research Environment and the end-user / developer relation;
• A description of transversal innovations OpenDreamKit is pushing for;
• Notes on open source (mathematical) software development processes, with a focus on some systems the VRE is developing;
• Elements of strategy for reaching out for a wide range of end-users (workshops, ...)

Now we want to decide what would be meaningful for this v2. We certainly can briefly refer to the previous one, stating that on the strategic side we kept on the same process and that it was fruitful. So now, what would be additional useful information?

• We promised that More details about the innovations ODK is developing and implementing will be available in the second version of this document at Month 45, when the VRE is much more mature.
• Were there some changes in our processes that we would want to discuss? E.g. slightly shiftling from all-in-on to packages for SageMath?
• Other points?

[nthiery]

@fangohr @defeo @kohlhase @stevelinton @minrk @VivianePons @ClementPernet : suggestions and help appreciated!

[nthiery]

We discussed with @stevelinton yesterday, and came up with a partial plan (see the issue description). Further suggestions of material welcome, notably along the "more details about the innovations ODK is developing and implementing" we promised.

[nthiery]

I am about to initialize the report according to the above plan. I will insert \TODO and mentions for chunks where I would need your contribution; feel free to take over and edit other parts as well!

[nthiery]

@dimpase: would you please review the early sections and adjust them w.r.t. the WP7 changes? I imagine it's mostly about updating the references to tasks/WP, and maybe adjusting the emphasis on social aspects. We can discuss this further if needed.
Thanks in advance!

[nthiery]

@fangohr: do you mind rereading Section4 on "reaching out to users" to see if we want to update anything there? Maybe we could find a better title btw. I added a \TODO.

[nthiery]

I just pushed an updated report.tex file, with the content of the v1 and stubs for the new sections with plenty of TODO's. Please see the source link in the top comment and search for your name :-) It should be a couple paragraphs per person, so not too much work.
Moving on to other deliverables; so the file is fair game!

[stevelinton]

I've added some material on IP and licensing things in section 5, based on the GAP experience. It's rough both because it's missing some details and because I'm not sure if it's the right kind of thing. Feel free to comment or amend.

[kohlhase]

I have written some text for D6.3 (datasets), please re-read. This also needs some text from @JohnCremona about LMFDB

[JohnCremona]

On Wed, 28 Aug 2019 at 11:29, Michael Kohlhase ***@***.***> wrote: I have written some text for D6.3 (datasets), please re-read. This also needs some text from @JohnCremona <https://github.com/JohnCremona>

... who is writing that right now.

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23?email_source=notifications&email_token=AAXU32PNQHLRNBMEVEELXWLQGZHPTA5CNFSM4BPHE5S2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5KUY3A#issuecomment-525683820>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXU32N373YTCDV6HGJBILDQGZHPTANCNFSM4BPHE5SQ> .

[embray]

@jdemeyer @dimpase There is a TODO item in the report that reads:

\TODO{setup the stage by giving some indications on the volume of
ODK's contributions: which software, number of lines contributed by
Erik+Jeroen+Dima as measured by GitHub, ...}

How would you each like to handle this? I don't think counting actual "number of lines contributed" is necessarily practical to estimate or meaningful. But perhaps you could each highlight for me some major contributions you've made to different projects. Obviously Sage being one of them (FWIW, here are the "top contributors" (as measured merely by number of commits) to Sage since roughly the start of the project. But of course, this says nothing about the complexity/triviality of commits. And there were many other projects contributed to.

[jdemeyer]

...and it's miscounting my contributions on that page since I changed email address. Surely I worked on SageMath before 2019!

[jdemeyer]

Regardless of that, I don't see the connection between number of contributions and the "Sustainability" that this section is supposed to be about.

[nthiery]

For those that are not here in Cernay: it's really just to give a rough order of magnitude to provide a bit of context to the reader. The maintenance burden of 1Ml of codes is not the same as 1kl of code. Also to give some idea of how much of our contribution was to existing software and to new software. What makes it sustainable differs a bit between the two cases. Any other form of context is good too.

[jdemeyer]

I'm working on this...

[jdemeyer]

Done.

[dimpase]

It's vacation time for us, back to work next week. Hopefully it can wait till then.

[embray]

From this ecosystem, ODK will eventually deliver a flexible toolkit enabling research groups

This is a bit pessimistic for the second version, no? I suggest changing "eventually deliver" to "has delivered"...?

[nthiery]

This is a bit pessimistic, no? I suggest changing "eventually deliver" to "has delivered"...?

Good catch. That chunk was copy pasted from some early material on ODK and indeed needs updating. Please proceed :-)

[embray]

I have been asked:

\TODO{@dima / @embray: brief story about the impact of the openssl
license mess and how it affect(ed) sage and our efforts at promoting
packaging for modularization }

Problem is I don't really understand either (I'm a poor person to ask because I am not, and have never been interested in software licensing questions). I do know that for some reason, due to uncertainties about OpenSSL's old SSLeay license with some (all?) versions of GPL, there were open questions about how it can be integrated with distributions of GPL'd software (Sage is GPLv3). This especially impacted the MacOS binary distribution for some reason. This in turn made pip installation difficult. This part I can comment on. But what I don't understand is the exact issue with OpenSSL's license as it pertained to Sage in the first place. Maybe the details don't matter, but if anyone has a better explanation (@dimpase @vbraun @EmmanuelCharpentier ?) it would help.

Update: Went ahead and added what I could in 170f52e; the details probably don't matter much beyond what I wrote but I wasn't 100% sure.

[EmmanuelCharpentier]

\TODO{@dima / @embray: brief story about the impact of the openssl license mess and how it affect(ed) sage and our efforts at promoting packaging for modularization }

I do not really understand it either (I am certainly not a lawyer nor anything suchlike). My "best" information source comes from this snippet:

OpenSSL license (#OpenSSL)

The license of OpenSSL is a conjunction of two licenses, one called “OpenSSL License” and the other being the license of SSLeay. You must follow both. The combination results in a copyleft free software license that is incompatible with the GNU GPL. It also has an advertising clause like the original BSD license and the Apache 1 license.

We recommend using GNUTLS instead of OpenSSL in software you write. However, there is no reason not to use OpenSSL and applications that work with OpenSSL.

Coming from gnu.org, I take this statement as authoritative (I'm too old to try and fight the weather...).

I understand that the "new" OpenSSL license is GPL compatible.But this will apply to OpenSSL 3.0 and later. Unfortunately:

For any release made before OpenSSL 3.0.0 (namely the 1.1.1, 1.1.0, 1.0.2, and all prior releases including those not currently supported), the dual OpenSSL and SSLeay license applies.

The latest OpenSSL release being [1.1.1c]((https://www.openssl.org) as I'm writing this, we are settled with a GPL-incompatible OpenSSL.

Since Sagemath is GPL-licensed, we can't incorporate OpenSSL in our distribution. However, using the above loophole ("However, there is no reason not to use OpenSSL and applications that work with OpenSSL"), we can but recommend to install it systemwise and (re-)compile Sagemath in order to get functional Python, R and pip among others (I have personally checked a couple of times at least that GnuTLS is not enough to get this result, at least for pip and R...).

A better solution would be to officially depend on OpenSSL, but this was not inconsiderably balked at... So, as far as I understand it, we ship binaries OpenSSL-unaware.

Since the recompilation of Sagemath requires a non-negligible amount of time, resources and general system fu, one can tell that the public using Sagemath binaries uses a crippled system.

We could create a set of OpenSSL-depending binaries, depending on a systemwide OpenSSL but not shipping it. But I'm afraid that our available resources forbid it at the moment...

[nthiery]

Thanks everyone for the information! For the quick story I envisioned here in the report: it's just about illustrating the fact that composability of software to build complex systems requires licensing schemes that are as simple as possible. So no need to go into the legal details; suffices to tell a brief story explaining how the sheer fact that there is a plausible license incompatibility made us jump through hoops after hoops and, in turn, made -- and still makes -- our users's life so much more complicated. Which really is a pity. Thanks in advance! PS: please also see this TODO as a mere suggestion; if the idea does not fly, let's drop it.

[embray]

@EmmanuelCharpentier Thank you for the info. I think that fits with what I already wrote, so I probably won't add too many more details; as @nthiery it was just an example case. I pinged you because I know this has been a bugbear for you; your writeup of the issue here is a nice reference to have, and I agree that Sage-the-distribution should depend on and include OpenSSL. I also wish the note from the GNU organization, that the "combination results in a copyleft free software license that is incompatible with the GNU GPL", went into more detail about exactly what's incompatible and how it impacts usage, but oh well.

[nthiery]

I took care of my remaining TODO's, wrote the abstract, looked at the whole document at a broad scale, and did some minor adjustments. I believe it's mostly good to go. Two remaining points:

• A paragraph about workshops to be updated w.r.t. the latest period (@IzabelaFaguet)
• Time permitting: a complete proofread (@IzabelaFaguet?)
  Thanks in advance!

[nthiery]

Remember how we originally did not quite know what to do with this deliverable? Well, thanks to the contributions of many, I believe we have made it an interesting read, harvesting out of our distributed collective thoughts a neat overview of how we manage innovation in our communities.
Kudos everyone!