How to Break an API: Cost Negotiation and Community Values in Three Software Ecosystems

From AcaWiki
Jump to: navigation, search

Citation: Christopher Bogart, Christian Kästner, James Herbsleb, Ferdian Thung (2016) How to Break an API: Cost Negotiation and Community Values in Three Software Ecosystems. Proceedings of the ACM SIGSOFT Symposium on the Foundations of Software Engineering (FSE) (RSS)
Internet Archive Scholar (search for fulltext): How to Break an API: Cost Negotiation and Community Values in Three Software Ecosystems
Download: http://breakingapis.org/fse2016.pdf
Tagged:

Summary

Authors:

investigate the decisions developers make with respect to breaking changes to see how the different values play out at the smallest scale and relate to ecosystem-wide policies and values.

Contribution:

case study of three software ecosystems, contrasting their change-related practices, values, policies, and tools. Our results have implications for understanding how stakeholders can influence change negotiation and design or change software ecosystems.

Research questions:

  • How do developers make decisions about whether and when to perform breaking changes and how do they mitigate or delay costs for other developers?
  • How do developers react to and manage change in their dependencies?
  • How do policies, tooling, and community values influence decision making?

Authors interviewed 28 developers from three ecosystems: Eclipse, Node.js/npm, and R/CRAN.

Reasons given for making breaking changes:

  • technical debt
  • efficiency
  • bugs

Mitigations taken by those making breaking changes:

  • maintaining old interfaces
  • parallel releases
  • release planning
  • communication with users

Users monitor changes, often not actively due to high burden, sometimes through social awareness (hearing of an important change or others' problems), or reactively.

Users reduce their exposure to change by:

  • limiting dependencies
  • selecting appropriate dependencies (trust of developers, activity level, size and identify of user base, project history, project artifacts)
  • encapsulating from change

Eclipse values compatibility most highly, R/CRAN ability of users to install a current system, Node.js/npm ability of developers to make changes. Different values/policies can result in resources being treated as fixed or foci for collaboration.

Conclusion:

We argue that community values play an essential role in shaping a software ecosystem, yet they can be somewhat difficult to distill from the outside (we had a general notion, but were not aware of the actual values going into the study). Making community values and the involved tradeoffs explicit and transparent can help to ensure that all stakeholders understand the tradeoffs of decisions made by the platform and the accepted consequences, such as higher costs for certain stakeholders or reduced attractiveness to newcomers. Such political transparency can help to understand and resolve conflicts and to guide design discussions.

Theoretical and Practical Relevance

http://breakingapis.org/ is a website for the paper and a follow-on survey.

https://www.xwiki.org/xwiki/bin/view/Blog/HowToBreakAPI is a community's self-assessment in terms of the paper.

Retrieved from "https://acawiki.org/index.php?title=How_to_Break_an_API:_Cost_Negotiation_and_Community_Values_in_Three_Software_Ecosystems&oldid=10902"