The document discusses the necessity of standards in cloud technology and the importance of technology adoption from a customer-centric viewpoint, focusing on utility, interoperability, and independence. It emphasizes that successful standards emerge as side effects of effective technology implementation rather than being defined beforehand. Additionally, it warns against standardizing too early, suggesting that exploring and building should precede the establishment of standards.

1. What We Need are Standards
in the Cloud

2. If a standard falls in the forest and there is nobody there to
adopt it, is it still a standard?

5. My name is
Benjamin Black

6. And I have no standards.

7. Let’s talk about something interesting,
instead:

8. Technology adoption.

9. Customer-centric view

10. Why adopt a technology?

11. Utility:

12. Does this solve my problem?

13. Interoperability:

14. Can I combine vendors+products
to solve my problem?

15. Independence:

16. Can I be totally free of
vendor lock-in?

18. Utility

19. Interoperability
Utility

20. Independence
Interoperability
Utility

21. These are not equal.

22. A hierarchy of needs.

24. Utility

25. Interoperability
Utility

26. Independence
Interoperability
Utility

27. Some problems need not go past UTILITY.

28. e.g., SQL (in reality)

29. Some problems can’t achieve UTILITY
without INTEROP.

30. e.g., TCP/IP

31. The cycle:

32. 1] Disruption.

33. MASSIVE UTILITY

34. (and a lot of imperfection)

35. Rapid adoption
(by definition)

36. 2] Competition.

37. EXPLORATION

38. Endless variety

39. Goal: Discovery

40. Not just of
solutions.

41. But of the complete problem.

42. Many ‘standards’

43. (meaning no standard)

44. The seeds of interop are sown.

45. We are currently in this stage.

46. 3] Maturation.

47. FORMALIZATION

48. Our itch having been scratched, we turn to
less pressing matters.

49. Independence

50. Successful standards
formalize
what is already true.

51. Standards are side-effects

52. of successful technology.

53. There are no successful standards absent
successful implementations.

54. All successful standards are
de facto standards.

55. TANSTAAFL

56. Ra t e o f I n n o v a t i o n
De g r e e o f S t a n d a r d i z a t i o n

57. Utility
Ra t e o f I n n o v a t i o n
De g r e e o f S t a n d a r d i z a t i o n

58. Utility
Ra t e o f I n n o v a t i o n
Interoperability
De g r e e o f S t a n d a r d i z a t i o n

59. Utility
Ra t e o f I n n o v a t i o n
Interoperability
Independence
De g r e e o f S t a n d a r d i z a t i o n

60. (the innovation moves elsewhere)

61. Standardize too soon, and you lock to the
wrong thing.

62. Unclear that it is even possible to
standardize ‘too late’.

63. We have missed an important question:

64. What do we even mean by
‘standard’?

66. Standard

67. Standard
Standard specification

68. Standard
Standard specification
Standard committee

69. Standard:

70. What everybody uses.

71. Utility + Disruption
Standard

72. Standard specification:

73. What someone hopes you’ll use.

74. Interoperability
Standard specification

75. Standard committees:

76. The legislative branch.

77. Independence
Standard committee

78. Concerned with:

79. Licensing
Patent grants
Open process
Interoperable implementations
Open source
etc.

80. Special bonuses:

81. Politiks
Permanent seats
Preferential votes
Secret handshakes
etc.

82. If you don’t achieve UTILITY...

83. Customers won’t bother.

84. They want their problems solved.

85. Standard committees don’t build.

86. We can only discover the right standards by
building and exploring.

87. To discover the right standards, we must
eschew standards.

88. Go do.