Tools for creating and maintaining Software Development Kits (SDKs)
This project is maintained by betterscientificsoftware
Once a logical set of potential member packages has been identified, the work of bringing together software development teams coming from potentially very diverse cultures and work backgrounds begins. A good goal to begin with is to define an initial set of community policies for the SDK. A Progress Tracking Card (PTC) outlining an approach to define and adopt SDK Community Policies is available from the Better Scientific Software Team. Additionally, to promote a stronger, more functional community it is important to consider several factors:
Community policies should be discussed among all development teams. When applicable, it is important to have representation from members with a variety of software engineering expertise and maturity. Mandatory policies should not be estabilshed that many potential members cannot feasibly comply with unless the policy is absolutely necessary. Such policies can be designated as future policies. Future policies typically require additional refinement or time before adoption as membership criteria. Future policies should not simply be suggested practices with no intention of full adoption.
Bringing to gether many development teams will usually require an intentional effort to establish common vocabulary and vision. Early on, people may frequently talk past each other due to a lack of these common building blocks. Working towards these common goals can help promote team building. It is usually not possible to obtain consensus on all major issues, but achieving a common understanding is important for a high-functioning community.
It is not necessary for the entire development team of a member package to be engaged in the SDK effort, but the team members that are engaged need to have enough leverage to implement agreed to community policies that the project is not already compatible with.
Establishing workflows and policies and doing planning activities for the SDK community does not replace these activities at the member package level.
Another key aspect of building an SDK community is clearly identifying the specific needs of the community that will make the SDK valuable. Understanding and communicating these needs is useful for obtaining and retaining funding for SDK efforts. These needs are highly specific to each SDK, but some examples of the kinds of needs that an SDK community can help to meet are:
Achieving and maintaining the interoperability of member packages. This is critical for users wanting to leverage a variety of packages in a single ecosystem.
Agreeing on supported version(s) of third-party software commonly used by member packages, as well as policies for adding or dropping support for new versions.
Providing coordinated support for commonly used third-party software that has been abandoned or is otherwise not sufficiently maintained.
Developing common testing infrastructure for CI or other testing to help promote the portability and interoperablity of member packages. When done in the smaller context of an SDK, as opposed to, for example, E4S, it is sometimes possible to catch issues sooner, or closer to the tip of development, which can make testing interoperability at the E4S or other higher levels more sustainable.
Coordinating porting efforts, such that common platform issues do not have to be resolved independently by many teams.
Providing a trusted source for complimentary tools. In this way, a set of tools can be used together as a suite that is more valuable than the sum of its parts.
Serving as a common point of contact for users who have needs that are currently unmet. After gaining an understanding of the requirements, it may be apprpopriate for one or more member packaages to coordinate to provide the needed functionality.
Providing a forum to develop standard interfaces and critical best practices. While some diverse efforts in an area allow for the best ideas to proceed, it is also important not to duplicate efforts unnecessarily.
Once a SDK community has been established, it can be challenging to promote growth and improvement. After a set of packages has achieved compatibility with the policies, does it make sense to add a policy or strengthen a policy if it would cause some existing member packages to no longer be compatible? It might if the policy is sufficiently important, but regardless it might also cause strain on the relationship between the package development team and the rest of the SDK team. One option in these cases is to simply wait, and this can be effective if a planned policy change is announced far in advance. Another approach that can be employed is to use a badging system. Such a system rewards packages with badges for achieving policy compatibility at different levels. In this way, incentive is available for lower and higher levels of compatibility. This approach is being considered for E4S.