O.K. - thank you folks for your encouraging and enlightening comments.
You really cheered me up some, and thus I drew some energy from it to be put
back into the project.
Let me first summarize a bit on what was suggested in the various mails, and
how these issues should (IMHO of course) be addressed:
1. There is still quite some interest in GGI.
Nice. Nothing we need to do about it, apart from trying to keep our happy
customers happy, which I think we do pretty well at regarding support here
on the list. Another issue is GGI acceptance in the public, which can stab
our customers in the back ... I'll talk about that later.
And for our less happy customers, which are usually due to badly maintained
subsystems: We really got to get some people to work on the areas that are
needed. And to get coders we need good publicity. Again - I'll talk about
that later.
2. Our Homepage needs a serious refreshment. I feel that myself. While it is
pretty clean and simple, especially for those who know the project, it lacks
some spice for the others. We need some eye-candy there, and we should
change it on a regular basis to keep people hitting the site.
A few suggestions for that:
a. We feature a "cool GGI Screenshot of the week". I'd volunteer to take the
pics all you out there would send me and judge them and integrate them with
the website. Webbased voting would also do, but someone would have to set
that up.
b. I have kind of a webcam here which is GGI enabled, at least if I rewrite
a few small tools I lost in my HD crash. Should be no biggie.
However that wouldn't be a really interesting thing to look at - if it
really gets interesting, I'll surely have turned it off in time :-) ...
Moreover, as I'm not on a permanent connections, updates would be at most
something like twice a day or something.
And we'll probably have to restructure it a little to the current mainstream
"sourceforge"-structure like "info - screenshots - download - contact".
More ideas very welcome.
3. We have a problem with our distribution model.
We tell most people to get a recent devel snapshot, but its size scares
them. We have nicely split rpms and debs, but they are out of date.
O.K. - I think we should do the following:
Apart from the full snap, generate at least 2 more tgzs with libgii and
libggi separated out. Even better would be libgii, libggi, svgalib_wrap
and kgi. The rest ist pretty much optional. Maybe libwmh for some people.
This should cost nothing but a few small changes to the docs, the webserver
scripts and some space on the ftp-server.
4. We need a release.
I need to talk to Marcus about that, to recheck, that there isn't much that
really needs to be fixed. When we agreed on that, making a release would be
nothing but keeping our hands off the code until the next snapshot
generation, if we adopt the model from 3.
5. Someone suggested a "small release", with only the most important
targets.
I don't think this would be good. The beauty of LibGGI shows in the big
choice of possible targets. I think targets are detected reliably enough to
cause no problem in the build process. If any do, we should just disable
them in configure.
6. Someone suggested "advertising on questions", i.e. answering questions
like "I can't get bla to work" with "if you used GGI, you wouldn't have to
bother with getting bla to work".
Basically, this is right, and I think many people here already do this. As
long as the answer is true and solves the problem, I think this really is a
good way to attract more people to GGI.
7. Someone suggested a big IRC meeting.
This would indeed probably rise the spirits some. I do remember the times,
when I summarized such meetings with that famous fantasy-touch stories ...
was quite some fun, and I think we should start having so much fun again ...
;-).
8. Someone asked about EvStack.
To my knowledge, the linux-input project tries to establish something like
it. It really was a great project, but it dives deeply into kernel internals.
I don't have the nerve to do that again, as I have pretty much rid myself
from Linux kernel development in favour of more portable stuff. While the
evstack principle and its modules are fairly portable (EMan surely knows
what I am talking about - right ?), the kernel interfacing isn't.
If someone wants to pick that up again, I'll surely assist in any way.
O.K. - how does that sound ? Comments and volunteers welcome.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
