Section 3: Strategies for Building an Open Source Ecosystem #
Demonstrate Leadership on Open Source #
Strong leadership is essential in any organization – especially government – in setting policies and building up capacity that will ensure the success of open source adoption. If you are taking this course, you are in a great position to demonstrate such leadership.
Capacity building to support the adoption of open source software can start long before a procurement or development process begins. Consider hosting regular, organization-wide workshops on open source software, IT strategy, or procurement innovation to help demystify these topics for everyone. Emphasize opportunities for acquiring better products and services, simplicity, efficiency, and creativity. You will be surprised at the number of people who get excited and ask to be involved.
Reduce barriers to open source adoption within your organization by “giv[ing] teams that want to use open source the permissions they need to do so, and simplify the processes to let them focus on finding and matching software to the needs of their users.”[^13]
Build a Right-Sized Team #
Governments – especially small and medium-sized jurisdictions – do not necessarily need to have software developers on staff. However, to effectively obtain and manage digital assets, they should:
Ensure that a wide variety of staff members have a basic understanding of how software procurement, development and maintenance works.
Support internal working groups and champions.
Join networks with peer jurisdictions and open source software communities to share challenges, opportunities, capacities, resources, and processes.
In smaller governments or agencies, the person accountable for the organization’s technology strategy may be best positioned to oversee open source software adoption.[^14] It is also important to note that one staff member can perform multiple roles throughout the process. For example, an IT specialist might also be the product owner and the end user.
Beware, however, of relying on passionate “champions” to take on large amounts of open source software work off the side of their desk. Open source software requires active engagement – it can flatline if a key champion burns out, encounters too many barriers, or leaves the organization. If you’re still taking this course, that champion might be you. Advocate for long-term, systematic support for open source. The return on investment is significant, especially as more software products are adopted and as procurement, implementation and maintenance processes are solidified.
In larger governments or agencies with substantial internal capacity, setting up a centralized office or team is a good step toward institutionalizing open source.[^15]
Attract Talent by Building an Open Source-Friendly Organization #
There are several reasons why hiring and retaining talented IT professionals is easier in an organization that is open source first.[^16]
Open source software is widely used by companies, from development to production. That means talent focus on developing capacity to use it, and seek opportunities to enhance their working knowledge for career advancement;
By contributing to open source software projects, individuals become part of a public “network of trust” and add to their resumes;
Some report that working with open source software improves their job satisfaction because they are contributing to a massive community project (source code fixes, bug reports, documentation updates, etc.);
Open source software provides learning opportunities, because contributors have access to “everything running under the hood” and can learn from more experienced developers).
Work in the Open and Engage Continuously with Users #
Working in the open and centering the end user are key principles and well-accepted best practice in contemporary software. This is especially true in the case of open source software that is developed using agile method (which are, themselves, best practices). To work in the open means “publicly publishing your work on software projects, including existing drafts, future progress, and other work products.”[^19] In order to design and implement software well, you need to know your end user and continuously engage them in three key ways:
Early user research. If you are designing new software or writing an RFP to procure new, adapted or existing software, the starting point is the user. In each of these scenarios, the first step in your process will be discovery research with the end user, to identify their needs and pain points. This is also the time to consider the accessibility needs of different user groups and build these in from the start.[^20] “User stories” as they’re called, become descriptions of software features. They guide the development of the product and evaluation of the end result.
Product evaluation. Over the course of a development or procurement process, the end user should be involved in evaluating mock-ups and early drafts. This will keep your software close to actual uses and needs. Front-line staff can give feedback on how to best integrate the software with their job, and become empowered to use and maintain the software over time.
Ongoing adaptation and maintenance. Particularly in the case of open source software, the software will be adapted and maintained over time. New features and compliance can be added as standards, policies, and end-user needs change. Users should be empowered to offer suggestions, review potential features, identify bugs, and – if they are competent – to contribute to the code itself.