gnustep-dev
[Top][All Lists]
Advanced

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

Re: Marketing (Was: Re: New developers and publicity)


From: Alex Perez
Subject: Re: Marketing (Was: Re: New developers and publicity)
Date: Tue, 28 Sep 2004 13:10:23 -0700 (PDT)

On Tue, 28 Sep 2004, Dennis Leeuw wrote:

> Banlu Kemiyatorn wrote:
> > On Mon, 27 Sep 2004 15:22:08 -0600, Adam Fedor <address@hidden> wrote:
> > 
> > 
> >>What I'm more afraid of is that people will be interested in this, but
> >>nothing will get done.  That's happened more than once in the past.
> >>
> >>So feel free to start this. I certainly hope we can accomplish
> >>something.
> 
> A very valid point, and I am guilty on a atleast two occasions...
> The problem with marketing GNUstep is that it is hard to do marketing 
> for a couple of libs :) so we need to define the product "GNUstep".

Yes, first and foremost.

> 
> Which is more or less what Banlu is telling us too below.

Indeed. Thanks, Banlu!

> 
> What I have in mind is not the "hard-core" approach which you can do 
> with a "product", but more the awareness part by creating a Build Guide, 
> a History document, a desktop manual so people can have a look what apps 
> written with GNUstep look like.
> And the next step was the programmers guide(s)... but I am not a 
> programmer, so I failed. Thank god there is Adrian Robert to atleast 
> fill in the blanks on the API documentation.
>  From my server logs I know that the programming guides are needed. They 
> quickly surpassed the Build Guide as most read document on my site.

This sort of stuff should be coagulated on GNUstep.org or at some sort of 
subdomain.gnustep.org which follows the GNUstep.org look and feel, so 
there is some sense of documentation cohsiveness. The other problem is 
that, currently, CVS is a limiting factor in how we can update the site, 
because we can't easily say "user foo has commit access to the GNUstep web 
CVS folder bar" which I feel is imperative if we want to have multiple 
people responsible for multiple parts of the GNUstep site and 
documentation.

> 
> What I would like to do is still to try to position GNUstep as a 
> developers tool, thus not the DE part. Meaning the framework, and GORM, 
> PC, EasyDiff... and probably need a nice GDB frontend too and a Code editor.
> 
> That means that for people to get an interest in GNUstep there need to 
> be some documentation on:
> - Begin programming Objective-C
> - Start programming GNUstep
> - UI design guide
> - GORM manual
> - PC manual
> - other developer app manuals
> And with manuals I mean NOT man-pages but books that can be read online, 
> PDF etc.

We could also consider trying to get a limited run of someof these things 
printed, and sell them to raise a few bucks for future documentation or 
marketing projects. 

This leads me to my second point, which is that we really need a GNUstep 
Foundation. Actually, we need two. One in the United States, and one in 
Europe. While I can't speak for Europe, a nonprofit in the united states 
can legally accept tax-deductible donations from both corporations and 
individuals. This is imperative if GNustep is to become more recognized 
and respected. I know of at least a couple of American GNUsteppers who 
might be interested in getting such a beast off the ground. Anyone up for 
such a task in Europe? Dennis?
 
> Next to that there should be some public awareness. Which means there 
> should be some pieces of news we can submit to the news sites. The 
> problem (for me) with a weekly editorial, is the time it consumes. With 
> my current job I can't guarantee a weekly or even monthly editorial.
> But it is a great marketing tool if you can submit a progress report 
> often, so if someone else is willing to run through the Changelogs and 
> create a progress report. That would be nice.
> The release early, release often paradigm would also be helpful. Maybe 
> from GNUstep-core 1.0 on a release system could be used where 1.0, 1.2, 
> 1.4 etc. are the stable releases, there is also 1.1, 1.3, 1.5 which are 
> unstable but with rapid release cycles. As soon as a piece of 
> functionality is more or less stable... do a release.
> That creates visibility. If there would be one person to update the 
> versions in Freshmeat, GNUstep would popup more often.

Yes, an official "release notifier" position would be nice, and we could 
even cycle it per month or per release if we wanted, since it's so 
tedious.

To further discussion on this topic, I have started a GNUstep-marketing 
mailing list. I will send a follow-up e-mail momentarily which contains 
information on how and where to sign up.

Cheers,
Alex Perez
> 
> 
> > 
> > 
> > In my opinion. I think marketting GNUstep is a waste because it is not a 
> > desktop
> > environment. End-users make a system self-sustainable since technically they
> > paid (in a way) developers to live. It's better to put marketting
> > effort into a desktop
> > environment, eg. backbone and etoile. However, it would be better (in a 
> > view)
> > for the desktop environments to share openness with end users as much
> > as possible.
> > 
> > Now for the DE goal if people agree with the above idea.
> > 
> > In short term, I think it is a good idea to have a desktop environment 
> > project
> > under GNU's umbrella. It is a quick way to have people to agree on 
> > something.
> > And I'm expecting Adam to start this (if he can agree with the idea)
> > to reduce any
> > possible social conflict.
> > 
> > In long term, the GNU brand and politics could defer the project. In that 
> > case
> > some people can start doing something like GNOME did if they think GNU's
> > political view isn't as important.
> > 
> > There will be no further opinion from me on this subject because I'm busy
> > building my own DE which is focusing DTP and I would like to dictate it. ;)
> > 
> > 
> > _______________________________________________
> > Gnustep-dev mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/gnustep-dev
> 
> 
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]