Working paper 2013/19

7 June 2013


High-level group for the modernisation of statistical production and services (HLG)

Meeting, Geneva, 14 June 2013



Software Collaboration and Sharing at Statistics Canada


Executive Summary


In keeping with its international strategy, IT strategy and Corporate Business Architecture principles, Statistics Canada would like to further collaborate with its NSO partners on sharing and developing software. This paper describes Statistics Canada’s experience and practices, highlighting key success factors and challenges.


The key models for collaboration are:



Scope of collaboration

Share software code

The organization that owns the software provides a ‘licence to inspect and modify the code’, and possibly to distribute the modified code.

Share software executable

The organization that developed the software provides a ‘licence to use’, directly or via a reseller. Typically, maintenance and support is also provided.

Collaborative development

Organizations develop the software together. Partners can contribute in kind or financially, and third parties may also contribute, such as contractors or the Internet community. An appropriate open source software licence would best meet the needs for this model.


While there is no formal guidance to the Government of Canada departments on software collaboration, Statistics Canada can

  • provide a licence to others to use, modify and distribute software where it is owner of the copyright for all components.
  • release its software under an Open Source licence of its choice, if this will meet its needs and with an understanding of the risks involved.
  • participate in existing Open Source initiatives and hire contractors to contribute to Open Source software.
  • enter into other forms of collaborative development arrangements, with some limitations.


StatCan should select with its partner NSOs an appropriate first collaboration initiative of mutual value.  To maximize success, the recommended approach is to adopt best practices, processes, culture, tools and methodologies from the Open Source, to adopt agile and lean methodologies, and to use a suitable recognized Open Source licence.


Some key success factors for collaborative software development are

  • clearly articulated purpose, outcomes and roles and responsibilities
  • strong project management, with a focus on participant co-operation, communication and empowerment
  • commitment to compromise to achieve desired common outcomes, supported by a solid planning and change management framework to control diversity, complexity and scope
  • strong management support
  • engaging all participants who have the right mindset, with mechanisms in place for continuous interaction
  • a core of participants with experience with open source software development or co-development.


Key challenges are

  • adjusting to the culture of the open source model
  • fear of loss of control
  • compliance with legislated standards and directives of each country.


StatCan’s significant experience building generalized systems and adoption of service oriented architecture and shared models such as GSIM and GSBPM makes it now possible to pursue a software collaboration initiative with partner NSOs. In addition, StatCan is looking into making some of its existing generalized systems available to other NSOs as Open Source, provided it can ensure that the software can continue to meet its own requirements.


1.     Introduction

This document presents the Statistics Canada (StatCan) and Government of Canada (GC) context for collaborating on software development and sharing software with other organizations such as other national statistical offices (NSOs). It also presents some case studies, with associated lessons learned, and proposes a set of requirements for successful collaboration, including licensing considerations.


StatCan context — collaboration as an enabler to CBA

In 2009, StatCan embarked on a redesign of its corporate business architecture (CBA). This initiative has three key objectives:

  • enhance the quality of its products and services
  • improve responsiveness in delivery of new statistical programs
  • deliver operational efficiencies.


To achieve these objectives, StatCan is streamlining core business processes and implementing a rationalized set of robust and flexible systems aligned with its business architecture. Key enablers include a suite of generalized systems that automate statistical methods, standard collection architecture, tools and processes, and shared IT platforms and services. The GC is also reviewing its business architecture for the delivery of common services including finance, HR, and IT. Its Chief Information Officer is directing all departments to rationalize, standardize, reuse, cluster and collaborate.


StatCan, in keeping with its international strategy, IT strategy and CBA principles, would like to further collaborate with its NSO partners, to

  • initiate new joint software development initiatives, enabled by the Generic Statistical Business Process Model (GSBPM), the Generic Statistical Information Model (GSIM) and the Common Statistical Production Architecture (CSPA), colloquially known as the “Plug and Play initiative”
  • leverage the efficiencies and potential for innovation of the open source collaborative process itself
  • improve how it shares software with partners in the GC and counterpart NSOs.


Why should we do this?

The benefits that StatCan seeks through this increased collaboration are

  • improved quality of its software, which in turn will improve the quality of its programs
  • software that is more agile to respond to changes in business requirements
  • reduced total cost of ownership of software, where common processes and methods are adopted
  • improved alignment to the GSBPM and the GSIM, which in turn will enable further collaboration
  • improved interaction with stakeholders by using common models and standards as well as greater interoperability
  • opportunities for staff to learn new statistical and IT methodologies, approaches and skills.


2.     Legal Framework in the GC

Before presenting how software collaboration is affected by the GC legal framework, it is important to provide some key definitions.


What is software?

Software essentially comprises “computer programs,” which are considered literary work and therefore subject to Canada’s Copyright Act. Software also comprises elements that are also subject to the Copyright Act, such as

  • executables, or object code
  • source code — for the core software and any supporting tools
  • documentation
  • data that might drive functionality (e.g., configuration or code tables).


The owner of a copyright title and moral right title to software provides others specified rights to it via a licence, which can provide the licensee the rights to do one or more of the following:

  • install and use
  • distribute instances of the original software
  • inspect and learn from the source code
  • change the source code, install and use it
  • distribute the modified software.


The licence also provides any other rights, restrictions, conditions or obligations required by the owner of the software. It typically includes terms regarding intellectual property (IP), liability, indemnification, confidentiality, termination and appropriate law, among others. A key consideration is that determining entitlement for software requires knowing the source of all its elements. If GC employees produced all the elements, then the GC owns all rights to the software; if open source or propriety software components are included, or if contractors developed components, then determining entitlement becomes more complex.


For federal government organizations, the Financial Administration Act makes software a capital asset that can be capitalized, expensed, and declared surplus. Federal managers therefore track the effort and costs associated with designing, developing, implementing, enhancing and supporting in-house software, as these costs are capitalized or expensed in departmental financial statements.


What is FOSS[1]?

‘Free and open source software (FOSS), or simply ‘open source software’, refers to computer software applications for which the authors or copyright holders release the source code under a licence. That licence authorizes anyone to use the software, modify it and redistribute it. While FOSS terms and obligations vary greatly, several categories of clauses are commonly used:

  • general disclaimers of warranty and/or liability
  • notice obligations, which generally require the licencee to notify downstream users of the particular FOSS licence that applies to the work
  • source code obligations, which generally require the licencee to provide the source code of the software when they distribute it
  • hereditary licensing obligations, which generally require the licencee to only release any modifications or improvements as FOSS under the same licence.


The first two disclaimers and notice obligations are present in nearly every FOSS licence.

FOSS licences are usually classified as

  • hereditary, where the licence includes an obligation to ‘inherit’ the licence for modifications made to the software
  • permissive — where the licence includes no such obligations.


This categorization is very simplified: hereditary and permissive licences include widely varied obligations and circumstances where they take effect. For more details, please refer to Annex A.


Guidance to Canadian federal departments and agencies

There is presently no up-to-date formal guidance to Canadian departments and agencies on software collaboration and participation to FOSS development. Instead, departments and agencies are asked, before embarking on such initiatives, to consult their departmental legal advisors: each situation is unique and can present different risks depending on the participants, the nature of the software, existing licensing applicable, liability implications and other considerations. That said, we can confirm the following advice.

  • Departments and agencies are encouraged to collaborate on software development and to share software across all levels of the Canadian public sector.
  • The Financial Administration Act must be given due consideration when determining capitalization of software assets and coding employee time and other monies spent on FOSS or other collaborative software development, enhancement and support.
  • Compliance with the Contracting Policy is essential: co-development arrangements cannot be used or be even perceived as an alternative to procurement of IT services.
  • StatCan is subject to the Communications Policy of the Government of Canada and must manage the administration and licensing of Crown copyright in co-ordination with the Department of Public Works and Government Services. Within StatCan, Information Management Division is responsible for all licensing except software licensing, which is the responsibility of Informatics Branch.
  • Consult Legal Services before finalizing any co-development agreement with an organization outside the GC, or before formally selecting a licence for the resulting software.
  • Consult Legal Services before issuing any new licences for software StatCan owns.
  • Ensure that any existing licensing rights, conditions and obligations of components or supporting tools are respected by employees, contractors and partners using their software.
  • Ensure that IP rights of all other parties are respected, including those of contractors who have contributed code and may have retained IP rights as per clauses in their contracts.
  • The resulting software is still subject to all GC policies, directives and standards such as Common Look and Feel (CLF) for Web applications and bilingualism. Exemptions can be sought when necessary for the success of the initiative, but should be approved before proceeding.


The table below provides some examples of what we can and cannot do in the GC:


Can we?


Give away IP to another organization to our existing code

No, even if we have all rights for all its components.

Instead, we can provide a licence with the appropriate terms and conditions.

Provide a licence to our software or contribute our existing software to a software collaboration initiative or open source initiative

It depends. The type of licence we can offer depends on the rights we have to all the components of this software. Automated tools are available to support this analysis.

The decision must be fully informed and must consider all implications and risks. StatCan already provides various types of software licences to NSOs and others.

Take over IP to code we don’t own after we have modified it

No, but we may still have a licence that allows us to modify the code, use it, and perhaps distribute it, depending on the licence granted to us.

In the end, what matters is that we can do what we need to. We should ensure that our needs can be met before we embark on a co-development agreement.

Start a new open source software development project, or contribute to an existing project

Yes, GC employees can, and do, contribute to FOSS development projects, as long as they have been approved by their senior managers and are of benefit to the GC. Departments can also hire consultants to enhance FOSS that is used to support their programs, and to provide maintenance and support services.

If we start a new project, it gives us the flexibility to choose the appropriate licence model, unless reusing existing components with more restrictive licences or pre-existing IP. Resources spent on FOSS development should be coded as per Financial Administration Act rules.

Contribute financially to another organization’s software development in return for a licence

Yes, but subject to proper procurement rules (granting authority) if the organization is outside the GC  essentially the same rules as for procuring a licence.

An MOU or agreement should be put in place if contributing before development is completed, and include the licence to be issued. If development is completed, only the licence is required.

Co-develop software with other organizations (with or without a FOSS licence)

Yes, but an MOU should be put in place to ensure clear understanding of all parties, and licence agreement should also be negotiated beforehand if outside of GC.

There are many forms of collaboration: contributions can be ‘in kind’ or financial, a third party can be contracted to do the work, for example.

Continue on our own with software developed initially as open source

Yes, referred to as ‘forking’: but all restrictions specified in the open licence need to be respected.

Forking should be a last resort option to maximize benefits of collaboration.

Enter into a co-development arrangement to enhance our software

Yes, but must clearly not even appear to bypass procurement policies.

Licence agreement should be negotiated beforehand.


3.     Collaboration Models

Collaboration on software can range from sharing best practices, models and/or methodologies to working together from initiation to implementation and even sharing infrastructure as well as support and maintenance services. All collaboration models can achieve benefits, though at different levels and with different advantages and disadvantages. It is also possible to go back and forth between models at different stages, with some limitations. Annex B presents four StatCan examples of software collaboration using different models.


Sharing model — “To allow someone to use or enjoy something that one possesses”

In this model, partners share their software under different terms, which may or may not allow the recipients to ‘make it their own’. This model offers great opportunities for cost-saving, and can bring us closer to the true collaboration model — the more we already share, the easier collaboration will be. Sharing is the model most used by NSOs and is further enhanced by a shared inventory of software and the creation of user communities. The table below presents some shared and associated considerations:



All non-code deliverables

The Copyright Act is still applicable for user requirements, specifications, design documents, models and standards, etc. In practice however, these are shared freely with the understanding that they remain the IP of the author, and that citations will be included where distributed to third parties.

Code (executable) and documentation production version

Code is shared by its owner by issuing a licence to the software to those who wish to use it. This licence includes the rights to install and execute the software, but may or may not include the right to view the code, modify it and distribute it, depending on the circumstances. For most applications built by StatCan and shared with other NSOs, the licence does not provide access to the code. The licence issued may be free or for a fee: the code may be provided directly by the organization that developed it, or may be issued and licenced via a reseller. The organization acquiring the software will of course need to separately acquire any required database management system (DBMS) and other commercial off-the-shelf (COTS) software required to run the code, such as SAS. However, the software may also be provided in the form of ‘software as a service’ (SaaS), hosted on infrastructure provided by the organization that developed it, or by a third party. The organisation acquiring the licence under this model would conduct a fit-gap assessment of the functionality offered by the software against its own requirements, just as it would for any COTS. A key consideration when acquiring the software under this licence model is whether the provider organization will consider its requirements when maintaining and enhancing the software, especially if it plans to invest significantly in the software implementation. As well, the provider organization must also be very careful in committing to integrating client organizations`future requirements or ensuring backward compatibility. ‘Best effort’ is generally the principle applied.

Source code and documentation

As for the above, code is shared by its owner by issuing a licence (possibly FOSS), but in this case it provides the rights to modify the source code. The acquiring organization may then create its own version of the software, and can contribute back their updates (which may be required by the licence issued). What started as code sharing can then later turn into a collaboration initiative.

Implementation, maintenance and support services

Sharing in this context means that one organization provides the services to another. Given the costs incurred by the provider organization, financial arrangements are required. This service can also be provided by one organization (or a third party) after an application is developed collaboratively and can even be provided when an organization has modified the source code to meets its unique requirements. For generalized systems, StatCan provides maintenance and support services to NSOs who acquire a production version and pay the annual maintenance fee.


Sharing in this context is one organization providing the infrastructure (development, testing and/or production) to another. This could include the required platforms in a ‘platform as a service’ model, such as application integration software or DBMS. However, given the current StatCan network topology context, and the legal implications of having SSI data residing on another country’s infrastructure, this would be extremely challenging for StatCan.

Software as a service (Saas)

Sharing in this context is one organization hosting the entire application to another — software as a service. The same considerations and challenges as for sharing infrastructure apply to SaaS.


Collaborative development model — “Working together to achieve a goal”

While collaboration potentially offers more benefits than sharing, it also offers more challenges. The resulting application needs to meet the needs of all participating organizations, including compliance with their respective standards and the ability to run on all partners’ platforms (unless using Saas): the application must also be robust, flexible and high-performance. The table below provides a simplified overview of which deliverables can be developed collaboratively, and the associated attributes. More details on what is needed for successful collaboration are covered in Section 4.


Scope of collaboration


Planning artefacts, methodologies and practices

Develop together project management plans, governance structures, methodologies and other documents.

Unless subsequent deliverables are also developed collaboratively, value-added may be limited.

User requirements and specifications

Develop user requirements and specifications that meet the needs of all partners — with plans to develop jointly — or have one partner develop and later share code or executable under a licensing model, or each partner still develops their own. Collaboration could be partial — initial requirements and/or specifications done together and then bifurcate for the following phases.

Collaborating on user requirements and specifications would be of limited value if the resulting application is not developed collaboratively or developed by a partner and shared by others. Agreeing to a set of prioritized requirements for the shared software that meet the needs of multiple NSOs would be challenging but necessary if code would be jointly developed.

Architecture and design

Similar to above, but could be done with or without collaborating on the code. User requirements need not be identical.

Would be of value independent of other deliverables being developed collaboratively.

Models and standards

Joint development of models and standards can be done independently of collaboration on any other deliverable.

There are many benefits from collaborating on shared models and standards, even if everything else is done individually. GSBPM and GSIM are examples of successful collaboration on models.

Code and documentation

The partners would use a ‘divide and conquer’ approach — break down the software into smaller parts or modules and give them to different developers or teams of developers to work on separately. A development platform and agreed-upon licence would be required. System and user documentation for the shared/core software should also be written together and then translated as needed by each organization.

All above deliverables need to have been developed collaboratively for the shared functionality/core software. Some organization-specific components and modifications to existing applications would also likely need to be developed by each partner. Each would also need to configure the core software to meet its needs, including any reference tables. Benefits include high code quality and reduced costs.

Support services

Partners can develop a fully collaborative service model, in which support services are provided by all partners. This can be done even if previous deliverables were not developed collaboratively (share model). However, the fact that all previous deliverables were developed collaboratively does not automatically require that support services be provided collaboratively.

Unless the application is hosted and provided as SaaS, each partner may want to provide its own first-level support services or use a third-party provider due to language and time zone barriers. However a best practice would be for second-level support to be shared.

Maintenance services

Unless a partner has decided to go their own way, they would continue to collaborate for the ongoing maintenance of the software. As for support services, they may also wish to collaborate on Maintenance even if the software was not developed collaboratively (share model)

As for all previous phases, collaboration can take many forms, including financial contribution.

Collaboration should continue for Maintenance to reduce costs.


Partners collaboratively provide and support a shared infrastructure, or have it provided by a third-party. They can also only collaborate on the Development and/or Testing infrastructure.

The same considerations apply here as for the ‘share infrastructure’ model. This may use an “infrastructure as a Service (IaaS) and/or “Platform as a Service (Paas) model.

Software as a service (Saas)

Partners collaborate to provide the hosted application as a service, on a shared infrastructure. Any required software licenses (for example SAS and DBMS) would need to permit such an arrangement.

Same considerations apply here as for the share infrastructure model.


The above table offers very simplified options, and many other variants are possible. Also, partners can use a divide and conquer approach for any deliverable above, though it is most useful for the construction phase. Of course, solid project management and governance will be essential to ensure cohesion and efficient delivery, and that each organization is realizing the desired outcomes of the project.


4.     What is needed to collaborate on software development?

During the planning phase

  • Negotiate a written agreement. At minimum, this agreement, or MOU, should identify the vision and objectives for the initiative, the benefits sought and roles and responsibilities of all parties, the high-level project plan and associated deliverables, IP rights assignment for the resulting software, financial arrangements and contributions in kind, termination and notices clauses, liability, and other pertinent information. It should specify the licences to be used for the resulting software.
  • Identify any existing code that will need to be used for the project including any FOSS, ‘shared source’[2] or ‘closed source’: this will inform the decision on the software licence.
  • Select a software licence. While an MOU is sufficient to collaborate with other federal departments, as the GC is considered one legal entity, collaboration with other organizations requires a software licence for the resulting software. A suggested approach is to select an existing commonly used open source licence: however, it is not recommended that StatCan select one licence model and impose it on all collaborative projects. Instead, StatCan and its partners should select the most suitable licence model for each project, considering potential security risks, IP protection, all partners’ constraints (including their respective legal frameworks), and the outcomes sought. Some considerations:
    • There will not always be a choice as to which licence to apply. Where a hereditary licence obligation is already in force, the code must remain under the same licence.
    • When distributing a project comprising entirely one’s own code, and/or code that does not engage hereditary obligations, any FOSS licence will do. It is also possible to dual-licence code, for example to participate in two different communities that use different licensing norms.
    • Overall, licensing decisions usually involve one consequential decision: whether to apply a hereditary or permissive licence. Permissive licences maximize the scope of downstream users, with broad appeal to the entire private sector; hereditary licences are appropriate in cases where it is important to receive back downstream changes, or where it is important to ensure that work built on an initial investment remains open and free.
    • In some circumstances, an open source licence may not be the right choice: instead, a customized licence may need to be developed in order to meet the needs of all parties.
  • Agree on the set of prioritized user requirements that the new shared ‘core’ application must meet, and on what will be met by new country-specific components or existing country-specific applications. Coming to a consensus on user requirements, and associated methodologies, will be challenging but essential. We face this challenge continually in developing generalized systems that must meet the needs of disparate clients within StatCan. Every effort must be made to streamline and prioritize the collective set of requirements, yielding a system that is not unduly complex: needless complexity could compromise the performance and maintainability of the final system. Of course, multilingual support and CLF compliance for web applications are two key StatCan requirements; each country will have their own set of mandatory requirements to address. The key will be to find ways to address them while keeping the shared components as simple as possible. Standardization and alignment of statistical methods and processes across survey programs within StatCan has proven effective when a solid planning and change management framework is in place. Solid executive support is also key for consolidating and streamlining requirements.
  • Agree on IT methodology, tools, platforms, models and standards. Participating organizations must select together a development methodology (Agile and Lean are most appropriate) and a set of development tools (including any database and application integration) to be used. The participants must also agree on a set of coding and documentation standards and code review processes. If the tools to be used involve COTS to run the resulting application (for example SAS), then all current and future participants will have to acquire this COTS and possibly harmonize future upgrades, assuming that the resulting application will be deployed independently in each organization (i.e., not a SaaS). Participants must also agree on the models and standards to be used.
  • Select, acquire and install an application lifecycle management tool or ‘social coding platform’. At minimum, tools are needed to support versioning and issues tracking. Better yet is a complete platform offering all of these elements for collaboration in a single, integrated hub (code and document repositories, wikis, tracking tools, personal profiles, RSS feeds and discussion threads). These capabilities lower the barriers of collaboration, and help contributors write better code faster. Examples include GitHub, SourceForge,and TeamForge.
  • Agree on a shared project management plan, project governance structure and project manager. Each participating organization also requires its own project plan and governance structure. The role of the project manager is key: but in the open source model, the focus is less on managing tasks and more on managing and facilitating interactions and collaboration in a distributed, virtual community of developers. One key consideration is breaking down the software project into smaller, simpler parts, or modules, with minimal interdependencies. This enables individual developers or small teams to work separately. A rigorous planning and priority framework will be required across participating NSOs to ensure that collaborative investments deliver common tools and shared solutions.
  • Identify the project team members with the right skills and mindset from each participating organization, and identify their respective roles. If sub-contractors are used, their contracts must support the need to contribute to code under a specified licence. Employees on the team must be briefed on all aspects of the project, including the licensing model to be used. Ideally, they should be familiar with collaboration on open source software, or ‘inner sourcing’. The roles of developers must be assigned. Anyone can be a contributor, but only those identified as ‘approvers’ can commit submitted code, ensuring quality of the final product — for example verifying that secure coding practices and other standards were followed.
  • Agree about logistics for communications, financial arrangements, resource allocation, etc.


During design and development

Ensuring that established frameworks and plans are still followed and that participation and engagement remains high is important during this phase, as is a commitment to co-operatively agree on changes to user requirements, specifications, architecture and design. The challenge associated with this cannot be understated: it is likely the largest single risk to the success of any software collaboration initiative.


Some additional considerations:

  • Licensing requirements associated with any new components, FOSS or otherwise, should be continually monitored. If an essential tool or code with an incompatible licence is selected, then the licence for the resulting software must be revisited or another tool selected. Developers will need to maintain an internal record of what code is in the software and what licence applies to each element. Some build automation tools support this task. For more complex projects, automated code scanning can be used to conduct an audit of the code. Using code from software libraries that have already audited their code is another way to minimize risks.
  • If additional partners are added along the way, the MOU/agreement should be updated to reflect them. As well, their requirements and contribution into the overarching project plan should be incorporated. New contractors hired to contribute code under the FOSS licence (i.e., part of the shared core) need to have contract clauses compatible with the license selected.
  • If there is an impasse on a key decision, or timelines no longer meet the needs of a partner, that partner can go it alone from that point on, assuming the license issued permits it. The partner might rejoin the project later — this is facilitated by social coding platforms, which is one more reason to use one. Collaboration can still continue, but in a different form.
  • Organization-specific components, interfaces, or modifications to in-house systems, as well as development of new ‘services’ to in-house systems to support the use of the new software, are the responsibility of each organization. Each partner must also ensure that these will work with the core software, and that project timelines are aligned. Of course, any organization-specific configuration including reference files (for example, to drive multilingual support) are also the responsibility of each organization.


After development is completed

  • Each partner must conduct its own integrated testing on its infrastructure, then analyze track the issues that are its own to fix. Training is also best provided by each organisation.
  • Before distributing the software, a last due diligence assessment of licence obligations and licence interoperability should be conducted.
  • Once the shared software and all in-house components are completed, each organization must implement on its own infrastructure (unless infrastructure is shared or using a SaaS model)
  • The support model for the shared software should be defined, taking into consideration the requirements of all parties. Maintenance of the software itself is best done collaboratively as per the open source model, but arrangements can be made for some partners to contribute financially rather than in kind. First-level end-user support is best provided by each partner; second-level support can be provided collaboratively.
  • Changes or enhancements to the initial requirements must be agreed to collaboratively with every attempt to address unique functionality via add-ons. The shared software’s roadmap will need to be managed collaboratively.  Forking is an option at any point, if all else fails.
  • Partners should take stock of the initiative and evaluate its success, and analyze lessons learned to inform any subsequent collaboration initiative.


5.     Conclusions and Recommendations

StatCan’s vision is to design and construct all statistical production systems using a component-based approach built on robust and flexible common systems and processes. Software collaboration with NSOs and other partners supports this vision, and offers many opportunities. Collaboration can be achieved by sharing software and other deliverables or services, or by working together towards a common goal, for some or all stages of software development. Hybrid models are also feasible: it is also possible to go from one model to another, with some limitations. Key models possible include:



Scope of collaboration


Share code

The organization that developed the software provides a ‘licence to inspect and modify the code’, and possibly to distribute the modified code. Typically the code is provided ‘as is’, with no support or maintenance.

  • Easiest model for the providing organization.
  • Most flexible for the acquiring organization.
  • Offers the least financial benefits.
  • Has been used at StatCan with various partners.

Share executable

The organization that developed the software provides a ‘licence to use’, directly or via a reseller. Typically, maintenance and support is also provided.

  • Similar to using a COTS.
  • For the acquiring organization, this model is best if the provider provides support and maintenance and incorporates its requirements into future releases.
  • Can result in significant savings for the acquiring organization when compared to the cost of building their own solution.
  • Can be burdensome for the provider organization.
  • Has been used at StatCan with various partners.

Collaborative development

Organizations develop the software together. Partners can contribute in kind or financially, and third parties may also contribute, such as contractors or the Internet community. An appropriate open source software licence would best meet the needs for this model.

  • Offers the most challenges and the most benefits.
  • Has been used at StatCan in context of FOSS.
  • Key enablers for using with NSOs include
  • common standards and models
  • service-oriented architecture
  • business architecture alignment.


StatCan should continue maximizing the use of the first two models, and select with its partner NSOs an appropriate first collaborative software development initiative. The functionality selected should offer mutual value to all partners and leverage the shared models and common statistical architecture, and the requirements should already be aligned. The resulting shared software should be compliant and secure, robust, scalable, interoperable, flexible and high-performance. To maximize success, the recommended approach is to adopt best practices, processes, culture and tools and methodologies from the open source, to adopt agile and lean methodologies, and to use a recognized open source licence. The licence selected for a given initiative should be the one that best supports the desired outcomes, meets all partners` current and future needs and addresses constraints imposed by any existing code that will be part of the final product.


Some key success factors for collaborative software development are

  • clearly articulated purpose, outcomes and roles and responsibilities
  • strong project management, with a focus on participant co-operation, communication and empowerment
  • commitment to compromise to achieve desired common outcomes, supported by a solid planning and change management framework to control diversity, complexity and scope
  • strong management support
  • engaging all participants who have the right mindset
  • mechanisms in place for continuous interaction of participants
  • a core of participants with experience with open source software development or co-development.


Key challenges are

  • adjusting to the culture of the open source model
  • fear of loss of control
  • compliance with legislated standards and directives of each country.


StatCan has seen success in many software collaboration and sharing initiatives, and has experienced challenges in others, from which important lessons were learned. In addition, StatCan has significant experience building generalized systems and has adopted service oriented architecture and shared models such as GSIM and GSBPM. StatCan`s commitment to building component-based solutions makes it now possible to pursue a software collaboration initiative with partner NSOs. Such an initiative, even partial in scope and resulting in separate systems, would be worthwhile. In addition, StatCan is looking into making some of its existing generalized systems available to other NSOs under a FOSS licence, provided it can ensure that the software can continue to meet its own requirements.

Annex A — FOSS[3]

The Free Software Foundation (FSF) and the Open Source Initiative (OSI) publish the two most widely accepted definitions. The FSF adopts a principles-based approach that promotes the idea that software should be “free as in freedom. The FSF's Free Software Definition sets out four essential freedoms for free software (see text box at left).[4] The FSF also maintains a list of approved free software licences that meet its criteria under the definition.[5]


The OSI adopts a more business-focused approach to FOSS, promoting the ways that the private sector can benefit from using and releasing open source software. The OSI’s Open Source Definition has 10 criteria for open source software (see table below).[6] Where an open source licence meets these criteria, it becomes OSI approved.[7]

OSI: OSS licences must permit and include the following:

1. Free redistribution

2. Source code

3. Derived works

4. Integrity of author's source code

5. No discrimination against persons or groups

6. No discrimination against fields of endeavor

7. Distribution of licence

8. Licence must not be specific to a product

9. Licence must not restrict other software

10. Licence must be technology-neutral


One distinctive and commonly-encountered feature of FOSS divides licences into two categories:

  • with a hereditary obligation (also called copyleft, share-alike, or reciprocal), which stipulates that modifications to the software must also come under the same licence. If users makes changes to hereditary software or include some hereditary-licenced code in their own software, they cannot distribute the new work as restricted-source software: they must only redistribute the new code under the same FOSS licence;
  • without such an obligation.[8] FOSS licences without this stipulation are generally referred to as permissive. In these cases, authors of any modifications are under no obligation to place their changes under the same licence, or even under a FOSS licence at all. In general, authors of modifications can even use and redistribute the modified software as a restricted-source software application. The two different types of FOSS licences are illustrated in the figure below.


A. Distribution under a hereditary licenceB. Distribution under a permissive licence

However, the distinction between these types of licences can be blurred: different hereditary licences stipulate to varying degrees when this hereditary obligation to distribute under the same licence engages. This is perhaps the most confusing aspect of FOSS licences and deserves careful attention. To determine whether a certain activity invokes a hereditary obligation, one must consider the type of distribution and the extent of integration with the original code.

With respect to the type of distribution, hereditary obligations only arise with certain distribution-like activities. Where there is no such distribution, the licences almost always allow a person to use and modify hereditary-licenced software without ever releasing their code. For example, StatCan can change and customize software under a hereditary licence for its own use or any GC use, and is not obligated to share this software or the software source code. However, a distribution does trigger a hereditary obligation to distribute under the original licence. Two common types of triggers are found in FOSS licences:

  • distribution of source or object code: Distribution of the software, either over the Internet or on a physical medium such as a CD, whether as source code or object code, is the most common trigger for a hereditary obligation. For example, this is the trigger set out in the popular GPL licence.
  • Access over a computer network: This is a much broader trigger that imposes a hereditary obligation whenever others access the licenced software over a computer network.


Note that even if the software is distributed, the hereditary obligations still only extend to certain modifications, depending on the licence.

The subsistence and extent of the copyleft feature is generally the FOSS issue most important to FOSS users and contributors. The table below presents the key differences in benefits for both types of licences.




Beneficiaries of the FOSS release

Everyone: commercial software vendors, support services, etc.

Everyone, but only those willing to release their software as FOSS, under the same licensing terms as were granted to them (some restricted-source software vendors absolutely prohibit hereditary licences such as the GPL).

Beneficiaries of downstream code changes

The whole community, but only if the business, or other developer, chooses to contribute modifications back under the permissive licence.

The whole community in every case where a business, organization, or individual distributes the modifications, as the licence then mandates releasing the changes under the same FOSS licence.

Licence complexity

Often very simple and understandable (e.g., the popular ‘Two-clause BSD’).

Relatively complex, requiring careful legal analysis (and some risk of misinterpretation).


Permissively licenced code can be included in projects under hereditary licences, other permissive licences, or restricted-source licences.

Hereditary-licenced code cannot generally be included in a project under any other single licence.


Benefits of FOSS

  • Cost. The total cost of ownership for using any software involves three major categories of expenses: up-front licensing costs, ongoing maintenance and support costs, and software upgrade costs. When using FOSS, the up-front licensing cost is zero (aside from internal costs of assessing the software and the licence). As well, FOSS software often incurs lower ongoing maintenance costs, as it permits anyone to install, fix, and otherwise support the software. This can enable a more competitive tendering of support services amongst firms.
  • Flexibility. As the code is available, it also allows an organization to adapt it to meets its own unique needs, within the constraints of the FOSS licence, which might require for example to contribute back changes or limit the choices of licences when distributing the modified software.
  • Interoperability. FOSS fosters the use of open formats and standards, which promotes interoperability.
  • Security. When using FOSS, all of the source code is openly published. This makes it difficult for anyone to surreptitiously insert malicious code. It also enables security auditors and security researchers to inspect the code for flaws. For this reason, defense and national security agencies very often use FOSS.[9] Where FOSS is well-developed and well-inspected by third parties, security is generally improved. There are some security risks as well, discussed below.
  • Avoiding vendor lock-in. When a restricted-source software application becomes entrenched in an organization’s or business’s processes or products, the organization becomes locked in to that software vendor for any new features, bug fixes and, in many cases, product support. Where a vendor is unwilling to implement a new feature, the organization may need to switch to an alternative often at considerable cost. When a particular vendor is slow to provide bug fixes or support, timelines and security may be compromised. FOSS offers the advantage of creating an open marketplace for providers of all types of support. Any support business with sufficient software development competencies can add new features and fix bugs in the software; FOSS users can also switch to a different support provider whenever an existing company no longer meets their needs or timelines.
  • Support for the local economy. Depending on the dynamics of a software industry in a particular locality, FOSS use may better support local businesses in the area.[10] Because FOSS is openly available, distributable, and modifiable, a greater breadth of smaller support service businesses may provide commercial services. Rather than a single vendor providing the warranty and technical support, any competent local IT business can provide these services. Rather than a single vendor being the only one in a position to customize software, a local business can provide specialized versions of the software.

Risks and Drawbacks

  • Lower user familiarity. User familiarity with FOSS software is often much lower than with restricted-source software packages. Restricted-source software has a strong foothold in schools (at least in Canada) and many people learn to use computers with restricted-source software, as it is pre-installed by hardware suppliers. For this reason, FOSS can require more training and support.[11]
  • Security risks. Because all of the source code of FOSS is openly published, anyone including black hat hackers can examine the code for security holes.[12] In particular, malicious attackers can observe where FOSS software shares the same design, code base, or architecture as software that may have known security vulnerabilities.[13] Of course, this drawback must be weighed against the security benefits mentioned earlier. In many cases, malicious hackers can still gain access to the source code of restricted-source software where non-disclosure agreements, company ethics procedures, or vendor security mechanisms fail. While restricted-source software security depends on an attempt to maintain an information imbalance between the ‘white hats’ (computer security analysts) and the black hats, FOSS software security depends on an open competitive process of finding and closing security holes.
  • Loss of control over software management. The easy, no-cost option of downloading FOSS from the Internet, and instantly installing it, offers an attractive way for employees to sidestep procurement processes. This creates two problems: employees may contractually commit the organization to the terms of the software licence without management’s knowledge; and losing track of what software is running on employee workstations complicates systems security management. However, these systems management issues are present whether or not an organization chooses to make use of FOSS.

A licence-specific obligations map is presented below, but this general mapping is only a guideline. Nuances in particular licences often alter these sets of obligations. The following decision flowchart sets out more fully these core obligations for the most popular FOSS licences.[14]

Annex B



6.       OpenM++ and Modgen


Both OpenM++ and Modgen are microsimulation development frameworks. They are used to develop continuous-time event-based microsimulation models. StatCan develops these models for its own analytical needs, but also builds models for clients on a cost-recovery basis. Modgen is the software developed and currently used by StatCan and others. It is now at ‘end of life’ and needs to be replaced. OpenM++ is a proposed set of open source tools that will be portable and scalable, provide 64-bit support, will support parallelism and may replace Modgen. OpenM++ is also targeted to provide software as a service (SaaS) models for the research community.


  • For OpenM++ (new)
    • University of Ottawa  (U of O) — current lead
    • Statistics Canada — expected future lead
    • External Web Communities (future)
  • For Modgen (StatCan’s current tool)
    • Statistics Canada (owner)
    • Various NSOs and other organizations (users)


  • For OpenM++
    • OpenM++  initial development is funded by a grant received by U of O
    • If StatCan adopts it as a replacement for Modgen, it will fund its maintenance and support, with in-kind contributions from partners
  • Modgen development was primarily funded by StatCan; its maintenance and support is fully funded by StatCan

Collaboration model

  • Modgen’s model is ‘share object code via licence’ free of charge, with some collaborative development. Client organizations such as the World Health Organization have provided funds to implement enhancements; others have made in-kind contributions for example, the Canadian Partnership Against Cancer developed a web interface.
  • Initially, U of O’s proposal was to co-develop a new version of StatCan’s Modgen software. However this approach failed (see lessons learned): instead, U of O proposed to begin development of a new FOSS, tentatively called OpenM++.
  • OpenM++’s model is ‘collaborative development using FOSS licence’. Initial design and development of OpenM++ is being done by U of O, with participation by StatCan and others (later).

How it is used

  • The framework, a key component of which is a pre-compiler, is used by subject-domain experts to build complex microsimulation models using statistical data.
  • Researchers then use the models to support analysis — conduct what-if scenarios, etc. They also do this analysis with tools that are part of the framework.

Key contacts




IT Team Lead responsible for the project at StatCan

Michael Goit


System Engineering Division in Informatics Branch

Project Manager:  U of O

Steve Gribble

University of Ottawa

Program-area Director responsible  at StatCan

Chantal Hicks


Modelling Division in Analytical Studies Branch

Licensing model

The FOSS license for OpenM++ has not yet been selected but StatCan favors a hereditary license to maximize the receipt of downstream changes, and to ensure that work built remains open and free. For Modgen, a simple licence to use the software ‘at your own risk’ is used.

StatCan status and  outlook

OpenM++ is  at the design and prototyping stage. Modgen has been in production for 15 years.

StatCan is taking a keen interest in the development of OpenM ++. If  OpenM++ can ultimately replace Modgen, StatCan may be able to avoid a multi-year redesign project on its own. StatCan hopes to have enough information to make a decision on OpenM ++ by the end of 2013.

Methodology, platform and tools

  • For OpenM++
    • Subversion repository and wiki (for now)
    • Linux platform for compiling and testing
    • Agile methodology is used
    • Primary development environment are Windows using Microsoft Visual Studio 2012, and C++ 11 as the primary language for coding
    • Parallel hardware/software technologies should be used, as well as FOSS tools for parallel computation, lexical analysis and grammar parsing, as well as database

Lessons learned

No lessons have been learned yet on the co-development process for OpenM++ as it is still in the early stages. However, originally U of O, which needed a 64-bit version of Modgen and received a grant to fund this effort, proposed to co-develop this new version. Ultimately, this option was not pursued because of clauses in the co-development agreement requested by U of O, to minimize their risks, plus constraints and issues associated with these requirements for StatCan. Some lessons learned from this effort:

  • Before embarking on a co-development initiative with an organization outside the GC, ensure that it is not being done as an alternative to procurement. One key consideration: if the primary objective of the co-development arrangement is to meet StatCan objectives, this could be seen as an alternative to procurement.
  • IP cannot be promised to be relinquished ahead of time (even after it was modified by the other party) upon pre-determined events such as StatCan “stopping support” of the software or “not accepting the work delivered by the other party as the official version.”
  • StatCan should not promise to provide a licence to freely redistribute the modified code ahead of time, unless for a limited time frame (e.g., 5 years). Instead, StatCan should only offer to “consider in good faith to grant further rights” at a future date, once it has the facts to make an informed decision. Otherwise, the GC would be facing an endless commitment to notify the other party of the software ‘support status’. Essentially, the GC would be making a decision ahead of time without knowing the entire context it may be facing at this future date., U of O, for its part was concerned about making a financial investment in modifying the code without assurance of being able to not only use the modified software, but also to distribute it freely if StatCan stopped support or did not accept the modified version.
  • A consideration for StatCan was the impact on its program and its clients of having potentially multiple production versions of Modgen in use and possible liabilities faced by StatCan for the relinquished modified version.

Potential for NSOs

  • Modgen is already used by other NSOs and others.
  • OpenM++ is expected to be similarly used by other NSOs.



7.       Web Experience Toolkit (WET)


The WET is a set of web accessibility and presentation tools. It consists of reusable components for building and maintaining websites that are accessible, usable, and interoperable. WET eases compliance with the Government of Canada Standard on Web Accessibility, the Standard on Web Usability and the Standard on Web Interoperability. The WET solutions were applied to the presentation framework of Drupal to develop a publically accessible distribution platform to meet Government of Canada requirements for accessibility, usability and interoperability. The framework has been tailored for organizations that need to comply with standards for accessibility and bilingualism or that simply need a distribution that gets them up and running quickly using a set of modules that can support common enterprise business requirements.


Within StatCan, the WET tools and Drupal will be used for all StatCan external sites by 2016 (approximately) and for most intranet sites. It is also used for the new open data portal developed by StatCan, data.gc.ca.


Key projects recently implemented using this new framework include the Canadian Economic Action Plan, the Statistics Canada blog, consultation module and Innovation Channel, the Public Works buyandsell portal, Science.gc.ca, Ottawa.ca, and the University of Ottawa (in September 2013).


  • Treasury Board Secretariat (TBS) is the lead.
  • Canadian Public Service organizations (federal, provincial and municipal), and non-government organizations. Key participants include Statistics Canada, the Canadian Transportation Agency, the City of Ottawa,  and the University of Ottawa.
  • External web communities.
  • More than 93 members representing 50 organizations now contribute to the Drupal Web Content Management Framework project.


  • Core resources funded by TBS.
  • Contributions in kind provided by all partners.

Collaboration model

The ‘collaborative development using FOSS licence’ model was used.

  • The WET software/tools were co-developed from inception using a FOSS license, although the number of contributors has changed over time.
  • It is based on Drupal, a pre-existing renowned FOSS web content management system (WCMS) with a much broader community.

How it is used

  • The WET tools themselves and the Drupal software are used and configured by IT developers to build WCMSs).
  • The end users of the resulting WCMS application are the content owners of the websites that use them to manage the content of their websites.
  • Ultimately, the general public are the end users of the external websites created using Drupal and the WET, and StatCan employees are the end users of intranet sites created using these tools.

Key contacts




IT Chief responsible for the project at StatCan

Andrew Sinkinson


Administration and Dissemination Systems Division (ADSD) in Informatics Branch (IB)

Project Manager, GC level

Paul Jackson

(613 960-1032)

Treasury Board Secretariat

Program area Chief responsible

Lucie Gauthier

(613 951-5374)

Dissemination Division

Licensing model

MIT license is used for WET. Drupal is licensed using the GNU General Public License, version 2 or later.

StatCan status and outlook

  • StatCan has been using WET solutions (widgets) since February 2012. WET templates were adopted in January 2013. Drupal has been in production at StatCan also since January 2013. Initially, it was used only for static websites.
  • The current WET is here to stay at StatCan and in other GC departments. The recent launch of the Web Renewal Initiative: its goal is to modernize the Government of Canada's online communications capabilities, including websites and use of social media. This will enable the government to engage online with its constituents using Web 2.0 technologies, and enable more and better access by citizens and businesses to government information and services on mobile platforms. The first release is the consolidation of Internet sites to one single Internet portal www.canada.gc.ca  for information on programs, services, initiatives and Government of Canada products. The GC will soon select and procure the WCMS for the consolidated Internet portal.

Methodology, platform and tools

  • GitHub used as the ‘social coding’ platform. IRCan was used previously
  • Development tools are various IDEs, xdebug, GIT and Drush.
  • Development methodology is Agile (iterative).

Lessons learned

  • While there were growing pains at first related to the development process, this initiative has matured. It is now a highly successful collaboration, resulting in high quality websites and significant cost savings.
  • IRCan was initially used as the platform, but GitHub was adopted because
    • significant resources were needed to manage WET on IRCan
    • the non-intuitive interface discourages participation from collaborators and external stakeholders
    • TBS would need to invest more resources to ensure IRCan complies with the standards on web accessibility and web usability and official languages policy.
    • No application programming interface enabled automation of time-consuming tasks.

Potential for NSOs

  • Drupal is already used by other NSOs.
  • WET is not currently used but would definitely benefit other NSOs. Other NSOs can leverage the capabilities of the Government of Canada web community. Canada has been putting its web experience toolkit onto GitHub, an open source platform that enables web professionals outside the Government of Canada to use our artifacts and contribute back.



8.       BLAISE


BLAISE is a powerful and flexible system used for computer-assisted survey processing. It can perform computer-assisted telephone interviewing, computer-assisted personal interviewing, computer-assisted self-interviewing, computer audio recorded interviewing, web-interviewing, interactive editing, high-speed data entry, and data manipulation. Blaise also has full survey management capabilities. It is used worldwide by National Statistical Offices (NSOs) and related scientific research organizations for producing official statistics. These organizations use BLAISE on a wide variety of surveys — labour force surveys, consumer price surveys, multilevel rostering household surveys, panel surveys, business and economic surveys, institutional surveys, health surveys, energy surveys, environment surveys, agricultural surveys and other related surveys.


  • Statistics Netherlands is the lead and owner of the software.
  • About 30 organizations worldwide use BLAISE.
  • Westat is the reseller.


  • Initial software development was funded by Statistics Netherlands.
  • Organizations using BLAISE contribute to its maintenance and enhancements by paying annual licensing fees to the reseller.
  • Ongoing support is also covered by the annual licensing fees.

Collaboration model

The  ‘share object code via licence’ model is in effect, with use of a reseller.

  • Statistics Netherlands developed the software, which is now used by others via a licence to use the software issued to each organization, distributed by the reseller, Westat.
  • Ongoing maintenance and enhancements are driven by a user group representing organizations that use the software. This group meets annually at a users conference and at an annual meeting of the BLAISE Corporate Licence Users Board. The user group communicates throughout the year, discussing issues, improvements, needs and direction of the software.
  • Tier 1 support is provided by the reseller;  Tier 2 by Statistics Netherlands.
  • Statistics Netherlands makes all modifications to the software.

How it is used

  • IT staff use the BLAISE software platform to develop and generate collection applications to support the operations of collection partners.
  • Program areas (business and social) determine the specifications for the surveys and use the end product of surveys — data — generated using BLAISE survey applications.
  • The end product generated by BLAISE (called Survey Instrument) is used by Collection Program Management Division staff in the regional offices and head office to perform interviewing and other data-collection activities for the social, business, institutional and agricultural program areas.

Key contacts




IT Chief responsible at StatCan

Robert Meester


Collection Systems Division (CoSD) in Informatics Branch (IB)

IT Team Leader responsible at StatCan

Éric Joyal


Collection Systems Division (CoSD) in Informatics Branch (IB)

Project Manager for BLAISE

Lon Hofman

Statistics Netherlands

Primary Contact for Reseller

(Vice President)

Jane Shepherd, Ph.D.



Program area  Assistant Director responsible

Sylvie Bonhomme


Collection Planning and Management Division in Collection and Regional Services Branch

Licensing model

The BLAISE license is typical of those used for proprietary software. Selected features:

  • StatCan pays an annual fee for the rights to use the software for a specified number of ‘usage units’.
  • The licensee is the Government of Canada — not just StatCan, as all departments are part of the same legal entity.
  • The licence does not allow StatCan to ‘rent’ the software, host it or time-share it.
  • The obligation to support the software is in effect for one year from signature of the licence, renewable yearly for additional years.
  • There are no clauses that provide the source code to any user organization if the owner or the reseller no longer supports it. Each organization would need to find an alternative solution and migrate its surveys to the new solution.
  • The reseller is liable up to $1 million for direct damages if the contract is terminated for default before it elapses (one year plus four option years).

StatCan status and outlook

In use at StatCan since 1998 and for a broad range of surveys, BLAISE is expected to be phased out by 2019. In its place, the Integrated Collection and Operations Systems (ICOS) platform and a web-only model will be implemented, featuring electronic questionnaires and other applications built in-house by StatCan.

Methodology,platform and tools

N/A – StatCan does not have the code, so BLAISE is essentially like any other COTS product.

Lessons learned

  • This ‘share object code’ model works very well, especially for ‘big players’, who have more leverage to get enhancements they need into the product. This is very much in line with the situation for COTS. As a large-scale user of BLAISE, this has served StatCan well.
  • Challenges for StatCan include the ability for the current software version to meet Common Look and Feel requirements and to be the single tool for collection, irrespective of model, and scalability. Common Look and Feel requirements are a challenge for many GC departments when using COTS and in collaboration initiatives.
  • The model fostered innovation in finding solutions given the broad base of users, which led to the collaborative development of supporting tools, such as CAPI monitoring tools.
  • The model led to other collaboration initiatives with participants. For example, the United States Department of Agriculture shared code built using BLAISE, and StatCan then customized this software. StatCan also established a partnership with the University of Michigan: the two organizations collaborated on the research and development of computer assisted interviewing methodologies, processes and technologies. The collaboration also included sharing of research and development experiences, findings and best practices.

Potential for NSOs

  • BLAISE is already in use in other NSOs.



9.       Generalized Systems — ‘G-Suite’


StatCan’s comprehensive suite of generalized systems spans the spectrum of the survey processing cycle. The suite includes sampling, estimation, edit and imputation, tabulation, disclosure avoidance, export to standardized formats (for dissemination) and microsimulation, to name a few generalized functions. Many of the systems are available in both batch mode and interactive mode, and can be embedded within other systems. They are also very modular, configurable and interoperable; some are now available as web services. Generalized systems do not require the intervention of IT staff to be used within a given application. Instead, subject matter and methodological expertise is needed to ensure that processing, specified by end users’ parametization, is done properly to deliver the correct outcomes. At StatCan, generalized systems are centrally funded. Their use by all program areas is also prescribed for all functions they support.


  • Statistics Canada (owner).
  • Various NSOs and other organizations (users).


  • All development, maintenance and enhancements is funded centrally by StatCan.
  • Software support is mostly funded by StatCan: as well, organizations that have acquired production versions of the software and pay annual maintenance and support fees. StatCan has issued close to 200 licences for its generalized systems, not including Modgen, which is provided as a free download.

Collaboration model

  • The collaboration model with those outside StatCan is ‘share object code via licence’ – for a fee, or at no cost, depending on the software. Client organizations contribute to development by reporting bugs and proposing enhancements. However, StatCan makes all decisions about the software roadmap, functionality and tool set used. Upgrades are driven by StatCan business requirements and IT drivers.
  • Within StatCan, elements of the collaborative software development process also apply: generalized systems are developed to be generic, and to meet the needs of a large group of users.

How it is used

  • IT specialists responsible for generalized systems work with ‘business owners’ (typically in Methodology Branch) and with program areas to continually improve the functionality, reliability and performance of generalized systems, and to ensure they are maintained and supported. For most generalized systems, methodologists develop the methodology and write specifications (and often develop prototypes). Then, IT staff design, develop and implement the final system. Final acceptance testing is then performed by methodologists  and subject matter areas.
  • IT staff responsible for a program area system that requires automation of a generalized function work with IT specialists responsible for the generalized system to integrate it to meet client requirements.
  • Program areas use the resulting systems/solutions to deliver their programs.

Key contacts




IT Chief responsible for SAS generalized systems

Yves Deguire


System Engineering Division (SED) in Informatics Branch (IB)

IT Chief  responsible for other generalized systems

Benoît Fontaine


System Engineering Division (SED) in Informatics Branch (IB)

Program area Directors responsible  at StatCan (‘business owners‘)


Methodology Branch, Analytical Studies Branch, Dissemination Division, Standards Division.

Licensing model

  • For production licences provided for a fee, a customized licence is used that gives the licensee perpetual permission to use the software (with restrictions). The small fixed fee includes the costs of issuing the licence, on-premise installation and consultation. StatCan also offers optional maintenance and support of its production licenses for an annual fee. It offers additional services on a cost-recovery basis.
  • For production software provided at no cost (such as Modgen), a customized licence providing the licensee perpetual permission to use the software is used. The software is offered as is, with minimal support.
  • Evaluation software is offered using a customized licence providing, for a limited time, permission to use, at no cost.
  • Unsupported and beta software are also offered using a customized licence, providing perpetual permission to use at no cost.

StatCan status and outlook

The first generalized systems were developed over 30 years ago: the suite has grown, and systems have become more comprehensive, flexible, performant and robust. All systems are ever greened as per an established roadmap agreed on with all stakeholders. Additional systems are still being added — more recently G-Tab (tabulation) and G-Export (export for dissemination). StatCan will continue to invest in its suite of generalized systems for the foreseeable future. It also plans to make all generalized systems into web services, to maximize interoperability and flexibility and simplify integration into other systems.

Methodology, platform and tools

  • Rational Unified Process is the development methodology.
  • Various tools are used, most commonly SAS, C/C++ and the .NET framework, sometimes in combination.
  • Team Foundation Server is used for code management, version control, collaboration and document management.

Lessons learned on collaboration/sharing

  • Developing a suite of generalized systems was very worthwhile for StatCan. It yielded cost savings, standardized methodologies, systems of higher quality that are better supported and maintained, quicker turnaround to develop new applications, and greater developer productivity as they get familiar with the suite of generalized systems and how to integrate them.  However challenges include clearly delineating the functionality that belongs in the generalized system versus what is ‘pre-processing’ and ‘post-processing’. Adopting the GSIM may reduce the need for information formatting that makes up most of the pre- and post-processing. Other challenges are having all stakeholders agree on requirements for the core system functionality and managing competing priorities and timelines of different clients and projects. Finding resources with the right skills and ‘mindset’, who can code complex applications that are very generic or metadata driven is another challenge. Statcan would have to face all these challenges, though, when collaborating on software development with other NSOs.
  • For NSOs that acquire StatCan’s generalized systems, the financial benefits are significant given the small acquisition cost and maintenance and support costs. If they also adopt these systems broadly across their organization, they should also accrue the same benefits as StatCan. The only disadvantage is that, while they may influence development, they have no control over what enhancements or fixes are done and when. If they require enhancements that StatCan does not, their needs may not be met. This is essentially the situation when using COTS, but NSOs typically have more influence on the development of StatCan generalised systems does than a typical COTS user.
  • The broad base of users of generalized systems, which includes clients outside of StatCan, contributes significantly to the high quality of the systems.
  • Central funding of generalized systems was critical to their success. Early adopters do not have to bear the cost of the shared functionality, and this ensures that systems are continually updated and supported to the benefit of the whole organization. In collaborations with NSOs, central funding would also be of benefit.
  • Governance and directives stating that the generalized systems are to be used whenever a function needs to be automated are also key to realizing the desired outcomes.
  • Providing access remotely in different time zones provides some challenges, especially given our limited capacity.

Potential for NSOs

  • Most generalized systems  are already used by other NSOs and others.



[1] Source: Free and Open Source Software Licensing Primer for Natural Resources Canada – Hickling, Arthurs and Low (2012)

[2] For example, Microsoft Shared Source CLI, C#, and Jscript License, which are not FOSS

[3] Source: Free and Open Source Software Licensing Primer for Natural Resources Canada – Hickling, Arthurs and Low (2012)

[4]. Free Software Foundation, “Free Software Definition.” 2012. <http://www.gnu.org/>.

[5]. Free Software Foundation, “Various Licenses and Comments about Them. 2012. <http://www.gnu.org/>.

[6]. Open Source Initiative, “The Open Source Definition” (accessed 2012). <http://opensource.org/> [OS Definition].

[7]. Open Source Initiative, “Open Source Licenses” (accessed 2012). <http://opensource.org/>.

[8]. See, for example, Heather Meeker, The Open Source Alternative (John Wiley & Sons, 2008, Hoboken NJ), 22.

[9]. Fadi Deek and James McHugh, “Open Source Technology and Policy” (New York: Cambridge University Press, 2008), 310311 (extensive use of FOSS in the U.S. Department of Defense and the National Security Agency) [Open Source Technology and Policy].


[11]. See Migration of Public Administrations, supra note

[12]. Kirk St. Amant and Brian Still, Handbook of Research on Open Source Software (Hershey: Information Science Reference, 2007) [Handbook on OSS], 210.

[13]. Ibid., 192.

[14]. Shown are core obligations only for BSD licenses (two-clause and three-clause), MIT license, GPL license suite (versions 2.0 to 3.0), Apache License 2.0, Eclipse Public License 1.0 (EPL), and the Mozilla Public License (MPL, versions 1.1 and 2.0).