Renaming the keys for the 'Support and Maintenance' group (#360)

Renaming prefix from `SP-` to `SM-`

Author: spier

patterns/2-structured/maturity-model.md

@@ -175,10 +175,10 @@ InnerSource projects need a means for self assessment. Metrics can be one aspect
 
 Not only should feature development be owned by InnerSource teams - support and maintenance is also part of the teams core tasks.
 
-* SP-0: Support given by the core dev or support team. A business contract guaranties the support. There is no knowledge about the product outside the team.
-* SP-1: There are rules and regulations to formalize the support on the product, given by a dedicated supporting team.
-* SP-2: Support for InnerSource contributions is formalized through InnerSource patterns like [30 Day Warranty](./30-day-warranty.md) or [Service vs. Library](./service-vs-library.md).
-* SP-3: There are rules and regulations to formalize the support on the product, given by a mature community.
+* SM-0: Support given by the core dev or support team. A business contract guaranties the support. There is no knowledge about the product outside the team.
+* SM-1: There are rules and regulations to formalize the support on the product, given by a dedicated supporting team.
+* SM-2: Support for InnerSource contributions is formalized through InnerSource patterns like [30 Day Warranty](./30-day-warranty.md) or [Service vs. Library](./service-vs-library.md).
+* SM-3: There are rules and regulations to formalize the support on the product, given by a mature community.
 
 **Culture**