-
Notifications
You must be signed in to change notification settings - Fork 12
/
goals.ltx
84 lines (75 loc) · 3.91 KB
/
goals.ltx
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
\hypertarget{goals}{}
\unnumberedsection{Setting Open Source Goals}\label{goals}
One of the keys to using open source successfully is setting
appropriate goals. While open source is not a panacea, there are
certain circumstances and problems to which it is very well suited.
This section contains a list of goals that we have seen open source
address successfully. We intend it to be all-encompassing for typical
use --- that is, this list should cover the goals that an open source
project can reasonably achieve in the vast majority of circumstances.
If you have a goal that isn't captured by this list, it might be a
poor match for open source as typically practiced.\footnote{Is it also
possible, of course, that the list is incomplete. If you think we
missed something, please let us know at
\otsurl{https://www.OpenTechStrategies.com/archetypes/feedback}.}
\textbf{Development and Collaboration}
\begin{itemize}
\item Expand or amplify developer base, especially non-staff developers
\item Gain market insight
\item Gain or maintain insight in a particular technical domain
\item Influence a technical domain
\item Create a framework for partner onboarding and collaboration
\item Lead a standardization effort
\item Disrupt an incumbent, hold off insurgents
\end{itemize}
\filbreak
\textbf{External Positioning}
\begin{itemize}
\item Ease customer fears of vendor lock-in
\item Deepen engagement with users, create more paths for engagement
\item Increase transparency for customers and partners
\item Establish a basis for product reputation
\item Support organizational branding and credibility
\end{itemize}
\filbreak
\textbf{Internal or Structural Change}
\begin{itemize}
\item Improve internal collaboration (cross-individual or cross-departmental)
\item Create opportunities for internal mobility
\item Expand or reshape developer hiring pool
\item Improve morale and retention
\item Create paths of flow for bottom-up innovation
\item Improve and maintain open source capabilities (both technical and social)
\end{itemize}
\filbreak
Before you start picking goals off this list, take a moment to reflect
on the overall purpose of your effort. Open source is one toolset in
an overall strategy, and these open source goals only have value in
service to a larger vision. Know your mission, your cooperative and
competitive landscape, your short- and long-term milestones, and the
resources you have at your command. That context should tell you a
lot about what you need from your open source investment, and it
should help narrow your goals to an achievable list.
All eighteen goals are probably plausible, to some degree, for any
given open source project. Your project cannot, however, move in
eighteen directions at once.
Think about which of the goals would fill important gaps in your
larger strategy. Pick a few goals based on that --- we normally say
three, and although that's not a hard-and-fast limit you should think
carefully before exceeding it.
Then match those selected goals up with archetypes that suit them. If
the goals you've chosen align with archetypes that fit your project
and fit your overall mission, that's a good sign you've found a path
that has served other projects successfully. If you cannot find that
alignment, look harder at some of the other possible goals, or
consider different archetypes or blended archetypes.
Finally, document your goals: make them explicit and discuss them with
your team. The more clarity people have about how the strategy drives
the work, the better they can fine tune the work to your real goals.
Consider what indicators you can use to establish starting points and
targets. We cover metrics elsewhere (see
\fullref{metrics-archetypes}, p. \pageref{metrics-archetypes}), but
you don't need quantifiable indicators at this stage anyway. You just
need to be able to answer the questions ``How will we know if it's
working?'' and ``What signs might indicate that we need to make
adjustments?''