supasympa · September 14, 2016 19:59
diff --git a/open-social-software-engineering b/open-social-software-engineering
 #Open, social, software engineering in risk averse environments

 *Lewis Barclay, April 2016*



 > Open source software is about freedom and choice, but freedom and choice introduce risk 

 > **- (Gartner, June 2011)**

 ------

 ##The open and social software engineering landscape

 Software engineering is an inherently social activity and in the last 10 years open, social software engineering (or OSSE as I call it from herein) has thrived on a culture of fast paced community correction through social engagement backed by online tooling. Practitioners are encouraged to use tools like StackOverflow, GitHub, BitBucket, Slack etc to communicate, develop and publish their output which is usually open source software (OSS) or something related to it. They use tools, conventions and behaviours to evolve software of regularly proven quality, rapidly, by encouraging feedback loops to core development teams. With the benefits this approach leverages comes new risks, including the following OSS specific risks identified in the paper "Managing Risk in Open Source Software Adoption" - (Franch et al, 2013):

 > 1. how to design the viewpoints from which one can look at an ecosystem in order to collect information for managing the evolution for the OSS products to be embedded? 
 2. how to secure that specific features of OSS do not harm business models and their underlying business strategies?
 3. how to implement a systematic approach towards understanding and representing dependencies involving OSS components for assessing risks?
 > 
 > **- (Franch 2013)**

 In trying to understand the problems faced adopting OSSE in risk averse environments, I've read articles, white papers and books that cover; security in open environments, lean thinking in corporate environments, culture in software engineering driven companies and articles on managing risk when adopting OSS. Having done so I've documented my initial understanding in section 1 and and introduced some of my own thinking around how to apply what I've learnt in section 2.

 ----

 ##1.0 Risk, organisational differences and practise

 > It seems that it is the nature pf most large, publicly held companies to be chronically prevention focused, leaders tend to be motivated by a sense of responsibility to the company's many stakeholders and a fear of making mistakes. When these prevention-focused companies decide to take a promotion-focused goal-innovation, for instance - there is a dissonance between the chronic safety focus of the organisation and the aspirational goal of the disruptive innovation.
 > 
 > **- (Poppendieck and Poppendieck - 2015)**

 
 ###1.1 Mitigating risk in open environments 

 In non-technical open environments, where communities are encouraged to thrive and evolve, localized security is provided to manage risk with minimal restriction or preventative measures, in this case laws are made, and policing is used to evidence wrong doing and correctional actions are taken to fix problems, additionally laws are regularly reviewed and evolve relative to the maturity of the community. Likewise in a technology focused environment, the same challenges are faced, a balance is required, allowing the community to evolve and thrive but at the same time the community needs security. In both environments, the development of trust is key and, much like in parenting, trust has to evolve alongside recognized good practices becoming habits.

 ###1.2 Two types of organisation

 Organisations fit into two categories when facing risk; those that have an attitude where "preventing error is cheaper than fixing it" (PECF) or those that can fix errors and move forward. 

 Organizations that can afford to fix errors can attempt to answer the inherent OSS risks by further encouraging social activity and openness. They can take a "just fix small problems quickly and rapidly recover" approach, therefore avoiding big disasters. The weight and pace of the open community they embed themselves within assists in fixing small problems rapidly and they do this in the community enclosure before any irrecoverable damage has had an opportunity to occur.

 In contrast incumbent organisations involved in manufacturing, medicine and finance cannot afford some of these errors, let alone any disasters. They are usually limited by industry regulation and need to protect a successful track record and a developed customer base. They have more to lose and by the same token have to consider higher order attacks and cyber security to a greater degree than companies outside of these industries. In these environments risk is more often mitigated through enforcing restrictions and trust levels are fixed. Of course, PECF prone organisations have been employing highly technical, complex solutions for managing their technical risk for many years and have become experts in doing so. This has largely occurred in environments using proprietary software and *closed engineering* practices that inherently struggle with the ability to rapidly innovate and release software without large associated costs. 

 ###1.3 Current OSSE practices

 The participants of the first International workshop on Social Software Engineering and Applications categorised SSE as:
 > * Community-centered: Software is produced and consumed by and/or for a community rather than focusing on individuals
 * Collaboration/collectiveness: Exploiting the collaborative and collective capacity of human beings
 * Companionship/relationship: Making explicit the various associations among people
 * Human/social activities: Software is designed consciously to support human activities and to address social problems
 * Social inclusion: Software should enable social inclusion enforcing links and trust in communities

 > **- (SoSEA 2008)**

 OSSE has been propelled recently by the following:

 1. The maturity of software engineering communities and OSS, including; Apache, RubyOnRails and NodeJs, MongoDB
 2. The evolution of tooling to support social software engineering activity, including: GitHub, StackOverflow, Slack
 3. The provision of SaSS services to support software delivery like: AWS, Heroku, CodeShip, Docker
 4. Evolving software design that supports SOLID principals and XP patterns.  

 Practising OSSE is no longer an amateur, second class activity practised by programmers in bedrooms. It has matured and has developed into a first class option for startups and established corporates alike who recognise that it can offer: 

 * a short time- to-market software service and product delivery 
 * reduced development and maintenance costs,
 * and increased customization capabilities


 --------------------------------

 ## 2.0 Adopting open social engineering 

 > Companies such as Apple and Google have embraced a network centric view of software ecosystems, and developed novel business models, with varying degrees of openness – from the adoption of selected open web standards, to the promotion of key web APIs as ad-hoc standards, to the (more or less) full embrace of open source software – to encourage the emergence of massive global hardware/software ecosystems surrounding their products and services (e.g. iPhone, Android, etc.).
 >  
 > **- (Franch 2013)**

 ###2.1 First steps
 To restate: 
 > Open source software is about freedom and choice and software engineering is an inherently social activity.  Therefore to truly leverage capabilities an organisation has to promote social activity, freedom and choice.

 ####2.1.1 Promoting social activity, freedom and choice
 Netflix has a [great slideshare presentation on the culture it cultivates](http://www.slideshare.net/reed2001/culture-1798664/58-With_the_Right_PeopleInstead_of) and in amongst the slides there are statements like:

 > "Most companies curtail freedom as they get bigger"
 > "Increase talent density faster than complexity grows"
 > "Instead of a culture of process adherence we have a culture of creativity and self-discipline, freedom and responsibility" 

 The Lean Mindset (Mary Poppendiek and Tom Poppendiek - 2015) discusses many relevant topics in a software delivery environment and it abruptly points out that:
 > "One very likely cause of innovation problems in large companies is that the regulatory fit is wrong. These companies have developed a strong prevention focus but significant innovation cries out for a promotion focus"

 They go on to describe Ganas as: 

 > "The desire to learn, the ability to sacrifice and the wish to get ahead"

 The [Valve employee handbook](http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf) begins with:
 > "A fearless adventure in knowing what to do when no one’s there telling you what to do"

 In all three of these publications there is a trend of encouraging experimentation, failing fast and often and learning from failure but what is striking is the need to trust. Solutions for promoting social activity, freedom and choice are described heavily in the first two publications and implied in the third.  


 ####2.1.2 Mitigating the risk

 As stated, social software engineering:
 * is community-centered
 * requires collaboration
 * values social activities, 
 * and promotes social inclusion

 Mitigating the risk of adopting these behaviours has to be non-limiting. Security policies, restrictions, software, hardware, access, work environments and personnel have to be reviewed and aligned against these facets - regularly. 

 New solutions must be found when existing ones prevent any of these facets existing.

 As an example, new industries and tools are emerging to fight higher order attacks and cyber security in more open and connected environments. Companies like [https://www.digitalshadows.com](https://www.digitalshadows.com) offer cyber situational awareness that "can help to detect and help contain cyber-related incidents", for example. 
 These kind of services might offer risk mitigation that is less restrictive of the facets of OSSE.

 ###2.2 Introducing OssOps

 If we take a lead from the recent wave of "DevOps" in software engineering: An organisation looking for the benefits of OSSE could, for example, look to create a new discipline, potentially advised by people who have lead security in traditional open environments; universities, colleges, charities etc.

 The practitioners of the new discipline, we'll call them OssOps, would be embedded within product and project teams and their purpose is to *enable teams, allowing them to be open and social, encouraging good practice and behaviour whilst  mitigating damage from errors*.

 > OssOps practitioners would avoid disasters through rapid error recovery. They are bobbies patrolling the streets, rather than politicians, creating laws to be enforced. They have the power to completely enable the team whilst policing behaviour and developing secure solutions.

 To implement successful OssOps would require:
 1. A trusting culture
 2. A reasonably flat hierarchy
 3. Fully empowered OssOps individuals who work within teams
 4. Individual practitioners at first that coach teams until they are operating with an OssOps mindset and make themselves redundant

 ### 2.3 What the habits and behaviours of OssOps could look like

 1. Constant code review and correction
 2. Continuous penetration testing
 3. Removal of software hardware and access restrictions
 3. Preferring first hand evidence and correction over distant enforcement
 4. Hardening software while developing solutions
 5. Encourage OssOps everywhere, internally and externally on open platforms 
 6. Bounty Hunting. Offering a price for the discovery of failures and weaknesses in software
 7. Encouraging teams to gain experience by solving community problems not just internal ones
 8. Encouraging an open, secure, social mindset by propagating the mantra "avoid disasters and rapidly recover from small errors".

 ### 2.4 An example

 A fear of breaking data-protection law by publishing data on Slack could lead a risk averse organisation to avoid using the tool completely and in-turn avoid the gains others have seen from its clever integrations! I liken this to a fear of using A-roads because it's easy to break the speed limit. In an trust aligned environment the OssOps practitioner would encourage the use of Slack but would actively work to encourage practice that doesn't contravene company ethics or break the law. The OssOps practitioners would actively develop software solutions that assisted team members in avoiding this in everyday practice. i.e. using [the slack API](https://api.slack.com). If an error does occur - let's say a data protection breach, integrations and automation could inform an OssOps engineer, potentially before it occurs. Behaviours could be adjusted and rapid recovery is made from the error. Disasters are avoided.


 -------------


 References
 ----------------
 [Top sober security concerns 2016](https://blog.varonis.com/social-engineering-remains-a-top-cybersecurity-concern/)

 [Managing risk in OSS adoption](https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&ved=0ahUKEwjL8YbM0qfMAhWJ7hoKHaHZAaIQFggoMAI&url=http%3A%2F%2Fwww.riscoss.eu%2Fbin%2Fdownload%2FShare%2FPublications%2FICSOFT-EA_2013_78_CR.pdf&usg=AFQjCNG7WF6GKxcpafeHlVfnzjxq8sG4rw&sig2=gqsY2hlOdT_IOgjSSYoOOw&bvm=bv.119745492,d.d2s&cad=rja)

 [Mitigating risk in open environments](http://www.securitymagazine.com/articles/86743-greg-wurm-mitigating-risk-in-open-environments)

 [Digital shadow - search light](https://www.digitalshadows.com/digital-shadows-searchlight/)

 [Netflix Culture](https://www.slideshare.net/mobile/reed2001/culture-1798664)

 [The Valve employee handbook](http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf)

 [OSS Watch](http://oss-watch.ac.uk)

 [Social software engineering](https://en.wikipedia.org/wiki/Social_software_engineering)

 Further reading
 ----------------------
 [3 Financial companies innovating with open source](https://www.linux.com/blog/3-financial-companies-innovating-open-source)

 [RISCOSS white paper - managing risk and cost in open source software projects](http://www.riscoss.eu/bin/download/Discover/Whitepaper/RISCOSS-Whitepaper.pdf)

 [OSS Watch - software sustainability maturity model](http://oss-watch.ac.uk/resources/ssmm)

 [OSS Watch - Reuse Readiness Rating](http://oss-watch.ac.uk/resources/reusereadinessrating)

 [Critical Strategies to Manage Risk and Maximize Business Value of Open Source in the Enterprise](https://www.gartner.com/doc/1730521/critical-strategies-manage-risk-maximize)

 [Five mistakes to avoid when implementing open source software](https://www.gartner.com/doc/1851922/mistakes-avoid-implementing-opensource-software)
	#Open, social, software engineering in risk averse environments

	Lewis Barclay, April 2016



	> Open source software is about freedom and choice, but freedom and choice introduce risk

	> - (Gartner, June 2011)

	------

	##The open and social software engineering landscape

	Software engineering is an inherently social activity and in the last 10 years open, social software engineering (or OSSE as I call it from herein) has thrived on a culture of fast paced community correction through social engagement backed by online tooling. Practitioners are encouraged to use tools like StackOverflow, GitHub, BitBucket, Slack etc to communicate, develop and publish their output which is usually open source software (OSS) or something related to it. They use tools, conventions and behaviours to evolve software of regularly proven quality, rapidly, by encouraging feedback loops to core development teams. With the benefits this approach leverages comes new risks, including the following OSS specific risks identified in the paper "Managing Risk in Open Source Software Adoption" - (Franch et al, 2013):

	> 1. how to design the viewpoints from which one can look at an ecosystem in order to collect information for managing the evolution for the OSS products to be embedded?
	2. how to secure that specific features of OSS do not harm business models and their underlying business strategies?
	3. how to implement a systematic approach towards understanding and representing dependencies involving OSS components for assessing risks?
	>
	> - (Franch 2013)

	In trying to understand the problems faced adopting OSSE in risk averse environments, I've read articles, white papers and books that cover; security in open environments, lean thinking in corporate environments, culture in software engineering driven companies and articles on managing risk when adopting OSS. Having done so I've documented my initial understanding in section 1 and and introduced some of my own thinking around how to apply what I've learnt in section 2.

	----

	##1.0 Risk, organisational differences and practise

	> It seems that it is the nature pf most large, publicly held companies to be chronically prevention focused, leaders tend to be motivated by a sense of responsibility to the company's many stakeholders and a fear of making mistakes. When these prevention-focused companies decide to take a promotion-focused goal-innovation, for instance - there is a dissonance between the chronic safety focus of the organisation and the aspirational goal of the disruptive innovation.
	>
	> - (Poppendieck and Poppendieck - 2015)


	###1.1 Mitigating risk in open environments

	In non-technical open environments, where communities are encouraged to thrive and evolve, localized security is provided to manage risk with minimal restriction or preventative measures, in this case laws are made, and policing is used to evidence wrong doing and correctional actions are taken to fix problems, additionally laws are regularly reviewed and evolve relative to the maturity of the community. Likewise in a technology focused environment, the same challenges are faced, a balance is required, allowing the community to evolve and thrive but at the same time the community needs security. In both environments, the development of trust is key and, much like in parenting, trust has to evolve alongside recognized good practices becoming habits.

	###1.2 Two types of organisation

	Organisations fit into two categories when facing risk; those that have an attitude where "preventing error is cheaper than fixing it" (PECF) or those that can fix errors and move forward.

	Organizations that can afford to fix errors can attempt to answer the inherent OSS risks by further encouraging social activity and openness. They can take a "just fix small problems quickly and rapidly recover" approach, therefore avoiding big disasters. The weight and pace of the open community they embed themselves within assists in fixing small problems rapidly and they do this in the community enclosure before any irrecoverable damage has had an opportunity to occur.

	In contrast incumbent organisations involved in manufacturing, medicine and finance cannot afford some of these errors, let alone any disasters. They are usually limited by industry regulation and need to protect a successful track record and a developed customer base. They have more to lose and by the same token have to consider higher order attacks and cyber security to a greater degree than companies outside of these industries. In these environments risk is more often mitigated through enforcing restrictions and trust levels are fixed. Of course, PECF prone organisations have been employing highly technical, complex solutions for managing their technical risk for many years and have become experts in doing so. This has largely occurred in environments using proprietary software and closed engineering practices that inherently struggle with the ability to rapidly innovate and release software without large associated costs.

	###1.3 Current OSSE practices

	The participants of the first International workshop on Social Software Engineering and Applications categorised SSE as:
	> * Community-centered: Software is produced and consumed by and/or for a community rather than focusing on individuals
	* Collaboration/collectiveness: Exploiting the collaborative and collective capacity of human beings
	* Companionship/relationship: Making explicit the various associations among people
	* Human/social activities: Software is designed consciously to support human activities and to address social problems
	* Social inclusion: Software should enable social inclusion enforcing links and trust in communities

	> - (SoSEA 2008)

	OSSE has been propelled recently by the following:

	1. The maturity of software engineering communities and OSS, including; Apache, RubyOnRails and NodeJs, MongoDB
	2. The evolution of tooling to support social software engineering activity, including: GitHub, StackOverflow, Slack
	3. The provision of SaSS services to support software delivery like: AWS, Heroku, CodeShip, Docker
	4. Evolving software design that supports SOLID principals and XP patterns.

	Practising OSSE is no longer an amateur, second class activity practised by programmers in bedrooms. It has matured and has developed into a first class option for startups and established corporates alike who recognise that it can offer:

	* a short time- to-market software service and product delivery
	* reduced development and maintenance costs,
	* and increased customization capabilities


	--------------------------------

	## 2.0 Adopting open social engineering

	> Companies such as Apple and Google have embraced a network centric view of software ecosystems, and developed novel business models, with varying degrees of openness – from the adoption of selected open web standards, to the promotion of key web APIs as ad-hoc standards, to the (more or less) full embrace of open source software – to encourage the emergence of massive global hardware/software ecosystems surrounding their products and services (e.g. iPhone, Android, etc.).
	>
	> - (Franch 2013)

	###2.1 First steps
	To restate:
	> Open source software is about freedom and choice and software engineering is an inherently social activity. Therefore to truly leverage capabilities an organisation has to promote social activity, freedom and choice.

	####2.1.1 Promoting social activity, freedom and choice
	Netflix has a [great slideshare presentation on the culture it cultivates](http://www.slideshare.net/reed2001/culture-1798664/58-With_the_Right_PeopleInstead_of) and in amongst the slides there are statements like:

	> "Most companies curtail freedom as they get bigger"
	> "Increase talent density faster than complexity grows"
	> "Instead of a culture of process adherence we have a culture of creativity and self-discipline, freedom and responsibility"

	The Lean Mindset (Mary Poppendiek and Tom Poppendiek - 2015) discusses many relevant topics in a software delivery environment and it abruptly points out that:
	> "One very likely cause of innovation problems in large companies is that the regulatory fit is wrong. These companies have developed a strong prevention focus but significant innovation cries out for a promotion focus"

	They go on to describe Ganas as:

	> "The desire to learn, the ability to sacrifice and the wish to get ahead"

	The [Valve employee handbook](http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf) begins with:
	> "A fearless adventure in knowing what to do when no one’s there telling you what to do"

	In all three of these publications there is a trend of encouraging experimentation, failing fast and often and learning from failure but what is striking is the need to trust. Solutions for promoting social activity, freedom and choice are described heavily in the first two publications and implied in the third.


	####2.1.2 Mitigating the risk

	As stated, social software engineering:
	* is community-centered
	* requires collaboration
	* values social activities,
	* and promotes social inclusion

	Mitigating the risk of adopting these behaviours has to be non-limiting. Security policies, restrictions, software, hardware, access, work environments and personnel have to be reviewed and aligned against these facets - regularly.

	New solutions must be found when existing ones prevent any of these facets existing.

	As an example, new industries and tools are emerging to fight higher order attacks and cyber security in more open and connected environments. Companies like [https://www.digitalshadows.com](https://www.digitalshadows.com) offer cyber situational awareness that "can help to detect and help contain cyber-related incidents", for example.
	These kind of services might offer risk mitigation that is less restrictive of the facets of OSSE.

	###2.2 Introducing OssOps

	If we take a lead from the recent wave of "DevOps" in software engineering: An organisation looking for the benefits of OSSE could, for example, look to create a new discipline, potentially advised by people who have lead security in traditional open environments; universities, colleges, charities etc.

	The practitioners of the new discipline, we'll call them OssOps, would be embedded within product and project teams and their purpose is to enable teams, allowing them to be open and social, encouraging good practice and behaviour whilst mitigating damage from errors.

	> OssOps practitioners would avoid disasters through rapid error recovery. They are bobbies patrolling the streets, rather than politicians, creating laws to be enforced. They have the power to completely enable the team whilst policing behaviour and developing secure solutions.

	To implement successful OssOps would require:
	1. A trusting culture
	2. A reasonably flat hierarchy
	3. Fully empowered OssOps individuals who work within teams
	4. Individual practitioners at first that coach teams until they are operating with an OssOps mindset and make themselves redundant

	### 2.3 What the habits and behaviours of OssOps could look like

	1. Constant code review and correction
	2. Continuous penetration testing
	3. Removal of software hardware and access restrictions
	3. Preferring first hand evidence and correction over distant enforcement
	4. Hardening software while developing solutions
	5. Encourage OssOps everywhere, internally and externally on open platforms
	6. Bounty Hunting. Offering a price for the discovery of failures and weaknesses in software
	7. Encouraging teams to gain experience by solving community problems not just internal ones
	8. Encouraging an open, secure, social mindset by propagating the mantra "avoid disasters and rapidly recover from small errors".

	### 2.4 An example

	A fear of breaking data-protection law by publishing data on Slack could lead a risk averse organisation to avoid using the tool completely and in-turn avoid the gains others have seen from its clever integrations! I liken this to a fear of using A-roads because it's easy to break the speed limit. In an trust aligned environment the OssOps practitioner would encourage the use of Slack but would actively work to encourage practice that doesn't contravene company ethics or break the law. The OssOps practitioners would actively develop software solutions that assisted team members in avoiding this in everyday practice. i.e. using [the slack API](https://api.slack.com). If an error does occur - let's say a data protection breach, integrations and automation could inform an OssOps engineer, potentially before it occurs. Behaviours could be adjusted and rapid recovery is made from the error. Disasters are avoided.


	-------------


	References
	----------------
	[Top sober security concerns 2016](https://blog.varonis.com/social-engineering-remains-a-top-cybersecurity-concern/)

	[Managing risk in OSS adoption](https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&ved=0ahUKEwjL8YbM0qfMAhWJ7hoKHaHZAaIQFggoMAI&url=http%3A%2F%2Fwww.riscoss.eu%2Fbin%2Fdownload%2FShare%2FPublications%2FICSOFT-EA_2013_78_CR.pdf&usg=AFQjCNG7WF6GKxcpafeHlVfnzjxq8sG4rw&sig2=gqsY2hlOdT_IOgjSSYoOOw&bvm=bv.119745492,d.d2s&cad=rja)

	[Mitigating risk in open environments](http://www.securitymagazine.com/articles/86743-greg-wurm-mitigating-risk-in-open-environments)

	[Digital shadow - search light](https://www.digitalshadows.com/digital-shadows-searchlight/)

	[Netflix Culture](https://www.slideshare.net/mobile/reed2001/culture-1798664)

	[The Valve employee handbook](http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf)

	[OSS Watch](http://oss-watch.ac.uk)

	[Social software engineering](https://en.wikipedia.org/wiki/Social_software_engineering)

	Further reading
	----------------------
	[3 Financial companies innovating with open source](https://www.linux.com/blog/3-financial-companies-innovating-open-source)

	[RISCOSS white paper - managing risk and cost in open source software projects](http://www.riscoss.eu/bin/download/Discover/Whitepaper/RISCOSS-Whitepaper.pdf)

	[OSS Watch - software sustainability maturity model](http://oss-watch.ac.uk/resources/ssmm)

	[OSS Watch - Reuse Readiness Rating](http://oss-watch.ac.uk/resources/reusereadinessrating)

	[Critical Strategies to Manage Risk and Maximize Business Value of Open Source in the Enterprise](https://www.gartner.com/doc/1730521/critical-strategies-manage-risk-maximize)

	[Five mistakes to avoid when implementing open source software](https://www.gartner.com/doc/1851922/mistakes-avoid-implementing-opensource-software)