Group Progress

Last week our team made solid strides on our Transformer‑based contributions:

• Apr 16: Submitted PR #37596, which adds comprehensive tests for the new Tensor Parallel integration.
• Apr 20: Merged PR #37635 to introduce “resume checkpoint” support in the ClearML callback, complete with a dedicated test file.
• Apr 20: Responded to Issue #37627 by providing a base code template for fine‑tuning the SigLIP2 model, helping the issue opener get started quickly.

• Now: Submitted PR #36310 — Add time‑based evaluation strategy to Trainer.
  • What it does: Introduces time‑based evaluation, saving, and logging to the Hugging Face Trainer, so you can configure intervals in minutes rather than steps.
  • Why it matters:
    • Ensures consistent evaluation/logging across hardware of varying speeds (CPU vs. GPU).
    • Guards against lost progress by saving checkpoints at fixed time intervals.
    • Allows real‑time monitoring of training progress.
  • Sample configuration:

    training_args = TrainingArguments(
        output_dir="./test_output",
        eval_strategy=IntervalStrategy.TIME,      # Evaluate every N minutes
        eval_minutes=1,
    
        save_strategy=IntervalStrategy.TIME,      # Save every N minutes
        save_minutes=1,
    
        logging_strategy=IntervalStrategy.TIME,   # Log every N minutes
        logging_minutes=1,
    
        per_device_train_batch_size=8,
        num_train_epochs=200,
    )
    

  • Status: Fixes #36310. Waiting for reviewer feedback.

Video Insights: “Open Core” in Business

In our industry video, Joseph Jacks, Scott McCarty, Ray Pick, and others dove deep into the concept of Open Core:

• Open Core vs. Closed Core
  • Open Core companies publish a fully functional, open‑source core—often 99% of end‑user value—and monetize add‑ons, cloud services, or premium features.
  • Closed Core companies keep their core technology proprietary and exclusively monetize access to that core.

• Not a Single Business Model
  Open Core isn’t tied to one way of making money. Companies may simultaneously sell support, managed services, t‑shirts, or proprietary extensions around the open core project.

• Community Contributions & Trust
  Transparent contribution guidelines, open roadmaps, and clear stewardship policies (e.g., GitLab’s “feature proposal evaluation” checklist) build trust and encourage both vendor and individual contributions.

• Historical Baggage
  Early Open Core players sometimes shipped “crippleware” community editions, creating controversy around whether the free core was “seriously usable.” Today’s leaders like HashiCorp, Confluent, and Databricks have shown that a healthy Open Core can drive massive adoption without compromising quality.

• Terminology Matters
  While some view “Open Core” as pejorative, the panel concluded that distinguishing Open Core (company type) from Open Source (technology license) and Closed Core (proprietary) helps clarify strategy and internal culture.

In‑Class Discussion

Building on the video, our class explored why organizations choose Open Core:

1. User Hook & Upsell
   Offer a generous free tier to onboard users, then convert power users with premium features (e.g., advanced clustering in Redis Enterprise).

2. Ecosystem Lock‑In vs. True Openness
   Proprietary extensions can create deeper lock‑in, but a fully open core—with multiple vendors competing to provide services—delivers stronger freedom and flexibility for customers.

3. Cultural Alignment
   Open Core companies often embrace open decision‑making practices, publish design docs, and invite community input into their roadmaps—aligning internal culture with the ethos of their codebase.

4. Label Sensitivity
   For some, the term “Open Core” conjures negative memories of under‑featured community editions. We debated whether a fresh label (e.g., “Commercial Open Source”) might avoid that baggage—but agreed clear definitions and transparent policies matter more than the buzzword itself.