diff --git a/docs/project/going_public.md b/docs/project/going_public.md new file mode 100644 index 000000000000..c537ef9d5517 --- /dev/null +++ b/docs/project/going_public.md @@ -0,0 +1,260 @@ +# Criteria for Carbon to go public + + + + + +## Table of contents + +- [Overview](#overview) +- [Criteria](#criteria) + - [Broader field experience required](#broader-field-experience-required) + - [Sustained interest to use Carbon from multiple organizations and individuals](#sustained-interest-to-use-carbon-from-multiple-organizations-and-individuals) + - [Prototype implementation](#prototype-implementation) + - [Demonstration of potential](#demonstration-of-potential) + - [Learning material](#learning-material) + - [Prepare for new contributions and feedback](#prepare-for-new-contributions-and-feedback) + - [Launch event](#launch-event) +- [Risks](#risks) + - [Relationship to C++](#relationship-to-c) + - [Perception of ownership by a single organization](#perception-of-ownership-by-a-single-organization) + - [Over-promising](#over-promising) +- [Leak contingencies](#leak-contingencies) + - [Minor leaks](#minor-leaks) + - [Major leaks](#major-leaks) + + + +## 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. diff --git a/proposals/README.md b/proposals/README.md index d6796f4547ee..7af71c72fa7f 100644 --- a/proposals/README.md +++ b/proposals/README.md @@ -31,6 +31,7 @@ request: - [Decision](p0044_decision.md) - [0051 - Goals](p0051.md) - [Decision](p0051_decision.md) +- [0063 - Criteria for Carbon to go public](p0063.md) - [0074 - Change comment/decision timelines in proposal process](p0074.md) - [Decision](p0074_decision.md) - [0083 - In-progress design overview](p0083.md) diff --git a/proposals/p0063.md b/proposals/p0063.md new file mode 100644 index 000000000000..e7e456bf8cb1 --- /dev/null +++ b/proposals/p0063.md @@ -0,0 +1,38 @@ +# Criteria for Carbon to go public + + + +[Pull request](https://github.com/carbon-language/carbon-lang/pull/63) + + + +## Table of contents + +- [Problem](#problem) +- [Background](#background) +- [Proposal](#proposal) +- [Alternatives considered](#alternatives-considered) + + + +## Problem + +Carbon is currently private, and should have a clear plan for going public. + +## Background + +Some of this is explained to people when they're asked if they'd like to +contribute to Carbon; the purpose of this proposal is to provide documentation. + +## Proposal + +See /docs/project/going_public.md. + +## Alternatives considered + +We have also considered going public immediately. We believe the noted criteria +are important to address before proceeding.