GovTech Singapore is a year into efforts to apply innersource - internal open source practices - to the way it develops and maintains code, with hopes that the effort may ultimately extend beyond the agency and be used across the Singapore government.
Speaking at the GovTech Stack 2022 developer conference yesterday, distinguished engineer Hunter Nield said that the agency had laid foundations for innersource and is starting to expand its use, initially within GovTech but with ambitions to apply it to codebases outside of GovTech as well.
Innersource is an increasingly popular set of software engineering practices that are used to create an open source-like culture inside of an organisation.
Breaking silos
The intent is to break down project silos, enabling developers to more easily find useful code and documentation that others have made, and potentially contribute to its improvement and upkeep.
Initial efforts focused on an innersource working group, a community of practice that has grown to around 30 contributors across GovTech over the past 12 months, with an intent to involve coders from across the government.
Part of the working group’s role is in “dogfooding” innersource; that is, using innersource itself as a test case, Nield said.
“We started building out our internal open source repositories of [innersource] practices, documentation and tools, but that’s not the goal that we want,” he said.
More significant applications of innersource are now starting to emerge.
“We’ve started looking at our internal platforms to be innersourced,” Nield said.
“The Singapore Government Tech Stack (SGTS) as well as GCC - the Government on Commercial Cloud - are progressively being innersourced as we develop.”
The SGTS comprises a suite of tools and services hosted on a shared infrastructure that is intended to reduce agencies' time to stand up new digital capabilities.
The GCC has a similar function, and is described in GovTech documentation as “a ‘wrapper’ platform that provides government agencies with a consistent means to adopt commercial cloud solutions offered by cloud service providers.”
Nield said there is active discussions underway within GovTech that could lead to all code developed by the agency being “innersource-by-default”.
“The discussions have started on how we think about innersource-by-default for the whole of GovTech as an example for the rest of government,” he said.
Such a move could show development teams outside of GovTech the types of codebases and projects that “make sense” to be innersourced: “Which parts of our projects actually you start to open up so we can have much better collaboration, much better discoverability, and to help our teams find information much faster, reuse code, reduce the time to deliver value to our citizens.”
This fits with ambitions for innersource practices to be used right across the Singapore government.
“We don't want this to necessarily be a GovTech initiative,” Nield said. “We want this to be something that is beneficial to the entire government.”
However, GovTech could play an important support role in innersource’s expansion; Nield suggested one option could be for the agency to centrally host “a dedicated core team of innersource developers to help teams both innersource their projects or to contribute to projects to keep them going if they are no longer funded.”
“This is an interesting challenge about project funding in government. We need to think about how we create the longevity [of software projects] and where they would live,” he said.
A year of work
A lot of preparatory work has been put in over the past year to set foundations for the propagation of innersource practices, both inside and outside of GovTech.
“We started to think about three key foundational pieces that we put together to make innersource a success,” Nield said.
“One of those is the platform: building out a single hub that we could start to utilise for innersource.”
GovTech has made SHIP-HATS, its software development lifecycle and CI/CD platform, into this “innersource hub.”
Efforts have also been invested into defining “practices, the patterns and guidelines that … would be relevant for teams who are internally opening their projects and how to make it easier to enable the discoverability, the ability to contribute back again or to have scalable governance processes,” Nield said.
The third pillar of efforts has gone into raising awareness to get teams familiar with innersource practices and achieve buy-in and adoption.
GovTech has put together a framework to guide innersource adoption.
The framework maps out the stages of innersource adoption that might be expected: moving from a purely closed source codebase to one that is openly discoverable by other teams, that starts to accept contributions from outside of the immediate project team, and what that might mean for the way the project is structured and maintained on an ongoing basis.
Governance and licensing is an issue that the agency has spent time working through, particularly as it wants code to be potentially shared and reused.
“In somewhere as large as the government where we have almost 100 different entities, we needed to come up with a particular legal framework that we could start to engage and instil a bit more confidence in the teams utilising the innersourced repositories,” Nield said.
“So engaging with GovTech legal, we came up with what we called the GovTech Public Sector Licence, which is a permissive licence inspired by much of the open source licences for sharing code.
“It’s not just about the usage of code and the expectations for agencies and their vendors but it’s also about safeguarding what happens when code is contributed back again - who owns it, how it’s being done.
“So part of that is introducing a licence file - which is the standard process in open source - in the same way, that we do for innersource. These things are included in every repository or in source code files that may be distributed for the projects that will start to internally open their code.”
Nield said thought had also been put into how to manage code contributions to “ensure we’re merging quality [code] into the projects”. This could comprise a mixture of peer review and automated checks.
