Partially Open Source Model

Overview

MicroBuilder uses a partially open source architecture that balances community extensibility with enterprise-grade reliability.

What's Open vs Closed

✅ Open Source: Community Integrations

The following components are open source and community-extensible:

Integration modules (Slack, GitHub, Stripe, Notion, etc.)
Module specifications and schemas
Example implementations
Testing frameworks for modules
Documentation for module development

Repository: microbuilder-integrations

🔒 Closed Source: Core Engine

The following components remain proprietary:

Deterministic build engine
Capability Matrix routing logic
AI planning and orchestration
Core platform infrastructure
Subscription and billing logic

Repository: Private (this repository)

Why This Model?

Benefits of Partial Open Source

Community Innovation
- Anyone can contribute new integrations
- Rapid expansion of supported services
- Community-driven feature development
Enterprise Reliability
- Core engine remains stable and tested
- No breaking changes from community PRs
- Deterministic builds guaranteed
Security & Trust
- All modules are cryptographically signed
- Maintainers review and verify code
- No arbitrary code execution in builds
Sustainable Business Model
- Core platform monetization preserved
- Community contributions enhance value
- Win-win for users and business

How It Works

1. Community Contribution Flow

┌─────────────────┐
│ Developer       │
│ Creates Module  │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ Submit PR to    │
│ Public Repo     │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ CI Verifies:    │
│ • Tests pass    │ ← Test verification happens HERE
│ • No forbidden  │
│ • Valid schemas │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ Maintainer      │
│ Reviews & Signs │ ← Only signs if tests passed
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ Promote to      │
│ verified-release│
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ Available in    │
│ Production      │
└─────────────────┘

2. Build-Time Module Resolution

When building an app, the deterministic engine:

Resolves required modules from build specification
ONLY loads modules from the verified registry
Validates cryptographic signatures (proves tests passed)
Checks integrity hashes (SHA-256) against actual artifacts
Scans for forbidden APIs in the code
Executes module code in isolated sandbox

Key Principle: Unverified modules are rejected at build time.

3. Verification System

Every verified module undergoes:

At Signing Time (Maintainers):

✅ CI tests must pass (unit tests, integration tests)
✅ Code review by maintainers
✅ Security audit
✅ Cryptographic signing with private key

At Build Time (Automatic):

✅ Signature verification: Proves maintainer approved it (and tests passed)
✅ Integrity verification: SHA-256 hash of actual artifact matches
✅ Forbidden API check: No file system, child processes, etc.
✅ Schema validation: Input/output types defined

For Contributors

How to Submit a Module

Fork the public integrations repo
Create your module under /examples/<your-module>/
Follow the Module Specification
Test thoroughly with >80% coverage
Submit a pull request
Wait for maintainer review and signing

Requirements

✅ Deterministic behavior (same input → same output)
✅ No forbidden APIs (fs, child_process, net, etc.)
✅ Full TypeScript type safety
✅ Comprehensive tests (>80% coverage)
✅ OSI-approved license (MIT, Apache-2.0, etc.)
✅ Clear documentation

What Happens After Approval

CI runs all tests and verifies no forbidden APIs
Maintainers review code for security issues
If approved, maintainers sign module with private key
Module is promoted to verified-release branch
Core platform syncs signed modules
Your module becomes available in production builds
You're credited in the module registry

For Platform Users

Trust & Security

When you use MicroBuilder:

✅ Only verified modules are used in your builds
✅ Cryptographically signed by maintainers (proves tests passed)
✅ Integrity-checked before execution (actual code verified)
✅ Forbidden API detection prevents malicious code
✅ Sandboxed execution isolates module code
✅ Provenance tracking - every build records module versions and hashes

Module Transparency

View all verified modules:

In the admin registry (logged in)
In the public repo

Each module displays:

Name and version
License (all OSI-approved)
Signature hash
Signed date
Source code (public repo)

For Maintainers

Signing Workflow

Review submitted module PR
Verify CI checks passed (especially tests)
Audit code for security issues
Run signing workflow with private key (only if tests passed)
Promote to verified-release branch

CRITICAL: Never sign modules that haven't passed CI tests. The signature is proof that tests passed.

Security Responsibilities

As maintainers, we commit to:

🔐 Secure private key management
🔍 Thorough code review before signing
🧪 Verification of all test results before signing
🚫 Rejection of malicious or low-quality code
📝 Transparency in rejection reasons

Technical Architecture

Cryptographic Signing

// Maintainer private key (secret) - only sign if tests passed
const signature = RSA_SHA256_sign(module, PRIVATE_KEY);

// Public verification (anyone can verify)
const valid = RSA_SHA256_verify(module, signature, PUBLIC_KEY);

Two-Phase Verification

Phase 1: Signing Time (Maintainers Only)

CI tests must pass
Code review approval
Security audit
Cryptographic signing

Phase 2: Build Time (Automatic)

Signature verification (proves Phase 1 happened)
Integrity verification (artifact not tampered)
Forbidden API detection
Schema validation

Module Registry Structure

registry-verified/
  slack.post_message@1.0.0.json
  github.create_issue@2.1.0.json
  stripe.create_payment@1.5.0.json
  ...

Each file contains:

{
  "name": "slack.post_message",
  "version": "1.0.0",
  "inputs": { ... },
  "outputs": { ... },
  "entry": "dist/index.js",
  "integrity": "sha256-...",
  "license": "MIT",
  "signature": "...",
  "signedAt": "2025-01-01T00:00:00Z"
}

Build Provenance

Every build records:

{
  "buildId": "build_123",
  "modules": [
    {
      "name": "slack.post_message",
      "version": "1.0.0",
      "integrity": "sha256-...",
      "signature": "...",
      "verified": true
    }
  ]
}

Governance

Decision Making

Module acceptance: Maintainer review required + CI tests must pass
Breaking changes: Semver versioning enforced
Security issues: Immediate module revocation possible
Community feedback: GitHub discussions and issues

Roadmap

Future plans:

Community voting on module priorities
Automated signing for trusted contributors (after N successful PRs)
Module analytics dashboard
Community module marketplace

FAQ

Q: Can I use unverified modules?

A: No. The deterministic builder only accepts cryptographically signed modules from the verified registry. This ensures build reliability and security.

Q: How are tests verified?

A: Tests run in CI on the public repo. Maintainers only sign modules that pass all tests. The signature itself is proof that tests passed.

Q: How long does module approval take?

A: Typically 3-7 days, depending on code quality and security review complexity.

Q: Can I fork and self-sign modules?

A: You can fork the public repo and modify modules, but only official maintainer signatures are accepted by the production platform. For custom modules, contact us about enterprise licensing.

Q: What if a module has a vulnerability?

A: We immediately revoke the signature and notify all users. A fixed version is fast-tracked for signing after tests pass.

Q: Is the module source code auditable?

A: Yes! All module source code is in the public repository. You can audit it before using it in your builds.

Resources

Verified at the core. Open at the edges.