This guide is intended to help OSPOs of all maturity levels build an open source training course that is created with purpose to deliver impact. Whether your OSPO recently launched or is looking into re-doing the firms open source training, this guide will provide ideas and content that can be implemented to a comprehensive open source training course.
This guide will also cover other considerations such as how to promote the training course after it has launched and a list of topics that might make more sense living in documentation rather than in the training course itself.
Determining Open Source Training Topics
Open source encompasses an array of topics. It will be up to the OSPO to determine what topics would best be suited for their firm's open source strategic roadmap and employees.
Suggested areas of concentration for training but not limited to:
Open Source 101
- What is open source?
- What is the difference between open source and proprietary code?
- Different ways to participate in open source
- Benefits to participating and contributing to the open source community (employee, firm, and open source community)
- Open source vs commercial/proprietary
- Open source licenses (permissive and Copyleft)
- Internal process and guidelines (internal tooling, workflow, teams/people that own processes and guidelines - might not be all owned by the OSPO)
- Contribution best practices
- Contribution models (link to CLA/DCO documentation)
- Internal process (internal tooling, workflow, teams/people that own processes and guidelines - might not be all owned by the OSPO)
- See: Contribution Training
- Benefits and ways of participating in the open source community
- Approval process to participate in open source community
- Antitrust laws
Training For Compliance
Assess the current state of the firms open source culture, policies, guidelines, and processes.
When a firm launches an OSPO it will be important for the OSPO to gather open source information regarding:
There might be one, all or none of the items listed above that the OSPO inherits. For example, if the OSPO inherits a process that allows contributions on behalf of the firm the OSPO will have to assess and see if this process needs to be revised, discarded, and built new. By taking account the firms current open source policies, guidelines, and processes there will be a better understanding of what infrastructure needs to be built before a training course can be created depending on the topic. Therefore, the target date to launch a training course might be targeted for a later date until certain items are solidified to create training content.
Internal vs External Training
There is free training such as Open Source Licensing Basics for Software Developers provided by the Linux Foundation that can be shared internally, providing training that is readily available.
Note: Each of the activities in the body of knowledge links to relevant training courses, which are also listed in the left-hand navigator under the "Training" category.
Firms can certainly rely on free courses like the ones mentioned in place of creating a training course themselves.
There are a few advantages to creating an internal training course:
- Cater to internal processes, policies, and guidelines
- Combine different open source topics that make sense for the firms needs
- Determine the amount of time a developer would need to take to complete the open source training
- Can update and revise content to stay relevant
Collaborate with Internal Partners
An OSPO works closely with internal partners like Legal and Compliance to accomplish open source initiatives. OSPOs processes and guidelines are sometimes intertwined or dependent on other teams (engineering and non-engineering) processes, policies, and or guidelines. Because of this, transparency and collaboration around creating the open source training is imperative.
Internal collaboration with the corresponding topics may look something like this:
- Open Source 101
- Executive Office
Collaboration with internal teams will make sure that content is brought together by the subject matter experts. By collaborating, you will also strengthen your relationships with these teams and bring visibility to how the OSPO is an intersection across various teams within the firm.
Tip: Have your Legal review all content to ensure that the content is expressed correctly, accurately reflecting the firm and the open source community.
Create a Training That Caters To All
By providing a foundational open source module along with firm-specific material the training course will be more easily digestible to developers of all levels in open source (link to developer maturity model).
Usability Testing and Content Review
Usability testing is beneficial for many reasons. Having multiple developers from all ranges of experience take the training course will offer insight and feedback is extremely beneficial to the training course before launching it. It is recommended, if possible, to have the developers take the training course on the real Learning Management System (LMS). This will give the developer the full experience, offering the opportunity to see if there are any logistical problems as well or if directions need to be rephrased. This will also give insight to how developers feel after taking the course.
Here are some questions to think about:
- Do they feel more curious about open source?
- After taking the training, do they know where to find the necessary documentation if they need guidance?
- What are some interesting key take-aways that developers took away?
Resources that can be included in the training
- General open source links
- OSPO documentation links
- OSPO contact
Promoting the Training
After the training course has launched it is important to make sure that it is visible to the firm. Having a link set up in the OSPO home page is a start.
Different ways to promote the training course:
- Host an internal event
- Promote the training in the firms newsletter
- Blog articles
Other Types of Training
There are other ways to spread knowledge of open source practices aside from building a training.
Organising a deep-dive session on a particular topic can help raise awareness of the OSPO. Some examples:
- Run a talk about the purpose of foundations, and invite FINOS or another foundation along to talk.
- Invite internal open source teams to a panel discussion, bringing to light the OSPO and what it does, the purpose of the internal open source project and the fact that there is OSS being done internally.
- A spotlight session on particular internal contributors and what how they engage with open source.
- Inviting external experts (e.g. security experts) to explain how to engage with working groups or standards. Leverage foundation membership to discover these.
Bringing awareness to open source (add details here).
An internal hackathon using some pieces of open source software can be a good way to learn about the dynamics of open source consumption or contribution. (add links)
Training courses are more static and harder to update than documentation. Topics for documentation vs topics for training can come down to a few things:
Does the topic cater to the masses or is this specialized?
Example: How to contribute at the firm to cater to the masses vs how to open source a project might apply only to a few
Will the content need to be updated more frequently?
Example: External links can change from time to time. Using external resources on the training course will reduce the risk of having broken links and having to update the course.