The practices of open source communities can vary greatly, as can the deliverables. How can users and integrators of open source determine the status, stability and stature of projects under consideration?
This blog lays out example metrics for open source communities and the code they deliver. The KPIs - Key Performance Indicators - include both object/quantifiable metrics, but also more intangible ones.
The mission of the OpenTAP Blog is to make connections between test automation and open source software, first and foremost around the OpenTAP platform. But the universe of open source test automation extends beyond our favorite project and includes other test automation platforms and technologies that can complement and extend OpenTAP. There are myriad self-styled "test automation" platforms and frameworks that are developed and distributed as open source, with use cases a broad swatch of functionality.
Testing open source software (OSS) presents unique challenges, from its decentralized development model to the diverse user base to the varying levels of contributor expertise. Testing community-developed software must also meet challenges arising from the vast number of projects, and in particular, from developer focus on innovation and functionality.
Open source is a methodology whereby developers collaborate to create and share software, documentation and other artifacts.. Inner source is the application of the same methods but within a single organization. It applies to test automation as it does to other types of software, fostering collaboration, transparency, and shared ownership of testing tools and frameworks.
An OSPO or Open Source Program Office is a centralized team or department within an organization that manages open source strategy, policies, and practices. The concept of an OSPO has become increasingly popular as more companies recognize the importance of open source in software development and IT in general.
A source-available license grants users access to source code, allowing them to view, modify, and sometimes distribute the code. However, there may be restrictions or limitations imposed. These restrictions most often include limitations on commercial use, restrictions on redistributing modified versions, or requirements to share modifications with the original developer without necessarily making them public.
Dual Licensing (or multi-licensing) is the practice of releasing source code under multiple licenses. Most open source software is published and distributed under the rubric of a single license: Apache, GPL, Mozilla or about one hundred other licenses recognized by the Open Source Initiative.
Dual licensing, while adding complexity to use and management of open source software, serves several needs and application use cases:
Every year brings changes in the open source ecosystem. Myriad new projects, new applications and frameworks, new foundation working groups and new business trends. 2023 was no exception.
Open source software is no longer viewed as a novelty; indeed it is today thoroughly mainstream, to the point of banality. Nonetheless, the emergence of new projects and the progress of existing ones, the use of open source licenses, the role of open source code and the ups and downs of the open source ecosystem continue to present both challenges and opportunities.
Artificial Intelligence (AI) is a focal domain for developers, for end-users and for the venture capital community. It’s as hot a commodity as Linux and open source were two decades ago. But AI and open source share more than just hype. Across natural language processing (NLP), Machine Learning (ML), Computer Vision, and Robotics, both AI and open source drive the democratization of technology, and open source is helping to drive the utility and ubiquity of AI platforms and applications.
In October, the GNU project and the larger category of Free Software turned 40 years old. This blog explores the impetus and nature of Free Software, the philosophy, projects and licenses involved, how Free Software compares to Open Source Software, and the impact of Free Software and Test Automation.
Free Software was once considered radical, even anathema to organizations wishing to preserver rights around intellectual property. When introduced in the 1980s, it was not expected to be particularly significant or even to survive.
Well, survive it has, and has flourished.
Often, organizations large and small get the urge to craft their own FOSS licenses. This desire arises and persists despite the existence of over one hundred OSI-approved licenses, plus over two thousand other self-styled FOSS licenses. These FOSS-ish licenses do not earn a place on the OSI list because they are either too similar to existing approved licenses or they violate principles of the Open Source Definition and the Free Software Definition.
This blog addresses motives for writing new licenses and why you should resist the urge.
Open source is everywhere. It is highly visible, easy to acquire, use and deploy. The facility of acquisition and use can give open source, collectively, the appearance of a tech candy store, tempting developers and end-users to take fists full of open source code, sometimes without regard for the implications for intellectual property, security and general overhead.
Open source (including Free Software may indeed be free to acquire, use and deploy, but that usage is accompanied by a set of risks, some of which are shared with traditional proprietary software, while some are not.
