Jonathan, if you want to get a bit acquainted with C++ and edelib, you could join enjoy as developer for some time. It is a media player in the spirit of EDE (keep it simple). Currently, I'm the only developer.

www.launchpad.net/enjoy

By the way, I think it is a good idea to centralize all the documentation on the wiki. We have to remove the old EDE1 stuff as soon as possible, and then start writing about EDE2. This is a first article aimed at EDE2: http://www.equinox-project.org/cgi-bin/trac.cgi/wiki/DevelopmentHowTo

Greets,

Double12


2009/3/8 Jonathan Price <jonathanius@gmail.com>

<excerpt from a previous message to Sanel>

Both when I first got interested in developing FOSS, and over the past
few days especially, I have done some research and formulated this
business model.
Its goal is to outline ways in which developers can code free, open
source software while still making enough income to survive:
First off, most of the business models used today by propriety
software do not take advantage of how easily software is distributed
and copied, things that are inherent in all data.  A recent OSnews
article will illustrate this: Internal statistics from Microsoft show
that illegal, unlicensed versions of Windows made up almost a fourth
of all copies being used. What kind of business model gets 1/4 of its
revenues stolen due to pirating? Though there are copyright laws in
place, they are nearly impossible to enforce. People will copy
software whether it is legal or not. I (along with all other fans of
open source software) think software should be legal to freely copy.
What is needed is a business model that is robust enough that it is
not harmed when people freely copy and distribute it.
One idea I had to accomplish this is to implement a framework in which
users can commission devs to make themes for EDE. If they cannot find
a theme that they like, they can pay a small fee to have a theme
custom made or an existing one ported for them. (when I say themes, I
do use the term in the same way that the word is currently used in EDE
- window decorations, I am envisaging something broader, that will
supersede it, window decorations, panel and menu styles, fonts, icon
sets, system sounds and even wallpapers, all download-able from a
single location on the website.) After the theme is completed it would
be posted for free on the site so that everyone could download and use
it. This could also be used for more than just individuals, developers
making a distribution who wanted to use EDE for their default DE could
pay have their own tweaked, branded theme made for them. It came to
mind that, if the request was for something more elaborate, they might
need more than a simple theme, they may need revisions to be done to
the DE itself, so, I thought ,we could do extensions (or modules,
whatever we want to call them) as well. But the expansion did not stop
there. Later, I was reading on Wikipedia about business models and I
read about one called the Street Performer Protocol, in the context of
software design:

"Software developers could announce a price structure to add various
features to an existing public-domain software package, and users
could pay for the features they want. When sufficient interest
generates the right amount of funds for a given feature, it is
created." - from: The Street Performer Protocol and Digital
Copyrights, by John Kelsey and Bruce Schneier [the paper in which it
was originally introduced]

That really got me thinking. Originally the idea (for themes) had been
only one party (a single person or a group such as a distribution
maker who needs EDE branded for their distro) that requests and funds
feature. In this idea, multiple parties - a large group of people who
share interest for a feature - can all pitch in to fund it. There is a
goal - a price set by the developers based on how much time the theme
or feature (which I will call a 'module') would take to develop. There
would also be some kind of a time limit. The people either pledge the
money and the money is collected when the goal is reached, or the
people send in the money to be stored until the goal is reached,
unless the goal is not met, in which case the money is given back to
the people. I favor the people sending the money in, so that they do
not pledge money that they do not have and then not pay up, this would
be a huge problem and the module would have to be delayed. If we take
the money in though, we don't have that problem.
People could also pledge with certain conditions, such as: "I will
give $1 per $20 that the project receives, up to $30". In this case
the maximum amount that the contributor is willing to donate is sent
in and, when the time limit is reached the contributor is sent back
the remainder. (Given the pledge mentioned above and a $400 total -
not including whatever the contributor gives - the contributor will
send in $30 and receive $10 back). Instead of a static time limit
measured from the time the project starts, we can have the time limit
that is measured from the time the most recent donation comes in, that
way if money is coming steadily, the project does not die, but if
people lose interest in the project and stop donating to it, the time
limit will soon expire and the people get their money back. There is
no risk for the contributor, either he gets the feature he wants or he
gets his money back.

Here's how it would look in the context of EDE:
1- One of the users wants something added to EDE, the user fills out a
wish list form (which would be provided on the site) giving a
description of the feature they would like implemented, it could be a
feature for EDE itself, an icon set the user wants designed or
anything else the applies to EDE. When the request is submitted it is
forwarded to the developers.

2 - The developers have three choices, they can reject the idea,
decide to unconditionally implement it into  EDE, or decide to
_conditionally_ develop it as a module. If the the developers decide
to develop the module conditionally they give it a price tag based on
how long it would take to design, and forward it the person who
proposed the module.
3- If the developers decide to develop it conditionally the user
decides whether he can fund it himself or to let it become a publicly
funded project. (If the user does not respond within a certain period
of time, it automatically becomes a public project). If decides to pay
it all himself, he does that, otherwise he tell the devs to post it as
a public project.
4- If the user payed for it himself the devs make it and give it to
the user, otherwise the devs assign it the time limit (which starts
when the first donation to the project is made, the time limit freezes
where it was when the last donation that meet or surpassed the goal
was made.
5- If the goal is reached when the time limit expires the project goes
on the development list, people can still donate to the project, this
will cause to be moved up in priority, we would probably develop the
modules in the order of percentage which it surpassed the goal. (So if
there are 3 projects, one with the goal of $100 which totaled to $102,
another with a goal of $20 which totaled to $40 and yet another with a
goal of $10 which totaled to $14, we would develop the one with the
$20 goal first, the $10  second and the $100 last).
If the idea is especially good we can, when it is suggested, merge it
directly into the EDE 'core' to be developed unconditionally, instead
of making it a conditionally developed project.
Contributors could donate to these unconditional projects just like
they would to conditional projects, except that there would be no time
limit or goal to meet. The developers could place portions or features
of EDE that we want to develop in either of these
categories(conditional or unconditional) for the users to specifically
donate to.
In this way, all components of EDE are proposed(either by the
developers directly, or by the users) and funded through a single
framework.
Everything that is produced is free, people only pay to get stuff
developed, it is both compatible with the ideals of free software, and
invincible to pirates because it is impossible to steal something that
does not yet exist ;-P.
However, this is not the only way that the project can be funded, ads
are another massive source. You said that the site will not be very
profitable with ads unless it is Slashdot-like. I don't know exactly
what you mean by Slashdot-like, but I do know that we definitely need
a lot more content if we want EDE's website to be profitable. Right
now, the website only tells you what you absolutely have to know.
EDE's documentation is horrible. Thankfully however, I love writing
documentation and would be happy to do quite  a bit of that. One of
the great advantages of well documented software is that it empowers
the users by helping them to understand how the software works. In
addition to making it easier for them to use the software, it also
increases likelihood that users will contribute code, and suggestions.
One idea I had to accomplish this is to answer every question that is
asked on the forum in an FAQ. When other documentation (such as the
installation instructions) is written or revised, the answer to every
applicable FAQ is integrated into it. For starters I would go through
all the threads on the SF forums and make them into an FAQ so that its
all in one place. We also should move the forums from SF to our
website so that all the forum traffic (and thus ad money) goes to us.
This would also give us more control and enable us to make signing up
a quite a bit easier than it is to sign up to SF, we would need just a
username, password, and email address for notifications. Basically we
want to centralize all existing documentation and write a ton more.
The website is our only portal to the world. It very important for any
open source project to have a large, active community, we want to
encourage it in every way we can. Another thing that we probably want
to do is expand and emphasize the devlog, it should be on the front
page (integrated with news) and contain the latest of EDE news, tips,
ideas for new features and articles on design philosophy, etc. It's
both a way of getting people on the site and finding out what the
community wants (via comments).
All these factors should combine to make the website a very busy place
and to encourage a very active community.

Here are some of the articles I read while formulating a FOSS
compliant business model, please read these articles before
responding:

damnsmalllinux.org/income-guide
// great guide on running an open source project without living on the
street ;-)

firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/673/583
// the article in which the Street Performer Protocol was first proposed

logarithmic.net/pfh/rspp
// a variation of the SPP called the Rational Street Performer Protocol
</excerpt>

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H