going_public.md 12 KB
Criteria for Carbon to go public
Table of contents
Overview
Open, transparent, and public development is often the best way to build a developer community. Long-term evolution of Carbon behind closed doors does not align with our core principles.
However, there are risks associated with going public too soon. We only get one chance to make a first impression. At the end of the day, Carbon's success does not rely solely on technical merit. Messaging, marketing, and branding are also vital to Carbon's success. Carbon must not only be a technically excellent language, we must also tell the right narrative about Carbon.
Additionally, there are costs associated with going public. Greater participation brings greater administrative and logistical overheads.
Carbon can be expected to go public when most or all criteria are satisfied:
- A critical mass of Carbon evolutionary decisions need broader field experience to determine the right choice.
- Sustained interest to use Carbon from multiple organizations and individuals.
- Carbon has a prototype implementation.
- Carbon's potential can be demonstrated.
- Learning material is available for Carbon.
- Community members are prepared to handle a large influx of new contributions and feedback.
- The community is ready to run a launch event.
These criteria are guidelines. Any proposal to go public with Carbon, including whether criteria are sufficiently met, will be reviewed as with other evolution proposals.
Criteria
Broader field experience required
We expect many of Carbon's evolution decisions to be based on our experiences with and knowledge of other programming languages, particularly C++. As Carbon matures, we expect some decisions will be made where we are making a temporary choice pending broader field experience. For example, we may need to see how Carbon is used in order to understand the best approach for a feature.
Field experience is a combination of:
- Implementation Experience: The experience and feedback gained by implementing a design, process, or idea. We should be able to obtain much of the implementation experience we need without going public.
- Usage Experience: The experience and feedback gained by using an
implementation of a design, process, or idea.
- We will be able to obtain some usage experience without going public, but the diversity of that experience may be limited. Our usage experience will also be biased by our involvement in the design and implementation of Carbon. We will be more likely to use things in the way that the designers and implementers intended.
- To ensure our designs are robust, we need to experience the Hyrum's Law effects that come from broad and surprising usage of Carbon. This can only truly be achieved through a public developer community.
- Deployment Experience: Deployment experience is usage experience over time, as the underlying designs and implementations change and tooling-assisted migration is utilized. Because time is required, the earlier we expand our usage experience, the quicker we will be able to expand our deployment experience.
At first, few aspects of Carbon's evolution will be blocked on usage and deployment experience. As Carbon ages and we obtain implementation experience, we will start to find that we cannot make progress or build confidence in certain things without wider usage and deployment experience.
As Carbon evolves, we should consider and document where we would benefit from or be blocked on field experience that requires going public. We should record these needs in terms of concrete open questions that need to be addressed by field experience. We should regularly review this set of open questions. At some point, the value of addressing this set of open questions by way of public field experience will become significant enough to warrant the costs associated with going public.
Sustained interest to use Carbon from multiple organizations and individuals
We should ensure there is sustained interest to continue with Carbon, even if circumstances later shift. This interest should come from multiple organizations and individuals. It is important that Carbon be a collaboration in order to ensure its longevity and broad applicability. Even if most of Carbon's early contributions come from one organization, it remains crucial that others have sufficient interest to contribute to its ecosystem.
Prototype implementation
Carbon must have a prototype implementation to go public. We will be unable to build excitement and a user base without a prototype implementation, and we will be unable to get the valuable field experience that justifies the administrative and logistical costs of going public.
We need to develop a set of requirements and schedule for a minimal viable public release of the language and implementation. Determining that set of requirements is outside of the scope of this document.
Demonstration of potential
Carbon should only go public if it's showing promise towards delivering on its goals. That means that we need to have a set of demonstrations of Carbon's potential.
This will likely include both "micro" demonstrations (specific examples that highlight particular capabilities) and "macro" demonstrations of applications and libraries implemented in Carbon.
Learning material
Learning material is critical for making it easy for newcomers to understand Carbon, how it is differentiated from other programming languages, and our plans for the future. For example:
- Documentation, including a specification.
- User guides, including an introduction targeting new engineers.
- Example code.
- Blog posts.
Prepare for new contributions and feedback
When we launch, we should expect to receive many new contributions, comments, and bug reports. To successfully build a developer community, we need to have mechanisms in place to receive all that input and be responsive to it.
Prior to the launch, we should review all of our processes and systems and ensure they are ready and suitable for a large influx of new contributors. We should also ensure that members of the Carbon community are prepared to commit time to assist new contributors in the days and weeks after the launch.
Launch event
We should have a compelling launch event plan when we go public. For example:
- A website.
- Technical talks from multiple speakers and organizations. This could be at a conference or in our own remote or physical event.
- A game plan for social media and tech press.
Risks
We recognize a few unfortunate realities about how Carbon may be perceived when it goes public. These present a risk to Carbon.
If Carbon goes public too soon or without the right narrative, Carbon, Carbon's goals, and Carbon's principles may become misperceived. Such misperceptions could undermine the success of Carbon, regardless of technical merit. During our launch, we must work hard to address and minimize these risks.
Relationship to C++
It's important for the Carbon and C++ communities to work together effectively, given that Carbon is trying to provide a path forward for some (although not all) users of C++.
We must take steps during the development of Carbon to ensure that multiple organizations are involved. We will ensure that launch announcements clearly acknowledge and thank the individuals and organizations which have been involved during its private development.
Perception of ownership by a single organization
Carbon may be perceived as being owned and pushed by a single organization. We must take steps during the development of Carbon to ensure that multiple organizations are involved. We will ensure that launch announcements clearly acknowledge and thank the individuals and organizations which have been involved during its private development.
Over-promising
While Carbon is private, it's easy to have discussions with everyone involved to explain its experimental nature, and avoid having anybody become overly reliant while the future is still in doubt. Once Carbon goes public, it's likely that regardless of what we say, some developers will expect that the experiment won't be abandoned.
It's important that the launch plans and communications clearly and accurately communicate the experimental nature of Carbon, and discourage viewing it as a "ready-to-go" system. There are things we might do later, such as training classes, which may mislead developers at an early stage and thus should be approached with caution. The degree to which we encourage developers to use Carbon should be commensurate with risks of Carbon being abandoned.
Leak contingencies
Community members should strive to control the timeline and narrative for launching Carbon. Having the decision of going public forced upon us by leaks would be unfortunate. We should err on the side of not letting leaks influence our launch.
Over time, some leaks are going to be inevitable. The closer that Carbon gets to a planned launch and the larger the community is Carbon, the greater the risk of leaking. It is important for us to distinguish between minor leaks which do not warrant a response, and major leaks which do.
Minor leaks
A minor leak is an unintentional disclosure of Carbon which does not have the potential for exponential growth in the number of people aware of Carbon. In a minor leak, most or all parties are friendly to us and are unlikely to intentionally spread information about Carbon against our wishes.
For example:
- Accidentally mentioning Carbon to someone you believed was already aware of it.
- Accidentally mentioning Carbon in an email to a C++ committee list.
- Accidentally mentioning Carbon on social media and then deleting the mention shortly thereafter.
Minor leaks should be avoided, but will generally be ignored.
Major leaks
A major leak is a disclosure of Carbon which has the potential to exponentially grow the number of people aware of Carbon. Major leaks will typically involve either substantial social media or tech press exposure outside of our control. For example, if a tech press site publishes an article about Carbon.
In the event of a major leak, the core team will critically evaluate possible next steps:
- If the Carbon experiment isn't showing enough promise to continue, a major leak may lead to development stopping.
- Give permission to a member of the Carbon community to comment in order to defuse the situation.
- Take Carbon public prematurely.
This will be based on considerations such as diminished value of remaining private, as well as the value of adding more information to a dialogue that may help preserve Carbon's reputation.