Open Source

We effusively use, contribute to, and publish Open Source software

Usage #

• When we write reusable code for Silicon Ally (outside of the context of a given client) we will make it open source under one of the licenses described below.
• We’ll prefer using open source software and technologies over proprietary software when we’re setting up infrastructure. Prior to procuring any proprietary software (or recommending a client do so) we will survey the open source landscape to see if there is a suitable OSS replacement.

Contribution #

• We encourage our engineers to contribute to Open Source projects when aligned with their client work. Any contributions made in this way are considered core work.
• Contribution doesn’t just mean code - asking and answering questions on Stack Overflow, filing bug reports with dependent projects, and writing occasional “how to” blog posts are all considered valuable Open Source contributions.

Yearly Donations #

Every year, Silicon Ally solicits from employees a list of open-source projects that we used as part of building our software. The project can be a development tool, a production library, or something in-between. To qualify for the list, a project needs only to be developed under an open-source license, actively used by one or more employees, and accepting monetary contributions.

Employees will then rank each project on how important they think it has been for our organization. Ratings will be averaged, and donations will be given out on a weighted basis.

For this past year (2022), we’re splitting $1,000 dollars (~0.5% of revenue) between 12 open-source projects, and we hope to increase it to 1% of revenue for next year’s distribution.

Publication #

• Every contract with a client will codify an approach for identifying common pieces of infrastructure/bizlogic and extracting them into open source projects.
  • We’ll generate some reusable materials for explaining this process to our clients, and describing the practical and high-minded benefits of the approach.
  • A client’s willingness to support this objective should be one consideration (among many) in client selection and work allocation.
• When working for a client, we’ll aim to have 10% of the project time used to contribute to open source work that supports the client’s project.
• When publishing open source work, we will do so in a standalone, public repository, and include the rationale for any decisions made around publication.
• We prioritize good documentation in open source projects - it’s a reflection of our brand, and is the dominant factor in moving the needle on adoption/use.

Exceptions #

• Avoid using or publishing open source software to directly handle payments and other exceptionally sensitive data - contributions in this space are fine.
• Avoid publishing code that is unlikely to be reusable - ex: tight coupling to a niche problem space, uses technologies that aren’t well suited
• Avoid publishing code that will be hard to maintain - ex: code that is hacky, buggy, has known vulnerabilities, poor test coverage, relies on unstable dependencies, etc.

License #

• Default: MIT
  • OSS’ value isn’t limited to the non-commercial space, and the commercial line isn’t one that sorts worthy from unworthy projects.
  • CopyLeft may inhibit adoption for folks that are reticent or inflexible to publishing their own code (for, at minimum, the reasons we list in the “exceptions” section). We don’t want to hold others to a standard we’re unwilling to hold ourselves to.
  • MIT is a notoriously “fire-and-forget” OSS license, and will require very little upkeep
• When constrained by an OSS license, choose the most permissive allowed by dependencies. Prefer more open licenses in selecting dependencies.

Checklist #

At a minimum, every piece of open-source software we publish will have:

• A public GitHub repo in the Silicon-Ally organization
• An OSI-approved license
• A README.md file containing:
  • An overview of what the project is and where it might be useful
  • The client for whom we developed the project (as part of a larger effort)
  • A link to API documentation
• Tests and continuous integration, usually running on GitHub Actions
• An appropriate versioning scheme, usually SemVer unless there’s a compelling reason not to.

Additionally, any software with a web-based UI will meet the WCAG 2.1 AA Standard, usually verified with automated tools.

This checklist doesn’t apply to forks of other OSS projects.