One of the biggest challenges I faced while operating a community at a major cybersecurity firm was getting people to share the great stuff they wrote, especially code, scripts or non-product tools. Cybersecurity professionals are more sensitive to the risks posed by sharing information, and often the response is to not openly share.
That's not to say they aren't sharing - they are, but all through email and private channels, rather than openly in your knowledge base or community.
It's simpler to get people to share internally, where customers and partners cannot hold them accountable for their work. But the default state is sharing content through email, which is difficult to search and the history isn't accessible to newcomers. You can drive behavioral changes by writing up the answer in the internal knowledge base or community and sending the link as a response. Coach your key collaborators and team leaders to do this, and eventually it becomes the norm.
It’s more difficult to get external sharing started. Your website or community terms of service should already outline expectations of content use and support for all members, employees included. Yet, your technical contributors may still not feel comfortable sharing externally, especially after a tech giant fired a couple of engineers for their Def Con talk.
It may feel counter-intuitive, but defining a policy for your internal audience may actually encourage them to share scripts and code with your customers and partners. This policy should include clear definitions or descriptions of:
- Official product: Include branding, expectations of support and avenues of delivery
- Volunteer contributions: You may need to differentiate between code that augments existing products (i.e., scripts that automate functionality) and code that replaces product functionality (i.e., an alternate interface built through the API) or acts as a stand-alone application (i.e., an open source application that doesn't rely on the core product line to function); you may need to enable a structure, either formal or volunteer, for code review
- Third Party submissions or links: Content made by anyone other than the company or its employees/contractors that is not hosted on delivery platforms owned, operated, or sponsored by the company.
You may need to define whether open source or other code content created by employees during their employment but hosted/housed in non-company repositories are treated as volunteer contributions or as Third Party. In Figure 1 below, I split the Volunteer contributions into two categories based in part on where the company published their content; your outline may be simpler. Customize Figure 1 to create a synopsis of the points to cover in writing your policy.
Figure 1: Description of Types of Code Shared by a Company and its Employees
|
|
Official Product |
Volunteer Contributions to Product |
Volunteer Tools & Applications |
Third Party Code, Tools or Applications |
|
Author/ |
Created by Company through standard engineering/product processes |
Code, scripts, tools or applications created by an employee outside the normal engineering/product process |
Any code not created by the company or a current employee |
|
|
Code Function |
Provides activities or services as defined by product management or legal contract with the customer |
Augments, enhances, relies on, or provides examples for corporate product(s)
|
Provides alternatives to or stands separate from corporate product(s) |
Not determined by company, but generally helpful to audience in some way |
|
Expectation of Support |
Company supported |
Individual or crowdsourced support; no company support |
Not determined by company; no company support |
|
|
Expectation of Use |
Defined by terms of use or legal contract |
End-user can review or inspect code, and copy, modify, or otherwise use code as they deem fit |
A license or permission is required to review, copy, modify or use code |
Not determined by company |
|
Delivery |
Formal delivery through established corporate or product channels |
Informal distribution by author through community or knowledge platform |
Informal distribution through community or knowledge base, or formal distribution by company as freeware/open source |
Not determined by company |
|
Code Review |
Standard Engineering or Support QA Processes |
Informal peer review |
Structured peer review or corporate code review - Review before sharing externally |
Not required |
|
Licensing |
Defined by corporate legal team |
Covered by website or community Terms of Service |
Determined by author and/or corporate legal team |
Covered by website or community Terms of Service |
Once you’ve written your code-sharing policy, you can work sharing code into your knowledge flow or business processes; Figure 2, below, is a very simple example.
With a clearly defined policy and knowledge flow, your teams should feel more comfortable sharing the non-product work they do with their peers, partners and customers. Remember, however, that your policy and knowledge flow need to work with your website, community or knowledge base Terms of Use and be clearly promoted by your community, knowledge base or website as an informal, unofficial, or unsupported content.
Collaboration & Communication Strategist Carlota Sage uses her love of technology and language to help information security companies communicate and collaborate better. When not making the technical world a better place, she makes jewelry, feeds people waffles, or destroys/rebuilds old Mazdas.