To get it, you have to enroll for 12 months, pay 150E of guarantee, and then 39,90E per month. Or you can buy it: 99EUR for the 14" screen, 429EUR for a 20".
Who will want to pay this price for a "Super Minitel"?
>Not that there would be a better distribution ?than Debian, but tat does not mean there's no room for improvement.
I think Knoppix is showing the way : a live cd distribution based on Debian, easy to install.
A Idea is to create meta packages, which are installing pre-configured set of packages. Then, you can start with a minimal working system and add big amount of packages in one command.
State of the GnuCash project, a call for help The GnuCash project is having a hard time. I think most everyone agrees that GnuCash is a critical piece of software for the Linux desktop. It's also one the largest free software projects. How big is it? GnuCash currently has 287,853 physical source lines of code (SLOC). For example, had the current GnuCash CVS been included in RedHat 7.1, it would come in 21st position in code size (see http://www.dwheeler.com/sloc/). At that time, the current GnuCash CVS source would have been pretty similar in size to qt, postgresql or perl, about 60% of Gimp and between 12% and 16% of Xfree, Mozilla or the Linux kernel. Although GnuCash comes up in every discussion of needed software to get Linux on the desktop, the GnuCash project currently has only about seven active developers (active being used very loosely here, considering I included myself) and enjoys far less exposure than many projects of a similar size.
We may be headed for a dead end if we don't reorganize and refocus our efforts. GnuCash badly needs more manpower (not just developers), and needs to get it quickly.
How did we get here Of course, every project could always use more developers, but the consecutive demise of both Gnumatic and Linux Developers Group caused the loss of most of GnuCash's core developers two years ago. The few volunteers that were left focused on new features, in the hopes of attracting users and hopefully also developers. We've managed to take it to 1.8.5 (to be released in a few days), and in the process GnuCash gained Small Business features, Scheduled Transactions, a completely new import UI with Bayesian filtering, OFX and HBCI support, Mortage and Loan Repayment druid, and many, many others. We are very proud of it and we clearly have more users judging from traffic on gnucash-users, and all should now be well in GnuCash-land.
Not quite. We didn't attract many new developers and all those new features have to be maintained and debugged. They also represent a huge tech support burden, since most of the features were not documented properly due to time constraints. GnuCash has grown too large for the current developers to properly debug and maintain the current code base, add new features and write documentation, all at the same time.
I hate to admit it, but in our quest for new features, choices had to be made and a lot of important things are currently being neglected. If the GnuCash project can't manage to attract more contributors and refocus the efforts of those it already has, it's going to become unmanageable. We often say that Linux would survive even if Linus got hit by a bus. Well, right now I am not too certain that GnuCash would currently survive if Derek Atkins got hit by a bus.
So now I'll try to suggest some solutions.
What core developers should do to help future developers There are many reasons for our difficulties to attract developers and other contributors, but it all comes back to the same problem: real or perceived, the barrier to entry is too high. To get more developers, we must make it easier to contribute to GnuCash. "Casual" hacking on GnuCash to scratch an itch is much to hard, even for an experienced developer.
Work on the developer documentation problem There is no complete and current architecture and API reference. Now that we've put the doxygen plumbing in place, we must make sure that ALL functions that are in public headers ARE documented, even if only by saying "Document me!", so the doxygen docs become truly authoritative. Then put the docs on the web site. We must also write a report writing Howto: We already have some very powerful reports, but this is the single most common offer for help we receive "Hi, I'd like to write "foo" report for GnuCash, can someone help me or point me to documentation on that subject". Sometimes I wonder if anyone knows anymore... So the answer is always the same: 'there isn't any; use the source Luke'. We are wasting the chance to hook countless new developers.
Slashdot Mirror
To get it, you have to enroll for 12 months, pay 150E of guarantee, and then 39,90E per month.
Or you can buy it: 99EUR for the 14" screen, 429EUR for a 20".
Who will want to pay this price for a "Super Minitel"?
>Not that there would be a better distribution ?than Debian, but tat does not mean there's no room for improvement.
I think Knoppix is showing the way : a live cd distribution based on Debian, easy to install.
A Idea is to create meta packages, which are installing pre-configured set of packages. Then, you can start with a minimal working system and add big amount of packages in one command.
State of the GnuCash project, a call for help
The GnuCash project is having a hard time. I think most everyone agrees that GnuCash is a critical piece of software for the Linux desktop. It's also one the largest free software projects. How big is it? GnuCash currently has 287,853 physical source lines of code (SLOC). For example, had the current GnuCash CVS been included in RedHat 7.1, it would come in 21st position in code size (see http://www.dwheeler.com/sloc/). At that time, the current GnuCash CVS source would have been pretty similar in size to qt, postgresql or perl, about 60% of Gimp and between 12% and 16% of Xfree, Mozilla or the Linux kernel. Although GnuCash comes up in every discussion of needed software to get Linux on the desktop, the GnuCash project currently has only about seven active developers (active being used very loosely here, considering I included myself) and enjoys far less exposure than many projects of a similar size.
We may be headed for a dead end if we don't reorganize and refocus our efforts. GnuCash badly needs more manpower (not just developers), and needs to get it quickly.
How did we get here
Of course, every project could always use more developers, but the consecutive demise of both Gnumatic and Linux Developers Group caused the loss of most of GnuCash's core developers two years ago. The few volunteers that were left focused on new features, in the hopes of attracting users and hopefully also developers. We've managed to take it to 1.8.5 (to be released in a few days), and in the process GnuCash gained Small Business features, Scheduled Transactions, a completely new import UI with Bayesian filtering, OFX and HBCI support, Mortage and Loan Repayment druid, and many, many others. We are very proud of it and we clearly have more users judging from traffic on gnucash-users, and all should now be well in GnuCash-land.
Not quite. We didn't attract many new developers and all those new features have to be maintained and debugged. They also represent a huge tech support burden, since most of the features were not documented properly due to time constraints. GnuCash has grown too large for the current developers to properly debug and maintain the current code base, add new features and write documentation, all at the same time.
I hate to admit it, but in our quest for new features, choices had to be made and a lot of important things are currently being neglected. If the GnuCash project can't manage to attract more contributors and refocus the efforts of those it already has, it's going to become unmanageable. We often say that Linux would survive even if Linus got hit by a bus. Well, right now I am not too certain that GnuCash would currently survive if Derek Atkins got hit by a bus.
So now I'll try to suggest some solutions.
What core developers should do to help future developers
There are many reasons for our difficulties to attract developers and other contributors, but it all comes back to the same problem: real or perceived, the barrier to entry is too high. To get more developers, we must make it easier to contribute to GnuCash. "Casual" hacking on GnuCash to scratch an itch is much to hard, even for an experienced developer.
Work on the developer documentation problem
There is no complete and current architecture and API reference. Now that we've put the doxygen plumbing in place, we must make sure that ALL functions that are in public headers ARE documented, even if only by saying "Document me!", so the doxygen docs become truly authoritative. Then put the docs on the web site. We must also write a report writing Howto: We already have some very powerful reports, but this is the single most common offer for help we receive "Hi, I'd like to write "foo" report for GnuCash, can someone help me or point me to documentation on that subject". Sometimes I wonder if anyone knows anymore... So the answer is always the same: 'there isn't any; use the source Luke'. We are wasting the chance to hook countless new developers.