Christophe Rhodes writes:
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"?
It would be hard to come up with such a person, I think.
Perhaps more to the point, who "owns" the development process?
That's a more reasonable question to ask. I think it would have to be a very active current developer, but I don't see one like that at the moment. Probably Tim Moore would be the one that comes closest.
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...
True, and I do think McCLIM needs such an owner (I have called that person a Newman-type person for McCLIM). I am afraid there are no candidates at the moment. And Tim now has a real job, so we can expect even less work on McCLIM from him.
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.
There are indeed many such problems that need to be addressed. While technically speaking I have the time over the next year to take on this ownership, I do not think I will, because I have at least two more large-ish programming projects to take care of. Though I guess if Dave Murray takes care of Climacs, and someone else of Gsharp, I could work on McCLIM :-)
Also, like I have said many times, McCLIM needs a near-total overhaul in terms of code maintainability and compliance with the standard. So if I were to take ownership, I would not start by fixing immediate problems, but by improving the code in order to make such fixes easier. We are talking at least a few months of work I would think.
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.
Sure.
I suppose this boils down to two questions. Firstly, how do we best manage the development resources that we currently have?
I think this will be hard unless there is at least one person willing to invest time in understanding the spec and the code. Only someone with a relatively global view of both would be able to determine whether a suggested patch for a problem will break something else. Now, with a bit of luck, that person would not have to actually do that much coding, but could rely on others to actually suggest patches.
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...
Automatic regression testing would be very nice, but it is a huge task in itself. It requires, it seems to me, having understood the spec, which we know is both ambiguous, self contradictory, and incomplete.
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 --
A score editor certainly has some limited audience, but it could be a killer app to its particular audience. For that, it needs to work properly, which is why I was planning to work on it a bit more this year.
A text editor could be a killer app when it acquires functionality comparable to SLIME, and even better in some areas. Implementing most of SLIME in Climacs probably requires a lot of work, but I am guessing that the existence of features unique to Climacs would attract more developers willing to put into it what is currently in SLIME. Though, that will not help McCLIM very much.
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...)
There are two different meanings here to "killer app". The first meaning is an application that is interesting to the general public and that provides functionality that existing applications do not have. Gsharp could become such an application, but it would attract very few, if any, developers.
The second meaning is an application that is uniquely hackable because it is written in CL and would therefore attract CL developers who would be willing to put up with fewer features than what some similar existing application have, in return for easily being able to add their own features. Closure and Climacs are such applications.
I think the second type of applications would be more suited to attract new developers for McCLIM.
And to answer your question, no I am not personally working on anything else, exciting or not.
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...
Definitely.
If you've made it down to here, congratulations, and thank you for reading :-). Any thoughts?
I really do think that someone would have to sacrifice the better part of a few months to fully read and understand the spec and the code. It would be easier for someone who has already read and understood the spec, of course.