Open Source Culture

 

"Given enough eyeballs, all bugs are shallow"[2]

Introduction

As the basis for their operation, computer programs include a set of commands that define the way that they function. This series of commands is known as “source code,” and they define the way that the computer functions. The source code can be “closed,” accessible only by its software developers or “open” and accessible to the software’s users. A program whose source code is classified as open is referred to as “open source.” Hence, the code is accessible to other developers and can be used, distributed and copied. Developers who make changes to this code can then choose whether to safeguard the changes or whether to republish them to the community of developers. Additionally, open source code can be developed “communally” – with a number of developers working together on the development of an application.

The structure of software can be understood as layered, with each layer serving as the infrastructure for the layer above. This is due to the iterative nature of software development – creation of sections of code, using them to create additional sections of code and so on. The process stops with a “thin layer” of code that is not intended for repeated usage. This layer defines the functional dimension of the product – that is, the lines of code that serve specific functions in one specific product. The layers below the “thin layer” are tools for achieving this purpose, and they may be relevant in the context of other products.

Open source code, by its nature, is intended to serve different software projects, and therefore serves the infrastructure layers. Developers who choose to use open source code presume, rightly, that infrastructure code that serves many projects is ostensibly better infrastructure code than that which is developed for a specific project. Moreover, adopting open source code allows developers to minimize the required investment in non‐functional layers of the product and to focus their resources on the final objective.

The rate of change in our world is so fast that one can say that innovation in an organization is to some degree a condition for its success. This increasing rate of change is closely related to the digital revolution that has at its center the language of bits‐ that is, software. Hence, there is great interest in the level of adaptation in an organization like the Israel Defense Forces (IDF) to the software field (as opposed to the traditional focus on hardware). Furthermore, this level of adaptation, due to the central place of the software field to every aspect of developing military power, also reflects the level of general innovation in the organization. More concretely, and given the understanding that the phenomenon of software development based on an open source culture is the leading trend globally, this research will attempt to reveal the level of innovation in the IDF using this as a prism.

The basis for this research question is the assumption that today, open source development is the correct way to develop software in organizations – for which I will provide support at the beginning of this article.

In order to define indicators that reflect “the adoption of open source” I defined three “measuring scales.” On the basis of these conceptual “scales” I will try and place the Israel defense establishment, including the IDF, in relation to two other case studies – civilian industry and the American military‐defense establishment. I believe and hope that the research conclusions can assist the force design bodies in the IDF, MAFAT (the Administration for the Development of Weapons and Technological Infrastructure) and even the different military corporations.

The research method included measuring on three scales with each covering one dimension and then developing a comparative rating for each of the three test cases on a single scale comprising all three of the dimensions:

The first dimension and the most basic is the axis measuring open source usage. This axis ranges between total non‐use of open source to the use of open source “as is” and finally to “professional use” where changes and adaptations are made to the code.

The second dimension is the community axis. The intention here relates to the community of software developers themselves. This axis ranges between usage of open code alone to publication of code which was written independently. In the middle, one can find developers who only publish changes and adaptations which were made to existing open source code, a kind of “returning the favor."

The third dimension is the organizational direction axis. As opposed to the previous axis which focused on the software developer community, this axis focuses on the management level. It is intended to examine the importance of open source code as a significant factor among the different considerations the organization’s leaders take into account, and how this factor is expressed in formal processes.

Accordingly, the structure of the research includes an explanation of open source code and why it is a natural development in the software field; the second section is the comparative discussion – the Israeli defense establishment in comparison to others; and the last section deals with roadblocks and incentives to the adoption of open source in organizations and why there is a need for open source in the military. This research is based on different research sources and on interviews with personnel from the R&D and force design environments of the Israeli defense establishment.

On Open Source Code

This section will define what open source code is and will detail its advantages and disadvantages according to the literature. Source code is the basic code of computer software, and features a series of commands that define how a computer functions. Source code that is developed using the “open source” approach is by definition accessible to other developers and available for use, distribution and replication. Users can make changes to the source code which can then be marketed for free or for a fee. Developers who make changes to a piece of code can choose to protect the changes or republish them back to the developer community so that this upgraded product can be used in other software in the future. This is subject to the source code’s license which defines the legal rules for using it. In open source software, in principle and intention, there is no duty to define or report on the types of usage or to identify the users. The user license for open source code is only for the code itself and is not related to a specific product as a whole. It therefore follows that the connection between a right of usage and between a specific product is voided.[3] Concomitantly, in proprietary software, the users and community of developers outside the company which developed it, are not able to view the source code. Accordingly, the end user’s ability to make personal adaptations and changes is limited to the settings defined by the developer company.[4]

At the beginning of the public discourse on open source code, open source was attributed to an ideology that was hostile to intellectual property and rights, due to the view that it was possible to bring a greater social benefit by minimizing the element of intellectual property in software. Today, however, the prevailing view sees open source as a new business model. As opposed to proprietary software companies which depend on sales of user licenses, the business model for open source software depends on the provision of services and technical support. Consequently, alongside the option to download and use software without payment, there are also additional services for which the companies charge.[5] Richard Stallman, President of the Free Software Foundation said: “Open source is a development methodology; free software is a social movement.”[6]

Open Source software can be developed through a “social” approach where a number of developers cooperate to develop a piece of software. This kind of development, which is done by independent sources, over time generates a wider and more varied perspective than that created by a single company.[7]

In contrast to the development of “closed” software initiated and planned by a particular company, there are several reasons for the trend to use open source development, including: Low cost; an improvement in the quality of the product; the freedom to disconnect from the software provider; and increased security. In light of this, open source development provides a response to specific problems in such a manner that 98% of corporations use it in varied ways.[8]

Many supporters of open source argue that it allows for increased security in an integral fashion, due to the fact that everyone can view the code, edit it, and change it.[9] Research which sought to confirm this assertion found that while closed code had 20‐30 bugs on average per 1,000 lines of code, in Linux, which is an example of open source software, an average of 0.17 bugs were found for each 1,000 lines of code.[10] In this context, we can appreciatively note “Linus’s law” which asserts that if enough eyeballs are checking code, all the bugs will be found, and a way will be found to solve them.[11]

Another advantage of open code software is relatively fast development speeds due to the fact that more developers are involved in its creation. A further is the fact that open source code allows for an efficient penetration of new markets. Furthermore, companies that offer open source software can set the professional bar in that sector and gain a competitive advantage over other companies. The successes of these companies create a feeling of belonging and loyalty among the developers who worked on the final product.[12]

There are additional advantages when using open source, such as the reduced cost of marketing and logistical services. Open source software is more reliable, given that in most cases, thousands of independent programmers check it and fix any problems they find. The resulting product is more reliable because modular systems allow programmers to develop interfaces and to add new capabilities. As a result, an innovative product is created ‐ after all, open source is the result of broad cooperation between developers.

Furthermore, the amalgamation of different perspectives, organizational objectives and personal goals among those participating in software development, an amalgamation that is built into open source development, accelerates innovation.[13]

However, there are experts who argue that there is a negative side to open source. Among the disadvantages are the facts that sometimes the process of open source development is not clearly defined and that the stages of development, such as systems analysis and documentation, are likely to be neglected. Some software experts and researchers note that open source does not lead to the creation of quality systems, primarily due to a lack of clarity in the development processes, delayed discovery of defects and a lack of empirical evidence.[14] When analyzing the business aspects, there are those who argue that open source development supplies the basic technical requirements, but the requirements of the market remain unfulfilled. With regard to the software security element, open source allows hackers to more easily discover weaknesses and gaps in software than with “closed” software development.[15]

Open Source is the Natural Development of the Software Field[16]

Software development is an iterative process that creates resources in the form of sections of code and re‐uses them for the creation of more complex resources that are also made up of sections of code. The process finishes at the stage when a “thin layer is reached” which is made, as far as possible, of code which is not for re‐use. This layer reflects the functional dimension of the product being developed (the Business Logic). Consequently, this layer has full responsibility for the specific requirements of the product, and is not the foundation for other software layers written above it.

In the process of software development, the goal is to focus as much as possible on the functional “thin layer” which reflects the product’s objectives, and to deal less with the infrastructure layers that are only a tool for the existence of the functional layer. That being said, there is a problem ‐ without quality infrastructure it is very difficult to effectively develop the functional layer. Consequently, and despite the desire to focus on the end goal, a constraint arises which demands a significant investment of resources.

The quality and value of code that is re‐used (“infrastructure code”) can be measured by the number of times it is used and the range of uses. That is, the more a section of code “wins” by being used in more programs of greater variability, it is recognized as being higher “quality” code or “more infrastructural,” and therefore a higher value asset. Accordingly, the most effective, and indeed the only, way to create and improve high value infrastructure code is through repeated re‐use.

Consequently, one can say that a software developer will always use code that was previously written, and in principle, it doesn’t matter if the code was written by him or another developer. Therefore, open source constitutes a potential capability, from a technical standpoint, and is even logical from a financial standpoint given that it allows for a division of labor between several developers. By using infrastructure code wherever possible, a developer can focus his efforts on the functional layer of the product which is, as noted, the end goal, while the infrastructure is just a means.

With regard to the sharing of infrastructure code by the developer who writes it, there are several considerations when deciding whether to keep or share it with the community. On one hand, the code is the product of his work, on the other hand the value of the code is assessed and improved, the more it is used by other users and adapted to their needs. Therefore, if it is important to a developer to write efficient infrastructure code, he should want to share it with other developers in order to improve it. In this way, the developer receives confirmation of the quality of the code, and more significantly, the developer receives better quality code in return. In other words, ‐the infrastructure software development field works on the principle from the Jewish sages (quoted in the Talmud): “He has sustained a benefit, and he has sustained no loss.” This principle is completely different from the intuition of most people who work in creative work or who deal with intellectual property.

The purpose of open source code is to allow the developer to focus as much as possible only on the “thin layer,” the unique component needed for the particular product they are developing. Open source allows software developers to rely on original infrastructure code that is better quality than the proprietary alternative, because it was developed and enhanced by a large community, and has been tested in different contexts. The open source community generally supplies better quality code due to the “shame effect”‐ the fact that different developers do not want to be perceived as someone who supplies solutions that are not optimal. Finally, the existence of an open discourse on code created through a joint writing process naturally generates a critical discourse with regard to the most effect approach to development. Different developers from different backgrounds ultimately lead to more effective decision‐making and correspondingly better quality code.

These two dimensions – the first represents the psychological‐sociological element and the second the use of discourse as a means to enhance knowledge development – are familiar in the field of software development. Examples can be seen in techniques such as Code Review, whereby one developer presents the code that they have developed to another developer and advocates for his work. Additionally, Extreme Programming is another example where two developers work together on the same code. The sociological space that is created during open source development directly serves these two dimensions.

Software development in the framework of open source constitutes, not just a more advanced embodiment of quality software, but seemingly the only way to maximize the unique advantages of the software field in a relevant manner. Therefore, the same importance attached to software must be given to open source.

Consequently, if the army is to enter the software field, it must adapt to open source as well.

After my survey of the open source field and the understanding of the deep logical basis which defines this approach as a condition for basic effectiveness in the software field, you can understand why I argue that there is a correlation between the level of adoption of open source and the issue of innovation in an organization. “Open source” is an elementary process of organizational adaptation to the new digital environment. Therefore, the degree to which the IDF adopts open source and understands its importance “organizationally”, is an important indication, to my understanding, of its ability to adapt and innovate on a more general level.

Obstacles and Incentives to the Adoption of Open Source Code in Organizations

From an analysis of the business sector we can learn that open source has many positive influences on organizations. It accelerates processes through work practices that “economize” on the need to write large amounts of infrastructure code by starting from scratch each time. Open source code is an inseparable part of the community of developers which enables the utilization of the wisdom of the crowd – which is much greater than the internal resources of any business organization. This contributes, naturally, to long term maintenance and to solving bugs. Even more importantly, open source is fertile ground for new ideas and enhances the innovation in an organization, thereby increasing its competitive advantages.[17]

The wave of globalization sweeping the world shows that the problems in software are global problems. The problems that occupy an organization on one side of the globe are also occupying organizations on the other side. Indeed, the use of open source by organizations allows them to engage in broad cooperation which contributes to the optimal solving of problems.[18]

Despite all the advantages, there are also obstacles which affect the process of adopting open source by organizations and companies. Among the obstacles are the need for a connection to the internet. There are organizations, primarily security organizations, in which not all employees have free access to the global internet.[19] Especially in these organizations, but also in others, the traditional principles of information security sometimes presents an additional difficulty to this technical challenge.[20] Another problem relates to open source licenses and obstacles which arise from the lack of formal support and training as well as a lack of long term planning.[21]

All of these obstacles are also relevant, naturally, to military organizations. In addition, interviewees in security and military organizations bring up obstacles such as the NIH phenomenon (Not Invented Here), which is accompanied by attitudes such as: “Only I know how to develop” or “I know best”, etc.[22]

Why is Open Source Code Needed in the Army at all?

The army faces the same IT problems as industry. However, most of the activity and the technological research focuses on the systems that directly influence combat on the battlefield. Less visible systems naturally tend to be developed at a slower pace due to complex bureaucratic processes which guide the relations between industry and the IDF. Given the nature of militaries, many problems arise in a range of fields. The attributes of open source code allow the re‐use of solutions to common problems and also allow the flexibility to develop new solutions and services. Therefore, as in the civilian world, open source can also reduce development costs and significantly shorten development times for military applications, especially for the infrastructure layers of software.[23]

Furthermore, due to the fact that the source code is open, the dependence of the army on a single contractor is significantly reduced. Open source should allow the army to benefit from competition between contractors and the potential for rapid development and deployment. Besides, open source allows great flexibility. The fact that the source code is open also enables its adaptation to different needs and users. This flexibility is what turns open source to a practical solution for the army.[24]

Open source, especially for infrastructure layers, is ready for immediate use, which as noted, enables developers to work efficiently and to focus on adapting the software to the user’s needs, instead of devoting time to developing systems from scratch. Accordingly, open source allows for shorter development times and encourages innovation. Reducing the effort needed for infrastructure tasks enables greater focus of development energies on innovation and solving problems in the real world and not on software. Especially important, to my understanding, is the conclusion that projects that include open source increase cooperation, by developing communities focused on specific fields. These communities are the basis for cooperation, ideas and knowledge. As noted, cooperation expands the awareness and innovation for a particular project.[25] These are particularly significant benefits for security organizations whose tendency to insularity, even at the price of redundant development, is well known.

Nonetheless, there are those who argue that open source code damages the security of the software, and it should therefore not be used in a classified environment. The security of open source code is based on improving the code and its testing by many developers in many and varied situations. There are circumstances where open source code is less secure, but the open source model has shown that it can fix security problems very fast. Furthermore, hiding the code does not actually prevent attacks on the software.[26] The US Department of Defense (!) noted that:

The continuous and broad peer‐review enabled by publicly available source code supports software reliability and security efforts through the identification and elimination of defects that might otherwise go unrecognized by a more limited core development team.[27]

Also, a military organization retains control over the open source code that it adopts, and can closely monitor the results in order decide which parts of the code to add to its systems, and which not. Accordingly, the chances of introducing a “Trojan Horse” through open source code are reduced.[28]

(Soldier in MAMRAM coding. IDF Spokesperson's Unit) 

Comparative Discussion – The Israeli Defense Establishment in Relation to Others

In this section of the research we will use various scales in order to measure the place of the Israeli defense establishment in general, and the IDF in particular, in relation to the business sector and the US defense establishment. Given that open source code is adopted by organizations on a wide scale, it would seemingly be possible to analyze it just by measuring its level of usage. However, in order to answer our research question we would like to propose an analysis of three separate indices:

Level of Usage Axis – The first index and the most basic is the axis measuring open source usage. This axis ranges from total non‐use of open source code to “as is” use of open source code, and finally to “professional use” where the code is edited, modified and adapted. This axis naturally shows whether open source code is used at all in the organization, and it reflects the quality of the usage – whether the organization adopts open source code “as is,” in other words “basic” use or whether the organization engages in further development and adaptation of the existing code, that is “professional” use. 

“Community" Axis – The second dimension is an axis relating to the community of developers themselves. This axis ranges from merely using open source code to the publication and distribution of original code that the developers have written themselves. In the middle we can find developers who publish changes and the adaptations that they have made to existing code, a kind of “returning the favor.” This axis shows how much the developer organization considers itself a part of a wider community of open source developers. Firstly, this axis indicates whether open source is merely used ‐ that is use of an asset that was produced by a community of developers without providing anything in return. Further along the axis, the level of cooperation between the organization and the community of developers grows. At the midpoint, the organization returns the changes it has made to existing code to the community, and at the top end of the scale, the organization contributes original code to the community. The contribution of original code to the community of developers, which involves receiving feedback and criticism, is an important indicator of the level of effective adoption of open source code. An organization that has deeply internalized the advantages of the open code approach will not hesitate to present the code that they have developed for review and enhancement by the developer community.

The Institutional Axis – The third dimension and the most significant is the institutional directive axis. This ranges from the implementation levels to the senior management level, including the heads of the organization. This axis shows the degree to which the use of open source derives from an initiative of the junior ranks, who understand at the practical level the advantages of open source, or up to the establishment, as reflected in its formal decisions and management work plans, which might pragmatically promote the use of open source. Consequently, this axis reflects the degree to which open source is an important factor in the organization’s decision making. This axis is of course the engine for promoting the other axes which reflect its importance, especially in security organizations which have a clear hierarchical culture and tendency to insularity due to security concerns.

In the following section we will present research based on the three axes described above, covering the American defense establishment, the Israeli defense establishment and an open source‐oriented commercial company. 

Before we continue with the article, I would like to emphasize the importance of the institutional directive axis and the reasons that it is, to my understanding, the core of the analysis. In order to do so I will present a number of official analyses which were conducted at the governmental level in Israel and globally: In 2002 legislation was proposed with regard to the use of open source code by former Member of Knesset (MK) Nechama Ronen. The proposal included an amendment to the Mandatory Tenders Law (Amendment – Acquisition of Open Source Code Software), 2002 which proposed to determine that “The state, government corporations and other public bodies as determined by the Finance Minister will not contract to acquire software, unless it was developed by the open source model,” aside from special cases in which the Finance Minister approves an exception. The preamble to the legislation stated, among other things, that:

As a part of our understanding of the software market and within the framework of the free economy, the use of open source code should be encouraged. This code enables immediate solutions to failures and in this way leads to development, upgrading and expansion of different software applications for the benefit of all users, without artificial boundaries and obstacles by bodies that try to perpetuate themselves through their control of source code.”

The preamble continued:

It should be noted that this amendment is a response to general trends in different countries such as the United States (California), Finland, France, Germany, Thailand, Taiwan and China which have all begun legislative processes to encourages public institutions and governments to use open source code.”

The proposal was scheduled for a first reading in the Knesset, but the legislative process on the issue was aborted.[29]

The British government in April 2012 published another document under the title “All about Open Source.” The document noted that the low level of use of open source mainly derives from a lack of understanding of its advantages and related to a “risk adverse” organizational culture. The document also noted that the low level of use is supplemented by a mistaken perception with regard to information security in open source and its accompanying services. The challenge, according to the British government, is to offer both proprietary solutions and open source solutions, and to analyze and compare them in an impartial manner according to their quality.[30]

A Comparative Analysis – Measuring the Adoption of Open Source in Different Organizations

A Commercial Company with a High Level of Orientation to Open Source

In the commercial sector we find widespread adoption of open source. As noted, there are many advantages for organizations that use open source, from more efficient processes to reduced budgets. Accordingly, a commercial company that wishes to maximize its profits and has a high level of orientation to open source, should be represented on the three axes as follows:

With regard to the level of use axis, the company would mainly use open source. This reduces expensive development time, enabling the company to divert resources to other uses, and can even improve the quality of the product. The company would use open source code in an orderly and formal manner, both at a “basic” level, with no changes to the existing code, and at a “professional” level where changes are made to the code to adapt it to specific needs.

As noted above, with regard to the community axis, the company would make widespread use of open source and would encourage its developers to distribute the open source code that they have adapted as well as their original code. This would be done, as mentioned, out of an understanding that the publication of the code to many developers contributes to improving it, which results in a higher quality product without any additional financial outlays. In this way, the company can also improve the performance of its employees, given that they would understand that their work would be widely publicized, and they would therefore be likely to invest more in its development.

With regard to the institutional directives axis, the company would exhibit signs of the adoption of open source at all management levels, from the developer to senior management. Also, the company would change its business model, in light of the adoption of open source, in order to enjoy its many benefits. It would be noted that other companies in the market are also working to adopt open code, leading management to work to adopt it faster in order to retain the companies standing in a competitive market. From the company’s perspective, the full adoption of open source code by the senior management enables its adoption on both the usage and community axes.

The American Defense Establishment

The American defense establishment went through a process of integrating open source into its development processes, and today it has adopted open source to a degree that resembles the business sector. However, there are a number of differences, including the emphasis placed on compartmentalization between different projects – compartmentalization from the global internet as well as compartmentalization between developers who work on closed sites only accessible to authorized users.

The US defense establishment was exposed to the advantages of open source at a relatively early stage. Research points to initial adoption of open source in the US Armed Forces and the Defense Department (DoD) from 2003 with its prevalence increasing every year. At first the process of adopting open source took place in a pinpointed manner in different places at a low military level. However, in light of the success of several projects, the DoD saw the advantages and created a process for the formal integration of open source into the system.[31] Recently the White House even published a draft policy paper regarding the development of open source in all federal agencies, a paper whose purpose was to increase the openness of the federal government to the use of apps and to reduce costs in the field.[32]

During the above process, the regulations for software procurement were changed and different technological forums were established. The DoD produced a booklet which included guidelines, in order to promote the adoption of open source, in which it was written for example:

In almost all cases, Open Source Software (OSS) meets the definition of “commercial computer software” and shall be given appropriate statutory preference in accordance with United States Code [ ] Executive agencies, including the Department of Defense, are required to conduct market research when preparing for the procurement of property or services [ ] Market research for software should include OSS when it may meet mission needs.[33]

For the perspective of the developers we can refer to the remarks of Elizabeth A. McGrath, Deputy Chief Management Officer at the DoD to the House Armed Services Committee in 2010:

Our current approach to implementing IT systems takes too long, costs too much, and often fails to deliver the performance improvements we seek. On average, it takes 81 months in DoD from when an IT program is first funded, to when it is fielded. Given the rapid state of improvement in the IT field, this means that we are delivering systems that are outdated before we ever turn them on.[34]

The development of open source code in the DoD ranges from the use of a private cloud as a development platform to full public access. The public cloud that is used is called GitHub[35] and it requires access to and a global internet address. In addition, two models exist in the public cloud: The first includes opening the code to the whole world, without charge; while the second model includes private storage areas, with authorization granted only by the project manager. That is, the code is open to a specific group only or for a fee. On the other hand, the DoD’s private cloud requires a connection to the internet, but its address is not accessible to all. Access to this cloud is available only to authorized users from the DoD and requires identification. This cloud also offers two models: In the first, the development allows all users of the cloud access to the code. In this way the model allows a broad development environment which is both protected and free; the second model includes private development by groups within the cloud, and access to the code depends on authorization by the project managers or for a fee.[36]

A forum authorized by the DoD, the Mill‐OSS (Military Open Source Software) was founded in 2003. The forum’s objectives are to create and maintain an active community of developers, civilian and military, who use, improve and share open source software within the DoD’s framework. Most of the members of the community work directly for the DoD or as contractors and see their work as supporting the United States combat efforts.[37]

Another model is the forge.mil site which requires authorization on the basis of a social security no. and security classification. This site is unique in that you can find military code on a regular internet server. Furthermore, in order to strengthen this community, the DoD created business incentives and decided that any company that uploads code to forge.mil can be certified as an authorized contractor of the DoD without going through the regular long and bureaucratic procurement process.[38]

Returning to our measurement scales for the level of adoption of open source in the American defense establishment, we can say that with regard to the usage axis, we can see that there is extensive use of open source in the American defense establishment. The use of open source is organized and formal, and it takes place at both the “basic” level, with no changes being made to the code, and at the “professional” level, where the code is adapted to the different needs of the armed forces.

With regard to the community axis, there is cooperation between the community of developers who are developing open source code for the armed forces, with military and civilian developers working together on different approved platforms. On the one hand, it seems that there is widespread cooperation and full transparency of the code during development, but on the other hand, we are talking about limited cooperation, with most of the development being done on relatively closed platforms which require pre‐authorization for use. Furthermore, there are projects which are compartmentalized within closed development environments from the outset. This suggests that the American defense establishment is advanced in the field of community but has not yet utilized the full capabilities. It would seem that the American defense establishment is well aware of the benefits of the open source world and is seeking to maximize them, but at the same time, is restraining itself and engaging in controlled and managed cooperation for cyber defense and information security reasons.

With regard to the institutional directives axis, we can see deep internalization of the value of open source, which had been widely adopted at the senior level. As noted, open source was initially seen only at the level of the developers, but as understanding of its inherent advantages spread, it was disseminated among the entire defense establishment. Additionally, open source influenced force design processes in the American army when procurement and development processes were changed.

The Israeli Defense Establishment and Open Source

The Israeli defense establishment, for the purposes of this article, consists of the Defense Ministry, the IDF, defense industry companies (Israel Aerospace Industries, Israel Military Industries, Elbit and Rafael) and MAFAT. On this basis we will analyze the defense establishment according to each of its components.

The Defense Industry

Israel defense companies adopted open source for their work in a very slow and complicated fashion due to their organizational cultures. These are large organizations with many bureaucratic processes, which makes any type of change a challenge. Second, due to the classified nature of their work, their developers do not have constant access to the internet, as specified above. Additionally, in order to protect the security of their software, information security officers sometimes delay or prevent the adoption of open source. The professional experience of many of the workers in the defense industry does not include the use of open source, which makes it somewhat more difficult to change their work habits. That said, it should be noted that a steering committee on the use of open source in the industry exists, with members from Israel Aerospace Industries (ELTA), Elbit, Rafael and MAFAT. These bodies share unclassified information in order to benefit from the large advantages of building processes to use and adapt opens source software. The committee discusses, among other things, issues that relate to the licensing of software, intellectual property, information security and product support.[39]

Moreover, the defense industries have experience in cooperating with regard to the Wassenaar Arrangement on Export Controls for Conventional Arms and Dual‐Use Goods and Technologies. Member countries are committed to reporting the sale of certain items, among them software, including their intended end use and the end user. Naturally, this reporting duty sometimes creates difficulties and sometimes even prevents Israel defense industry companies from purchasing and upgrading software. In these cases, the use of open source can be a solution to this problem as one of the basic principles of open source is that it can be shared freely with no duty to report.[40] In Israel, as in the United States, forums and NGOs were created to promote the use of open source. In the military context, the forum Mill‐OSS.il exists. The membership of these forums include representatives of the different corps in the IDF and employees of the defense contractors, among others. The forums organize a number of conferences each year for the defense establishment in order to promote the use of open code among members.[41]

Within Israel Aerospace Industries (ELTA) there is widespread use of open source code in the place of proprietary code. In addition, as a part of its IT procurement processes, open source solutions are also being considered. Open source is now used at all stages of development.[42]

Rafael also uses operating systems and development environments based on open source. The operating systems were adapted to the needs of different projects and are used on several systems. In addition, the company claims that its level of knowledge on the subject has grown and new capabilities are being added to the company.[43]

Similarly to the other companies, Elbit also makes controlled use of open source. The company is even working to develop a clear policy regarding open source, while emphasizing the need for organized work practices and clear definitions of standards for licensing, supervision and oversight. Elbit, in coordination with other defense industry bodies, supports the NGO “Hamakor” (lit the source) which promotes the use of open source in Israel. The NGO organizes annual conferences on open source for the defense industries.[44]

IDF

While the defense companies took steps forward to adopt open source, the IDF began its journey into this world relatively late.[45]

The adoption of open source in the IDF, as with the early stages in the American defense establishment, began from below.[46] Young developers came with knowledge and prior experience of the use of open source code, and they are the primary cause of its entry into the armed forces. In 2013, when Brig. Gen. Daniel Bren took over as the Commander of the IDF's Lotem Division (The Technological Unit for Operational IT in the C4I Directorate), a deliberate effort was made to inculcate a development culture based on the Agile methodology (which uses open source) within the C4I Directorate and later within the rest of the IDF. As in the other cases, the younger generation, at the captain rank, were the first to push for the adoption of the open source methodology. The mid-level officers — lieutenant colonels — were characterized by a lack of willingness, and they delayed the change process.[47] The obstruction by mid-level officers pushed the Commander of Lotem to formally create a forum of "Young Turks" made up of programmers at the rank of captain which led to the development of processes for development using the Agile philosophy.[48]

The background to the conceptual revolution in Lotem was the clear and conscious understanding of the importance of adaptation to the software world. During Brig. Gen. Bren’s remarks at the Third International Conference on IT organized by the Israel Defense company, he argued that not only is the IDF facing many challenges, but the essence of these challenges is in their speed and intensity. In the past, the rate of change was slower, and was suited to five year plans during which systems could be developed. However, the rate of change today is dramatic and is even faster than the time the IDF takes to change in response. Today, the time needed to develop a system from the presentation of user requirements to integration is between a year and a half to two years. However, integration of a system after two years is not relevant. Therefore, he argued, a change needed to be made to work in a more efficient, correct and relevant manner. The change should include among other items, adoption and inclusion, which constitute the central pillar that enables the business world to remain relevant and to generate a competitive advantage. The term PFE (Proudly Found Elsewhere) is the opposite of NIH (Not Invented Here), meaning that if an off‐the‐shelf solution exists, it should be adopted if suitable. The IDF is assessed on its speed and relevance and not just on the quality of its development.[49]

Brig. Gen. Bren added that the resource that can most facilitate this change is the human resource, but one must pay attention to the gaps between generations. The way that the senior command thinks is different from the way young soldiers think. On the one hand there is an advantage to experience and maturity of the older generation and on the other hand, there are many advantages to the networked and technological understanding of the young generation.[50] In an interview, Bren elaborated and said that the key difficulty, at least in the unit he commands, is the intransigent middle command level.[51]

Matching Brig. Gen. Bren’s remarks, the C4I Directorate has made great efforts and engaged in considerable staff work whose objective was formal direction, creating standards and encouraging a transition to ‘open source’ processes.[52] Furthermore, efforts were made to create an infrastructure for the open source community on the military intranet. Despite all of these efforts, most of the interviewees for this research were not familiar with these efforts and were not partners to the development of original code on this joint infrastructure. Even in the interview with the Commander of the Lotem unit, Bren noted that at the combined‐arms IDF‐wide level, the IDF still would “receive a mark of 6” for the level of adaption to the world of open source development. It turns out that the difficulty in implementation is connected to the C4I Directorate’s difficulty in giving active direction including policy on the one hand, and the lack of a joint combined‐arms environment on the other.[53]

We can say that the adoption and use of open source is widespread among young developers in the IDF and enjoys the support and direction of the senior command, at least in the C4I Directorate. Indeed significant work has been done in the field in recent years,[54] and even a number of hackathons have taken place.[55] With regard to cooperation with writing code, we can see several examples similar in form to GitHub, which are used internally in the Intelligence Directorate, the C4I Corps and the air force among others. However, with regard to cooperation between the community of civilian developers and the army, the field is only at a very early stage of development.

In summary, the IDF is on the way to internalization of the open source world. Training of developers by the C4I Directorate is adding ever expanding circles of IDF personnel to the open source community within the IDF.[56] Internal problems within the IDF with regard to accepting the C4I Directorate’s policy by other bodies within the IDF and the issue of joint infrastructure are still significant obstacles in the process.

MAFAT

MAFAT (the Administration for the Development of Weapons and Technological Infrastructure) is responsible for the connection between the IDF and the Israeli defense industry.

MAFAT, from my perspective, is encouraging the adoption of open source within the defense establishment. It decided to promote software which can serve several users, with each user investing only in the section that is unique to them and not in the infrastructure layers.[57] Similarly, MAFAT authorizes procurement plans which use open source. However, unlike the practice in the US DoD, MAFAT strictly adheres to Regulation 10/1 for the procurement of armaments (a J5/IDF Policy and Plans Directorate Regulation) which does not refer to software at all, let alone open source.[58] It follows that while MAFAT contributes to the adoption of open source in the defense establishment, it does so passively.[59]

While trying to trace the reasons for the delay in developing an official active policy within MAFAT, several of the interviewees for this research raised a number of conjectures and explanations. One of them claimed that the reason that MAFAT is avoiding promoting the issue is connected to the organizational culture and bureaucracy. With regard to organizational culture, MAFAT apparently does not see software as a key element in measuring the success of its people.[60]

With regard to the bureaucratic reason, which is pertinent across the defense establishment, information security is still the main bureaucratic obstacle. Despite the arguments of experts who maintain that there is no such thing as “classified code,” due to the separation between code and classified information and using the analogy of code as a table and the information as a computer, the information security officials still tend to see “openness” as a threat. The great emphasis placed on information security reflects, as argued by some of the interviewees, a risk averse culture which prevents the weighing of the expected advantages of open source and exaggerates the weight of the risks.[61]

The lack of a clear official policy becomes apparent when taking into account approaches made by actors in the defense industries calling for the promotion of open source and in light of the ongoing delays in doing so, according to several interviewees.[62]

The unique place of MAFAT as an intermediary between the military world and the industrial‐technological world increases the significance of the delay in formulating an official policy. While we cannot absolve the IDF of full responsibility for its actions, indeed the IDF “connects” with the external technological world primarily through MAFAT. That is to say, this body is meant to mediate the most up to date technological tidings into the army, and in this context the army is to some extent dependent on it. This dependence is strengthened due to the fact that the army is largely cut off from the global civilian internet. However, in the context of open source, the update from the defense industry arrived late. The reason lies in the fact that the Israeli defense companies and large corporations, such as Microsoft, were themselves behind the rest of the world, and they, therefore, didn’t have an interest to “tell the army” about the developing phenomenon.[63] As noted, it would seem that MAFAT itself has not yet formulated a clear and consistent policy on the issue, and therefore cannot mediate the gap which was created with the army.

To summarize this section, we can say that with regard to the Israeli defense establishment on our scale, in terms of the usage axis, we can see that open source is used by the Israeli defense establishment. The use of open source in the IDF and defense establishment is widespread and is even expanding. We can even say that there is an informal atmosphere of encouraging this trend and especially within the different internal frameworks – within specific units, within clear projects or specific communities of common interest in the defense industry. However, “open source” is not regulated and formally accepted, and in most cases is only used by developers in its “basic” form, with no changes made to existing code, and only sometimes “professionally” where changes are made to the code and it is adapted to the different needs of the army. With regard to the defense industry, we can see an increase in the level of usage of open source in the most recent period. However, without clear policy directives from the defense establishment, it is used only in a limited fashion.

With regard to the community axis, there is very limited sharing among the community of open source developers for use by the army, where army personnel are aided by civilian personnel to develop code. Nevertheless, there is a certain level of internal sharing, within each corps, of code between different developers. Regarding the sharing of IDF code with the civilian community, the process is largely non‐existent today. This is true, as noted, for the defense industry as well – they do not share code among themselves and do not publish code for the community of civilian developers. It is clear that the Israeli defense establishment is behind the times in the community field and is far from maximizing all of its advantages.

With regard to the institutional directives axis, we can only see a limited internalization of the benefits of open source. The existing official attitude is limited and only a few are familiar with it. Among the IDF’s command backbone there are a few commanders that clearly deal with open source, such as the Commander of the Lotem unit. Within the primary practices used to manage projects in the IDF and MAFAT, there was little clear expression of a policy on the topic.

Thanks to open source, development personnel in the IDF reached impressive achievements, but as opposed to the practice in the United States, this did not influence force design processes and did not lead to changes in organizational processes. Consequently, software procurement processes were left unchanged and were not updated. It should be noted that personnel in the IDF command backbone and MAFAT argue that there is support for open source, but it is only passive support in the form of authorizations for specific projects, and has not included a cross organizational comprehensive statement of purpose. That being the case, in the Israeli defense establishment open source has still not garnered clear official organizational standing nor a corresponding implementation policy.

Conclusion

The technical wave of transition to open source cannot be stopped forever. When looking at the business sector for comparison we can say that companies that try and stop the flow will collapse. The army, which lacks business learning mechanisms, needs to procure critical self‐awareness, to understand the revolution, and to engage in change.[64] Indeed, as we found, the IDF C4I Directorate recognized this need and has begun a process of assimilation, principally through a revolution “from below.”

With regard to the range of adoption of open source, we can now see that the Israeli defense establishment is late to the game, relatively, while the US Armed Forces, at least according to official publications, and the business sector are determinedly overtaking it.

This suggests that the Israeli defense establishment, including the IDF, MAFAT and the Israeli defense industry, must change in order to improve their position, make their work more efficient and maximize their capabilities.

For the level of usage axis, on the one hand the IDF seemingly has no reason to turn to open source for developing software, given that it understands its needs in the best way possible and can meet them. On the other hand, the IDF does not really have the capability to ignore this phenomenon, given that it only develops end user applications and bases itself, also at the level of infrastructure development, on open source. Accordingly, despite the army’s level of understanding of the operational needs and internal development capabilities, it cannot develop everything from scratch, and in practice has not developed completely by itself for a number of years. Accordingly, the use of open source should continue at the developer level and it should even be encouraged by creating openness to the issue and building suitable technical conditions, such as connection to the global internet.

For the community axis, the army can demand from the defense industry that they use open source. It can demand that the defense industry companies base their work on existing open source code, and it can also demand that they release the code that was developed for a specific project, to the other defense companies. Steps such as these would enable the development of better quality code for the reasons outlined above. In addition, the army could establish an IDF GitHub. Just as app stores exists today and consumers can choose what apps to use, a code store could be opened and developers could choose the code they wish to use. This is, as noted, in addition to open source’s role in setting the bar for quality code. More important – if quality code becomes the standard, there will be demand for all developed applications to be based on similar algorithms. In this way the establishment organizations will be able to cooperate in a structured fashion. This will be a major contribution to the never ending efforts to create a genuine joint combined arms digital work environment within the IDF.

As discussed, the changes highlighted above are dependent and influenced by the organizational direction axis.

For the organizational direction axis, it would be appropriate for the IDF to fully adopt the policy that was recently developed, to distribute and integrate it, and to ensure that it is backed up by an appropriate networked infrastructure. The Israeli defense establishment, in its widest definition – including MAFAT and the defense industry – needs to help the IDF formulate this policy and implement the required transformation.

In order to best adopt open source, it could be re‐ conceptualized as a standard. Open source is of best quality when many people use it. Therefore, open source can be defined as a specific quality bar for future projects. In this way the IDF will find itself in a supervisory role with regard to the defense industry and will require them to achieve appropriate development standards. The adoption of open source can influence cost efficiency calculations when making procurement contracts.

Today there is a preference for granting procurement contracts to large and theoretically stable companies, due to a fear of losing capabilities or services in the future. However, opening the source code would enable the reduction of the dependence of the army on one proprietary company, and as a result lead to efficiency processes and considerable savings. Indeed open source can be distributed to other companies or for internal development, for future development or for support services, and therefore the inbuilt preference for larger companies over others, the customary preference today, will become less relevant and less worthwhile.

Among the required changes is a clear response to the obstacles. With regard to the need for support, from Brig. Gen. Bren’s perspective, an army branch that opens a service and places it on the IDF cloud will need to also support users in the other branches, which would constitute a paradigmatic change for the IDF. Furthermore, the old approach whereby software is naturally accompanied by a guarantee and support needs to change. Open source is usually not bought, and therefore an internal organizational support capability needs to be created for the code in order to enjoy its advantages. Moreover, there are paid models for code, for support, for complementary products etc. The use of systems that are open between the army’s different branches should be promoted. With regard to information security, Brig. Gen. Bren argues that avoiding implementing technology which is critical to solving operational problems due to the fear of dealing with the cyber defense problem – could lead to losing the war. Also, the trick is to bring advanced technologies and to create for the software a cyber‐defense architecture.[65] Nonetheless, the information security issue demands a comprehensive institutional and professional response, including aspects of personal security for those serving in the defense establishment.[66]

In summary, we can say that our defense establishment, in relation to the United States, is late in formally adopting open source, at least with regard to what can be understood from its official policy. The establishment sees the required achievement for the adoption of open source in accord with the horizontal axis, “level of usage” alone. This, as far as it is concerned, means it is a part of the global current. Nonetheless, as had been argued here, the Israeli defense establishment is missing an enormous spectrum which is realized in the American defense establishment.

There is something to aspire to with regard to both open source adoption by the senior levels across the defense establishment and the external publication of code by the community in order to improve it.

[1] Ms. Carmel Or is a student in the Honors track in the School of Government and Diplomacy at the Interdisciplinary Center, Herzliya. This research is partly based on interviews conducted with position holders in the IDF and the defense establishment whose names are not approved for publication. The research was read by relevant position holders and found to have a solid basis

[2] Linus's Law, by Eric S. Raymond quoted from the website: http://www.mil‐ oss.org/resources/articles‐papers‐presentations

[3] Goldschmidt R., (2014), The Use of Information Technology Systems based Open Source in Government Ministries, Jerusalem, Knesset Research and Information Center.

[4]  Ibid

[5]  Ibid

[6] Stallman Richard. (19.6. 2007). "Why "Free Software" is better than "OpenSource".Philosophy of the GNU Project. Free Software Foundation, https://www.gnu.org/philosophy/free‐software‐for‐freedom.en.html

[7] Verts William, (13.1.2008). "Open source software". World Book Online Reference Center, http://www.worldbookonline.com:80/wb/Article?id=ar751706

[8] Murphy, David (15.8.2010). "Survey: 98 Percent of Companies Use Open‐Source, 29 Percent Contribute Back". News & Opinion. PCMag.com. Retrieved 22.11.2015, http://www.pcmag.com/article2/0,2817,2367829,00.asp

[9] Seltzer, Larry (2004‐05‐04)."Is Open‐Source Really Safer?" PCMag.com. Retrieved 22.11.2015, http://www.pcmag.com/article2/0,2817,1566726,00.asp

[10] Michelle Delio. "Linux: Fewer Bugs Than Rivals," Wired.com. Retrieved 22.11.2015,http://archive.wired.com/software/coolapps/news/2004/12/66022

[11] Raymond Eric. S., (1999). The Cathedral and the Bazaar, http://books.google.com/books?id=F6qgFtLwpJgC&pg=PA30#v=onepage&f=false

[12] Srinarayan, Sharma; Sugumaran, Vijayan; Rajagopalan, Balaji (2002)."A framework for creating hybrid‐open source software communities". Info Systems Journal 12: 7–25, http://www.cin.ufpe.br/~in953/lectures/papers/ISJAFrameworkForCreatingHybrid‐OpenSourceSoftwareCommunities.pdf

[13] Hal Plotkin, (December 1998). "What (and Why) you should know about open‐source software". Harvard Management Update, pp. 8–9.

[14] Ioannis, Stamelos; Angelis, Lefteris; Oikonomou, Apostolos; Georgios L. Bleris (2002)."Code Quality Analysis in Open Source Software Development."Info System Journal 12: 43–Retrieved 22.11.2015.

[15] Ibid

[16] Haniya, N. Interview (2015)

[17] Source No. 1: Interview with an actor in the Intelligence Directorate: 29.12.15.

[18] Ibid

[19] Ibid

[20] Source No. 2: Interview with an actor in the Israeli defense establishment: 1.12.15.

[21] Source No. 1: Interview with an actor in the Intelligence Directorate: 29.12.15.

[22] Ibid

[23] http://www.mil‐oss.org Downloaded on 17.1.16.

[24] Ibid.

[25] Ibid.

[26] Ibid.

[27] DOD. (16.10.2009) Available at http://www.mil‐oss.org/resources/us‐ dod_policy‐memo_clarifying‐guidance‐regarding‐oss_16oct2009.pdf

[28] Source No. 2: Interview with an actor in the Israeli defense establishment: 1.12.15.

[29] R. Goldschmidt. Op. cit.

[30] Ibid

[31] Source No 3: An interview with an actor in the Israeli defense establishment: 7.1.16.

[32] Ruchira Prasad (16.3.2016). "White House to share Custom Code with Open Source Community." Open Source, http://opensourceforu.com/2016/03/white‐ house‐to‐share‐custom‐code‐with‐open‐source‐community/

[33] DOD, 2009, op. cit. To ensure efficiency and reduce the potential for waste, the Federal Government has enacted legislation directing its agencies exercise a preference for commercial and non developmental items (NDI) "to the maximum extent practicable"

[34] Statement by Ms. Elizabeth A. McGrath Deputy Chief Management Officer before the House Armed Services Committee, 2010

[35] GitHub is a service for storing code on the internet for open source software projects, which includes the version management application Git. In 2011 it was recognized as the most popular storage service for open source code.

[36] Source No 3: An interview with an actor in the Israeli defense establishment. 7.1.16.

[37] http://www.mil‐oss.org Op. cit.

[38] Source No 3: An interview with an actor in the Israeli defense establishment: 7.1.16.

[39] R. Goldschmidt. Op. cit.

[40] Source No 3: An interview with an actor in the Israeli defense establishment: 7.1.16; Source No 2: An interview with an actor in the Israeli defense establishment: 1.12.15.

[41] Source No 3: An interview with an actor in the Israeli defense establishment: 7.1.16.

[42] R. Goldschmidt. Op. cit.

[43] Ibid.

[44] Ibid.

[45] Source No. 3: An interview with an actor in the Israeli defense establishment: 7.1.16.

[46] Source No. 7: Interview with Brig. Gen. Daniel Bren, then Head of the Lotem Division

[47] Ibid

[48] C4I Directorate, The Technological Unit for Operational IT (Lotem Division), “Summary of the Commander of Lotem’s Remarks During the Presentation of the Output of the “Young Turks” team”, internal IDF document.

[49] Bren, D., Address to the Third International Conference on IT organized by the Israel Defense company, 9.11.2015. Accessed via youtube at: https://www.youtube.com/watch?v=5Hkhze3YUvw

[50] Ibid

[51] Source No. 7: Interview with Brig. Gen. Daniel Bren, then Head of the Lotem Division

[52] Lotem, Policy on Adopting Open Source in the IDF, internal draft, 2016. Also: IDF Technological Standards Committee No. 22 – Summary of remarks by Lotem Commander, 8.7.14.

[53] Source No. 6: An interview with an actor in the C4I Directorate: 6.4.16.

[54] See Yossi Hatoni (6.12.2015) “Open Source is Even More Relevant to the Needs of the IDF”, PC, People and Computers, http://www.pc.co.il/it‐news/201133 (Hebrew)

[55] See LTC Ori article in this volume.

[56] Usage data for the C4I Directorate’s Yohanan site shows a gradual rise in the number of users from a few hundred in 2012 to thousands by March 2013.

[57] Source No. 3: An interview with an actor in the Israeli defense establishment: 7.1.16.

[58] IDF J5 Regulation 10/1 for the procurement of armaments 59 Ibid

[60] Source No. 3: An interview with an actor in the Israeli defense establishment: 7.1.16.

[61] Ibid

[62] Ibid

[63] Source No. 5: An interview with an actor in the Intelligence Directorate: 14.1.16.; Source No. 4: An interview with an actor in the Intelligence Directorate: 14.1.16.

[64] Source No. 2: An interview with an actor in the Israeli defense establishment: 1.12.15.

[65] Bren, 2015, Op. cit.

[66] In order to be a member of a development community on the internet, you have to be identified as a user and build a positive reputation over time (Source No. 6).​

Bibliography Hebrew Sources