Direct answers, including the difficult ones.

The products labeled Free are intended to remain usable at no charge. Pro products fund capabilities that require persistent infrastructure. The public catalog distinguishes free, beta, and Pro products so a preview is not mistaken for a complete free service.

Most static tools and simulations do not require one. Accounts are used when identity is necessary, such as publishing, synchronization, ownership, collaboration, marketplace activity, or billing. Requirements vary by store.

No for ordinary use. Products run in a modern browser. Some apps can optionally be installed as PWAs. Contributors working on platform repositories may need Node.js, pnpm or Bun, Git, and Cloudflare tooling.

Some self-contained tools and PWAs do after their assets are cached; others need a network connection for fonts, models, APIs, multiplayer, publishing, or server features. Offline support is a per-product capability, not a universal guarantee.

Current Chromium, Firefox, and Safari are the general target. Advanced WebGPU, built-in AI, audio, file-system, or PWA features may work only in particular browsers. Complex simulations are usually easier to use on a desktop even when layouts support mobile.

Each audience has distinct search intent, product needs, contribution expertise, and deployment requirements. Separation also limits operational coupling. Shared conventions are adopted where they help, but one store does not need to release in lockstep with every other store.

No. Tools and simulations can contain defects, simplify a domain, or become outdated. Verify important results independently. Finance tools are not financial advice; educational science simulations are not laboratory or safety systems; AI output may be wrong.

Start from the result you need, then compare export format, account requirement, browser support, network use, maturity, and whether the work is high stakes. The field guide provides a decision path.

Usually, when its repository is public and the license permits it. Self-hosting can still require build tooling, Cloudflare services, OAuth credentials, databases, or separately licensed assets. The repository documentation is authoritative.

Some platform stores expose SDK and backend APIs, but there is no single stable ecosystem-wide public API. Authentication, quotas, compatibility, and support differ by store. Do not build a critical integration from an undocumented endpoint.

The ecosystem is designed to minimize collection, but the old blanket claim of "zero data collected" is too broad. Static tools commonly keep work in memory or browser storage. Cloudflare may process standard request metadata, and storefronts may use cookieless Cloudflare Web Analytics. Account, publishing, multiplayer, and Pro services necessarily process the data required to provide those features. See the privacy and data page.

For browser-only operations, generally not. It can leave your device when you deliberately use a network feature: an external AI provider, URL lookup, multiplayer room, account sync, publishing flow, file upload, email, or other backend service. Review the individual tool before entering sensitive information.

There is no single provider. Depending on the product, AI may run through browser heuristics, ONNX or Transformers.js models, WebGPU/WASM, supported browser-built-in AI, a user-authorized API key, or Cloudflare Workers AI on a Pro service. Tools should disclose the path they use.

This varies. Some static tools store a key in browser local storage. Platform key-vault features can encrypt stored keys and proxy authorized requests. Do not enter a high-value unrestricted key into a tool you have not reviewed; use provider-side scope and spending limits whenever possible.

Open Frontier does not operate a model-training program based on user content. If you invoke a third-party AI provider, that provider's retention and training terms apply to the request. Consult its policy before sending confidential or regulated data.

Do not assume the public tools are approved for health, financial, legal, government, export-controlled, or other regulated data. There is no ecosystem-wide compliance claim for HIPAA, SOC 2, PCI DSS, GDPR processor obligations, or similar regimes.

Use the controls provided by the specific product or contact its repository owner when no control exists. Retention is not yet standardized across every service. Browser-only data can generally be removed by clearing that site's storage.

Yes. Teachers can link directly to public simulations without provisioning student accounts. Review each simulation for curriculum fit and accuracy before assigning it, and provide alternatives where browser or accessibility requirements create a barrier.

Some stores include institute, challenge, collection, or learning-path material, but there is not yet a universally mapped curriculum with standards alignment, assessment rubrics, and instructor guides. That is a strong contribution opportunity.

They are educational software, not certified research instruments. Some implement established equations or algorithms, but validation depth varies. Domain-expert review, references, test cases, and explanatory assumptions are welcome.

Direct links are the most reliable option. Embedding depends on the target site's security headers and the product's own framing policy. For copying or adapting source, follow the repository license and preserve required notices.

The design standard includes semantic controls, keyboard use, contrast, and responsive behavior, but coverage is uneven, especially in canvas, 3D, audio, and simulation-heavy experiences. Educators should test the exact workflow and provide an alternative when needed.

Free-store projects generally use MIT-licensed source and public GitHub repositories. Do not infer that every Pro repository, third-party asset, model, dataset, font, book, or user contribution has the same license. The license file in the specific repository is authoritative.

Generally yes. Using a hosted tool does not transfer ownership of your original input or output to Open Frontier. You remain responsible for third-party rights, model terms, source-material licenses, trademarks, and the suitability of the result.

MIT-licensed repositories allow commercial modification and redistribution while requiring preservation of the copyright and license notice. Check the exact repository and all bundled dependencies or assets first.

You retain copyright in your contribution and license it under the repository's stated license when you submit it. Do not contribute material you lack the right to license.

Report the exact URL, the protected work or mark, your relationship to it, and contact details to the responsible repository owner. A disputed item may be disabled while provenance, nominative use, and license terms are reviewed.

Bug fixes, accessibility, tests, documentation, translations, performance, domain review, simulations, focused tools, templates, platform infrastructure, security reports, and curriculum material are all useful. See the contribution guide.

No. That pattern applies mainly to static tool and simulation stores. Platform products are normal multi-package codebases with SDKs, Workers, databases, CI, and tests. Choose a scope that matches your experience.

Use the repository for the affected store or product. The ecosystem spans multiple GitHub organizations. Store documentation and repository pages should point to the correct tracker; the umbrella GitHub profile is a fallback for discovery.

Correctness, a narrow and understandable change, accessibility, responsive behavior, privacy implications, dependency and asset licenses, test evidence, and fit with the local repository's conventions. Platform changes also need security, migration, compatibility, and deployment consideration.

Ordinary open-source contributions are currently voluntary. The planned Pro marketplace includes creator economics, but the project is pre-revenue and should not be treated as a current income opportunity. Any paid engagement must be separately agreed in writing.

Yes, but the human submitter remains responsible for understanding, testing, licensing, and reviewing the result. Large unexplained generated changes are less useful than focused changes with clear verification.

Repository-specific conduct files take precedence. At minimum, participation must be evidence-based and respectful, and must exclude harassment, malware, deceptive interfaces, plagiarism, illegal exploitation, and bad-faith disruption.

The intended model is that free products drive access and discovery while Pro products charge for server-backed value. The platform subscription concept is $9 per month with a creator usage pool; ProWebStore uses per-site pricing. This is a plan under validation, not established revenue.

The stated model does not depend on advertising or selling personal data. Hosting telemetry and analytics may still exist for operations and product measurement; that is different from behavioral advertising.

Maturity is uneven. Several core platforms are production-grade or production with caveats; simulations and many static tools are live; AI products are early beta; several Pro products are scaffolded or planned. The stakeholder brief gives a candid summary.

Catalog sprawl, inconsistent claims across stores, uneven test coverage, single-maintainer concentration, limited external contribution, incomplete Pro products, unvalidated conversion assumptions, and the operational burden of many domains and repositories.

Curriculum pilots, domain validation, accessibility audits, open-source mentorship, content distribution, cloud or model credits, public-interest technology programs, and creator onboarding are the most aligned opportunities. See the current asks.

Do not assume one policy applies to every preview. Public paid services should state price, renewal, cancellation effect, refund rules, taxes, included quotas, and overage behavior before purchase. The ecosystem is pre-revenue, so intended pricing is not the same as a current commercial offer.

Not as an ecosystem-wide default today. Any SLA, support commitment, DPA, data residency term, or procurement requirement must be agreed for the specific service in writing.

There is automated compliance and test infrastructure in the mature stores, but no ecosystem-wide claim of independent penetration testing or formal certification. Treat beta products accordingly.

Use the security reporting instructions in the affected repository if present. Avoid publishing exploit details before maintainers have had a reasonable opportunity to respond. If no security contact is visible, contact the repository owner privately through GitHub.

No uptime SLA applies to free public products unless a specific service contract says otherwise. Stores can be changed, consolidated, or retired. Open source reduces lock-in, but hosted availability is best effort.

No. Local storage, IndexedDB, and browser caches can be cleared by the user, browser, device policy, or storage pressure. Export important work and keep an independent backup.

Report the exact item and reason to the responsible store repository. Items involving malware, credential theft, harassment, illegal exploitation, impersonation, or rights violations can be disabled while reviewed. A mature marketplace will need documented appeal and repeat-offender processes.

It is currently founder-led and primarily maintained by Serge, with AI-assisted development and a growing set of repositories. The project does not yet have a formal foundation, elected governance body, or large maintainer council.

Repository maintainers make product-local decisions. Cross-store conventions are documented for areas such as layout, design, analytics, and roles, but internal architectures are intentionally not forced into one shape.

The catalog has grown quickly and some generated documentation lags source repositories. Counts can also differ because one source counts repositories, another lists storefront items, and another excludes previews. Dated status snapshots and explicit maturity labels are being used to reduce that ambiguity.

Near-term priorities are quality and discoverability for existing stores, stronger contribution workflows, external validation, more consistent documentation, completion of selected Pro capabilities, and evidence of real usage before further expansion. The detailed roadmap lives in the documentation.

Retirement should consider active usage, export or migration, source preservation where licensed, public notice where practical, route behavior, and deletion of server-side data. Free hosting is best effort and no product is guaranteed to remain online indefinitely.

Include the exact URL, browser and version, device or operating system, steps to reproduce, expected and actual behavior, console errors if available, and a screenshot that does not expose private data.

Free products are community and best-effort supported. Priority support is an intended Pro capability. Response times depend on maintainer availability and issue severity.

Visit docs.openfrontier.one for architecture, platform capabilities, store notes, maturity assessments, strategy, and roadmap.