FUTOmeter Idea: Sustainable FOSS Funding Through Usage-Based Nudges

Table of Contents

• The Challenge: FOSS Sustainability
• FUTOmeter: Measure, Manage, Sustain
• How It Works: Local Tracking & Gentle Nudges
  • Example: Android App
• Benefits
• Key Features & Design Goals
• Future Directions & Ambitious Goals
• Frequently Asked Questions (FAQ)

---

Important Disclaimer

⚠️ Please note that FUTOmeter is currently just a personal idea, originating from me (@thiswillbeyourgithub), a user who supports FUTO's mission to improve FOSS sustainability. While this concept has been discussed with @occhiojoe from FUTO, it is NOT an official FUTO project or product, and the name "FUTOmeter" is not an official designation. As of the last update to this document, this remains a personal proposal aimed at sparking discussion.

The author explicitly waives any rights to the "FUTOmeter" name and the core idea presented here in favor of FUTO, should they choose to adopt or develop it. The author's sole request is for appropriate official credit acknowledging the origin of the idea, allowing them to demonstrate their contribution.

---

"What you can measure, you can manage."

— Commonly attributed as the McKinsey Maxim

The Challenge: FOSS Sustainability

Free Open Source Software (FOSS) fuels innovation worldwide, yet sustainable funding remains a persistent challenge. Traditional donation models often rely on broad appeals, which can lead to "donation fatigue" among users who may not frequently use the software. Developers, in turn, lack effective ways to connect contribution requests to actual usage, potentially missing opportunities to engage their most dedicated users.

How can we create a funding model that is both effective for developers and fair to users?

FUTOmeter: Measure, Manage, Sustain

Based on the above quote, FUTOmeter proposes a bottom-up approach. It's envisioned as a collection of minimal, low-overhead libraries for local usage tracking, designed for easy integration into projects across various popular programming languages. They differ from traditional "telemetry" because the measuring is done entirely on-device, instead of from a distance (meaning of the prefix tele-), ensuring user privacy by default.

The core idea is simple: provide simple tooling to enable applications to locally track usage metrics and trigger donation prompts based on developer-defined thresholds, specifically targeting users who derive significant value from the software.

How It Works: Local Tracking & Gentle Nudges

1. Minimal Integration: Developers would include the lightweight FUTOmeter library for their language (designed with zero external dependencies).
2. Define & Count: Developers would use simple hooks provided by the library to "count" specific, meaningful actions within their application (e.g., futometer.increment('tasks_created'), futometer.increment('files_exported'), futometer.increment('images_edited')).
3. Set Thresholds and donation logic: Developers would configure thresholds that represent significant usage (e.g., trigger a prompt after 150 tasks are created), as well as what should happen once the thresholds_met FUTOmeter hook is triggered (e.g. an android notification).
4. Local Evaluation: The FUTOmeter library would track these counts locally on the user's device. Privacy is paramount; no data would be sent anywhere by default. Hence this is not telemetry and no privacy or legal remification ensue.
5. Targeted Notification: When a user's activity crosses a predefined threshold, the library would signal the host application to display a donation request. This request would feel more relevant as it's directly linked to the user's engagement level.

Timing the Notification: Instead of triggering the thresholds_met hook immediately upon reaching the threshold, FUTOmeter could be configured to perform this check periodically (e.g., monthly). If the thresholds are met during that check, the notification is shown. This approach ensures even heavy users only receive prompts periodically (e.g., once a month), potentially showing higher usage numbers in the notification text and further reinforcing the value they derive. But this is not a one size fits all situation (e.g. some software cannot rely on periodic runs).

Example: Android App

Let's consider a heavy user of the TODOlist Android app tasks.org. The developers could integrate FUTOmeter as follows:

1. Embed: Include FUTOmeter's Kotlin library in the app.
2. Count: Configure FUTOmeter to count specific actions:
   • Number of tasks marked as completed directly within the Android app (ignoring tasks completed via CalDAV sync from other clients).
   • Number of times the Android app is opened.
   • These counts would use simple FUTOmeter hooks like futometer.increment('tasks_completed_in_app') and futometer.increment('app_opened').
3. Thresholds and hook: Set thresholds baked into the app, for example: 100 tasks completed and 50 app opens, and wether they all have to be met or just a subset. Also set what should happen once the thresholds_met hook is triggered (say an android notification).
4. Wait for the trigger: Once a user reaches both or any thresholds, FUTOmeter would trigger the hook thresholds_met(tasks_completed=100, app_opens=50).
5. Act when triggered: When triggered, the dev logic would be executed, in our case this would display an Android notification (e.g. "Enjoying Tasks.org? You've completed 138 tasks (X per day) and opened the app 50 times! Consider supporting development by clicking on the donate button below.")

Suggesting Donation Amounts: Furthermore, the tracked metrics could help suggest a relevant donation amount. For instance, tasks.org could establish a baseline value, say $1 per 1000 tasks completed.

• A user completing 15 tasks daily (approx. 5475/year) might see a suggestion reflecting ~$5.40/year.
• A power user completing 100 tasks daily (approx. 36500/year) might see a suggestion reflecting ~$36.50/year. This makes the donation ask more concrete and tied to the value derived, while users with minimal usage (like someone barely using Digikam) wouldn't receive such prompts, ensuring the system remains fair and unobtrusive for casual users.

Benefits

• For Developers:
  • Minimum Investment: Lower overhead compared to building custom tracking/prompting systems.
  • Plausibly Higher Conversion: Requests tied to value derived, potentially with suggested amounts, may be more effective.
• For Users:
  • Informed Giving: Helps users understand which software they rely on most. By making usage value visible, FUTOmeter acts as a gentle "nudge" (as described in Nudge theory), making donation decisions more impactful and personally motivating without restricting choice.
  • Reduced Donation Fatigue: Fewer, more relevant donation requests.
  • Fairness: Prompts are linked to actual usage, not just installation.
  • Try Before You're Asked: Explore software freely without immediate contribution pressure.
• For the FOSS Ecosystem:
  • Sustainable Funding: Creates a potentially more reliable income stream for projects.
  • Value-Based Economy: Aligns funding more closely with software usage and value.
  • Fairer Distribution: Enables highly successful projects to potentially raise their donation thresholds over time, allowing users' attention and funds to flow towards other valuable FOSS components that might be less visible (e.g., libraries vs. user-facing apps). This addresses the challenge that user-facing applications often have more direct ways to prompt users than background services or libraries.

Key Features & Design Goals

• Cross-Language Libraries: One minimal, consistent library per popular language.
• Low Overhead: Designed for negligible performance impact (a more ambitious goal could be to offer both a full-featured version and a "lite" version for extremely low overhead or constrained environments).
• Zero External Dependencies: Ensures easy integration and avoids dependency conflicts.
• Privacy First: All tracking and threshold evaluation would happen locally by default.
• Developer Control: Developers would define what to measure and the thresholds for prompts.
• Inter-Library Communication: FUTOmeter instances would detect if they are running within a project that also uses FUTOmeter and combine the donation campaigns: (e.g., an android application implementing FUTOmeter, that relies on a database implementing FUTOmeter itself). This would allow for coordinated prompts, attributing usage across dependencies and requesting donations for the specific component or the entire stack. This is also fairer to libraries that do not face users so can't even ask for donation: the database FUTOmeter's thresholds_met hook would be redirected to the android app's thresholds_met hook. When the android notification asks for donation, it would mention both the app and the database's statistics.

Future Directions & Ambitious Goals

While local-only operation is the default design, future iterations could explore:

• Opt-in Aggregated Data: Allow users to optionally contribute anonymized usage data (potentially using techniques like k-anonymization and probabilistic reporting, similar to how aider.chat initially used a random number to only send telemetry for 1% of users - see source) to help developers understand feature adoption and usage patterns.
• Trusted Aggregation: This anonymized data could potentially be aggregated by the developer or a trusted third party (like FUTO), further enhancing user privacy.

These features would require careful design to maintain the core principles of user privacy and control.

---

Frequently Asked Questions (FAQ)

(As FUTOmeter is currently an idea, these answers reflect the intended design principles. Please open an issue if you have specific questions or suggestions!)

• Q: Would my usage data be sent anywhere?

  • A: By default, absolutely not. The design specifies that all usage counting and threshold checking would happen locally on your device. FUTOmeter is conceived with privacy as a core principle. Future versions might offer opt-in, anonymized data sharing, but local-only operation would always be the default.

• Q: How would this differ from standard analytics?

  • A: Standard analytics often focus on collecting broad data for product improvement and sending it to a central server. FUTOmeter's primary goal would be local usage tracking specifically to trigger contextual donation prompts for heavy users, without external data transmission by default.

• Q: Could I disable the donation prompts?

  • A: This would likely depend on the specific implementation within the host application. FUTOmeter would provide the mechanism for triggering prompts, but the application developer would decide how (or if) they offer users control over disabling them. For example the dev could want to ask for donation and keep asking once the threshold are met again, or could want to stop asking for donation after the user clicked on a "I donated already" button.

• Q: How often will I see donation prompts if I'm a heavy user? Can I stop them if I donate?

  • A: The frequency depends on the thresholds set by the developer and potentially a cool-down period (e.g., checking thresholds only once a month). FUTOmeter itself wouldn't dictate how an app handles prompts after a donation. A well-implemented app using FUTOmeter should provide a way for users to indicate they've donated (or choose not to donate) to prevent repeated prompts for the same usage level, but this control lies with the application developer integrating the library.

• Q: What kind of actions can be tracked? Could it track sensitive information?

  • A: FUTOmeter is designed to track simple, non-sensitive counts of actions defined by the developer (like 'files_saved', 'tasks_completed', 'app_opened'). It's not intended for tracking content (like the text of a task or the content of a file) or personally identifiable information. The open-source nature allows verification of what the library actually does.

• Q: How much effort is it for a developer to integrate FUTOmeter?

  • A: The goal is minimal integration effort. Developers would primarily need to: 1) Add the library dependency. 2) Call a simple increment('metric_name') function at relevant points in their code. 3) Configure the desired metrics, thresholds, and the logic to execute when a threshold is met (e.g., showing a notification or dialog).

• Q: Will the FUTOmeter libraries themselves be open source?

  • A: Absolutely. For transparency and trust, the intention is for all FUTOmeter libraries to be fully open source under a permissive license (like MIT or Apache 2.0). This allows anyone to inspect the code and verify its behavior, ensuring it adheres to its privacy promises.

---

This README was structured and refined with assistance from aider.chat.