Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Stateful Functions (StateFun) is a sub-project of Apache Flink that provides an API for building distributed stateful applications on top of Flink's runtime. It was introduced as part of the Flink ecosystem to support event-driven applications with a function-as-a-service style programming model, using remote function invocation over HTTP/gRPC.

The StateFun sub-project has been effectively unmaintained for an extended period. Since the last release (3.3.0 in September 2023):

• Zero commits have been made to the flink-statefun repository
• No new releases have been published, leaving the project 5+ Flink versions behind (built on Flink 1.16, while Flink has progressed to 1.20 and 2.x)
• Open pull requests remain unreviewed
• No sustained contributor activity has materialized despite repeated calls for maintainers

This situation has been discussed on the dev@ mailing list since April 2023. At that time, multiple options were proposed:

1. Finding Flink committers with bandwidth to maintain StateFun
2. Accepting community PRs with lighter review standards
3. Calling for new contributors via blog posts and social media
4. Spinning StateFun off as a separate top-level project (similar to Flink Table Store becoming Apache Paimon)
5. Sunsetting StateFun

Despite these discussions and interest expressed by a small number of users, none of the first four options produced sustained results. The original dedicated contributors (notably from Ververica) have moved on to other projects, and no current Flink committer or PMC member has the bandwidth or domain expertise to maintain StateFun's codebase.

Leaving StateFun in its current state is worse than a clean sunset:

• Users discover an unmaintained project with no clear signal that it is unsupported, wasting their time evaluating or adopting it
• Open PRs and issues create false hope that contributions will be reviewed
• Security vulnerabilities in StateFun's dependency tree (pinned to Flink 1.16 and its transitive dependencies) go unpatched
• Project reputation suffers when part of the codebase is visibly abandoned

This FLIP proposes to formally sunset the StateFun sub-project by archiving its repositories, updating documentation, and clearly communicating to users that StateFun is no longer maintained.

Public Interfaces

StateFun is a separate sub-project with its own set of public interfaces, none of which are part of the core Flink APIs. Sunsetting StateFun removes the following:

• StateFun Java SDK (org.apache.flink.statefun.sdk.java)
• StateFun Python SDK
• StateFun Go SDK
• StateFun JavaScript SDK
• StateFun runtime (a Flink application that dispatches function invocations)
• StateFun documentation hosted under nightlies.apache.org/flink/flink-statefun-docs-master/

No core Flink APIs, connectors, or runtime components are affected. StateFun has no integration points with Flink's SQL/Table API, DataStream API, or any other Flink sub-system that would require changes in the main Flink repository.

Proposed Changes

1. Archive GitHub Repositories

Mark the following repositories as archived (read-only) on GitHub:

• apache/flink-statefun: Main StateFun repository
• apache/flink-statefun-playground: Example applications

Archiving preserves all code, issues, and PRs in read-only form. Users can still fork the repositories.

2. Close Open Pull Requests and Issues

Before archiving, close all open pull requests and issues with a comment explaining the sunset decision, linking to this FLIP and the mailing list discussion. A template comment:

This issue/PR is being closed as part of [FLIP-569], which sunsets the StateFun sub-project. The repository will be archived as read-only. If you rely on StateFun, you are free to fork the repository under the Apache 2.0 license. See the mailing list discussion for context.

3. Update Documentation

• Add a prominent deprecation banner to the StateFun documentation pages stating that StateFun is no longer maintained and that no further releases will be made
• Update the main Flink website (flink.apache.org) to remove StateFun from the project's active sub-projects listing
• Keep existing documentation available in read-only form for reference by current users

4. Update the Flink Website

• Remove StateFun from the downloads page
• Remove StateFun from the main navigation or ecosystem pages
• Add a note on the blog or news section announcing the sunset, linking to this FLIP

5. Publish Maven Artifacts Notice

The existing StateFun Maven artifacts (org.apache.flink.statefun:*) will remain available in Maven Central as-is (Maven Central artifacts are immutable and cannot be removed). No action is required, but the POM metadata and documentation should make clear that these artifacts are no longer maintained.

6. Mailing Lists

StateFun discussions have historically used the main dev@flink.apache.org and user@flink.apache.org mailing lists. No separate mailing lists need to be decommissioned.

Compatibility, Deprecation, and Migration Plan

Impact on Existing Users

Users currently running StateFun 3.3.0 on Flink 1.16 can continue to do so. Archiving the repository does not affect deployed applications or published artifacts. However, users should be aware that:

• No security patches or bug fixes will be provided
• No compatibility updates for newer Flink versions will be released
• Flink 1.16 itself has reached end of life

Migration Options

There is no direct migration path from StateFun to another Apache Flink API, as StateFun's programming model (remote stateful functions) is fundamentally different from Flink's core APIs (DataStream, SQL/Table API). Users have the following options:

1. Continue using StateFun 3.3.0 on Flink 1.16 for as long as it meets their needs, accepting the risks of running on unmaintained software
2. Fork the repository under the Apache 2.0 license and maintain their own version. The ASF licensing permits this, though forks must make clear they are not part of the Apache Flink project (per ASF trademark policy)
3. Evaluate alternative frameworks that provide similar function-as-a-service or actor-model abstractions

Test Plan

No testing is required for this change, as it involves only repository management, documentation updates, and communication, not code changes to the Flink runtime or APIs.

Rejected Alternatives

Alternative 1: Continue Seeking New Maintainers

This approach has been tried since April 2023. Despite discussions on the mailing list and expressions of interest from a small number of users, no sustained contributor activity materialized. The original StateFun maintainers (primarily from Ververica) have moved on. After nearly three years without meaningful progress, continuing to wait is not a viable strategy.

Alternative 2: Spin Off StateFun as a Separate Apache Top-Level Project

This was raised in the original discussion thread as an option similar to Flink Table Store becoming Apache Paimon. However, becoming a TLP requires a healthy, self-sustaining community with active committers and PMC members, which is exactly what StateFun lacks. A project without active maintainers would not pass the Apache Incubator's requirements for a new TLP.

Alternative 3: Reduce Maintenance to Flink Version Bumps Only

One could argue for a minimal maintenance mode where the only changes are Flink version compatibility updates. However, even this requires someone with StateFun domain knowledge to validate that the runtime still functions correctly after a Flink upgrade. The last attempt to do this (upgrading to Flink 1.16 in 2023) required non-trivial work and a PR that was never merged. Without dedicated maintainers, even minimal maintenance is not sustainable.

Alternative 4: Move StateFun to the Apache Attic

The Apache Attic is designed for retiring entire top-level projects that have their own PMC. Since StateFun is a sub-project under the Flink PMC (not a separate TLP), the Attic process does not apply. The Flink PMC has authority over its own sub-projects and can sunset them through its standard governance processes (this FLIP and the associated vote).

Alternative 5: Leave StateFun As-Is Without Formal Action

This is the status quo and the worst option. It leaves users with an unmaintained project that appears to still be active, wastes the time of potential adopters, and leaves open issues and PRs in limbo. A clean sunset with clear communication is preferable to indefinite neglect.