The eight-step open source soft­ware adop­tion process

OpenSource For You - - INTERVIEW FOR U & ME -

Koohgoli rec­om­mends an eight-step process for ef­fec­tive open source li­cence man­age­ment.

Es­tab­lish a soft­ware li­cens­ing pol­icy: The first step, which is a nec­es­sary prac­tice, in­volves es­tab­lish­ing a soft­ware li­cens­ing pol­icy. Es­tab­lish what is ac­cept­able for your or­gan­i­sa­tion, and what is not. Typ­i­cally, de­ter­mine what kind of li­cences or li­cence stamps you be­lieve will be ac­cept­able for this project. List the stake­hold­ers to de­fine the pol­icy. Peo­ple from dif­fer­ent de­part­ments of the busi­ness—such as the li­cens­ing or le­gal group, the en­gi­neer­ing depart­ment, or the busi­ness di­vi­sion, and so on, can be in­volved as they un­der­stand the var­i­ous busi­ness re­quire­ments. Also, de­ter­mine what you would do in case a soft­ware li­cens­ing vi­o­la­tion oc­curs.

Soft­ware pack­age pre-ap­proval: The sec­ond step, which can be op­tional, in­volves defin­ing a process that al­lows de­vel­op­ers to re­quest for cer­tain off-the-shelf open source soft­ware to be used in their project. If some­body wants to use a soft­ware pack­age from out­side, what is the code they are go­ing to use? How are they go­ing to use it? Is it in bi­nary or source code for­mat? De­ter­mine how it will be mod­i­fied, and so on.

These re­quests will be com­piled, tagged and re­viewed. The pack­age be­ing re­quested for use is ex­am­ined, and re­lated li­cences are as­sessed and matched with the soft­ware pol­icy es­tab­lished; based on this eval­u­a­tion, the re­quest is ei­ther ac­cepted or re­jected.

Ex­ist­ing port­fo­lio as­sess­ment: The third step, which is nec­es­sary, in­volves es­tab­lish­ing a base­line about what you al­ready have in your com­pany. Ba­si­cally, it means analysing your ex­ist­ing con­tent and mak­ing sure that any­thing that vi­o­lates your ex­ist­ing soft­ware adop­tion pol­icy gets flagged, and if nec­es­sary, re­moved.

In­com­ing third-party soft­ware as­sess­ment and reg­u­lar soft­ware as­sess­ment: These are the fourth and fifth steps. Both of these, again, are nec­es­sary and re­late to analysing the con­tent that comes from out­side into your com­pany—from con­trac­tors, out­sourced or pur­chased from a third-party. You need to en­sure that such sourced con­tent is clean, and com­plies with the com­pany's soft­ware adop­tion pol­icy. It is wise to au­to­mat­i­cally an­a­lyse code to make sure that there are no sur­prises in the end, when the prod­uct is ready for the mar­ket. We know of com­pa­nies that do this scan­ning on a daily ba­sis.

Real-time li­brary check-in as­sess­ment: This step in­volves check­ing the con­tent that ex­ists in the con­tent li­braries of the or­gan­i­sa­tion, to de­ter­mine that each com­po­nent in the repos­i­tory com­plies with the es­tab­lished soft­ware adop­tion pol­icy.

Real-time au­to­mated as­sess­ment: These days we have so­lu­tions that work in the back­ground, like an anti-virus so­lu­tion, and de­tect any piece of open source soft­ware that is added to any work­sta­tion through USB or via the Web. The de­vel­oper im­me­di­ately gets an alert if any vi­o­la­tion of any li­cens­ing pol­icy is found. The de­vel­oper then has the choice of ei­ther re­mov­ing the piece of code en­tirely, or adding a com­ment that will be used for test­ing and would be re­moved later, and may con­tinue with the process.

Pre-ship­ment soft­ware as­sess­ment: This in­volves the anal­y­sis of the final arte­fact. If you have fol­lowed the ear­lier steps, there should be no sur­prises.

This is what we call a struc­tured open soft­ware adop­tion process. [Please use the fol­low­ing link to down­load the white-pa­per:­ntb]

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.