DragonFly BSD
DragonFly users List (threaded) for 2005-08
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

DragonFly BSD marketing

From: "Bob Bagwill" <bob@xxxxxxxxxxxxxxx>
Date: Sun, 14 Aug 2005 14:18:31 -0400

Marketing, a nine letter word ...

Not that I'm an expert, but I think it's important that Matt and his merry band make
it clear what they want from the DragonFly project, and what prospective users/developers
can expect. Notice that I wrote "project" not "product". In an open source project,
there are a variety of goals/attitudes/philosophies (yeah, I use too many slashes):

- This project is something I do when I ought to be studying for finals.
- This is my thesis project that I will abandon when I graduate.
- This is something to keep me occupied until I get a real job.
- I'll work on this until I run out of money.
- My enlightened employer pays me to write this.
- This is purely a research project.
- This is something I write just for myself and my friends, and I'm willing to share it with the world,
but don't bug us with requests, complaints, etc.
- When the technical goals of the project are reached, the product will be released/frozen/retired/abandoned.
- I expect this fork to be merged back into the mainstream.
- I expect this fork will replace the mainstream.
- When it's done, I'll move on to a new project.
- I want this project to attract developers and users and live forever.
- Total world domination.

and any combination of the above. Of course, every participant can have different goals,
and some may have private goals they don't choose to share.

It would be nice if the website made it clear what the project goals are (not just technical milestones for
the product). It's not reasonable to ask people to read every email list message for the last 2 years
to infer the project's hopes and dreams. Also, a good part of the project's direction may come from
private emails, irc conversations, etc. that new people have no access to.

As for the DragonFly product, I think it's important to state its intended use. It's reasonable to
say "This is a server operating system that _can_ be used on the desktop, but we don't plan to devote
resources to a desktop GUI."

That said, if you want to attract people, having a usable standalone OS is helpful, since not
everyone has a couple of spare machines to devote to playing with new software. But it's important
to know your target customers:

0) Random curious people

Potential customers only. They should be able to easily and safely satisfy their curiosity
about the product without consuming support resources. They probably can't contribute
anything. A clear, up-to-date website and sexy LiveCD

1) Desktop users (converts from Windows, Linux, other BSD's)

Not a desirable customer group. The current product is too volatile, there's no support
for this group, and they probably can't contribute anything in time, money, or expertise.
There's no reason for them to switch OS's. You don't have to alienate them, but you don't
want to disappoint them either.

2) Server administrators (also converts from Windows, Linux, and other BSD's)

Not very desirable either. Again, the product is too volatile, there's little support
for this group, there's no critical operational advantages to DragonFly yet, and they've probably
already committed their resources to other OS's. They are future customers.

3) Application owners/developers

Desirable. Having useful applications adds to the usability and momentum of a distribution.
We (speaking for the DF Team) want native support for DragonFly, as opposed to having to maintain
a library of DF-only patches. Applications that highlight DF's unique advantages are the most

4) Random hackers

Somewhat desirable. They have curiosity and energy. They may or may not be productive developers.
They are good for debugging, testing, patching. They may waste project energy by demanding too much
support, starting flamefests, pushing out-of-scope projects, etc. They can do minor projects.

5) Multi-BSD hackers

Very desirable. They already know BSD internals and philosophy. They are self-supporting.
They facilitate cross-pollination of code and ideas. They can do major projects.

Bob Bagwill

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