ESSnet SCFE DELIVERABLE D5-4 · This document is licensed under a Creative Commons License: Attribution-ShareAlike 4.0 International ESSnet SCFE DELIVERABLE D5-4 Guidelines and recommendations

This document is licensed under a Creative Commons License: Attribution-ShareAlike 4.0 International

ESSnet SCFEDELIVERABLE D5-4Guidelines and recommendations for development of training materialsand for open source solutions and projects

Project acronym:

SCFE

Project title:

“Sharing common functionalities in the ESS”

Name(s), title(s) and organization or the auhor(s):

Joaquim Machado, Dr. ([email protected])José Carlos Martins, Eng. ([email protected])

Instituto Nacional de Estatítica

Tel: +351 218 426 100Fax: +351 218 454 083e-mail: [email protected]

Date: 29 Dec. 2017

https://creativecommons.org/licenses/by-sa/4.0/legalcode

Table of Contents

Introduction.............................................................................................................................1

Guidelines and recommendations.........................................................................................2

Open source solutions and projects.............................................................................2

What is Open Source?........................................................................................2

Why Open Source is good for business..............................................................6

How to make an Open Source Project..............................................................10

Development of training materials..............................................................................18

Sharing and re-using training materials............................................................18

Creating training materials................................................................................18

Conclusions..........................................................................................................................26

Annexes...............................................................................................................................27

Annex A: Open source project launch checklist.........................................................28

References...........................................................................................................................32

Guidelines and recommendations for development of training

materials and for open source solutions and projects

Introduction

Inside the IT departments of Fortune 500 companies, a meaningful shift has taken place

over the past decade. For years, CIOs and CTOs bought closed-source, proprietary, off-

the-shelf software solutions from vendors like Oracle, IBM, SAP and Microsoft to drive

their technological initiatives. However, one only needs to look to see that a dramatic shift

away from closed-source software is occurring in plain sight. [1]

The adoption and integration of open-source technologies have rapidly usurped the

closed-source incumbents, so much so that investors are pouring record amounts of

money into open-source software investments. [2]

Also in the area of statistics we witness the increase of the use of open source software

solutions. Well-known examples of open source software used by statistical institutions

are: R (https://www.r-project.org/), R-Studio (https://www.rstudio.com/), JASP (https://jasp-

stats.org/), Gnu PSPP (https://www.gnu.org/software/pspp/), Hadoop

(http://hadoop.apache.org/) or LimeSurvey (https://www.limesurvey.org/).

New projects emerge every day and they are becoming more and more appealing.

However, one issue should not be overlooked: it is not enough to produce or use good

software solutions. Just as important as developing or using good software solutions, it is

very important to use or develop good support and training materials.

1

https://www.limesurvey.org/

http://hadoop.apache.org/

https://www.gnu.org/software/pspp/

https://jasp-stats.org/

https://jasp-stats.org/

https://www.rstudio.com/

https://www.r-project.org/



Guidelines and recommendations

Open source solutions and projects

What is Open Source?

Open source software is software developed by and for the user community [3].

The Open Source Initiative's (OSI) definition is recognized by governments internationally

as the standard or de facto definition.

OSI definition [4]

Open source doesn't just mean access to the source code. The distribution terms of open-

source software must comply with the following criteria:

1. Free Redistribution

The license shall not restrict any party from selling or giving away the software as a

component of an aggregate software distribution containing programs from several

different sources. The license shall not require a royalty or other fee for such sale.

2



2. Source Code

The program must include source code, and must allow distribution in source code as well

as compiled form. Where some form of a product is not distributed with source code, there

must be a well-publicized means of obtaining the source code for no more than a

reasonable reproduction cost, preferably downloading via the Internet without charge. The

source code must be the preferred form in which a programmer would modify the program.

Deliberately obfuscated source code is not allowed. Intermediate forms such as the output

of a preprocessor or translator are not allowed.

3. Derived Works

The license must allow modifications and derived works, and must allow them to be

distributed under the same terms as the license of the original software.

4. Integrity of The Author's Source Code

The license may restrict source-code from being distributed in modified form only if the

license allows the distribution of "patch files" with the source code for the purpose of

modifying the program at build time. The license must explicitly permit distribution of

software built from modified source code. The license may require derived works to carry a

different name or version number from the original software.

Accordingly, an open-source license must guarantee that source be readily available, but

may require that it be distributed as pristine base sources plus patches. In this way,

"unofficial" changes can be made available but readily distinguished from the base source.

5. No Discrimination Against Persons or Groups

The license must not discriminate against any person or group of persons.

3



Some countries, including the United States, have export restrictions for certain types of

software. An OSD1-conformant license may warn licensees of applicable restrictions and

remind them that they are obliged to obey the law; however, it may not incorporate such

restrictions itself.

6. No Discrimination Against Fields of Endeavour

The license must not restrict anyone from making use of the program in a specific field of

endeavor. For example, it may not restrict the program from being used in a business, or

from being used for genetic research.

7. Distribution of License

The rights attached to the program must apply to all to whom the program is redistributed

without the need for execution of an additional license by those parties.

This clause is intended to forbid closing up software by indirect means such as requiring a

non-disclosure agreement.

8. License Must Not Be Specific to a Product

The rights attached to the program must not depend on the program's being part of a

particular software distribution. If the program is extracted from that distribution and used

or distributed within the terms of the program's license, all parties to whom the program is

redistributed should have the same rights as those that are granted in conjunction with the

original software distribution.

1 Open Source Definition

4



9. License Must Not Restrict Other Software

The license must not place restrictions on other software that is distributed along with the

licensed software. For example, the license must not insist that all other programs

distributed on the same medium must be open-source software. Distributors of open-

source software have the right to make their own choices about their own software.

Software linked with GPLed libraries only inherits the GPL if it forms a single work, not any

software with which they are merely distributed.

10. License Must Be Technology-Neutral

No provision of the license may be predicated on any individual technology or style of

interface.

With the many business and government organizations that now use open source software

such as Linux, it's becoming increasingly clear that price is not the only advantage such

software holds. If it were, companies that adopted it during the Great Recession would

surely have switched back to the expensive proprietary stuff as soon as conditions began

to ease, and that's clearly not the case. [5]

Rather, free and open source software (FOSS) holds numerous other compelling

advantages for businesses, some of them even more valuable than the software's low

price. [5]

5



Why Open Source is good for business

Why Open Source is good for business? [5]

1. Security

It's hard to think of a better testament to the superior security of open source software than

the discovery by Coverity of a number of defects in the Android kernel. What's so

encouraging about this discovery, is that the only reason it was possible is that the kernel

code is open to public view.

Android may not be fully open source, but the example is still a perfect illustration of what's

known as "Linus' Law," named for Linus Torvalds, the creator of Linux. According to that

maxim, "Given enough eyeballs, all bugs are shallow." What that means is that the more

people who can see and test a set of code, the more likely any flaws will be caught and

fixed quickly. It's essentially the polar opposite of the "security through obscurity" argument

used so often to justify the use of expensive proprietary products, in other words.

Does the absence of such flaw reports about the code of the iPhone or Windows mean

that such products are more secure? Far from it quite the opposite, you might even say.

All it means is that those products are closed from public view, so no one outside the

companies that own them has the faintest clue how many bugs they contain. And there's

no way the limited set of developers and testers within those companies can test their

products as well as the worldwide community constantly scrutinizing FOSS can.

Bugs in open source software also tend to get fixed immediately, as in the case of the

Linux kernel exploit uncovered not long ago (2010) [6].

6



In the proprietary world? Not so much. Microsoft, for example, typically takes weeks if not

months to patch vulnerabilities such as the discovered Internet Explorer zero-day flaw.

Good luck to all the businesses using it in the meantime.

2. Quality, Reliability or Stability

In general, open source software gets closest to what users want because those users can

have a hand in making it so. It's not a matter of the vendor giving users what it thinks they

want users and developers make what they want, and they make it well. At least one

recent study has shown, in fact, that technical superiority is typically the primary reason

enterprises choose open source software [7].

3. Customization

Along similar lines, business users can take a piece of open source software and tweak it

to suit their needs. Since the code is open, it's simply a matter of modifying it to add the

functionality they want.

4. Freedom or No vendor lock-in

When businesses turn to open source software, they free themselves from the severe

vendor lock-in that can afflict users of proprietary packages. Customers of such vendors

are at the mercy of the vendor's vision, requirements, dictates, prices, priorities and

timetable, and that limits what they can do with the products they're paying for.

With FOSS, on the other hand, users are in control to make their own decisions and to do

what they want with the software. They also have a worldwide community of developers

and users at their disposal for help with that.

7



5. Flexibility or Agility

When your business uses proprietary software such as Microsoft Windows and Office, an

organization is on a treadmill that requires you to keep upgrading both software and

hardware ad infinitum. Open source software, on the other hand, is typically much less

resource-intensive, meaning that you can run it well even on older hardware. It's up to you,

not some vendor to decide when it's time to upgrade.

A recent example is the “forced/recommended” Microsoft Windows update on new

processors. [8]

6. Interoperability and Open standards

Open source software is much better at adhering to open standards than proprietary

software is. If you value interoperability with other businesses, computers and users, and

don't want to be limited by proprietary data formats, open source software is definitely the

way to go.

7. Auditability

With closed source software, you have nothing but the vendor's claims telling you that

they're keeping the software secure and adhering to standards, for example. It's basically

a leap of faith. The visibility of the code behind open source software, however, means you

can see for yourself and be confident.

8. Support

Open source software is generally free, and so is a world of support through the vibrant

communities surrounding each piece of software. Most every Linux distribution, for

8



instance, has an online community with excellent documentation, forums, mailing lists,

forges, wikis, newsgroups and even live support chat.

For businesses that want extra assurance, there are now paid support options on most

open source packages at prices that still fall far below what most proprietary vendors will

charge. Providers of commercial support for open source software tend to be more

responsive, too, since support is where their revenue is focused.

9. Cost and License management

Between the purchase price of the software itself, the exorbitant cost of mandatory virus

protection, support charges, ongoing upgrade expenses and the costs associated with

being locked in, proprietary software takes more out of your business than you probably

even realize. And for what? You can get better quality at a fraction of the price.

10. Try Before You Buy

If you're considering using open source software, it will typically cost you nothing to try it

out first. This is partly due to the software's free price, and partly due to the existence of

LiveCDs and Live USBs for many Linux distributions, for example. No commitment

required until you're sure.

None of this is to say, of course, that your business should necessarily use open source

software for everything. But with all the many benefits it holds, you'd be remiss not to

consider it seriously.

9



How to make an Open Source Project

Where to start? [9]

Perhaps the time to create a new project is when you realize that you have a tough

technical problem which you can’t solve on your own. Another motivator is when you’re

unable to find and join another project that does what you want it to do. Ultimately, there is

no right answer to the question. You start one when you need one and can’t find an

existing effort.

For enterprises considering a new open source project, you want to start by finding your

unique answer to “why?” Begin by asking a lot of questions about what is important to your

organization. It’s important to start an open source project for the right reasons.

The place to start includes secondary coding projects where an enterprise does not need

to be an authority, and where there may be a larger group of technologists around the

world who can help you solve a problem. If it is not mission-critical code, then it is likely a

good candidate to be open sourced. However, it should also be code that your company is

still actively using and maintaining.

Another issue to consider is whether your project is unique or if others are already working

on similar code because they have similar problems. Is the potential open source project

something that’s important for your company to offer and manage as a project and will

other users seek it as well? If so, then perhaps the idea makes a lot of sense.

You will also need to decide whether you want to donate your code to a vendor-neutral,

non-profit organization or retain some control by owning and running your own project.

Again, the answer depends on what you are trying to achieve.

10



When creating an open source project, at least 8 topics should be addressed:

1. Create a project summary paragraph

Example: "MyScrapt" is a web scraping tool used for extracting data for consumer price

index from websites.

“MyScrapt” works on Linux and Windows, and requires MySQL or Oracle.

2. Select a licence

Open source licenses are licenses that comply with the Open Source Definition — in brief,

they allow software to be freely used, modified, and shared. To be approved by the Open

Source Initiative (also known as the OSI), a license must go through the Open Source

Initiative's license review process. [10]

The following OSI-approved licenses are popular, widely used, or have strong

communities [10]:

• Apache License 2.0;

• BSD 3-Clause "New" or "Revised" license;

• BSD 2-Clause "Simplified" or "FreeBSD" license;

• GNU General Public License (GPL);

• GNU Library or "Lesser" General Public License (LGPL);

• MIT license;

• Mozilla Public License 2.0;

• Common Development and Distribution License;

• Eclipse Public License;

• European Union Public License, Version 1.1 (EUPL-1.1).

11



The EC has released the European Union Public Licence (EUPL), a tool for publishing any

copyrighted work as open source. The licence is legally consistent with the copyright law

of all EU countries and is especially well-suited for public administrations sharing IT

solutions. It is now approved by the EC in 23 official languages of the EU. New version of

open source licence EUPL available, the updated EUPL v.1.2 https://ec.europa.eu/digital-

single-market/en/news/new-version-open-source-licence-eupl-available

3. Select the tools for collaboration

a) Source code hosting service

Several source code hosting service exist1, but perhaps the most well-known/used

nowadays is GitHub (https://github.com/).

b) Community communication tools

Communication is very important in project management. A good communication plan

between project members is vital to project success. The community surrounding the

project must feel as being an active part of it. Without community “buy-in”, a project may

never get off the ground or may not be accepted once it is completed.

Some examples of communications channels/tools are:

• Forum;

• Mailing list;

• Bug tracking system.

1 Bitbucket, CloudForge, OSDN, SourceForge, etc.

12

https://github.com/

https://ec.europa.eu/digital-single-market/en/news/new-version-open-source-licence-eupl-available

https://ec.europa.eu/digital-single-market/en/news/new-version-open-source-licence-eupl-available



4. Release schedule

An open source project and its developers should follow a realistic release schedule. It is a

bad practice to announce releases and keep delaying them. On the other hand, a release

schedule should not be vague, giving the impression of carelessness. Also, a release

schedule show the community that the software is maintained.

5. Roadmap

Once a project is released as open source, its development roadmap and all related

discussions should be publicly available.

Although the roadmap and all discussions about it occur publicly and with the input from

the community, unless it has made other accommodations, the organisation still have the

final word on what goes into the roadmap.

6. Localization

One could argue that internationalization is not a must-have, and that may be the case for

certain kinds of software, especially developer-oriented software. But when making a

product that is for a non-technical end user, it will probably appeal to people all over the

world for whom English is not their native language.

Open source projects that are built from the start with internationalization in mind, enjoy

contributions from translators all around the world who want to localize the software so that

it’s more applicable to their users.

13



7. Documentation

At a minimum, an open source project should have the following documentation:

README – Provides general information about the project. It should tell who the program

is for, what it does and why the user might want to use it.

INSTALL - Provides step by step instructions for how to get it running.

CHANGES - Show a quick history of changes so users can see the evolution and

frequency of updates/releases.

AUTHORS - Identify the developer team and the contributors. Can also give credit to other

software incorporated in the project.

LICENSE - In this file it should be perfectly clear how the software is licensed.

It is a good practice to have more in-depth/complete documentation, namely:

• Wiki;

• FAQ;

• Online demos and videos;

• How To (recipes);

• User guides.

8. Sponsorship

The cost of sponsoring an open source project in a vast majority of cases is way below

how much it would cost to fix bugs or develop features internally.

Many open source developers are keen to take a corporate sponsorship deal for their

project. The same way, an organization can call for sponsorship for an open source

project. In a shared or replicated project one way of sharing costs/efforts is by sponsoring

the project, namely to develop new features or “bug hunting”.

14



In what concerns statistical products, statistical organisations have different options to

cover their requirements:

• They can specify and implement them autonomously;

• They can buy tailored solutions;

• They can share solutions with other organisations.

Sharing solutions has a lot of advantages, but has also challenges that have to be taken

care of.

Building a new service in collaboration

Starting point: Two or more statistical organisations have agreed to collaboratively develop

a new service from scratch.

Challenges:

• Getting the requirements and prioritize;

• Agree on licensing, timelines and financing;

• Organize work;

• Follow the “How to make an Open Source Project” slide list.

Integrating new features

Starting point: A service has already been developed, either by an individual organization

or already in collaboration.

15



Challenges:

• New requirements appear over time (i.e. new methods should be included);

• Not all users agree on new features to be included;

• Allow for forks of development and different stages of engagement.

Maintenance

Starting point: Services (shared or replicated) are in production.

Challenges:

• Bug fixing has to be organized;

• Security issues have to be solved;

• New versions of underlying software (Java!) have to be addressed.

Support

Starting point: Services (shared or replicated) are in production. Services have to be

deployed and integrated.

Challenges:

• Usage of software has to be explained

− Training

− Day-to-day support

• 1st level support has to be organized

16



Funding

Starting point: Along the whole service life cycle.

Challenges: How can costs/efforts be shared?

Solutions:

• Sponsoring;

• Participation in kind: Staff assigned to development and production;

• Setting up a fund (participation based on capacity).

An organization can increase the chances of a project success by carrying out an

extensive planning process prior to launch. The project launch checklist is a key element

of this process. It allows to verify that all essential elements of the project plan are in place.

In annex A we present an “Open source project launch checklist”. [11]

17



Development of training materials

Training programs for open source software provide a tangible, and sellable, product. A

successful training program not only builds revenue, it also adds to the overall body of

knowledge available for the open source project. By gathering best practices and taking

advantage of the collective expertise within a community, it may be possible for a business

to partner with an open source project to build a curriculum that promotes the project and

supports the needs of the company's training customers. [12]

Sharing and re-using training materials

"NO MATTER WHAT – DO NOT create training from scratch. Really! Before you sit down

to create that next manual, quick reference, user’s guide, STOP. Throw your question out

to your online social network for help and you will be amazed at all of the information that

will come your way. These are, after all, information professionals."

Beg, Borrow, “Steal” – Don’t Reinvent the Wheel When Creating Training [12]

Two notable models for developing open source training can be found in the Ubuntu

Learning Project1 (https://wiki.ubuntu.com/Learning) and the Flossmanuals.net project2

(http://flossmanuals.net/).

Creating training materials

In the absence of suitable training materials, an organization needs to create them from

scratch.

1 The Ubuntu Learning group is an umbrella for a number of educational projects.2 The Flossmanuals.net project offers a wiki-based book authoring system and accompanying book sprint model.

18

http://flossmanuals.net/

https://wiki.ubuntu.com/Learning



Designing a Training Manual [13]

Training manuals are particularly useful in the following situations:

• Trainees can use the manuals for reviewing the subject after training;

• It lets the trainee concentrate on and partake in the training during the training

session instead of taking detailed notes;

• It can serve as a reference document in the work place.

Developing a training manual is an important part in designing a formal training program. A

formal training manual ensures consistency in the presentation of the training program.

Another major advantage is that all the training information on skills, processes, and other

information necessary to perform the tasks is together in one place. Training manuals

should support the training objectives.

Manuals are generally developed using the most commonly used instructional design

models - the "ADDIE" model [14].

The ADDIE model is the generic process traditionally used by instructional designers and

training developers. The five phases - Analysis, Design, Development, Implementation,

and Evaluation - represent a dynamic, flexible guideline for building effective training and

performance support tools.

"A" stands for Analysis of the audience, and of training needs;

"D" stands for Design of training, its objectives, sequencing of tasks, etc.;

"D" represents Development of training/instructional materials, that are consistent with the

design requirements;

"I" means Implementation of the training;

"E" is Evaluating the training.

19



Training manuals can be designed to be used as:

• Work books – often used in training sessions. It provides basic information,

examples and exercises.

• Self-paced guides: designed for trainees to work through on their own.

• Reference manuals: for containing detailed information on processes and

procedures.

• Handouts: provide general information to support training done during the session.

• Job aids: provide step-by-step instructions to be used in the work place.

A well designed training manual, that is kept up to date, can become a valuable source of

information to the organization.

An effective manual:

• Is easy to read and has easy to follow instructions;

• Has an attractive design;

• Uses illustrations to enhance understanding;

• Can be used for future reference.

The following topics should be taken in consideration when designing the manual:

• Content – topics, tasks, procedures and other information arranged in a logical

sequence and broken down into small units;

• Audience – their reading skills, previous work experience;

• How the manual is to be used during the training session, afterwards (for revision)

and/or as a reference in the work place.

The training manual can have different versions for the trainer/presenter and the trainees.

The version for the trainer would include the basic text, prompts for discussions and

20



demonstrations or other activities. It could also include information or checklists on

preparation for the session. The trainee’s version will have the basic text, examples and

exercises, as well as space for making further notes.

Writing the manual

Once the purpose for the manual has been established and attention has been given to

the preliminary design, the main task of writing is the next step. First, organize the

contents into a logical sequence of topics. Break down the topics into smaller segments

that describe a task, procedure or concept. Include an overview on how to use the manual.

As preparation for the training session give a list of key points or a summary of what is

going to be covered at the start of each chapter.

What are the key elements of a Training Manual

The Training Manual may contain the following elements:

• A Cover page with plain or graphic with Title clearly written

• A Blank page after the cover page

• Table of contents

• An Introduction page on What-How-Who - "What the Manual is about", "How to use

the Manual" and "For whom the Manual is meant"

• A Navigational Tips page with visually catchy icons which will be used throughout

the manual

• Expanding the Table of contents - Objectives / Description of each topic / Section

Summary

• Placeholders for graphics

• Placeholders for work sheets

• Page for Conclusion

• Page for Further Reading

21



• Page for Bibliography / References / Citations

• A Blank page prior to closure

• Closing Cover page

The following advice has been given by many authors:

• Write in plain English: Avoid using technical terms, unless it is part of the work place

vocabulary. In that case make sure technical terms are explained in simple

language/terms. Spell out or explain acronyms and abbreviations.

• Use the active voice: It is concise.

• Be consistent in the use of terminology, tone and style of writing.

• Long sentences and paragraphs can be confusing. Use short sentences and

phrases. Numbered steps are easier to follow than long paragraphs.

• Include illustrations (graphs, flow charts, tables, pictures, screen displays, examples

of finished tasks) where appropriate to clarify concepts and enhance understanding.

It also adds visual interest. Illustrations should be in proper proportion to nearby

text.

• Write a detailed table of contents that include chapter headings as well as the next

level of subheadings.

• Write a detailed index, including cross-references, to make it easy to find

information. A good index makes the manual usable as a reference work for future

use.

• Check spelling and grammar.

After the completion of the first draft get feedback from trainers/presenters and other key

personnel. Implement any suggestions if appropriate.

The title page, table of contents, a glossary of terms (if used) and the index are prepared

last. On the title page the following should appear: Name of the manual, author(s),

22



company name, publishing date. A copyright notice can be included, as well as

acknowledgement of contributors if appropriate.

Presentation

An attractive appearance and ease of use can motivate the trainees to use the manual and

thus reinforce learning. Good page layout increase readability and make the information

more accessible. The organization of the material on the page guides the eye of the reader

- which areas get attention and in what order.

Graphic design principles

• Proximity: Group related pieces of information and other items together to form a

cohesive unit, e.g. illustrations should appear on the same page as the related text.

That is part of organizing the content in a logical order. Avoid too many separate

elements on the page. Use close proximity to indicate unity between items. Use

white space to separate unrelated items

• Alignment: The alignment of text and graphics is another technique in organising

the page. All the elements (text and graphics) should appear unified and interrelated

by their placement on the page.

• Repetition/Consistency: Consistency in the style of the elements (headings,

graphics, arrangement) gives visual clues to the reader. It also unifies the different

part of the manual and creates visual interest.

• Contrast: Creating contrast between sections visually organise the page, leading

the eye in a logical flow from one section to the next. Contrast is created by the use

of fonts, line thickness, colours, shapes and space. Create a strong contrast to be

effective.

• Fonts (or type): Avoid using more than two or three fonts in a document. Fonts can

be in italic, bold, light, heavy, or condensed versions. Avoid all uppercase – it is

difficult to read – use bold, italic or other versions of the font for emphasis. Titles,

headings and subheadings should be in a larger size font than the body of the text.

23



When combining different fonts, use fonts that are clearly distinct to create contrast.

It is often recommended to use a sans serif font for headings and a serif font for the

body of the text.

• Colour: It could be used in text for emphasizing and in graphics where appropriate.

When used judiciously it increases learning and retention. Avoid overuse of colour

as it loses its interest value.

Ease of use

Another consideration apart from the page layout is the collation of the manual to make the

final product easy to use. The following techniques might be helpful:

• Section dividers that extend beyond the page width make it easy to find sections,

especially if it has the topics printed on the tabs. This is especially appropriate for a

bulky manual that is to be used over several sessions.

• A detailed table of contents at the beginning of sections, in addition to the main

table of contents at the front of the manual makes it more accessible.

• Allow wide enough margins to accommodate the type of binding used, as well as

space for users to make key notes.

• When considering binding, use a method that would allow easy replacement of

pages. The manual can be updated easily, which adds to its reference value.

Legal issues

It is also very important to be aware of copyright and other legal issues before reproducing

the manual.

One of the most difficult tasks in developing quality training experiences is coming up with

authentic lab exercises and case study scenarios. Many people are reluctant to document

when they make mistakes but those experiences are what make great learning

24



experiences for others. How to deal with those issues becomes best practices which can

be fed into course development. [12]

25



Conclusions

Open source is not a business model for earning money. Trust and mutual benefits are

essential prerequisites. Working on this baseline is not new for statistical organizations

around the world. We hope we have shown how FOSS can be a template for collaboration

in CSPA/SERV.

“Sponsoring” by more advanced or capable organizations is welcomed.

Organizations can share and re-use software, but they can also share and re-use training

materials. However, in the absence of suitable training materials, organizations need to

create them from scratch. Special care should be taken when developing those materials.

26



Annexes

27



Annex A: Open source project launch checklist

28



Open source project launch checklist

Considerations

✔ Evaluate possibility of joining an existing open source project

✔ Evaluate the company’s ability to launch and maintain the project using the open

source model

✔ Evaluate the likelihood that other organizations may join the project from the start

✔ Evaluate success factors and set appropriate metrics for the open source project

Business strategy & plan

✔ Determine and set goals for your project

✔ Gather reasons for doing it from stakeholder

✔ Select code to be considered for the project

✔ Decide whether the project will include all code for an application or just parts of it

Create a business case for the selected proposal

✔ Determine if there is executive buy-in for the move

✔ Plan resource commitments for developers and funding

✔ Set budgets for costs, including development time, infrastructure and related

expenses

✔ Gather executives and tech staff for project discussions and decision-making

✔ Debate and finalize project scope and code selection

Legal Review

✔ Consider the impact of open sourcing on your company’s intellectual property

29



✔ Ensure full compliance with open source licenses

✔ Select an open source license for the source code to be released, document all

licensing requirements very clearly in your project

✔ Decide if you need a contributor agreement

✔ Consider the possible non-software outputs from the community and the

appropriate licenses, such as documentation and specifications

✔ Decide on any trademark related considerations

✔ Decide whether there are additional factors to build into your plans for an

ecosystem, such as conformance testing

Technical Review

✔ Remove critical dependencies on non-public components

✔ Provide documentation and use case examples

✔ Remove internal comments, references to other internal code, etc.

✔ Ensure coding style is consistent

✔ Update copyright notices in source code files

✔ Add license notice in source code file

✔ Add license text as a file in the root directory

Governance and Processes

✔ Define project governance steps and structure

✔ Set up a code repository, bug reporting, and code testing infrastructure

✔ Create supporting Slack channels (https://slack.com/), forums, and Wikis

✔ Create open lines of communication with contributors for project success

30

https://slack.com/



Branding and Marketing

✔ Set marketing strategy to promote an active contributor community

✔ Design project logo, color scheme, website, collateral, etc.

✔ Formalize branding guidelines

✔ Register social media accounts for the project (Twitter, Facebook, LinkedIn, etc.)

✔ Register domain names for the project

Launch and Maintain

✔ Open project and begin development work and contributions process

✔ Designate a community manager or community advocate

✔ Ensure any changes to direction or governance are clearly communicated

✔ Follow best practices of other similar communities

✔ Encourage and provide opportunities for face-to-face community building

31



References

[1] McCann, J. (September 2017). “The Meteoric Rise Of Open Source And Why Investors

Should Care”. [Online]. Available at:

https://www.forbes.com/sites/forbestechcouncil/2017/09/22/the-meteoric-rise-of-open-

source-and-why-investors-should-care/#62effb285484

[2] Thakker, D et al. (April 2017). “Tracking the explosive growth of open-source software”.

[Online]. Available at: https://techcrunch.com/2017/04/07/tracking-the-explosive-growth-of-

open-source-software/

[3] Open Source Initiative (2017). [Online]. Available at: https://opensource.org/

[4] Open Source Initiative (2017). “The Open Source Definition (Annotated)”. [Online].

Available at: https://opensource.org/osd-annotated.

[5] Noyes, K (2010). "10 Reasons Open Source Is Good for Business". PCWorld.

[Online] . Available at:

https://www.pcworld.com/article/209891/10_reasons_open_source_is_good_for_business.

html

[6] Noyes, K. (2010). "Linux Kernel Exploit Gives Hackers a Back Door". PCWorld.

[Online]. Available at:

https://www.pcworld.com/article/205867/linux_kernel_exploit_gives_hackers_a_back_door.

html

[7] Noyes, K. (2010). "Linux Is on the Rise For Business”. PCWorld. [Online]. Available

at: https://www.pcworld.com/article/207479/linux_on_the_rise_for_business.html

32

https://www.pcworld.com/article/207479/linux_on_the_rise_for_business.html

https://www.pcworld.com/article/205867/linux_kernel_exploit_gives_hackers_a_back_door.html

https://www.pcworld.com/article/205867/linux_kernel_exploit_gives_hackers_a_back_door.html

https://www.pcworld.com/article/209891/10_reasons_open_source_is_good_for_business.html

https://www.pcworld.com/article/209891/10_reasons_open_source_is_good_for_business.html

https://opensource.org/osd-annotated

https://opensource.org/

https://techcrunch.com/2017/04/07/tracking-the-explosive-growth-of-open-source-software/

https://techcrunch.com/2017/04/07/tracking-the-explosive-growth-of-open-source-software/

https://www.forbes.com/sites/forbestechcouncil/2017/09/22/the-meteoric-rise-of-open-source-and-why-investors-should-care/#62effb285484

https://www.forbes.com/sites/forbestechcouncil/2017/09/22/the-meteoric-rise-of-open-source-and-why-investors-should-care/#62effb285484



[8] Microsoft (19 Apr 2017). "The processor is not supported together with the Windows

version that you are currently using". [Online]. Available at:

https://support.microsoft.com/en-hk/help/4012982/the-processor-is-not-supported-

together-with-the-windows-version-that

[9] The Linux Foundation (2017). "Starting an Open Source Project - Where to start".

[Online]. Available at: https://www.linuxfoundation.org/resources/open-source-

guides/starting-open-source-project/#3

[10] Open Source Initiative (2017). "Licenses & Standards". [Online]. Available at:

https://opensource.org/licenses

[11] The Linux Foundation (2017). "Starting an Open Source Project - Open source project

launch checklist". [Online]. Available at: https://www.linuxfoundation.org/resources/open-

source-guides/starting-open-source-project/#7

[12] Lopez, B. 2010 (January 2010). "Developing a Successful Open Source Training

Model". Open Source Business Resource. [Online]. Available at:

http://timreview.ca/article/319

[13] Wikibooks (2017). “Designing a Training Manual”. [Online]. Available at:

https://en.wikibooks.org/wiki/Designing_a_Training_Manual.

[14] InstructionalDesign.org (2017). “ADDIE Model”. [Online]. Available at:

http://www.instructionaldesign.org/models/addie.html.

33

http://www.instructionaldesign.org/models/addie.html

https://en.wikibooks.org/wiki/Designing_a_Training_Manual

http://timreview.ca/article/319

https://www.linuxfoundation.org/resources/open-source-guides/starting-open-source-project/#7


https://opensource.org/licenses



https://support.microsoft.com/en-hk/help/4012982/the-processor-is-not-supported-together-with-the-windows-version-that

https://support.microsoft.com/en-hk/help/4012982/the-processor-is-not-supported-together-with-the-windows-version-that

Documents

ESSnet SCFE DELIVERABLE D5-4 · This document is licensed under a Creative Commons License: Attribution-ShareAlike 4.0 International ESSnet SCFE DELIVERABLE D5-4 Guidelines and recommendations