Why We Open-Sourced Second Ring—and Kept the Network Permissioned

The code can be copied. The relationships cannot.

I am deliberately giving away more of Second Ring, not less.

A person should be able to inspect an official LinkedIn Connections export or a Google Contacts address-book export, understand what that source proves, and get a useful evidence-labeled direct-contact audit without surrendering the file to BlitzMetrics. If our only advantage were a parser or a prompt, we would not have much of a business. Those are becoming easier to copy every month.

What is difficult to copy is a permissioned network of real people who contribute evidence, review one another’s work, make introductions only when appropriate, publish what they learn, and follow through. That is why the operating model is simple:

Free intelligence. Paid coordination and distribution.

What is the durable advantage in Second Ring?

The free skill helps you see what you already have. The Spotlight community helps you earn and activate the second ring.

This boundary matters. Raw contact data is not our marketing list. We do not need to collect somebody’s address book before proving value. Someone can use the local candidate skill without giving Second Ring an email address. If that person later wants a saved workspace, a permissioned second-ring contribution, or help activating the result through the Spotlight Network, they can choose that next step.

That is not charity and it is not a bait-and-switch. It is an open-core strategy: publish the knowledge and deterministic parts; charge for coordination, persistence, judgment, service, and distribution.

Why publish the skill instead of hiding the method?

Our building-in-public operating principle says we charge for our time, not our knowledge. Our Learn–Do–Teach and Content–Checklist–Software process says a useful experience should become a document, then a repeatable checklist, then software or an agent that other people can run.

Second Ring is that progression happening in public:

1. Content: We documented the original request, the mistakes, the privacy decisions, and the product build in the consent-first Second Ring build log.
2. Checklist: We turned the work into explicit rules for official exports, identity ambiguity, direct versus second-ring edges, consent, revocation, and honest recommendations.
3. Software: We built the hosted Second Ring product with a free scan, goal ranking, owner-controlled workspaces, and a consented contribution flow.
4. Skill: We packaged the deterministic audit as a publicly reviewable skill and parser with tests and synthetic data.
5. Community: We are inviting builders and users to improve the method, contribute permissioned examples, and turn the best findings into introductions, content, partnerships, and measurable outcomes.

The first four layers are increasingly easy to reproduce. The fifth compounds through trust and participation. A copied skill does not give somebody permission to use another person’s contact file. It does not create a warm introduction. It does not make a teammate follow through. It does not publish a useful story across a network of sites.

How is Second Ring practicing what it preaches?

A network-mapping product should itself be built as a network. That means the work cannot live only in my inbox or in one agent’s context window.

The article you are reading is one public receipt. The public skill pull request preserves the proposed code, license boundary, tests, and review discussion. The private application repository preserves the hosted product, database migrations, security controls, and deployment history. The public asset tracker helps people and agents find the canonical artifacts. Our builder–auditor operating model separates creation from independent review.

That is the same behavior Second Ring asks of a relationship:

• Name the claim.
• Show the evidence.
• Keep private context private.
• Ask permission before involving another person.
• Record what happened next.

When the product finds a possible path, it should not merely draw a pretty line. It should explain who the direct contact is, why that person is relevant to the chosen goal, what evidence supports the path, and what the next honest action is. The same standard applies to our team: an idea becomes real only when it has an owner, a reviewed artifact, and a visible result.

Where does each part of the system belong?

I upgraded the way our team uses GitHub so people can contribute through named accounts and reviewable pull requests. GitHub is not the moat; it is the public record that lets a current or future teammate see how work actually moves.

The public GitHub repository is the best place for an agent or builder to inspect the method. The private GitLab repository is the best place for the team to protect the SaaS control plane. This article is the strategic hub that explains why both exist and how they coordinate.

What does an excellent contributor actually do?

Our next constraint is contributor density: we need more people who can consistently take one unit of work from issue, to evidence, to reviewed release, to a live result.

I use the phrase “A-player,” but I do not want it to become a vague personality label or a public ranking of people. In this project, excellent performance is observable:

• Claims one bounded problem and finishes it.
• Separates verified facts, inference, and unknowns.
• Protects private contact data and obtains consent.
• Adds a test, a reproducible receipt, or a source a stranger can check.
• Documents failures instead of hiding them.
• Responds to review and fixes contradictions at their source.
• Leaves the next contributor with clearer documentation than they inherited.
• Connects the shipped work to a user outcome.

That is consistent with our existing public qualification process: show that you can make something, publish it, communicate, and follow through. The repository makes those behaviors visible without requiring a polished resume or a private recommendation.

Who do I want to bring into stewardship?

The first invitation list includes Daniel Goodrich, Cam Hazzard, Dylan Haugen, Ethan Van De Hey, and other builders in our orbit.

Daniel already has public Local Service Spotlight articles and a public measurement-skill repository, which is the kind of visible receipt we want more of. A broader cohort would bring product, athlete, content, onboarding, and field-use perspectives. The exact lanes should be chosen with each person, not invented for them in this article.

Potential teammates can also join from outside the current group. They can read our strategy, inspect the skill, see the review standard, and make one useful contribution before asking for a title. That is more honest than a recruiting page that says we have a great culture but hides how the work happens.

How can somebody earn more ownership?

1. Run it. Use the synthetic example or an export you are authorized to use. File one reproducible, privacy-safe observation.
2. Contribute. Claim one bounded issue and submit the smallest useful documentation, test, or code change.
3. Own a lane. Ship several accepted contributions in one area, close review feedback, and maintain the source documentation.
4. Steward others. Review contributions, run the release checklist, document failures, and help the next person succeed.
5. Maintain the system. Earn broader merge or release rights through repeated, safe stewardship—not through a title alone.

Never attach a real contact export, email list, invitation token, or private graph screenshot to a public issue. A useful bug report can be reproduced with synthetic or redacted data. Privacy is part of the test, not paperwork we add later.

Does giving away the skill ruin the SaaS business?

No. It clarifies what the customer is paying for.

The skill can normalize an authorized export, flag ambiguous identities, rank direct contacts against a chosen goal, and—when separately authorized relationship evidence is supplied—separate supported from contextual two-hop paths. That is useful—and it should be free.

A true second ring requires more: another person must choose to contribute, the product must preserve who asserted each edge, permissions must be enforced, revocation must work, identities must not be carelessly merged, and a human must decide whether an introduction is appropriate. Then somebody has to turn the opportunity into a podcast, partnership, customer conversation, hire, article, entity page, or other useful outcome.

That is where the SaaS and the community create value. The permission-first podcast example shows how to ask one guest whether they are comfortable introducing one specific person. The Marko Sipilä authority inventory shows how public proof can support outreach research; it does not by itself establish a private relationship or an available introduction.

Our value ladder begins with useful ungated knowledge. People who want to do it themselves should be able to. People who want durable infrastructure, collaboration, human help, and distribution can pay for those outcomes. We do not need to trap their contact file to create a business.

What will Second Ring never promise?

• A single LinkedIn export shows direct platform connections. It does not prove closeness or reveal a true second-degree network by itself.
• A public podcast, event, or shared page can show context. It does not prove private friendship or willingness to introduce.
• Membership does not guarantee an introduction, link, ranking, referral, customer, or hire.
• The product will not contact people automatically in the owner’s name.
• A named teammate is not a project owner until that person accepts and does the work.
• The skill will not be described as installed from the main marketplace until the public review is merged and a fresh install is verified.

Those limits make the product more useful, not less. A network graph becomes dangerous when certainty is manufactured. We would rather show “unresolved” than invent a path through the wrong Alex Smith.

What will we measure as the network grows?

We will measure the operating system, not collect people’s relationships as analytics:

• Browser-scan starts and completions; opt-in aggregate completion receipts from local-skill pilots
• Goal-specific recommendations viewed and acted on
• Owner-controlled workspaces created
• Permissioned contributor invitations accepted or revoked
• Useful introductions requested and completed
• Approved Spotlight examples published
• Issue-to-review and review-to-live cycle time
• Free-to-paid conversion today; privacy-reviewed 28-day retained-account cohorts as a follow-on

General product analytics should remain coarse. Contact names, email addresses, filenames, target text, and graph edges do not belong in a marketing dashboard.

What happens next?

1. Human contributors review the public skill pull request.
2. After merge, we run a fresh-install acceptance test and update the public installation guide.
3. The hosted product exposes the local-skill option without weakening the browser scan.
4. We invite the first stewardship cohort to claim narrow issues, not vague departments.
5. Operations gathers consented screenshots, feedback, and outcome receipts from real pilots.
6. We publish approved cases through the Spotlight sites and improve the skill and product from what users actually do.

This page is the canonical strategy hub. The build log owns the technical chronology. The public pull request owns the candidate skill and review receipts. The skill-pack registry owns current distribution. The Spotlight Network registry owns the public network map.

Frequently asked questions

Does the free skill send my LinkedIn export to BlitzMetrics?

The candidate parser makes no network requests and emits no telemetry. By default it prints a bounded, best-effort-redacted report to the invoking workspace; it creates a file only if an output path is requested. An AI product that launches it may receive that bounded report under its own data policy. “Not sent to BlitzMetrics” is not the same as “never handled by another service.”

Does Second Ring scrape LinkedIn or Facebook?

No. The current workflow uses official exports supplied by the account owner and separately consented relationship evidence. We do not ask for a social password.

Can one export reveal my real second ring?

No. One LinkedIn Connections export establishes only the platform’s direct-connection records. A Google Contacts export is an address-book signal. Neither proves closeness or a true second ring. A supported two-hop path requires another authorized source, a consenting contributor, or attributable public evidence with an honest label.

Does open source replace the hosted product?

No. The free skill is a private self-audit. The hosted product adds persistence, permissions, consented collaboration, revocation, history, and goal workflows. Spotlight services can add human coordination and editorial distribution, subject to program scope.

Can contributors see my contact data?

Not through the public repository. Private product data is owner-scoped, and a contributor sees and submits only through the consented invitation flow. Public examples must use approved, attributable, or synthetic evidence.

How can I contribute?

Review the public pull request, run the synthetic example, report one reproducible issue without private data, and propose a bounded fix. Make the next reviewer’s job easy by including evidence and a test.

Change note: This is a living strategy page. When the skill merges, plan boundaries change, or a named contributor accepts a stewardship lane, we will update the relevant source of truth and then update this page.