Component product market Friction:
Lets say
you're a little guy developing a consumer app - so called downstream technology.
The fastest way to develop something is to use opensource inputs - so called
midmarket technology.
But
there's a big gap between that scenario, and owning the technology/developing
from scratch: certainty. Who wants to 'license' an input technology, do a lot
of work to incorporate it, and then something bad happens in that relationship:
a) they
go out of biz, leaving you with some .dlls / .sos and no way to replace
b) they
up the price
c) they
change 'focus' to survive or are bought out by an integrator, and no longer
serve your niche.
To protect
yourself, you normally only use opensource as inputs, or 'competitive /
replacable' inputs: when there's more than one supplier in a domain, that do
approximately the same thing, so if something goes wrong with one input, you
have a backup/alternative plan-B.
For
example, lumai would probably sell more / get adopted more if there was a
competitor with similar API. Even if that competitor steals a bit of business,
there are probably a lot more downstream buyers that commit to using something,
once there are some alternatives/competition/plan-B.
Even
better, if there's some difference in quality / convenience, one may be an
entry-level input, another may be an aspirational input, allowing a high-priced
product developer to benefit from competition-as-stepping-stone.
Downstream
may not be sure about adoption of what ever they would integrate it into/their
product. So it doesn't make sense for them to pay upfront to cement a
contract/license/pay full-price for a fork, just to ensure continuity in the
off-chance their end-user/downstream-product sells/takes-off.
This
combination of downstream product market acceptance uncertainty, and
uncertainty about upstream input supply, impacts/causes friction/uncertainty-multiplication/Pr(a)*Pr(b)
when concidering projects, leading to fewer downstream projects.
And few
upstream projects. For upstream/midmarket component developers who are
concidering a product, and who look at these likely concerns by downstream
prospective adopters, may conclude that developing their component would not
pay off, or even if enthusiastic themselves, may have trouble finding any nieve
early stage investors who are unfamiliar with this friction, and so midstage
products don't get built.
Solutions to component product market friction:
1.
designed-in competition: midstream developers go out of their way to ensure
there's some competition in their space, by encouraging it, offering their API and/or
intellectual property for others in mid-market
2. development
sharing: downstream product developers search / hunt for and are open to 'shared
development costs' of upstream technology, with other like-minded downstream
product developers in non-competing product spaces, then no revenue streams are
needed/expected from the upstream component, and it optionally can be
opensourced
3. horse
trading: end product developers trade components already developed but not
originally meant/intended/targeted as mid-market components
