Open Source Watered Down?

[mgifford]

It really sounds like in
"6. Use open standards and solutions"

That open source is being marginalized.

Maybe the D5 Charter has changed since Canada & Uruguay became a part, but this sounds pretty clear & direct to me:
https://en.wikipedia.org/wiki/Digital_5#D5_Charter

There's another wishy washy statement in 6.1:
"6.1 Leverage open standards and embrace leading practices"

"leading practices" are the type of management speak that gave us Phoenix.

The "Using open standards and common government platforms will help the government:" also sounds like, the same old nonsense that brought us Canada.ca. 'Select & outsource our IT concerns to the right vendor and we'd have gotten it right' - that kinda thinking isn't useful.

I'm not saying that there isn't a role for common government platforms, but it just falls really short of the 2014 vision of the OGP - https://www.opengovpartnership.org/stories/open-source-and-open-government-challenges-ahead

Also, comparing with the USA playbook:
https://playbook.cio.gov/

It's like it's barely mentioned in this document.

Likewise with the UK:
https://www.gov.uk/guidance/government-design-principles

The whole "common government platform" thinking under the last government really killed web innovation in the government.

Can't we strive for a higher bar than this?

[pjackson28]

Thank you for your feedback! The Digital Playbook is a very early draft where we have so far taken the Digital Standards (previously named the Digital Principles, which were openly consulted) and have mapped in content from other sources (such as the UK, US, Ontario and Australia), in many cases copied and pasted verbatim (for now). That was the case for the "Using open standards and common government platforms will help the government:" wording that you are referring to where that block of content came from 9. Use open standards and common platforms (Digital Service Standard (Ontario). It is just placeholder content for now until an introduction is written for section 6.1 (being used as possible inspiration for now). We welcome suggested wording for the introduction to that section. You can see what we mapped in so far here: Government of Canada Digital Playbook comparison table (draft).

As for the titles of sections 6 and 6.1, they are at a high level, but that is because they come from the Digital Standards which are intended to be at a high level with a wide area of coverage (much like the titles from the referenced Digital Service Standards from other jurisdictions). More concrete guidance does needs to be provided beyond those high level requirements, including covering a variety of scenarios/projects, which in the case of the Digital Playbook we are attempting to do with checklists and implementation guides (much like the UK, Ontario, US and Australia are doing). We welcome your feedback and suggestions for concrete guidance and ways of approaching it.

As for your concern about common government platforms, I took a look at other jurisdictions, and found the following:

• 9. Use open standards and common platforms (Digital Service Standard (UK))
• 9. Use open standards and common platforms (Digital Service Standard (Ontario)
• 7. Use open standards and common platforms (Digital Service Standard (AU)

From my standpoint, “common government platform” doesn’t have to equal lack of innovation, just like having a bunch of different platforms doesn’t guarantee innovation either. There is plenty of room for sharing and reusing while also being innovative. The key will be in how we approach the platforms(s), whether they be common government platforms or not, which is where the concrete guidance is important. We welcome suggestions for checklist items, guides and other concrete guidance that can help lead to a strong culture of sharing, reusing and innovation, including with common government platforms.

[mgifford]

Thanks for this feedback Paul. There are real advantages to common platforms, if it is something that allows for innovation to happen in places where it can have a huge impact. If Estonia hadn't standardized on Drupal, I doubt that they would have been able to implement their eID system. They could develop a install profile that took care of multi-lingual, accessibility, CLF & then invest their limited time into building a solid integration with the X-road.

https://groups.drupal.org/government-sites#Estonia

It's just that with the GC the Web Renewal project really just seems to have squashed a lot of innovation that got started with the Wet Toolkit & CodeFest.

[smellems]

I added links to the UK Technology Code of Practice under Similar resources. I was looking at where to add the new Politique du libre from Montréal. I could put it at the same spot but I would like to add quotes from these. Can I add the following to the introductory text?

Give equal consideration to open source software when you choose technology.

Your technology project or programme could benefit from:

• solving common problems with readily available open source technology
• more time and resource for customised solutions to solve the rare or unique problems
• lower implementation and running costs

Be aware that open source software is not completely free, so take into account the total cost of migrating, including exit and transition costs.

Technology Code of Practice - Be open and use open source (UK))

Open standards can be used when designing individual elements of the solution.

Using open standards means you:

• save time and money by reusing things that are already available
• increase compatibility with all stakeholders
• potentially open up the range of companies you can purchase from as more of them are likely to use the same standard as you
• can move between different technologies when you need to and don’t get locked into contracts

(Technology Code of Practice - Make use of open standards (UK))

The city acknowledges that open source software and hardware:

• entail proven benefits, namely with respect to quality, safety of information, variety of functionalities and the pooling of solutions;
• contribute to the interoperability, reusability and interchangeability of solutions;
• contribute to data resilience;
• contribute to eliminating vendor lock-in;
• constitute an industry of their own and must be assessed on merit, like every other industry.

The city acknowledges that, as a public administration body, it must promote free competition in terms of software and hardware purchases.

Principle 1 - The city commits to systematically considering the solutions put forth by the open source industry for all replacement and development of software and hardware in an effort to remain transparent and to contribute to the common good and to the mutualization of solutions.

Principle 2 - The city commits to basing its decision to use an open source software or hardware on its ability to meet the business needs, and the technological and safety criteria, as well as on requirements specific to the open source industry.

Principle 3 - The city commits to favoring cooperation with other public administrations by using open sources licenses for the development of software and hardware solutions. It further commits to promoting the reuse of these solutions in the public sector.

(Policy concerning the use and development of open source software and hardware (City of Montréal))

[mgifford]

I'd love to see government give a preference to open source, if only to force the public sector to think beyond their particular silo.

The Government of Canada is the single largest purchaser of IT in this country. It employs more computer scientists than any other organization in Canada.

Think about the big problems that we could start to address if we started to work together and make collaboration the default. Sharing first and allowing our work to help make everyone's digital environment more secure, accessible, robust and private.

The real innovation of the internet is embracing abundance. Open source is what has allowed ideas on the internet to scale.

[pjackson28]

@smellems It would be good to add that to Similar resources, or even Implementation guides, if it helps with implementing the guideline.

As for where to put the blocks of content, most of it seems appropriate for a guideline introduction but some of it would probably be better in a checklist. For instance, "Give equal consideration to open source software when you choose technology." would seem to be good a item to add to the checklist, since it is something you want them to actually do, rather than the other content which explains more the why. Same with "Be aware that open source software is not completely free, take into account the total cost of migrating, including exit and transition costs", although that probably should be reworded to make it more checklist-like, such as: "Take into account the total cost of migrating when considering open source, including exit and transition costs, as open source software is not completely free."

Also keep in mind that the current sections that are available in the Digital Playbook are the same as what was in the UK Digital Service Standard (since we used that as the basis for this Digital Playbook). We could add more global sections if Introduction, Checklist, Implementation guides and Similar resources don't provide enough coverage for the content that we want to include (although probably should seek consensus with the other Digital Playbook contributors before adding any more global sections).

[smellems]

Thanks @pjackson28 It seems like a lot of things could go in the checklist items. Be open and use OSS, Make use of open standards, systematically consider OSS. Also what is the link between the Checklist (alpha, beta) in the Playbook and the Build it right checklist?

I will make a PR to propose changes.

I thought the Digital Playbook was to go into the details of how follow the Build it right Checklist that was to be based on the Digital Principles (standards).

I agreed with @mgifford that I would like to see the GC take a strong position in favor of OSS and I think that should be reflected in the Digital Principles, Checklist and Playbook.

[mgifford]

@pjackson28 I don't know if "Give equal consideration to open source software when you choose technology." is good enough. How does that deal with challenges like vendor lock-in or for that matter the ability to distribute solutions to other departments.

I'm not sure that warnings like "Take into account the total cost of migrating when considering open source, including exit and transition costs, as open source software is not completely free." are useful. I do think too often people do think that open source == free, which is obviously true. However, what you are saying should apply to any software. There are enough people who feel that SharePoint is "free" too because someone else pays for the license.

There are enough dis-incentives for project managers in government to think about alternatives to IBM, Microsoft, Oracle, CGI solutions. There is no need to add to those if we actually want to see changes in adoption.

[pjackson28]

@smellems The alpha, beta and live checklist sub-sections come from the UK, Ontario and Australia Digital Service Standards (they broke up the checklists similarly). I just copied that approach for now, but there should be a discussion about whether to maintain them as sections or to just use tags to identify alpha, beta and live items as the tag-based approach would give more flexibility from a data standpoint (so by extension more flexibility to alternate views of the playbook).

As for the Build It Right Checklist, that is a bit more complicated to explain. The Build It Right Checklist is intended to be a level down from the Digital Standards (Digital Standards = Strategic, Build It Right = Tactical) but it also only covers a subset of the Digital Standards. The Playbook guidance is an additional level down (operational) but it covers all of the Digital Standards and not just what Build It Right covers. So we are trying to address that relationship by including Build It Right as checklist items in the Digital Playbook (so tying Build It Right to the Digital Standards but also integrating it with the other checklists in the Digital Playbook).

[pjackson28]

@mgifford Those sentences were taken from Montreal's document, but it also is a fair point that Open Source shouldn't be singled out for considering total cost of migration. In my opinion, total cost should be considered regardless of whether a product is Open Source, much like other factors should be considered such as performance, degree to which the solution meets business/user needs, accessibility, etc. Open Source software often has an advantage on the cost front but it is still important to consider all the implications (including the implications of migrating to the new solution, such as flexibility and costs, in comparison to staying with the current solution) when choosing one solution over another.

[mgifford]

Thanks @pjackson28 I do really appreciate you re-using language. I'll have to look at changing that upstream when I find a chance.

[mgifford]

@pjackson28 I think those both of those quotes come from https://www.gov.uk/guidance/be-open-and-use-open-source

Not from the Montreal document https://github.com/VilledeMontreal/politique-libre/blob/master/Politique/PolitiqueDuLibre.md

Not sure

[pjackson28]

@mgifford Looks like you are right. Looking at @smellems earlier comment about content to include, I assumed it all was content from the Montreal document but now I see the UK Technology Code of Practice bolded text before the text I copied and pasted.

[mgifford]

No worries. If the GC were to follow Montreal, it might look more like this:

Guiding principles

Principle 1

The GC commits to systematically considering the solutions put forth by the open source industry for all replacement and development of software and hardware in an effort to remain transparent and to contribute to the common good and to the mutualization of solutions.

Principle 2

The GC commits to basing its decision to use an open source software or hardware on its ability to meet the business needs, and the technological and safety criteria, as well as on requirements specific to the open source industry.

Principle 3

The GC commits to favoring cooperation with other public administrations by using open sources licenses for the development of software and hardware solutions. It further commits to promoting the reuse of these solutions in the public sector. The GC acknowledges it's leadership role within Canada as well as aspirations globally.

Principle 4

The city commits to ensuring that all code or hardware developed by or for the government be under open source licenses and published when considered relevant for the community.

Principle 5

The city commits to contributing to the development communities of the open source software and hardware that it uses, where it is pertinent to do so.

[pjackson28]

For the Digital Playbook, the likely output for such items would be a checklist for the reader, so would probably end up being something like the following:

• ensure all code or hardware developed by or for the government is under open source licenses and published when considered relevant for the community

• contribute to the development communities of the open source software and hardware that your project is using, where it is pertinent to do so

@smellems Are your proposed changes including something similar as to what was suggested above (in the form of checklist items)?

[smellems]

Thanks @pjackson28 Can we propose Introductory text and checklist items based on exiting text and also invent our own?

[pjackson28]

@smellems Yes, you can propose changes to existing text and propose your own stuff as well. Each section of the Playbook has reviewers identified (normally from TBS) so any proposed changes will be flagged for review by the relevant reviewers.