There has been a subtle but important change that has occurred in open source collaboration over the past couple years. This is a change that is altering the very nature of open source, has enabled projects to innovate faster while dramatically growing in size and scale, guaranteeing the ability to deliver optimal results.
Technology companies are motivated to innovate faster and cut costs in the face of major technology advancements. In order to remain competitive and to excel in the market, they increasingly seek out software development approaches that leverage the open source community.
Companies are joining together across industries to share development resources and build common open source code foundations on which they can differentiate their own products and services. This collaborative approach is transforming industries like cloud computing and datacenters, to automotive and mobile computing, creating the next generation of technologies.
This change is somewhat akin to Pandora’s box. Now that the lid is open and the compelling arguments for collaboration are being demonstrated; the lid will never close. Instead open source collaboration will continue to grow and expand as even more companies opt to get involved.
A major effect of this growth and change will be seen in the number of new projects created and how a wide range of corporations and organizations will fund these ventures. Also as the number of participants grows, we will see improved features. The net effect is that the rate of innovation increases as well as the size of the code base and the complexity of the software.
However there is another interesting development occurring. Open source projects are learning to leverage and build upon each other, which creates inter-project dependencies. While open source projects are very good at creating communication channels and project structure focused on developing their software, creating optimal channels for sharing between projects isn't as well established. As dependencies grow the need for Open Source projects to work together increases as well.
Open source participants and proponents often talk about the nature of open source being about scratching their own itch. What that implies is that for a vendor to get the features they need, there is an incentive for companies to join and contribute.
Typically companies and organizations interested in combining technologies assign engineers to work on both projects. By participating in both the engineers are able to communicate the feature and technology needs within the projects. While this has achieved success, the increase in project size and rate of development can make it difficult to keep up with multiple projects. With feature prioritization only occurring at the engineering level it can questionably alter the proper strategic direction of the project.
Open Source projects need to begin to liaison with each other at the leadership level. Project leaders need to discuss and define the overall strategy and vision. These discussions need to have a long-term effect beyond the immediate needs for technical features.
Here are some things to consider when collaborating on a project:
- Project dependencies – This includes technologies that each depend upon one another in order to be successful.
- What these organizations signify to each other in terms of market acceptance, awareness and growth.
- What the relationship should be between organizations and what is the attainability of an optimal relationship.
- Gaps in technology and project structure.
- Steps that may help ensure that strategic directions align.
- Steps to orchestrate inter-organization coordination.
- How to measure success – Have a clear understanding of what the “polished outcome” should be.
Working together is what open source is all about. It's in our nature, our strength and is our future. Coordinating efforts with related projects and technologies creates an exciting future where open source will meet new technology challenges that will result in industry transformation and innovation.
This article is published as part of the IDG Contributor Network. Want to Join?