- Software Development
- How Open Source Communities Power Docker and the Container Ecosystem – InApps Technology 2022
How Open Source Communities Power Docker and the Container Ecosystem – InApps Technology is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn How Open Source Communities Power Docker and the Container Ecosystem – InApps Technology in today’s post !
Read more about How Open Source Communities Power Docker and the Container Ecosystem – InApps Technology at Wikipedia
You can find content about How Open Source Communities Power Docker and the Container Ecosystem – InApps Technology from the Wikipedia website
The economics of proprietary technologies become less viable as systems grow increasingly complex, requiring constant adaptation, changes and updates. Increasingly, proprietary software and systems are less robust than their open source equivalents. The Docker and container ecosystem is representative of this new market reality.
As many of the container-related projects move into enterprise production uses, a number of open source communities are being influenced by vendors such as IBM, Intel and Google, as well as by large customers such as Goldman Sachs, which are creating and backing powerful new open source foundations. These foundations reflect a new generation of commercial-style open source communities, lead by professional organizations such as the Linux Foundation, which now runs the Open Container Initiative, the Cloud Native Computing Foundation and the Cloud Foundry Foundation.
Created in June 2015, the Open Container Initiative (OCI) is an open specification and runtime for containers. OCI provides the end user with a view into how the overall market is evolving, the technical differentiations of the providers, and a context for looking at the past and future of an application-centric infrastructure.
The roots of OCI can be traced back to Docker and the development of its libcontainer technology. The libcontainer format enabled Docker to evolve in a design direction that was less centered around Linux and more around Docker. Specifically, it undocked itself from systemd, the critical launch component of the Linux kernel. As LXC was designed, systemd was the daemon responsible for launching and maintaining container processes in a manner that the operating system could manage.
As part of OCI, Docker donated libcontainer to the initiative. The overall goal is to ensure compatibility between systems and the code that utilizes containers, thus freeing the next generation of engineers to focus on innovating higher up the value chain.
With that background, the lines defining the companies become better understood and are exemplified in the data analysis of OCI and the difference that it has with the still-emergent Cloud Native Computing Foundation (CNCF). The CNCF is the newest open source project, initiated by Google and joined by Cisco, Docker, IBM, Mesosphere, Joyent and a host of other companies in the ecosystem that are trying to standardize scheduling and orchestration capabilities.
By reviewing GitHub activity statistics, InApps Technology found significant activity and industry cooperation within the tight-knit group creating the specifications. For the actual underlying runtime code (runC), which was migrated from libcontainer, there has been robust participation.
For background, CoreOS last Fall announced rkt, the specification developed by CoreOS for its Rocket runtime system. At CoreOSFest this past spring, the company announced App Container (appc), its own open source project based upon the rkt technology. Google, VMware, Red Hat, Hybrid Cloud OS maker Apcera and a gathering coalition of industry partners backed appc.
CoreOs has funding from Google Ventures. Furthermore, the CoreOS technology integrates deeply with Kubernetes, Google’s open source container management platform. Google, for its part, is focusing on the recently announced Cloud Native Computing Foundation, which has an emphasis on container management.
Docker, without a doubt, competes with both CoreOS and Google. They also cooperate with each other, which reflects the nuances of this fast changing world of application development and management at scale, as there is really no one universal solution.
Specification and Who is Leading the Project
OCI’s initial technical leadership included representatives from Docker, Red Hat, CoreOS, Google, and an independent developer with a company called InfoSiftr. Now that the project has been operating for a few months, we can see who is actually involved with the development of specifications, which is where the real power lies in this project. We found that there have been 24 contributors to the opencontainers/specs repository, with the most involvement from Huawei, Docker, Red Hat, IBM, Fujitsu and CoreOS.
The companies with the most active in contributors to OCI spec are Huawei, Docker, Red Hat, IBM, Fujitsu and CoreOS.
It is noteworthy that the previous top three contributors to appc’s spec — CoreOS’s Jonathan Boulle and Brandon Philips and Red Hat’s Vincent Batts — are actively contributing to OCI’s specs. Without the support of these leaders, activity in the appc project has slowed down tremendously since OCI’s announcement.
As the specifications continue to mature, it is important to note how important their development is to keeping some companies involved. For example, CoreOS just released an updated version of rkt based on appc, yet in the future it plans on releasing the same runtime based on the OCI specification.
If OCI is to be successful, it will at a minimum need companies like CoreOS to use agreed upon standards that will allow it to continue developing its own runtime while at the same time ensuring interoperability with applications built for Dockerfiles. Interestingly, CoreOS is still hedging their bets on OCI’s success. While heavily involved with the specifications, no CoreOS employee has made a contribution to the runC repository.
Involvement With runC
While specifications are the core of what OCI is about, Docker’s donated libcontainer is the actual meat of what developers are currently using. The level of GitHub activity for runC has actually picked up as compared to the work done in libcontainer, with 24 percent of the contributions in the repository happening since libcontainer migrated to runC.
There has also been an uptick in new contributors since OCI was announced, with 29 of the 127 contributors joining in the last two months. However, it is noteworthy that most of the contributions have come from Docker and Red Hat employees. Absent from the list of contributing companies is CoreOS. It is also notable that Google accounted for only two contributions (0.5 percent of the total), as opposed to the 18 percent it accounted for in the original libcontainer repository.
The OCI members most contributing are Docker, Red Hat, Huawei and IBM.
Which OCI Members Are Contributing
Our final bit of analysis was to compare the companies contributing runC and the actual membership roster of the OCI. We found that half of OCI’s member companies still do not have an employee contributing to the project.
What does a lack of participation mean? Of course, a company can adopt or support standards without actually contributing to an open source project. If that is the case, then OCI will have accomplished at least part of its mission by creating a standard that everyone can build upon.
But it does speak to what becomes of open source projects that become larger organizations with participation from commercial technology providers. The gap widens. Large companies make up most of the contributions and the smaller providers represent a tiny percentage of the total.
Apcera, Cisco, CoreOS, Docker, IBM, Intel, Pivotal, Red Hat and VMware are sponsors of InApps Technology.
InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.