Open Source Software - Internal Modifications

[Dan-Eli]

In Section “Open Source Software Use > Using Open source Software > Internal Modification/Internal Distribution ”, the White Paper is addressing the legal aspects of internal modification and use of Open Source Software (OSS). I agree totally with what is written in sub sections “Internal Modifications” and “Internal Distribution”. But I think it would be valuable to add the following problem/concern associated with internal modifications. It should be noted that internal modifications are in fact “internal forks of an OSS project”. Since modifications in an internal fork will typically not be committed back to the community, the owners of these forks will have to maintain them without the support of the community and, more importantly, will not be able to benefit from future improvements done by the community unless they reintegrate the modifications in their own fork or they somehow commit back their work to the community. The longer an internal fork evolves, the harder it is to integrate back into the community trunk. We at Natural Resources Canada (CCMEO) had that problem on two occasions and in retrospect we should had made a formal modification to the main project instead of going with the “easy and fast way” of the internal fork and modification. I’m sure there are cases where internal modification is the best way but one must leverage the pros and cons of that decision before going with the “easy and fast way”.

Daniel Pilon Canadian Center for Catography and Earth Observation Natural Resources Canada

[smellems]

Bonjour @Dan-Eli

The Whitepaper is currently being reviewed to publish a version 1.0, but we will be updating it in the future.

We are currently working on the Standards for using and publishing OSS and have a section on exactly that. https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/standards/using-open-source-software.md#dont-fork-open-source-software

If you can, have a look at the draft Standards as these will become the rules and guides for OSS in the GC - https://github.com/canada-ca/open-source-logiciel-libre/tree/master/en/standards

[Dan-Eli]

It's a great news that you'll publish a version 1.0. Do you have a time frame for the publishing of the version 1. Great to ear to our concerns are already addressed. Yes, I'll review the document.

Daniel Pilon Natural Resources Canada

[Dan-Eli]

I took a look at the rules and guides for OSS in the GC https://github.com/canada-ca/open-source-logiciel-libre/tree/master/en/standards Here are some comments.

• at section https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/standards/using-open-source-software.md#with-modification on internal use of OSS, the document well capture the concerns we had about internally modifying an OSS

• at section https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/guides/open-standards.md#guides-for-open-standards, we propose to a bullet on interoperability as one of the most important consequences of using open standards is the increase in interoperability

• at section https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/guides/using-open-source-software.md#guides-for-using-open-source-software, under "Using open source software means you can benefit from :", we propose to add the following bullet:" Software developed with open standards and interoperability in mind first"

• at section https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/guides/using-open-source-software.md#internal, we propose to add the following bullet: "Unless of a good reason, must publish the modification to the main OSS project"

• at section https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/standards/open-standards.md#objectives-and-expected-results, we propose to add a paragraph on how open standards are the keystone of interoperability

• at section https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/standards/open-standards.md#requirements, the seventh paragraph start with "Ensuring that the open source software requirements..." because we are in the open standards section. Is the paragraph should start by " Ensuring that the open standards requirements..."?

• at section https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/standards/using-open-source-software.md#without-modification, I'm not sure to well understand the paragraph that starts with "This is also true for combination of open source software to ..."

We developed a small model a to help OSS contributor scope their contributions and expectations depending on the offer of OSS and the maturity of the community. would you be interested in a summary of the model. I'm asking that because it's in French and in Power Point so some works needed to rewrite it.

Continue the good work on OSS First

Daniel Pilon Natural Resources Canada

[gcharest]

Absolument! Toute l'aide est fortement encouragée!

Merci beaucoup,

Guillaume

Le mer. 9 janv. 2019 14 h 16, Dan-Eli notifications@github.com a écrit :

I took a look at the rules and guides for OSS in the GC https://github.com/canada-ca/open-source-logiciel-libre/tree/master/en/standards Here are some comments.

-

at section https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/standards/using-open-source-software.md#with-modification on internal use of OSS, the document well capture the concerns we had about internally modifying an OSS

at section https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/guides/open-standards.md#guides-for-open-standards, we propose to a bullet on interoperability as one of the most important consequences of using open standards is the increase in interoperability

at section https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/guides/using-open-source-software.md#guides-for-using-open-source-software, under "Using open source software means you can benefit from :", we propose to add the following bullet:" Software developed with open standards and interoperability in mind first"

at section https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/guides/using-open-source-software.md#internal, we propose to add the following bullet: "Unless of a good reason, must publish the modification to the main OSS project"

at section https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/standards/open-standards.md#objectives-and-expected-results, we propose to add a paragraph on how open standards are the keystone of interoperability

at section https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/standards/open-standards.md#requirements, the seventh paragraph start with "Ensuring that the open source software requirements..." because we are in the open standards section. Is the paragraph should start by " Ensuring that the open standards requirements..."?

at section https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/standards/using-open-source-software.md#without-modification, I'm not sure to well understand the paragraph that starts with "This is also true for combination of open source software to ..."

We developed a small model a to help OSS contributor scope their contributions and expectations depending on the offer of OSS and the maturity of the community. would you be interested in a summary of the model. I'm asking that because it's in French and in Power Point so some works needed to rewrite it.

Continue the good work on OSS First

Daniel Pilon Natural Resources Canada

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/canada-ca/Open_First_Whitepaper/issues/149#issuecomment-452804981, or mute the thread https://github.com/notifications/unsubscribe-auth/ABnJ5YuRTzu4cGia7MRyCXH_svRsfU06ks5vBkAhgaJpZM4Z1wJi .

[Dan-Eli]

Nous présentons ici le modèle que notre centre a développé pour nos employés afin de les aider à mieux cadrer leurs contributions dans le domaine du logiciel libre.

Il est connu que les contributions dans l’environnement du logiciel libre peuvent prendre de multiples formes (écrire ou modifier du code, écrire ou modifier de la documentation, rapporter des bugs, écrire ou modifier des normes ouvertes …). Dans ce contexte, il est possible que les employés qui possèdent moins d’expérience et/ou d’exposition à l’environnement du logiciel libre aient des interrogations au sujet du type de contribution à faire ou encore aient des attentes trop élevées suite à une contribution.

Ainsi, une meilleure compréhension de l’environnement du libre dans lequel on désire contribuer permettra de mieux déterminer la contribution à faire et les objectifs qu’elle devrait atteindre.

Le modèle ici présenté a pour but d’aider les contributeurs à mieux comprendre l’environnement de logiciel libre dans lequel ils évoluent.

Pour évaluer l’environnement de logiciel libre, le modèle utilise deux critères pour un domaine d'affaires donné : premièrement, le niveau de dynamisme de la communauté; deuxièmement l’offre de logiciel libre.

Le premier critère « Le dynamisme de la communauté » permet de qualifier l’état de la communauté du logiciel libre intéressée par un domaine d'affaire donné.

Le niveau de dynamisme peut-être Faible, ce qui indique que le domaine d'affaires est soit nouveau ou très spécifique à une petite communauté ou encore qu’un ou plusieurs logiciels propriétaires rencontrent efficacement les besoins de la communauté et que l’intérêt pour le domaine d'affaires avec du logiciel libre est inexistant ou maigre.

Le niveau de dynamisme peut-être Fort, ce qui implique que l’intérêt pour le domaine d'affaires est partagé par une grande communauté d’usagers de logiciel libre et que la communauté est connue et active.

• Le nombre de participants sur les forums de discussion
• La fréquence des communications sur les forums de discussion
• Les conférences et les publications qui se rapportent au domaine d’affaires

Le deuxième critère « L’offre de logiciel libre pour un domaine d'affaires » permet de qualifier les projets de logiciel libre qui sont disponibles sur le marché pour un domaine d'affaire donné.

L’offre de logiciel libre peut-être Rudimentaire ce qui indique qu’il y a soit peu ou pas d’applications de logiciels libres ou peu ou pas d’infrastructure de logiciel libre pour le domaine d’affaires. Une offre Rudimentaire peut aussi être la conséquence d’un manque de normes ouvertes favorisant interopérabilité.

L'offre de logiciel libre peut-être Mature, ce qui indique que, pour un domaine d'affaires, il existe des applications et des infrastructures de logiciel libre qui sont disponibles, fonctionnelles et fréquemment mises à jour. Une offre Mature est également souvent liée à l’existence de normes ouvertes d’interopérabilité.

Les éléments suivants permettent de qualifier l’offre de logiciel libre pour un domaine d’affaires :

• Des projets sont disponibles sur GitHub, GitLab, BitBucket…;
• Les mises à jour des projets sont fréquentes
• Les discussions autour des projets sont actives;
• Les références web vers ces projets sont nombreuses et positives.

Il est important de noter que pour les deux critères présentés précédemment, les qualificatifs "Faible et Fort" ainsi que "Rudimentaire et Mature" ne sont pas des qualificatifs binaires, car bien souvent il existe un dégradé de nuances entre les deux qualificatifs.

Ces deux critères constituent les axes d’un plan (figure 1) afin de définir un espace de 4 quadrants. Chaque quadrant représente une situation particulière de contribution au logiciel libre. Voici une description des 4 quadrants ainsi qu'une liste de contributions typiques pour chaque quadrant.

                        Figure 1: Modèle de contribution

Le quadrant#1, « Le naufragé », représente habituellement un cas où le contributeur doit développer son propre logiciel libre et tenter de le faire connaître à la communauté (lancer un SOS). Cette situation peut survenir dans le cas d’un domaine d'affaires très pointu pour lequel la communauté de développeurs est restreinte et, partant, pour lequel l’offre de logiciel libre est faible, peu éprouvée ou peu active. Dans ce quadrant, le contributeur doit faire l'effort de publier son logiciel libre et en faire la promotion via des publications et/ou des présentations afin de commencer à rassembler une communauté pour migrer éventuellement vers le quadrant#2.

Le quadrant#2, "Le troupeau", représente souvent des cas de "early adopters" d'une technologie émergente. Le but du contributeur dans ce quadrant doit être de mobiliser les forces de la communauté. Comme dans tout balbutiement de nouvelles technologies, plusieurs variantes sont mises à l'épreuve ce qui a tendance à fragmenter la communauté. C'est à ce moment qu'il est important de rassembler la communauté pour développer des normes ouvertes à travers des organismes de normalisation afin d'assurer l'interopérabilité des applications du domaine d'affaires. Les gouvernements ont alors un rôle primordial à jouer afin de mobiliser les forces en présence afin de migrer vers le quadrant#3.

Le quadrant#3, "L'équipe", représente normalement le cas idéal de logiciel libre rendu à maturité pour un domaine d'affaires donné. Dans ce quadrant, le but du contributeur doit être de bonifier les logiciels existants. Dans un domaine d'affaire à maturité, il y a normalement peu de produits disponibles et ces derniers possèdent chacun une communauté reconnue de développeurs et d'utilisateurs. Dans un tel contexte, un contributeur aura toujours avantage à travailler avec la communauté pour faire ou faire faire une modification à un logiciel libre existant afin que ces modifications profitent à toute la communauté et que la pérennité de ces modifications soit prise en charge par la communauté.

Le quadrant#4, "Le recycleur", représente un cas atypique ou malgré une offre mature de logiciel libre le contributeur ne peut pas bonifier un logiciel existant, car son besoin ne cadre pas avec ceux de la communauté. Le contributeur doit tout de même tenter de travailler avec l'existant. Pour ce faire, ce dernier pourra travailler à partir d'applications libres existantes et développer soit des extensions via des "plugin" ou encore de nouvelles applications libres basées sur des infrastructures de logiciel libre. En dernier recours, il pourra utiliser la stratégie du "fork" pour satisfaire ses besoins. Le contributeur devra alors, à l'image du naufragé (quadrant#1), publiciser ses travaux afin de migrer vers le quadrant 2 ou 3 selon la situation.

Ce modèle n’est pas un absolu, mais un guide de bonnes pratiques…ou chaque contributeur devra ajuster ses contributions selon sa situation. Il est aussi important de garder en tête que peu importe la situation et le quadrant, il est pratiquement toujours possible de pouvoir contribuer activement au logiciel libre.

Note: Ce modèle n'est pas une copie ou une adaptation d'une publication, d’un site internet ou d’une présentation, vous pouvez donc vous en servir et modifier le tout comme vous le voulez (spécialement la figure qui provient d'une présentation à saveur humoristique), car le GC possède tous les droits. Il nous fera aussi plaisir de retravailler certains éléments à votre demande.

[gcharest]

Merci beaucoup pour le modèle!! Désolé pour le délai dans ma réponse.

[gcharest]

Nous allons conserver ce modèle pour la prochaine itération. La version actuelle est soumise pour approbation dans les différents communiqués. @smellems

[Dan-Eli]

Excellente nouvelle. Nous restons disponibles pour vous aider.