Submission deadline: 1 Apr. 2019
Publication date: Nov./Dec. 2019
Open source software (OSS) has conquered the software world; you can see it almost everywhere, from Internet infrastructure to mobile phones to the desktop. But not only that, although many OSS practices were viewed with skepticism 20 years ago, many have become mainstream in software engineering: from development tools such as Git to practices such as modern code reviews. In the programmer community, OSS has become so prevalent that some companies now expect potential employees to have an active GitHub profile that showcases their OSS contributions.For a phenomenon with as much impact on software development practice as OSS, it’s of crucial importance that we understand what works, what doesn’t, and why. Although researchers and practitioners have studied and discussed OSS for many years, we still don’t have a complete understanding of it as a whole or of the many aspects related to it. Akin to the famous quote about Wikipedia, “The problem with Wikipedia [read OSS] is that it only works in practice. In theory, it can never work,” we see OSS impact our lives every day, yet there’s only a limited number of theories about OSS that describe, explain, or predict how OSS impacts software engineering practice.
Practitioners can ascertain that OSS is an evolving environment that has changed much in the past 20 years. Scholars talk of three generations of OSS:
- In the first one, a community of volunteers led the development process.
- In the second one, the software industry started to interact with the community.
- In the third one, industry consortia are pushing forward OSS projects with a significant number of professional (that is, paid) developers.
And there’s increasing interest in OSS from the perspective of industrial practitioners, noticeable by not only the paid developers but also the rising number of previously closed-source projects being open-sourced.
This IEEE Software theme issue therefore aims to share with software engineering practitioners reports that analyze those OSS products, processes, practices, and tools that have had a major influence on software engineering practice. It’s important for the software engineering community to benefit from the insights gained from an overview of the realities, promises, generalizations, and pitfalls of OSS.
We refer to open source in a wide sense as in IEEE Software’s Jan./Feb. 2004 article by Cristina Gacek and Budi Arief (“The Many Meanings of Open Source,” pp. 34–40), which augmented and contained both the Open Source Initiative’s definition of open source (https://opensource.org/osd) and the Free Software Foundation’s definition of free software (www.gnu.org/philosophy/free-sw.html).
Possible topics include, but aren’t limited to,
- software development tools and platforms,
- open source software products and their adoption,
- economic and business aspects,
- legal aspects,
- quality issues,
- global software development,
- software ecosystems,
- release management,
- social software development,
- sociotechnical points of view,
- software analytics,
- programming languages,
- innersource,
- modern and public code review,
- software heritage,
- diversity, and
- good or best practices.
In addition to regular-length articles, we seek short experience reports. These reports don’t need to make a research contribution. Instead, they should present the experiences of practitioners or tool developers, sharing their practical experience and insights and focusing on the challenges faced, solutions attempted, and results obtained.
Questions?
For more information about the theme issue, contact the guest editors:
Submission Guidelines
Manuscripts must not exceed 3,000 words including figures and tables, which count for 250 words each. Submissions exceeding these limits might be rejected without refereeing. Articles deemed within the theme and scope will be peer reviewed and are subject to editing for magazine style, clarity, organization, and space. Be sure to include the name of the theme for which you’re submitting.
Articles should have a practical orientation and be written in a style accessible to practitioners. Overly complex, purely research-oriented or theoretical treatments aren’t appropriate. Articles should be novel. IEEE Software doesn’t republish material published previously in other venues, including other periodicals and formal conference or workshop proceedings, whether previous publication was in print or electronic form.
General author guidelines
For submission details: software@computer.org
To submit an article: https://mc.manuscriptcentral.com/sw-cs
