Open Sourcing Projects

What is the Open Sourcing Checklist?

It’s a an outline (not definitive) list of things to consider if you are looking to open source an existing software projects. You might want to use the list to put together some metrics to measure progress of the project.

Why use it?

Because it’s a good place to start

Suggested Time

Ongoing.

The Checklist

Phase One: Discovery

Meet with initial key stakeholders from BU and engineering to determine what success looks like for the community post-launch, vet with other stakeholders including executive team
Ensure plan for project success supports success of subscription/product offering
Ensure that the project is viable as an open source project from community perspective if a community project. or
Ensure the project will be carried by Red Hat if the projects sole goal is around Red Hat objectives (For example RDO to create OpenStack brand association with Red Hat)
Iterate through 2-3 phases of defining success to ensure buy-in and robust understanding of problem space
Understand any project specific needs for community launch, which might include:
Open sourcing of code base
Source code licensing
Project naming - legal, Brand and Marketing constraints
Product/project positioning
Content architecture - SRT, InfoSec, IT, design needs
Community governance model
Understanding target audience
Decisions on interaction model (mailing lists, forums, bug trackers, etc)
Decisions on how to enable people to move from user to contributor
Determine key stakeholders from each group at Red Hat
Individuals/teams who will need to provide approval on aspects of the launch (e.g. Legal must bless our terms of service)
Individuals/teams who will contribute to launch in an interlock fashion (e.g. Bob Engineer and Jane Developer will create packages and repos for source code distribution)
Time line issues
What are the driving factors for success for the launch (will the launch happen at an event?)
How long will it take to name a project?
How long do we spend building trust to join a new community?

Phase Two: Pre-Creation of Execution Plan

Articulate an open source strategy for the project, which should cover:
Rationale: Why are we open sourcing the project? What is the goal? A few possible goals might be: More users; Grow the vendor ecosystem; More developers; Increased awareness for product; Seed market segment; Undermine proprietary competing products; Promote our product portfolio.
Target audience: Who will use the software? What problem of theirs does the software solve?
Key stakeholders: The people (identified in the previous step) who must sign off on the strategy
Define approach to project execution. This is a consequence of the goals and the target audience. If the priority is a vendor ecosystem engaging with a platform, then developing the platform, and providing infrastructure for partner onboarding are the top priorities for the community.
Schedule a call with all key stakeholders as determined during discovery phase to:
Articulate project goals
Define pre-launch objectives (dates, deliverables) and post-launch objectives (community growth, downloads, etc)
- Articulate launch goals
- Walk through the definition of success for project
Revise definition of success as needed based on input from stakeholders
Determine points of contact to help with the launch process
Determine any additional outstanding Known Issues that might impact progression towards launch
Invite stakeholders to participate in project discussions via:
Weekly scheduled status update call
Determine attendee list for call
Project mailing list
Subscribing to launch Docspace/Mojo page
Watching Gitlab project space to comment on/close/monitor progress on issues

Phase Three: Create Execution Plan

Create communication resources (Docspace, mailing list, weekly status update calls and IRC channel if private communications are needed, otherwise use #osas)
Add appropriate points of contact to mailing list and Docspace
Create FAQ for launch and use this to determine what is known, what open questions remain and help to tease out any “gotchas” for launch
Create launch plan, including deliverables and complete by dates and publish in Docspace
Review launch plan during first weekly status update call and iterate on plan with key stakeholders
Once plan is finalized with key stakeholders, resource deliverables and begin executing to plan
Identify the support that is needed from others

Launch plans should include:

Tie-in to engineering time line so bits are available when we are ready to launch the community site
Items needing legal review and timeline for them
Documents: Terms of Service, Privacy Policy, etc.
Export control or other compliance checks for code base
Open questions about which technical tools to use for community site, depending on need, e.g. which forum software is best, with plan to make determination early
Documentation needs and plan for getting these documents created
Location for source code repositiories and buy-in from key stakeholders about the source code repository location and process for publishing the source code
Public Relations and Marketing Plan
Press and analyst briefings as needed
Editorial calendar for at least the first month post-launch for blog posts, Tweets and other social media
Calendar of target speaking engagements on this community, including proposed speakers for each event
Assist engineering with creating abstracts and submitting to CFPs as needed after getting buy-in from eng managers to send employees to speak on community topic(s)
Event plan for launch if launching at a conference or tradeshow
Order branded items, such as stickers, to give away at events or at employee talks about this new community

Phase Four: Execute to Plan

Track deliverables and bugs in Gitlab
Weekly status calls will include review of P0 and P1 deliverables/bugs, P2 if time
Ask for help on osas-staff@ for deliverables that need an owner or additional staff resources
Use at least one company wide call per month to provide general updates to the any interested parties on launch progress

Phase Five: Post-launch maintenance

Measure results from project against objectives - create and maintain a dashboard
Staffing plan and budget allocation for post-release maintenance - identify resources and needs (needs to happen before launch)

Best practices

Make the project launch specific mailing list useful, on topic and not less prone to causing information overload
In an ideal world, all discussions should take place or be reflected (summarized, with a link if applicable) on the project mailing list
If a thread starts as private mail and it looks like all material is public, move to project mailing list by adding to cc
If thread starts as private mail and it looks like material is sensitive, offer to post a summary to the project mailing list by a certain time, ask folks on thread to review summary if they wish to do so
If folks are not reading the mailing list and you need a response, send a link to the relevant thread in the list archive and ask for a response, escalate as needed (e.g. follow up with a phone call if no response to email)
If a discussion centers on user experience design, mailing list is not always the best tool for discussion. Make sure to post a summary of call, etc. in Gitlab issue or on list, as appropriate
Make best possible use of weekly launch status calls
Publish agenda prior to call and notes after call conclusion on project mailing list
As needed, create note taker rotation plan during first launch call so no one person is tasked with always keeping notes and call chair can concentrate on discussion
Review discussion points for all stakeholders during first half of call
Review P0, P1 and, if time, P2 issues in Gitlab during second half of call
Invite all call participants to stay for the second half of the meeting, but if they would prefer to drop they are welcome to do so, point to resources where they can follow up if they have questions on a specific deliverable
Keep resources up to date so folks can easily plug in when asked to help
Appoint air flight traffic controller from OSAS and from the BU to ensure launch plan Docspace is kept up to date with the latest details, including task owners, deliverable due dates, all assets such as slide decks, etc.
Check the education/experience level to see how much open source way training is needed. Possibly provide a white paper that explains what and why around radical transparency, etc.
Starting consideration: Do we start afresh, or join an existing community? What is the process for joining a new community?

List of Links / Further References:

Reference also the Product Launch Checklist from the Program Management Team for key deliverables required from the Product side. Valuable to understand which deliverables will align with community launches depending on scope, circumstances of Community Launch: https://mojo.redhat.com/docs/DOC-117979 Communication launch template: https://mojo.redhat.com/docs/DOC-1054334