by Cam Findlay, March 20151
1:(Community Awesomeness Manager, SilverStripe. E-mail: cam@silverstripe.com)
The Common Web Platform for the New Zealand Government is a strategically important web service delivery platform and has been seeing wide adoption among New Zealand government agencies. A key benefit of such a shared technology platform is reusability, in this case of the open source software code used to build the websites that operate on the platform. However, there has been relatively low sharing of open source licensed code taking place. This paper looks to show that this may be due to a lack of engagement between agencies, vendors and the existing open source Community of Practice around the SilverStripe Content Management System software. Seeing this community space as a knowledge and learning structure that fosters open innovation and leads to improved knowledge sharing is key. Further, why it is important that open innovation and code sharing takes place is framed as aligning directly with the New Zealand Government ICT Strategy and Action Plan and as such sharing code is strategically valuable. An ecosystem of thriving open innovation process and open source code sharing benefits the public sector in improved taxpayer fund effectiveness, supports NGOs in New Zealand, and grows economic value in the private sector. As an outcome, a set of principles are put forward for consideration by agencies working on the Common Web Platform around how they can better collaborate, share code and deliver better digital services.
The Common Web Platform (CWP) has seen increasing public sector adoption since its release in September 2013. It aims to deliver a shared set of web service delivery functionality by leveraging the benefits of Free and Open Source Software (FOSS) code and practices. The platform utilises SilverStripe Content Management System (CMS) maintained by a community of developers, commercially backed by SilverStripe Ltd. The default CMS product can be built upon to meet project needs by using modular components created by SilverStripe FOSS community that consists of people from all sectors and private citizens. Members build a level of interpersonal trust through informal interactions that allows them to easily share code and knowledge with each other and improve the overall community ecosystem. It has been noted that while public sector agencies are comfortable sharing code with each other in private, there has been little SilverStripe CMS code for reuse contributed by agencies on the CWP back to the FOSS community (Anderson, 2014). This seems to bypass other agencies from discovering and benefiting from FOSS code and practices. It is likely a lot of this code includes both generic web application logic (with benefits of reuse beyond the public sector scope) and public sector specific code (that may rightly need to be kept private). The following discussion follows on from code sharing workshop held in 2014 in which 8 public sector agencies and 3 private sector web development vendors explored the perceived issues around the lack of sharing code and participating in open innovation between stakeholders using SilverStripe FOSS on the CWP (See Appendix A).
Perhaps a key reason is that code sharing has been primarily viewed from an operational perspective, that is, a focus on the reduced costs and ways to exploit already shared code rather than a strategic perspective that looks at FOSS as both code and a collaborative public-private sector process of open innovation that creates value across boundaries (Morgan & Finnegan, 2014). Such processes require a commitment to ongoing trust building among all participants. This comes at a time when a step-change in the way public sector digital services are expected to be provided to both citizens and businesses as expressed in the New Zealand Government ICT Strategy and Action Plan (henceforth referred to as the 'NZ Govt ICT Strategy' in this paper) (Department of Internal Affairs, 2013). With this in mind, it is the intention of this paper to provide a robust reason why code sharing and working in an openly innovative way on the CWP aligns with the NZ Govt ICT Strategy and therefore should be more actively pursued. Key points from the strategy document will be pointed out and suggestions put forward as to why building trust through considering FOSS sharing principles and participation in FOSS communities can help achieve strategic ICT objectives in Government. This strategic alignment is offered without getting into a philosophical debate about FOSS versus closed source software that is often simply a matter of different perspectives (Polley, 2007). Providing a robust answer to the question "why work collaboratively, build trust leading to improved code sharing ?" will be key in helping all involved in the CWP initiative to better understand that sharing SilverStripe CMS code through the use of permissive, open source licensing is of benefit to themselves and makes best use of taxpayer funds. Further it creates potential for the investments made in the public sector to support NGOs in New Zealand, and grow economic value in the private sector (Grand, von Krogh, Leonard, & Swap, 2004; Henttonen, Pussinen, & Koivumaki, 2012; Morgan & Finnegan, 2014).
As a response to the mentioned code sharing workshop and a literature review into strategic FOSS adoption and open innovation in the public sector, a series of principles have been developed. These guide participants using SilverStripe CMS on the CWP towards improved processes by which collaboration on code occurs in government and meaningful code sharing can occur (Buffett, 2014; Majumdar, 2006). Without code sharing and open innovation, the network benefits of FOSS on the CWP are unlikely to reach their full potential. Given that the open source way of working has been around for decades, the sociotechnical processes already exist to implement a successful CWP FOSS ecosystem (Balter, 2012). By becoming more closely involved in the wider SilverStripe CMS Community of Practice (CoP) and seeing themselves as practitioners, public sector ICT and vendor staff can learn productive code sharing techniques from the FOSS community. As Wenger et al. (2002) state CoPs are "groups of people who share a concern, a set of problems, or a passion about a topic, and who deepen their knowledge and expertise in this area by interacting on an ongoing basis" (p. 4). The present SilverStripe CMS community contains a large body of knowledge, expertise and practices around code sharing and open innovation can already drawn from and contributed to by any stakeholder willing to make the investment in people and time to learn, that is, this CoP can be considered a space where the process of trust develops code sharing and open innovation through informal, yet highly organised social structures. If properly engaged by agencies this will lead to alignment with the NZ Govt ICT Strategy (Grand et al., 2004; Pardo, Cresswell, Zhang, & Thompson, 2001).
With this in mind, imagine the following scenario…
Agency A is looking to more effectively revamp it's digital web services and decides to redevelop it's website on the CWP. They start out with the core CWP SilverStripe code which gives them useful features out of the box, however they need to add further functionality. A quick search through the SilverStripe CMS community code catalogue reveals a useful module they could use to get the majority of the features they need. However, the module is missing a key feature they need, "Widget X". Rather than simply going ahead and trying to develop Widget X themselves, Agency A's IT staff are already active in the SilverStripe CMS community of practice and begin discussing the feature on the community mailing lists and forums, they also raise these feature requests as issues on the module's GitHub (a widely used code sharing platform) repository so that the whole community can see what they are proposing. Meanwhile, Agency B, whose IT staff are also scanning the community see the proposal for Widget X, needs exactly this feature, too!
*After an exchange of dialogue on community communication channels between representatives of Agencies A and B discussing the requirements for Widget X, they work out that while most of the requirements they both need from Widget X are generic, Agency A has a particular extra requirement which is deemed as something that should be kept private (it is very specific to Agency A's security and privacy policies). With this in mind, the two departments agree to have Widget X built including only the generic features (that they can both safely use without any risk) and Agency A agrees to create an additional module that builds on top of Widget X and will not be shared publicly (though other agencies may use it). They agree to share the cost of having Widget X created while Agency A will simply include the cost of it's additional private module as part of their own website redevelopment project. Agencies A and B approach Vendor Ltd, a web development company that specialises in SilverStripe CMS development to build Widget X. Staff from Vendor Ltd are big participants in the SilverStripe CMS community too, they are already aware of the proposed Widget X through the forum posts and discussions held out in the open, so they are able to quickly scope out the work (based on already having seen the requirements out in the community discussion spaces) and are able to build a trusted relationship with the departments, as they all identify as community members and see the benefits of building Widget X and sharing it with the wider community too. *
*The module is on another community member’s GitHub account and the work to add Widget X to the existing module will be carried out by Vendor Ltd who simply fork the module repository and begin working on the feature and start discussions with the module maintainer (who by the way, already knows about the new Widget X too and was part of the original community discussion about it). Vendor Ltd submits improvements to the code through 'pull requests' to the module repository as significant pieces of the work are completed. Meanwhile the module maintainers, the ICT teams from Agency A, B and C ( C have been monitoring the development of Widget X as it might be something they need in the future) and other community members comment on the code, pointing out any potential bugs or improvements (which are corrected by Vendor Ltd or the reporters themselves). When the module maintainer has reviewed each pull request of code and is satisfied that the code is good, they merge it in, and Widget X begins to take shape ready for use in projects. It meets the needs of Agency A, B, C, other FOSS community members and a not-for-profit organisation that has also recently adopted SilverStripe CMS and found the work on the code catalogue. Vendor Ltd also gets a good reputation within the community as gains further SilverStripe CMS related work from Agency D after hearing about their great service and support around developing Widget X and the value they have created for the other Agencies by sharing the code and working in an collaborative, open way. *
*The value of Agency A's original requirements has been multiplied by working in an openly innovative way. Agencies A, B, C and D now all have the functionality they need as the code was shared, built in a modular way and easily reusable effectively acting as a 4 x force multiplier of the taxpayer dollar (Ministry of Science, Technology and Innovation, 2009; Polley, 2007). Further, it has also created economic and social benefits for the non-profit/NGO sector, Vendor Ltd (as they continue to provide service and support around the module as they know it well) and any commercial projects that make use of the module code to help build their business’ website. By being strategic about code sharing in this case, a huge amount of value has been created which ultimately stems from the public good of shared code and the courage to view other organisations as interdependent collaborators as part of a wider value network approach to delivering digital services to citizens (Henttonen et al., 2012; Department of Internal Affairs, 2013). *
What is not shown here in this story is Agencies E and F. They had already both built a Widget X-ish feature in complete isolation from each other and the wider SilverStripe CMS community around the same time. The code was mixed in with their large website project codebase rather than building it in a modular way. Since they did not participate in the community, they had no idea about the discussions of Agencies A and B, nor did they communicate the fact they were building Widget X to the FOSS community which would have avoided a lot of duplication of time and costs. They now have excess code to maintain which could otherwise have been shared and maintenance would have been a shared responsibility by those using the module from the community (Morgan & Finnegan, 2014, Polley, 2007). Over the next few months community members add a number of great new features to Widget X that Agencies E and F need too. They have a choice, rewrite their application to use the shared Widget X module, or continue to maintain their own code patching in any new features added (creating extra ongoing costs every time the shared Widget X gets updated). Either way, by not being open to sharing and open innovation in the community, Agencies E and F now have created additional costs and are spending taxpayer funds on something that already exists.* *
Let's make sure that for the CWP, that Agencies E and F's approach remain a figment of this author's imagination. The kind of code sharing and open innovation thinking shown by Agency A and B working alongside private vendors and the SilverStripe CMS community as a larger value network has saved money, created trust allowing for great knowledge sharing to occur and makes the modular code more maintainable into the future (Nissen, Evald, & Clarke, 2014; von Krogh, Ichijo, & Nonaka, 2000).
At this stage it might be tempting to get into a philosophical debate about the commonly cited arguments for open source versus closed source software (both sides often make the same argument just from differing perspectives) (Payne, 2002). Instead, it would be more productive to consider the strategic aspects of open source, in particular how operating in an open source way aligns with the NZ Govt ICT Strategy. This ultimately helps everyone working towards improved government web service delivery pull together in the same direction. Firstly, let's define FOSS and open innovation. Even if you are aware of these concepts, we should set off on our exploration of the strategic side of open source with a shared understanding of how they are perceived within this paper.
While free as in cost, free and open source software actually more accurately refers to the set of licensing freedoms that accompany the source code (Buffett, 2014). These freedoms are commonly cited as the rights to reuse, copy, modify, and redistribute (Despi & Luca, 2006). Usually contributions back to shared code repositories are released under the same license as the original code. This is not to say that copyright does not exist in FOSS, it does and is held by the original creator of the software unless explicitly stated otherwise. Unless contracted out of, code developed by vendors for public sector agencies is considered to be Crown Copyright (Balter, 2012; Crown Copyright, 2014). While there are licensing frameworks in place for content and data (NZGOAL), there is currently little guidance around public sector FOSS licensing. The NZGOAL framework makes a reference that agencies wishing to share code should do so under open source licenses without stating which to use (State Services Commission, 2010). For SilverStripe CMS code, permissive licenses are favoured such as the Berkeley Software Distribution (BSD) or the Massachusetts Institute of Technology (MIT) licenses where the set of freedoms are passed on and reuse can occur as long as the original license is included with the software. Sharing code for reuse with SilverStripe CMS on the CWP helps to open up its strategic potential, that is, seeing code sharing as a process of open innovation rather than simply passing on an artifact of code (Morgan & Finnegan, 2014). What is valuable in this case is not the code itself, rather the expertise and knowledge gained and shared through studying the code and interacting with the community that maintains and uses it (Grand et al., 2004). For example, SilverStripe CMS is open sourced under the BSD license that is a highly permissive license allowing wide reuse of the code to benefit citizens (as a public good), public sector (as efficient use of taxpayer funds) and the private sector (helping economic growth) (Polley, 2007; Ministry of Science, Technology & Innovation, 2009). FOSS communities of practice help connect people across organisational and sector boundaries in a knowledge network, encouraging trust to develop, a prerequisite for knowledge and code sharing (Majumdar, 2006; Pardo et al., 2001).
Open innovation refers to the idea of organisations utilising both external and internal knowledge to innovate (Henttonen et al., 2012). It allows for the crossing of boundaries between organisations by connecting them in a value network where both risks and rewards are shared (Open Innovation, 2015). Organisations practicing open innovation see that knowledge is distributed widely and that relying on siloed knowledge has the potential to restrict performance. We can view that communities of practice act as a social store of organisational and industry knowledge that can pool research and development, allow the cross-pollination of intellectual property and shared knowledge artifacts (such as knowledge and code in the CWP context) (Wenger, McDermott, & Snyder, 2002). Open innovation takes a wide ecosystem view with organisations both drawing from and contributing back to the system (Henttonen et al., 2012). For example, building a website using existing SilverStripe CMS code and then contributing back any modular improvements and extensions that may have been developed through public code repositories would be considered open innovation. Simply drawing from the community as a "passive exploiter" (Henttonen et al., 2012, p. 136) without giving back is considered external innovation and within a FOSS context will not facilitate the benefits of code sharing as no connections, nor trust is formed with such an approach to exploiting FOSS code. Further, closed innovation sees the source of innovation as internal only. It perpetuates a need to exploit the innovation economically in order to recoup internal costs and likely keeps sharing to a minimum (Henttonen et al., 2012). Both external and closed innovation view processes like collaboration with others and sharing FOSS code as an operational cost or overhead. In contrast, open innovation sees these processes as a strategic value centre, creating something of ongoing value for all in the value network (Morgan & Finnegan, 2014). "Strategic open source raises questions about how businesses can effectively create and capture value not only from using the software artifact, but also from engaging with the open communities and commons-based peer production processes from which the software emerges" (Morgan & Finnegan, 2014, p. 227).
What remains to be detailed is to compare a selection of relevant strategic objectives from the NZ Govt ICT Strategy and to explain how an orientation towards open innovation and engaging in code sharing can align agencies and achieve strategic objectives. This alignment should help everyone in the web digital services space pull together in the same direction in order to provide better service to citizens and business alike. The following sections are headed with extracts of strategic action points from the NZ Govt ICT Strategy document and provide a discussion as to why open innovation and code sharing is strategically important for agencies.
The NZ Govt ICT Strategy's core focus is on government service digitisation, that is, being able to provide end to end online services for the majority of citizen initiated transactions with the government. This allows citizens to better interact with government without having to understand how government itself is structured (Department of Internal Affairs, 2013). Agencies that share FOSS code as a set of shared capabilities can accelerate the service digitisation process of the wider government (Ministry of Science, Technology & Innovation, 2009; Morgan & Finnegan, 2014). This is due to FOSS freedoms of reuse and redistribution of code that ensures the functionality is not developed (and paid for!) multiple times and likely makes websites more interoperable (Ministry of Science, Technology & Innovation, 2009). Agencies that have interdependencies in their end to end service blueprints should look towards ways of working which include co-funded, co-developed code and including input from the wider community in terms of ideas or code contributions. For example, the Danish public sector have adopted the idea of rapid digitisation of service provision and do so by ensuring that they use FOSS as a pragmatic tool for delivering strategic value to citizens and not simply relying on the operational, cost savings argument of FOSS—though many authors have proven a lower total cost of ownership over the long run (Buffett, 2014; IDA, 2001; Ministry of Science, Technology & Innovation, 2009). The Danish Ministry of Science Technology & Innovation state that "the liberty to modify software especially in strategic collaborations supports innovation … a public authority can provide relevant software components under an open source li[s]ence and thus drive [service] digitisation faster" (2009, p. 10). This alludes to clear reasons why public sector agencies creating code themselves or by way of vendors should insist on the code being created in modular ways and shared through permissive open source licenses. This ensures components are discoverable by the maximum number of interested stakeholders and the uptake of this code speeds the digitisation efforts of government. Unshared code that is kept siloed for no legitimate business, privacy or security reason, rather simply due to a dogmatic view of sharing, slows efforts towards quality digital service delivery (Henttonen et al., 2012).
This points out that modular code being developed for websites running on the CWP should be as a rule, shared through open source licensing. Unless a robust business reason exists (a legitimate privacy or security concern), there really is no excuse for not sharing code funded by the taxpayer (Scott, 2012). Any sensitive functionality or configuration can be abstracted off into project specific code or held in private modules (stored in private CWP code repositories). Generic functionality can and should be released into the open source community as modules where the responsibility for maintenance is shared among those stakeholders that use it (public sector or otherwise) (Morgan & Finnegan, 2014). This mode of thinking feeds into other NZ Govt ICT Strategy points such as "reuse existing functionality components from across the system wherever possible to reduce duplication and fragmentation" and "[systems] are appropriately modularised so that component parts can be upgraded over the expected life of assets" (Department of Internal Affairs, 2013). By design, FOSS code is often created to be modular, loosely coupled and able to be extended that creates more maintainable, lightweight modules. This makes code easy to reuse rather than duplicating efforts (Bouras, Filopoulos, Kokkinos, Michalopoulos, Papadopoulos, & Tseliou, 2014). These components can then be brought together into a project to achieve an agencies desired web services outcomes using code management tools. SilverStripe CMS development uses just such a tool called Composer and there is a catalogue of modules available to discover code for reuse (SilverStripe, n.d.).
This creates an ecosystem of capabilities which can be exchanged freely, updated independently by many contributors in an organised way and when widely used, shares the maintenance burden across the community of users of this code (that the public sector should count itself part of) (Henttonen et al., 2012; Morgan & Finnegan, 2014). Working within the community requires good coding practices, communication (digitally and in-person) and the development of trust between the stakeholders involved. For example, the modular approach used in SilverStripe CMS development promotes good practice code extension techniques and abstraction of reusable, generic features from sensitive code (SilverStripe, n.d.). If followed correctly, this ensures public sector websites do not end up with intertwined FOSS and sensitive code that is unable to easily benefit from community updates and will likely require additional costs in the future. Strategically, not following these modular coding practices means agency code would be less valuable to the SilverStripe ecosystem as it is unlikely to be able to be contributed back or create additional value (Mergel, 2014). Open sourcing code however should not be viewed as a silver bullet, if it doesn't make sense to share publically certain pieces of code, document the legitimate reasons (a 'security by obscurity' argument is unlikely to be accepted in the FOSS community) and keep it private (Stewart, 2014).
Code sharing and open innovation aids in achieving this strategic collaboration objective. As new functionality is required for SilverStripe CMS websites running on the CWP, working in an openly innovative way can help facilitate collaborative efforts towards building and sharing these required modules of code (Morgan & Finnegan, 2014). Working together with others on common problems gives rise to Communities of Practice (CoP) which are cross-boundary, cross-organisational spaces for knowledge exchange to take place (Wenger et al., 2002). There have been a few attempts at creating a distinct CWP CoP, however these efforts have not been well received, nor well used. Instead, if we view developers for CWP simply as practitioners of SilverStripe CMS development on the CWP, then a shared CoP acting as a valuable social store of knowledge and a space for collaboration already exists, that is, the SilverStripe FOSS community. This community interacts socially online through various digital channels and meets regularly in person locally in Wellington (and other centres around the world). Participants can share knowledge of what they have been working on. This may be something technical, such as a complex solution to a common code problem, or in the form of higher level case studies and module showcases. It is this community space that public sector and private sector organisations alike should look to participate in. For example, "Australian Government agencies will actively participate in open source software communities and contribute back where appropriate" (AGIMO as cited in Waugh, 2011, p. 1). Communities of practice form as an informal facilitation space for open innovation. Trust is built between participants and trust is a known precondition to knowledge sharing or in this context, code sharing. Simply put, we are more likely to share knowledge with those we trust, hence strategically getting agencies and other stakeholders to work together through FOSS communities helps meet this and other goals set out in the NZ Govt ICT Strategy (von Krogh et al., 2000).
3.1.4 "Focus on lowest total cost of ownership over time, delivering more affordable and sustainable services"
With total cost of ownership (TCO) there are two perspectives this can be approached from. FOSS can be considered from a purely operational point of view, that is, that there are no license fees to pay. That returns us to the exploitative viewpoint that FOSS should be used, as it is free in monetary terms and used purely on the basis of lower acquisition costs (Buffett, 2014). However it must be considered that technical operational costs are still involved in running FOSS systems or something more closed (Ministry of Science, Technology & Innovation, 2009). The strategic view on the other hand should be reframed as value creation (Morgan & Finnegan, 2014). Reuse of shared code should be considered to be a force multiplier of the tax dollar, that is, in the long term not having to spend on functionality more than once through collaborative efforts reduces the total cost to the whole ecosystem (Ministry of Science, Technology & Innovation, 2009; Polley, 2007). This more long termist look at total cost of ownership for strategic web projects on the CWP takes into account the shared capabilities and network effects of shared code used widely throughout a community of cross-sector developers. As more capabilities and code is shared and reusable, the costs of digital services across government will become more efficient (Pardo et al., 2001). Additionally, due to the modular code approach of SilverStripe CMS, the costs of upgrading and maintaining these capabilities in the long term will also factor in to a lower TCO due to shared upkeep and being able to modify code incrementally when required either using internal ICT teams or engaging with vendors (Ministry of Science, Technology & Innovation, 2009).
An interesting perspective that can be taken with sharing code, is that of shared code capabilities being a commodity containing mostly generic logic that can be built upon (Balter, 2012; Morgan & Finnegan, 2014). There is a shared ownership and responsibility model of shared code once it is released with an appropriate open source license into the FOSS community. Maintenance is carried out by those that use the code rather than it being a burden on a single entity (IDA, 2001; Morgan & Finnegan, 2014). With respect to the Crown ICT assets, code that owned by an agency and is not shared remains the burden of that agency to maintain and upgrade so we could say that this code is still on the agency's books as some intangible asset requiring upkeep. To align better strategically, a shift of perspective about the nature of code once shared could be helpful. It effectively removes it as a commodity from the agency and sets it up as a public good for other agencies and the wider FOSS community to make use of, effectively held in trust as a publicly available commodity asset by the community (Bouras et al., 2014). For agencies about to share code, in terms of risk of liability in releasing the code, most open source licenses (and indeed most proprietary software too) do not warrant the code, it is provided as it where is (Morgan & Finnegan, 2014). Interestingly, this does open up a market for complementary service and support around the code from the local ICT industry stimulating economic growth (Despi & Luca, 2006; IDA, 2001; Morgan & Finnegan, 2014). When commodity code is no longer siloed inside agencies or vendors, a focus on delivering more value to citizens by building value on top of this commodity code layer can be achieved (Grand et al., 2004). To take the strategic view, organisations that utilise commodity public good code should "break with the conventional 'intellectual property rights' business models" (Grand et al., 2004, p. 600) and allow code to be communally stewarded by the FOSS community rather than hold on to it as an internal asset.
3.1.6 "ICT skill and workforce needs are constantly changing ... communities of practice … will be established to provide agencies with consistent access to expertise"
Knowledge and learning through communities of practice is where FOSS is of great value. Shared code is able to be studied to learn from other developers approaches. Many FOSS contributors are highly skilled experts and their development knowledge is captured in the code they create and share (Henttonan et al., 2012; Morgan & Finnegan, 2014). If agencies, vendors and community developers that create SilverStripe code for CWP are able to interact with each other more in an informal space, there is potential for enhanced industry learning and knowledge sharing (Bouras et al., 2014). Interaction should take place in person with representatives from agencies, vendors and the wider community attending the regular Meetup groups, and virtually, utilising digital channels such as forums, mailing lists, and chat services within the existing SilverStripe community. This interaction will help those working on SilverStripe CMS web sites for the CWP to learn best practice approaches as the community acts as a steward of shared knowledge and the community itself develops best practices over time (Wenger et al., 2002). To date there has only been a small amount of agency staff interacting within the community and these seem to be agencies already championing FOSS and gaining the benefits of open innovation and code sharing.
The limited amount of code sharing noted by Anderson (2014) could be a product of this limited community interaction among public and public sector staff with the existing SilverStripe community members (who are also made up of public and private sector staff). While there may be concerns of bringing these groups together (due to perceived competitive rivalry or some other reason), the intention of a CoP is to act as a centre of trust and shared knowledge, and should be participated in openly while leaving competitive motives out (Wenger et al., 2002). In practice this could be difficult, none the less, it must be attempted if we are to start seeing improved ICT skills and learning around the ideas of FOSS and code sharing for the CWP. As the public sector is not in competition with itself, vendors should recognise that to deliver value to their public sector clients is to work with them collaboratively and ensure code developed is shared openly and able to be studied (Balter, 2012). This helps bring their clients into line with, and achieve objectives from, the NZ Govt ICT Strategy which is of high priority. Perhaps seeing knowledge and expertise gained in complement to shared code is the real source of value for agencies and vendors rather than code itself? Both agency and vendor teams will have the opportunity to continuously renew and grow their skills alongside the FOSS community as more code is shared.
Allowing agency and vendor staff to be part of the same CoP can also serve another purpose; that of a knowledge management function. In this respect managing an organisation's tacit knowledge (knowledge in the head) to avoid it walking out the door can be achieved (von Krogh et al., 2000; Wenger et al., 2002). As staff are allowed to engage fully in CoPs they begin to identify themselves as both staff of their respective organisations and as a practitioner of CoP. While they may move organisations in their career, the role of the CoP has become to act as a stable, informal support network for their profession and to grow their expertise (Wenger et al., 2002). When viewed through this lens, staff turnover of key personnel is much less of a knowledge loss. As long as the they continue to identify as practitioners, and both their new and old organisations are active participants in the CoP there are opportunities for both organisations to benefit from knowledge, it becomes socially stored in the community rather than siloed in one brain (von Krogh et al., 2000; Wenger et al., 2002). This openness by organisations to allow staff to engage and contribute code sharing in FOSS communities can reduce turnover itself and has the potential to attract high quality developers if they see this as a non-monetary perk of the job. The NZ Govt ICT Strategy states that "Government ICT will be a ‘best place to work’ with staff being engaged, incentivised and recognised in new ways" (Department of Internal Affairs, 2013, p. 24). Strategically there will always be renewed knowledge, learning and access to expertise simply by organisations working out how they can allow staff to meaningfully participate in these existing communities of practice.
The CWP is clearly a strategically valuable offering for agencies looking to improve their web service delivery processes and overall should help to speed up the government digitisation efforts. This however can only occur if reusable code is shared through open source licenses and collaborative efforts towards more open innovation are fostered between all stakeholders. Participation in the existing SilverStripe FOSS community can help improve code sharing by becoming a space where cross-boundary relationships can form and trust is grown. Working with others facing similar challenges and problems to solve (such as providing excellent digital service delivery) becomes a conduit to improved code sharing. The more proactive agency participation in the FOSS community either via face to face events or through digital channels, the more reusable, open source code will likely be generated and shared. Further, the community acts as a social store of knowledge and learning that agencies can draw from and contribute to. This aids in growing the collective pool of web services development knowledge across the entire sector and has positive externalities for NPO's and the private sector in terms of their web service delivery to the social sector and improved economic growth respectively. What is clear it that incorporating open innovation and engaging in FOSS code sharing is in direct alignment with the NZ Govt ICT Strategy, and in this respect agencies should investigate way to carry these practices out in order to drive successful digital service provision to the New Zealand public and business.
Based on this strategic view, a set of principles has been developed based on input from agencies and vendors that attended the code sharing workshop (See Appendix A), and research into code sharing and open innovation in government which appears to have a growing body of literature. Most of the principles below are in fact centred around changes process rather than any specific technological innovation. As Pardo et al. (2001) put it "knowledge about practice in a technological environment is not always about technology. The problems of this sort of practice remain complex human and organi[s]ational ones that can be assisted but not solved by technology" (p. A5). Following these principles aims to facilitate the strategic benefits of code sharing and open innovation in the public sector and each agency will need to work through how it goes about implementing these in practice.
-
Be open by default unless a robust business reason relating to privacy or security exists. Aim to release reusable modules under FOSS licenses, on social coding platforms such as GitHub or if kept private on the share CWP GitLab service.
-
When adding new features to digital service delivery, always check to see if something already exists or could be adapted for your needs. Ensure a full environmental scan of shared code catalogs maintained by the FOSS community before undertaking new work.
-
Aim to build new features in a modular way. View projects as a set of components rather than a monolithic codebase. You might use the code again in another project or other stakeholders could reuse it. Keeping code lightweight and modular allows more valuable customisations to be built on top of this commodity layer.
-
Release code publicly, early and often to allow others to contribute and catch bugs early. Use semantic versioning it indicate when code is ready to be used in production. Make code discoverable by submitting these to community module catalogues.
-
Consider the shared ownership and maintenance model of the code. Open source licenses usually contain a warranty disclaimer that means agencies do not acquire legal liability when sharing code. This allows others to safely reuse, maintain and upgrade the code as long as remains useful and there is no ongoing sole burden or risk on agencies to maintain the code (they they may opt to do so due to the utility for projects).
-
Engage in existing FOSS Communities of Practice. This is a social store of expert knowledge and stewards the development of best practices. Ensure you have representatives working across boundaries in these communities and participation is supported internally. This builds trust and social capital leading to improved knowledge growth as practitioners.
-
When working with vendors always insist that code is built to be modular, reusable and shared through FOSS licenses. Discuss any implications of this during the planning of work to ensure the long term availability of the code. Determine how the copyright and licensing will work.
-
Communicate the features you need to build by discussing them in the FOSS community (unless of course they are sensitive). Where common needs are identified work with other stakeholders (public or private sector) to share ideas and if appropriate, costs.
-
Always test code, report any issues in the appropriate manner or contacting the code maintainer. This aids in getting bugs fixed promptly and new versions released more quickly. Testing in general is also a good idea, by releasing code in social coding platforms you can often make use of automated testing tools they provide.
-
See shared code as a public good, take the long term view, work with others to build a common set of useful commodity features that benefit the public sector, facilitate social outcomes and drive economic growth.
"Open Source for Government: A collaborative resource for government employees looking to participate in the open source community" by Ben Balter, used under CC BY-SA 3.0 / Sections modified from original to fit New Zealand Government Common Web Platform context.
"Government ICT Strategy and Action Plan to 2017" by Department of Internal Affairs, used under CC BY 3.0 NZ.
Anderson, B. (2014). Common Web Platform wins Open Source Award. Retrieved from https://webtoolkit.govt.nz/blog/2014/11/common-web-platform-wins-open-source-award/
Balter, B. (2012). Open source for government: A collaborative resource for government employees looking to participate in the open source community. Retrieved from http://ben.balter.com/open-source-for-government/
Bouras, C., Filopoulos, A., Kokkinos, V., Michalopoulos, S., Papadopoulos, D., & Tseliou, G. (2014). Policy recommendations for public administrators on free and open source software usage. Telematics and Informatics, 31(2014), 237–252.
Buffett, B. (2014). Factors influencing open source software adoption in public sector national and international statistical organisations. Paper presented at the Meeting on the Management of Statistical Information Systems (MSIS 2014), Dublin, Ireland and Manila, Philippines. Retrieved from http://www.unece.org/fileadmin/DAM/stats/documents/ece/ces/ge.50/2014/Topic_1_UNESCO.pdf
Crown Copyright. (2014, November 20). In Wikipedia, The Free Encyclopedia. Retrieved February 5, 2015, from http://en.wikipedia.org/wiki/Crown_copyright
Department of Internal Affairs. (2013). Government ICT Strategy and Action Plan to 2017. Retrieved from https://ict.govt.nz/strategy/
Despi, I., & Luca, L. (2006). On the ambiguity of commercial open source. Anale. Seria Informatica, 4(1), 31–40.
Git. (2015, January 25). In Wikipedia, The Free Encyclopedia. Retrieved February 5, 2015, from http://en.wikipedia.org/wiki/Git_%28software%29
Grand, S., von Krogh, G., Leonard, D., & Swap, W. (2004).Resource allocation beyond firm boundaries: A multi-level model for open source innovation. Long Range Planning, 37(2004), 591–610.
Henttonen, K., Pussinen, P., & Koivumaki, T. (2012). Managerial perspective on open source collaboration and networked innovation. Journal of Technology, Management & Innovation, 7(3), 135–147.
IDA. (2001). Study into the use of open source software in the public sector: Part 1. Retrieved from http://ec.europa.eu/idabc/en/document/333/5849.html
Majumdar, D. (2006). Collaboration among government agencies with special reference to New Zealand: A literature review. Social Policy Journal of New Zealand, 27(2006), 183–198.
Martin, K., & Hoffman, B. (2007). An open source approach to developing software in a small organization. IEEE Software, January/February(2007), 46–53.
Mergel, I. (2014). Introducing open collaboration in the public sector: The case of social coding on Github. Paper presented at the 2014 European Group of Public Administration (EGPA) Annual Conference, Speyer, Germany.
Minnée, S. (2012). Why BDS? Retrieved from http://www.silverstripe.org/blog/why-bsd/
Ministry of Science Technology & Innovation. (2009). Open source software and the public sector. (Report by the National IT and Telecom Agency, Denmark, January 2009). Retrieved from http://www.digst.dk/Servicemenu/English/IT-Architecture-and-Standards/Open-Source-Software/Open-Source-Software-and-the-Public-Sector
Morgan, L., & Finnegan, P. (2014). Beyond free software: An exploration of the business value of strategic open source. Journal of Strategic Information Systems, 23(2014), 226–238.
Nissen, H., Evald, M., & Clarke, A. (2014). Knowledge sharing in heterogeneous teams through collaboration and cooperation: Exemplified through Public–Private-Innovation partnerships. Industrial Marketing Management, 43(2014), 473–482.
Open Innovation. (2015, January 30). In Wikipedia, The Free Encyclopedia. Retrieved February 5, 2015, from http://en.wikipedia.org/wiki/Open_innovation
Pardo, T., Cresswell A., Zhang, J., & Thompson, F. (2001). Interorganizational knowledge sharing in public sector innovations. Academy of Management Proceedings 2001, PNP: A6.
Payne, C. (2002). On the security of open source software. Information System Journal, 12, 61–78.
Polley, B. (2007, December). Ministry of Justice open source discussion paper. Retrieved from http://nzoss.org.nz/news/2007/ministry-justice-open-source-discussion-paper/
Scott, J. (2012). How Consumer Finance made open source both a policy and a mission. *Opensource.com. *Retrieved from http://opensource.com/government/12/4/how-consumer-financial-protection-bureau-made-open-source-both-policy-and-mission/
SilverStripe. (n.d.). SilverStripe documentation. Retrieved from http://docs.silverstripe.org/en/
State Service Commission (2010). New Zealand Government Open Access and Licensing framework (NZGOAL). Retrieved from https://ict.govt.nz/guidance-and-resources/open-government/new-zealand-government-open-access-and-licensing-nzgoal-framework/
Stewart, J. (2014). When is it ok not to open all source code? Retrieved from https://gds.blog.gov.uk/2014/10/08/when-is-it-ok-not-to-open-all-source-code/
The Cathedral and the Bazaar. (2015, January 21). In Wikipedia, The Free Encyclopedia. Retrieved February 8, 2015, from http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
von Krogh, G., Ichijo, K., & Nonaka, I. (2000). Enabling knowledge creation: How to unlock the mystery of tacit knowledge and release the power of innovation. New York, NY: Oxford University Press.
Waugh, P. (2011). Open government, what is it really? Retrieved from http://opensource.com/government/11/11/open-government-what-it-really/
Wenger, E., McDermott, R. A., & Snyder, W. (2002). Cultivating communities of practice: A guide to managing knowledge. Boston, MS: Harvard Business School Press.
CWP better code sharing workshop: Information collected from participants October 2014 (PDF, 995Kb)