OpenDreamKit / OpenDreamKit Public
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
D1.7: Innovation Management Plan v2 #23
Comments
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:
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?
|
@fangohr @defeo @kohlhase @stevelinton @minrk @VivianePons @ClementPernet : suggestions and help appreciated! |
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. |
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! |
@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. |
@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. |
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. |
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. |
I have written some text for D6.3 (datasets), please re-read. This also needs some text from @JohnCremona about LMFDB |
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>
.
|
@jdemeyer @dimpase There is a TODO item in the report that reads:
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. |
...and it's miscounting my contributions on that page since I changed email address. Surely I worked on SageMath before 2019! |
Regardless of that, I don't see the connection between number of contributions and the "Sustainability" that this section is supposed to be about. |
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.
|
I'm working on this... |
Done. |
It's vacation time for us, back to work next week. Hopefully it can wait till then. |
This is a bit pessimistic for the second version, no? I suggest changing "eventually deliver" to "has delivered"...? |
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 :-)
|
I have been asked:
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. |
I do not really understand it either (I am certainly not a lawyer nor anything suchlike). My "best" information source comes from this snippet:
Coming from I understand that the "new" OpenSSL license is GPL compatible.But this will apply to OpenSSL 3.0 and later. Unfortunately:
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 (" 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 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... |
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.
|
@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. |
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:
|
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. |
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.
The text was updated successfully, but these errors were encountered: