carbon-language/carbon-lang
1
0
Fork 0
mirror of https://github.com/carbon-language/carbon-lang.git synced 2026-09-24 21:10:12 +01:00
Code Issues Packages Projects Releases 10 Wiki Activity

Criteria for Carbon to go public (#63)

Browse Source 
- [Google Doc](https://docs.google.com/document/d/1Uir4sc1HuT5pOzRrFDnbuClzSYBEwE2Unbabr28e8iw/edit)
- [Ideas](https://forums.carbon-lang.dev/t/going-public-doc/139)
- [RFC](https://forums.carbon-lang.dev/t/rfc-criteria-for-carbon-to-go-public/146)
- [Decision announcement](https://forums.carbon-lang.dev/t/accepted-criteria-for-carbon-to-go-public/167)
This commit is contained in:
Bryce Adelstein Lelbach aka wash
2020-11-17 14:13:46 -08:00
committed by GitHub
parent 79a9b51d07
commit b8750e6c4b
3 changed files with 299 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/project/going_public.md
+260
View File
@@ -0,0 +1,260 @@
# Criteria for Carbon to go public
<!--
Part of the Carbon Language project, under the Apache License v2.0 with LLVM
Exceptions. See /LICENSE for license information.
SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-->
<!-- toc -->
## 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)
<!-- tocstop -->
## 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.
proposals/README.md
+1
View File
@@ -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)
proposals/p0063.md
+38
View File
@@ -0,0 +1,38 @@
# Criteria for Carbon to go public
<!--
Part of the Carbon Language project, under the Apache License v2.0 with LLVM
Exceptions. See /LICENSE for license information.
SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-->
[Pull request](https://github.com/carbon-language/carbon-lang/pull/63)
<!-- toc -->
## Table of contents
- [Problem](#problem)
- [Background](#background)
- [Proposal](#proposal)
- [Alternatives considered](#alternatives-considered)
<!-- tocstop -->
## 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.