Pragmatic validation metrics for third-party software components
Earlier this week at the IKS general assembly I was asked to present a set of industrial validation metrics for the open source software components that IKS is producing.
Being my pragmatic self, I decided to avoid any academic/abstract stuff and focus on concrete metrics that help us provide value-adding solutions to our customers in the long term.
Here's the result, for a hypothetical FOO software component.
Metrics are numbered VMx to make it clear what we'll be arguing about when it comes to evaluating IKS software.
VM1
Do I understand what FOO is?
VM2
Does FOO add value to my product?
VM3
Is that added value demonstrable/sellable to my customers?
VM4
Can I easily run FOO alongside with or inside my product?
VM5
Is the impact of FOO on runtime infrastructure requirements acceptable?
VM6
How good is the FOO API when it comes to integrating with my product?
VM7
Is FOO robust and functional enough to be used in production at the enterprise level?
VM8
Is the FOO test suite good enough as a functionality and non-regression "quality gate"?
VM9
Is the FOO licence (both copyright and patents) acceptable to me?
VM10
Can I participate in FOO's development and influence it in a fair and balanced way?
VM11
Do I know who I should talk to for support and future development of FOO?
VM12
Am I confident that FOO still going to be available and maintained once the IKS funding period is over?
VM1 can be surprisingly hard to fulfill when working on researchy/experimental stuff ;-)
Suggestions for improvements are welcome in this post's comments, as usual.
Thanks to Alex Conconi who contributed VM11.