Timothy Moore moore@bricoworks.com writes:
On Aug 8, 2005, at 1:11 PM, Christophe Rhodes wrote:
Thanks, I've applied this patch. (Whether it should take two weeks to apply a one-line patch, I don't know; you be the judge...)
No, it shouldn't. In my lame defense, I'm traveling and not paying much attention :) Thanks, Christophe.
I was going to start this message by saying "I wasn't trying to apportion blame", but then I realised that that would be a slightly disingenuous response. I was not and am not trying to apportion blame, but it was a pointed message nonetheless, and for the pointiness I apologise.
It does raise at least one question, though: who "owns" the McCLIM code, where by "owns" I actually mean "feels that he has ownership of"? Perhaps more to the point, who "owns" the development process? It's obviously harder to provide timely responses at present, when no-one can devote even a substantial portion of their time to McCLIM development, than it has been in the past, when students both feckless and directed have had as part of their tasks to work on it: now many of those students are Real People, with jobs and so on to sap their time and energy...
Now, we at work are using McCLIM as a substrate for our research and library work, but we seem to be diverging (not too rapidly yet, thankfully) in our local tree despite my having write access, simply because I cannot afford the time to take "ownership" (responsibility, if you will) of the various problems we encounter and work around -- such as the incremental-redisplay performance issues I've mentioned before, the status of arbitrary output-recording streams as candidates for updating-output, and suchlike -- we think we have another problem with freetype fonts (but the report for that might well be stuck in the mailing list moderation queue...), and so on, and so on.
I hope I'm not coming on too strong -- I certainly don't expect the world to arrange itself for my convenience, so that I can have what I want, right now -- but I think that we as a time-poor developer community need to think how best to manage going forward with McCLIM, now that a sufficient base of functionality has been built.
We don't have the luxury of commercial resources being thrown at us, and I suspect that this isn't going to change in the near term. Sadly, nor do I see much in the way of research funding in this area; these things are always possible -- I will try to sneak in requests for some time to work on the stack of lisp code that we use in future grant applications, for instance -- but the timescale and the odds are unfavourable. We even managed to avoid the shower of money (which, as Einstein proved, is equivalent to time) thrown at the Lisp community by Google -- the project I proposed to integrate R-trees into output-recording was not funded...
I suppose this boils down to two questions. Firstly, how do we best manage the development resources that we currently have? Some of this is a social problem, but the good news is that it's mostly technical: experience tells me that we're much better at solving technical problems than social ones. My own feelings on CLiki-as-bugtracker are known, I think, but Paolo is a perfectly acceptable User Interface from my point of view, so while he remains willing to serve like that, it's fine. What we lack is any kind of automatic regression testing to give confidence that bugs remain fixed; lacking a wide userbase as we do, we can't depend on timely notification of regressions from users. I have some of a Null backend for McCLIM which could be used, if completed, as a means of testing even the graphical output protocols; somewhat inevitably, though, I don't have time to advance on it at more than a snail's pace...
Secondly, how do we cause the available development resources to grow? Absent sources of funding, this means finding people to work for free... never a great prospect on its own. Killer apps and a certain amount of "evangelism" help; whether a text editor and a score editor are sexy enough for that, I don't know -- is anyone else working on anything exciting? (People here may not know that the closure web browser is at least partially revived: it is known to run in McCLIM using the X backend and recent CMUCL or SBCL releases; on the other hand, there's no way that a web browser is going to be a killer application in today's world...)
I'm afraid I don't have any easy answers -- and I know that these things take time. On the other hand, it's possible that a little thought now would reduce the time it takes for the situation with regards to active development to improve...
If you've made it down to here, congratulations, and thank you for reading :-). Any thoughts?
Cheers,
Christophe