(a reply to Matthew's post is in the 2nd half of this email.) On 21/10/10 21:29, Ian Clarke wrote: > Its not an "attitude", its a fact. Developers want to be part of projects > which are actually being used, and of course they need to discover those > projects in the first place. Few developers get excited about jumping on > board a project with a declining user-base.
This doesn't necessarily result in good project co-ordination/management. New developers result in (temporarily) *more disruption*, unless a project is well co-ordinated. >> So, I think a good way to address the problem of the bugtracker would be >> to re-think the current attitude towards releases. We want more users; >> however, many things that are needed to sustain this project in the long >> run **won't directly attract users** - doesn't mean we can skip or ignore >> them. > > Nobody suggested that. If you disagree, please provide specific examples. Um, well that was my entire point.. and the other 2 paragraphs you wrote (the ones I haven't quoted here) were actually straw men. I provided specific quotes at the bottom of my previous email. Also the evidence (ie. messy bugtracker) speaks for itself. You might not be neglecting it on purpose, but focusing on other things and never mentioning it, results in it being neglected. I've never seen you nor Matthew talk much detail about co-ordination/management. On 21/10/10 19:33, Matthew Toseland wrote: > My goal for Freenet is to have it secure, fast, and usable, solving the > substantial technical problems involved along the way, to have a lot of > users (hundreds of thousands at least), and to build a global darknet > (because IMHO the chances of a secure opennet are almost negligible, and a > robust opennet is a contradiction in terms) - which again requires a lot of > users and a lot of content. You spent most of your previous posts explaining why the current features are important, but really that's not what I'm arguing about. I don't have any gripes with what's *in* the roadmap, just its timing. You say that bugs will be dealt with in a separate period. Well, OK fine, this was not made explicit. I hope that you follow it through. > It is also very clear that more users results in more content results in > more users results in more content, that more performance, both in terms of > raw speed and data persistence, results in more users. The same is true of > ease of use, and of core functionality - which IMHO includes working > searching, easy blogging, chat, and filesharing. This is an oversimplified way of looking at things. More users means more support requests and more breakages and more attack attempts, and generally greater complexity. You need the infrastructure to deal with all of this. Otherwise, growth is unstable - does this not sound familiar? > Volunteer developers who do not depend on donation funding are very welcome > to do all those things. However if I am to expend effort on stuff that > won't get users, I will need to get value for money for my time. Volunteers have much less time than you do. If you go on speeding ahead with new features, whilst not doing enough bookwork/maintenance, we won't be able to keep up. (Think of a plane with a faster left engine than right.) The end result is that it becomes difficult to contribute future features, because we have this mountain of scrambled code/bugs to sift through. This *slows* user uptake *in the long run*. X -- GPG: 4096R/5FBBDBCE
