Files
opentf/TSC/2024-07-02_NOTES.md
Christian Mesh 59d24390b7 OpenTofu Charter and Governance (#2830)
Signed-off-by: Christian Mesh <christianmesh1@gmail.com>
Co-authored-by: Arel Rabinowitz <arel.rabinowitz@env0.com>
Co-authored-by: Igor Savchenko <igor@scalr.com>
Co-authored-by: James Humphries <jamesh@spacelift.io>
Co-authored-by: Roger Simms <roger.simms@harness.io>
Co-authored-by: Zach Goldberg <zach@gruntwork.io>
Co-authored-by: Scott Nicholas <snicholas@linuxfoundation.org>
Co-authored-by: James Humphries <James@james-humphries.co.uk>
2025-05-23 08:18:56 -04:00

6.6 KiB
Raw Blame History

2024-07-02

Attendees

Core Team:

TSC:

Agenda

Summary of the last meeting

What is the current Vision of OpenTofu? Build the IaC tool of choice for the Community and Businesses that use and support it.

How do we follow our Vision? We focus on Adoption by winning hearts and minds.

Who do we want to try to adopt OpenTofu?

  • Large Organizations / Cloud Providers
    • Slow movement, but critical features can cause shifts (State Encryption)
    • Seeking stability / low risk
  • Small Organizations / Startups
    • More agile / likely to give OpenTofu a try for smaller QoL improvements
  • Individual Developers
    • New developers are looking for a strong community to participate in
    • Existing developers are trying to keep their existing patterns / infra working with as little friction as possible

How do we entice them to Adopt OpenTofu?

  • Maintain compatibility with Terraform 1.5.5 as many organizations have frozen on this or lower version.
  • Track developments in Terraform beyond 1.5.5 and prioritize new features when they make sense for OpenTofu.
  • Continue to build new and exciting features that make OpenTofu stand out.
  • Gather information from TACOs directly and combine with community issue voting to help shape roadmap.
  • Testimonials / Logos for the website?

What is blocking them from Adopting OpenTofu?

  • FUD: Fear, Uncertainty, Doubt
    • Lack of knowledge on provider compatibility
    • Lack of clear information on goals / roadmap
    • Unsure about the long term viability of OpenTofu
    • Lack of dedicated support contracts (TACO opportunity?)
  • Cost of switching tooling / infrastructure

Do we want to prioritize different classes of potential OpenTofu adopters? Do we want to focus on Top Down or Bottom Up adoption?

Discussion
  • Website to address FUD / focus on tofu not manifesto
  • Janos has been prototyping website changes / messaging
  • Section for guides? Do we want to host or link to external guides?
  • Gold level sponsors / prioritize contributing sponsors. Look at blender as a good example.
  • Sponsored developers may be advocates for issues, as long as they are impartial.
  • Keep bugging TACOS / Founders for Testimonials and Logos for the website.
  • Janos: Developers are looking for features - Janos
  • Roni: Enterprise is looking for stability / confidence

Proposed workflow between TSC, Tech Lead, and Core Team

High Level Planning board on GitHub

This board will serve as a discussion hub / common view into what tasks / goals are priorities. Between releases the Tech Lead will manage updates to this board, meeting with the Core Team and TSC independently to keep this board up to date.

The Top Voted Issues (GitHub) should be taken into consideration when updating this board, alongside knowledge from TACOS about customer requests / roadblocks.

Release Milestones on GitHub

When the Core Team is wrapping up a release (alpha1 tentatively), the Tech Lead will meet with the Core Team and TSC independently to build out the next release milestone. This discussion around building this milestone should be based on the top items on the High Level Planning board.

How public should this process be? Items in high level planning might be useful to talk about in blog posts and articles, but could potentially misrepresent the flexibility of planning tasks at that level. Milestones on GitHub are inherently public, though they are treated as a goal and not a commitment. Frequently, issues that dont make it into a given release are added as a higher priority into the next release milestone.

Ownership of the OpenTofu VSCode Extension

We have two repositories forked by a community member for the VSCode extension (extension, language server). Plus, this person owns the OpenTofu extension in the Visual Studio Marketplace.

He did some work on the mentioned repositories, but not recently. Plus, the extension has major bugs (e.g., it throws errors when the Terraform extension is installed) and does not support our new features like State Encryption. The maintainer is not working actively on this extension. We reached out to him by email to ask about collaboration. He mentioned he kept changes to a minimum since hes unsure if he can maintain it without community backing. For easier collaboration, he suggested:

  1. To add us as co-maintainers.
  2. These projects should be moved under the OpenTofu organization.
    1. What permissions (if any) would the original forker have?

Do we want to accept any of the above suggestions? It is relevant to mention that the original Terraform repositories are owned by HashiCorp.

Discussion
  • Roni: We cant own the entire ecosystem, its a delicate balance on developer experience vs commitments. Core team are influencers to help getting third party tooling going.
  • Zach: My 2c is since our overall objective is opentofu adoption, fixing papercuts like IDE plugins should be in scope. Christian agrees.
  • James: Full legal review of pulling in the code. Prioritization? Limited typescript knowledge in the core team.
  • Roger: Golang considers lsp to be a high priority / in line with feature releases and documentation. Expectation of developers.
  • Ronny: How much control do we want/need over this project?
  • Janos: Not sure if we have bandwidth for this.
  • Roni: Ideally community would take this on, how needed is this today?
  • Christian: We are introducing new features for 1.8 and 1.9 that would benefit from this.
  • James: Lets track it on the high level board and continue discussing what impact it would have on the capacity for the next releases.
Decision
  • Lets track it on the high level board and continue discussing what impact it would have on the capacity for the next releases.