On Fri, Oct 14, 2005 at 07:56:36PM +0100, Neil Williams wrote: > On Friday 14 October 2005 6:53 pm, Chris Shoemaker wrote: > > I recently came across (via /.) a brief 1-page article titled "-Ofun": > > http://www.oreillynet.com/pub/wlg/7996. I agree with the author's > > thesis, which is that optimizing a project's development process for > > the pleasure of developers leads to all sorts of good things. > > Very interesting article - each objection is countered and he makes a good > case. Personally, I've found the "fun" being drained out of my gnucash > development because of the pressure to get G2 out. There are too few > developers and gnucash development itself, IMHO, is currently not much fun at > all.
I feel the same way, but I don't think it's because of any pressure related to G2. I think it's more just the whole painfulness of the whole process. I'm trying to pin down exactly what that includes. > > Nobody wants all this again with Gnome3. Something needs to change. I fear > the > loss of a "community" feel to gnucash. User community or developer community? Because I'm not sure I'd call this a "developer community". More like a small group of over-worked, over-tired, long-suffering, obstinately-determined coders desperate to have a decade's-worth of code not rot into oblivion. I don't know... an image of a pack of drowning rats just popped into my head. :) > > During my short time in gnucash, I've had contact with two possible new > developers who have decided not to pursue their interest. Various reasons are > given but the sense is that they have simply found something better to do > with their time. Something that is more fun, more involving and provides more > positive feedback may help to retain at least some of these people. > > How many of us have similar experience? Well, it's not for the easily depressed, but if you read -devel archives, you could probably come across ~50 of those over the past 5 years. :( > > > As applied to GnuCash, I would make a stronger assertion, though. I > > believe that GnuCash's continued progress and relavence, absolutely > > *depends* on a drastic revamping of the development process. > > I agree. > > What about this bit: > "Continuously push the team to sketch out ideas in code, committing quick and > dirty protypes that can be refactored as they grow." > > Quick and dirty prototypes may well break the overall build - I saw little in > the article about whether this was a problem or whether such a principle is > outdated by the move to a different version control method. Not outdated. In fact I think maybe this technique almost *requires* a version control with quick and easy branching. > The only > reference is v.brief: > > "Having this safety net allows the project to run full-bore without > time-wasting process getting in the way, and without undue worry that code > quality will suffer." > > The basis of the article is experience with the Perl6 compiler - a large and > complex project like that should mean that the benefits can be transferred to > our complex gnucash build. > > However, the devil may well be in the detail. By definition, people > interested > in a Perl6 compiler will tend to be other developers. Although gnucash-users > generates lots of wishlists and ideas, there aren't that many developers > coming our way. Our userbase is fundamentally different from the example in > the article. True, but the claim is that the project's success was due to the pleasant development process, not the project's content. I think it's a reasonable claim. > > So with limited numbers of possible new developers available, we aren't doing > a good job of encouraging their contribution. That needs to change. I agree, but I would say it differently. Let the pleasure of development be its own encouragement. We just need to remove the sources of *dis*couragement, i.e. the pain currently associated with development. > > > Fortunately, I don't think this will require much innovation. We can > > simply emulate the many projects that are thriving, attracting new > > developers, etc. However, I do think it will require a lot of > > initiative on our part. > > > > Does anyone agree? > > Yes. > > > If so, I'd like to start discussing what concrete things we can do to > > improve the whole developement experience, considering ideas from the > > article and elsewhere. > > > > E.g. Would a modern version-control system improve the development > > experience? (It seems like several of the other recommedations in the > > article depend on it.) > > By modern do you mean SVN or something more like GnuARCH? I've had a nasty > experience with gnuarch but I'm willing to give it another try. The problem > was that until the arch setup is well understood, it's a steep curve and the > confusion is immense. Simple failings in the "checkout" and "login" type > procedures are not handled gracefully by the current front ends - the errors > are misleading and unhelpful. The very fact that there are two front-ends > with different command sets is hard enough. I don't know what a good choice of version control would be. But I do know that if the version control is painful to use/learn, it pretty much doesn't support the goal of reducing pain. That said, I'm pretty close to desperate enough to try anything that looks promising. -chris _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
