[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Target market?



Hi,

On 7/23/07, Bill Nottingham <notting redhat com> wrote:
We don't have one! Seriously, I have yet to see anything that shows that
we have a coherent market, a plan for attack, or *anything* along those
lines.

Let's make one, and start the conversation here :)

But does Fedora have any goals?

Maybe we want to trumpet the customizability of Fedora, and focus on
highlighting user-contributed spins. If so, we should be focusing all our
efforts on creating web frontends, getting storage together, writing bits
for people to rate these spins, etc.

We should do that.

Maybe we want to investigate the online, connected destkop, and the possible
creation and use of open service frameworks. Then we should start heavily
investigating in infrastructure to host these apps and people's data. We
should start working on rolling out open-source backed versions of popular
online services (mail, chat, flickr, blog, etc), and working heavily with
legal to enter this space with a *truly* open policy about how the user owns
their own data, how to truly not be evil, etc.

We should also do this.

Maybe we want to trumpet Fedora'a ability to be ported to seconday arches
and portions of the embedded market. Then we need to heavily invest in
storage for contributed ports, cross-compiling support for all of our
software, and so on.

Maybe we just want to expand the reach of Fedora and drive more users to
the Fedora userbase. Then we need to start investing heavily in targeting large
markets, figuring out what they need, and implementing that. It means
investing heavily in selecting true best-of-breed apps for a coherent user
experience - no more shipping two desktops, 20 servers, and a gigabyte of
development libraries. It could be installers that run from Windows. It
could be tools that take the user's profile data from their Windows install,
for use on the LiveCD. It could be fixing all our software to use
NetworkManager, and partnering even more with Fluendo for codec deployment.
It involves partnering with various organizations, including RH, to provide
support, because you're not going to get mass market usage without *SOMEONE*
providing backend support for it.

We would be competing directly against Ubuntu here, which is probably
pointless.  I feel that if we can make a more persuasive point, we
might reach a critical mass where doing the above might make more
sense.

And there's plenty more that people have suggested we should be doing.
Overthrowing the music industry. Showcasing content production for graphic
artists. Just running rock-solid servers.

All of these are possible.


So this is something I've been wanting to focus on doing in the fall.
Let me start by naming a few orthogonal goals.

* A solid server platform - Something you can install on any vanilla
x86 box and run most any server app with no trouble, virtualization,
java middleware stacks, mysql, fileserving, you name it.
* A easy to use desktop platform - It has all the latest widgets and
doodads that make you say wow, this fits my thoroughly modern
lifestyle.
*An Online desktop - It connects you to other people, or sources of
information on anything and everything
* A customizable flexible system - You can disect it, clone it,
improve it, copy it, share it, remix it, merge it, break it, fix it,
what ever you do, don't ignore it.

And just one contradictory goal, for the time being

* An embedded desktop - Designed to run in a small footprint, based on
robust architecture.

Finally, a few parallel goals

* Gnome - bunch of little men marching across your system
* KDE - abuse of a certain prefixable letter
* Browser wars
* Development tools
* Fancy effects, such as Compiz and Metisse
* A console like interface I have a design in mind for, but no working
prototype yet.

I've organized these to show how compatible some of these goals are
with other goals.  Basically, orthogonal goals, when defined properly,
without getting out of hand work together on different parts of the
system.  Any single one of them could fail, and things might not work
as nicely, but it's not as bad as when *all* of the parallel goals
fail, or any of the contradictory goals interfere.

So let's throw them all together.  Let's say we have a rock solid core
system, which includes only base elements.  There's no GUI yet, but it
never crashes.  It's got an amazing unit test, it runs all hardware,
it manages firmware, it actually includes things as complex as
NetworkManager, pulseaudio, and other desktop tools.  Lying along side
it, we have tools to set up most database, email, web, or java
servers, plus anything else we want to support.  But since you can
remix the distro, they are part of a separate component that can be
remixed automatically.

Those are three orthogonal goals.  We can add on two more simply by
saying they are addons.  The online desktop is a bunch of tools that
simply aggregate information.  They are not directly integrated into
any desktop, as there is no desktop yet.  The desktop is it's own core
module that focuses as much as possible on just integrating into the
distro, but at the same time saving the user the mental overload
involved in actually managing a full fledged unix system.

Finally, since these are orthogonal, the server end, the online
desktop end, and the remixing end can all have a gui section that's
designed to integrate into *a* GUI, but not any gui in particular.  I
feel like we have enough freedesktop.org standards to work with in
those regards.

These can be a central set of goals, with one group overseeing the
integration of all these pieces.  This doesn't have to always be every
last piece must be as new upstream as possible, hacked together into
one explosive device.  Any unit can decide to wait one release cycle
to stabilize upstream, even if another area doesn't.  I have this
funny feeling that if the core kernel stays at the save version from
one release to another, just updating GNOME will make everyone go
"wow, this is new".  Likewise, when every distro is crashing on the
latest version of GNOME that should never have seen the light of day,
this won't be an issue, since hey, we got Py3k, PHP 7, Apache 3, JBoss
6, not to mention, it's remixable.  So when GNOME makes a point
release, respinning the distro for an interim release shouldn't be
hard to do either.

(And apparently Luis just said the same thing in fewer words....)

So bottom line is, if I were to talk about cohesive goals, I would
start with this.  Get a proof of concept out for Fedora 9, and then
try to spam the media with it as much as possible.

Or am I wrong?


-Yaakov


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]