In the time that I have spent with OpenLogic, I have worked with companies across many industries, and with companies ranging from a handful of developers to thousands of developers. One thing they have in common is that they typically have some type of open source policy, some far more developed than others.
“Be a Baker, not an Eater”
One of the benefits of using community versions of open source software is the ability to change and modify the source code and contribute (or commit) the new functionality back to the community. Acceptance of modified code contributions by the community will hopefully make the software perform better and become more secure. For the individual coder working with open source as a personal interest, a hobby, a learning experience, or even as part of a formal education this flexibility to modify and contribute to the project provides the freedom to explore possibilities on the bleeding edge of major Internet technologies. For the developer, engineer, enterprise architect, or system administrator working on a project for an employer, the freedom still exists. However due to various business concerns, the modifications and contributions should be managed carefully. For the later category of open source software users, today’s blog article will cover a few basic guidelines to consider when contributing open source code modifications back to the open source software project.
Many software development teams use external components in their projects, libraries, or tools provided by commercial vendors or open source communities. However, as anyone who has ever had to scramble after a vendor has gone out of business can tell you, these external dependencies are not without risk. Software companies can fail, products can be discontinued and open source projects can stagnate. Components that aren’t being maintained or security risks that aren’t being addressed can put your project in a difficult situation.
In my last post, I discussed where we came from and where we are now in regards to knowledge and understanding of open source software and licenses. I talked about how, not too long ago, there seemed to be a fair amount of denial when it came to the use of open source software in the enterprise. Today, open source software has garnered enough attention that the term "open source" is found far outside the software world. Yet, misconceptions and misunderstandings prevail. Why? How did we get here? And how do we get to the point where there is accurate and consistent knowledge around FOSS? More specifically, how do we get to a point where FOSS use in the enterprise incorporates a thorough and appropriate understanding that backs a FOSS policy that is tailored to the realities and practicalities of that particular business?
At the Linux Foundation Collaboration Summit in San Francisco in mid-April, I gave a talk titled, "FOSS Knowledge: A little does NOT always go a long way." The title was supposed to be a bit eye-catching; the subject-matter, hopefully thought-provoking. I've attended my share of open source software-related events and often the topics covered in the legal or business tracks relate to trends, information, tools, and best practices for the use of open source software, particularly in regards to license compliance - basically what one needs to do. But I'm finding that it is ever-more critical to look at knowledge: the understanding, awareness, and education around open source software and licenses.
Red Hat and the JBoss Community recently announced that they will be releasing a single compiled binary under the EAP.Alpha terminology, rather than posting a community release on the community site and a separate EAP early release on the Red Hat site. This naming change has confused some members of the community, but rest assured the EAP.Alpha release is still under the LGPL as per previous JBoss Community releases.
Today’s article considers some of the similarities, and differences, between community versions and enterprise versions of open source software. Mature open source usually comes from one of two sources of global communities: 1) communities like the Apache Software Foundation that are not directly affiliated with a specific corporate entity, or 2) commercial and open source software companies.
If you read a post on The Enterprise OSS Blog, please leave a comment. Let us know what you think, even if it's just a few words. Comments do not require approval, but they are moderated.OpenLogic reserves the right to remove any comments it deems inappropriate.