Open Source

Open Source Policy #

1. Introduction & Purpose #

This policy outlines the guidelines and procedures for FunnelStory’s engagement with open source software (OSS). Our goal is to encourage contribution to and use of OSS in a manner that is consistent with our business objectives, legal obligations, and engineering standards. Open source is a vital part of the software ecosystem, and we aim to be responsible participants.

2. Guiding Principles #

  • Quality: Our public open source contributions are a reflection of our engineering team. We strive for high-quality, well-documented, and thoroughly tested code.
  • Collaboration: We encourage collaboration with the open source community.
  • Compliance: We adhere to licensing requirements and best practices for open source engagement.
  • Security: We prioritize the security of our systems and data when using or contributing to OSS.
  • Transparency: We aim for transparency in our open source activities, where appropriate.

3. Using Open Source Software #

  • License Compatibility: Before incorporating any OSS into our projects, ensure its license is compatible with our intended use and does not conflict with our own licensing or create unintended obligations.
  • Security Vulnerabilities: Regularly scan and update OSS components to mitigate known security vulnerabilities.
  • Attribution: Properly attribute OSS components as required by their licenses.

4. Contributing to Open Source Projects (External Projects) #

  • Approval: Minor contributions (e.g., bug fixes, documentation updates) to existing external OSS projects are generally encouraged. For more significant contributions or if there’s any uncertainty, consult with your manager or the designated open source program lead.
  • Confidentiality: Under no circumstances should proprietary or confidential FunnelStory code, data, internal discussions, or upcoming features be disclosed or contributed to public open source projects. Ensure that contributions do not inadvertently expose sensitive information.
  • Copyright: Ensure that any contributions made during company time or using company resources are in accordance with our intellectual property agreements. Typically, the copyright for such contributions will be retained by FunnelStory, or assigned as per the relevant project’s contributor agreement.

5. Creating New Open Source Projects (Internal Projects Released Publicly) #

5.1. Project Initiation and Approval #

  • Proposal: Employees who wish to open source a new project developed at FunnelStory should submit a proposal. This proposal should include:
    • Project description and goals.
    • Rationale for open sourcing.
    • Proposed license (defaulting to Apache License 2.0).
    • Maintenance plan.
  • Initial Repository Setup: The initial repository for a new open source project will be created by @Preetam (or a designated administrator). All new projects will start as private repositories to allow for initial setup, code review, and ensuring no sensitive information is present before public release.
  • Review: The proposal will be reviewed for strategic alignment, legal implications, security considerations, and resource allocation.

5.2. Development and Maintenance Standards #

  • Licensing: All new FunnelStory open source projects will use the Apache License 2.0 as the default license, unless a compelling reason exists for an alternative, which must be approved. A LICENSE file containing the full text of the Apache License 2.0 must be included in the root of the repository.
  • Documentation:
    • A clear README.md file is mandatory. It should explain what the project does, how to install/use it, and how to contribute.
    • Comprehensive documentation for APIs, features, and architecture is required.
    • Contribution guidelines (CONTRIBUTING.md) should be provided.
  • Testing:
    • Robust unit tests, integration tests, and, where applicable, end-to-end tests are required.
    • Strive for high test coverage.
    • Automated testing (CI/CD) should be implemented.
  • Code Quality: Adhere to established coding standards and best practices. Code should be clear, maintainable, and well-commented.
  • Security:
    • Code should be reviewed for potential security vulnerabilities before initial release and on an ongoing basis.
    • Dependencies should be managed and updated to avoid known vulnerabilities.
  • Public Representation: Remember that our public repositories are a direct representation of our engineering team and FunnelStory. Maintain a high standard of professionalism in all code, documentation, and interactions.

5.3. Repository Management and Compliance #

  • Branch Protection: The main (or master) branch of all FunnelStory open source repositories must be protected.
    • Direct pushes to the main branch will be disabled.
    • All changes must be made through Pull Requests (PRs).
    • PRs must be reviewed and approved by at least one other designated maintainer before merging.
    • Status checks (e.g., passing tests) should be required before merging where feasible.
  • No Private Information: It is strictly prohibited to commit, push, or otherwise include any private or confidential FunnelStory information in public repositories. This includes, but is not limited to:
    • Internal credentials, API keys, tokens, or secrets.
    • Customer data or personally identifiable information (PII).
    • Proprietary algorithms or trade secrets not intended for public disclosure.
    • Links to internal-only resources, issue trackers, or repositories.
    • Comments or discussions referencing private company matters.
    • Carefully review all code and commit history before making a repository public.
  • Issue Tracking: Use the repository’s public issue tracker for bugs, feature requests, and discussions related to the open source project. Do not reference or link to internal/private issue trackers or tasks from public repositories.

6. Community Engagement #

  • Be respectful and professional in all interactions within the open source community.
  • Respond to issues and pull requests in a timely manner, as per the project’s maintenance plan.

7. Policy Review and Updates #

This policy will be reviewed periodically and may be updated as necessary.

8. Questions #

If you have any questions about this policy, please contact Preetam.