RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

Nicolas Mailhot nicolas.mailhot at laposte.net
Mon Jul 22 15:37:24 UTC 2013


Le Lun 22 juillet 2013 15:38, Matthew Miller a écrit :

> Whenever I go to a tech meetup or talk to someone from a new startup
> company, their developers are inevitably using a different (usually
> proprietary) desktop OS, plus a non-Fedora distribution on their code.

And the main reason has nothing to do with rpm, or Fedora packages
selection, or Fedora packages version, or that GNOME is not pretty enough,
and everything to do with the fact those companies are using managed
desktops. Managed meaning "my developers are writing cool code, I don't
want them to waste time installing or configuring their OS instead". So to
get those entities to use Fedora, you need to lower management costs, so
they don't feel any Fedora install is going to suck people time.

Management costs are:
1. changes released before they are mature enough, requiring people effort
to workaround the warts and missing bits
2. endless desktop churn and gratuituous backwards-incompatible changes
(not incompatible in the software sense, incompatible in the people
sense) : the people API is changing all the time. Linux (as a kernel or as
a server) is successful in those same companies because Linus and server
people refuse to invalidate existing know-how just because
3. lack of clearly defined LAN infra : Windows comes with AD and local
network sharing, our desktop comes with facebook clients. Guess which one
is actually useful to produce code. Linux for workgroups is a fantasy

All the rest is pretty much habits picked up while running other OSes as
managed desktops at work. They're not the cause those other OSes are
chosen as managed desktop, they're the effect of not being exposed to
Fedora conventions because it's not used at work.

If you to see more Fedora deployments in startups, you do not need to
change Fedora contents, you need to ask yourself "how would I built a
small Linux startup environment from scratch using Fedora and minimizing
operator/helpdesk costs, time and efforts", identify all the tools the
network/desktop admins/helpers would need, and make sure they are easy to
find, deploy and operate. That and convince some people change for
change's sake on the UI front is not a bright idea.

Startups do not care much for support contracts (they know they are small
fishes big IT companies have little time for), they care about the time
between "I have no work desktop" and "I have desktops my people can work
on, with the corresponding management infra, code repository, bug
trackers, test systems, etc". Crashes are ok as long as recovery time and
effort is small. First mover advantage is very important for a startup. It
won't sacrifice it to Fedora experiments.

Remember that mysql was insanely successful not because it was technically
brilliant, capable, or innovative, it was insanely successful because it
reduced the amount of work needed to manage it to the minimum. Liberating
dev time to do "cool stuff" without worrying about logistics.

Desktop selection logic is no different. It's all about "time/cost to be
operational". If you reduce this (perceived) time/cost, you'll see
startups adopting Fedora in droves, because startups only care about
getting profitable/bought before VC funding dries down, and are pretty
agnostic about everything else.

-- 
Nicolas Mailhot



More information about the devel mailing list