It was amusing for a while, and at this point it is just sad. Every so often, maybe the Gimp team itself puts out a survey, or external groups do some analysis. The results are consistent in that the Gimp UI is just bad. Frequently the survey results specifically and overwhelmingly offer a path forward: make the Gimp behave like Photoshop.
Now, I understand that the Gimp is light on developers So it might be a simple labor issue in getting fixes in. Or there are fixes ready to go, and the Gimp team is as obstinate in their UI as have been suggested by many others. Either way, no change happens.
Note to UI/HCI academics: if you actually want to better a project, choose anything but the GIMP. You would have a better chance of getting patches accepted for ed(1).
Posted May 20, 2011 15:08 UTC (Fri) by intgr (subscriber, #39733)
[Link]
if you actually want to better a project, choose anything but the GIMP. You would have a better chance of getting patches accepted for ed(1).
While I'm not familiar with the subject, I get the impression from the article that they never intended to get their work upstream -- they forked not just GIMP, but also GIMP's libraries and changed them in a backwards-incompatible manner. They didn't even base their work on the GIMP development version, but the stable release, which would be quite painful to integrate back into current GIMP development branch. There are no "patches" to speak of, it's unfair to fault GIMP developers for this.
The older LWN article Realtime Linux: academia v. reality comes to mind, which paints a very grim picture of the academia. Basically it states that most of the time the academics are more concerned with chucking out lots of papers and promoting said papers, to get more citations. Improving the state of affairs, or even coming up with something applicable, is secondary.
Fools errand
Posted May 21, 2011 14:01 UTC (Sat) by Trelane (subscriber, #56877)
[Link]
> Basically it states that most of the time the academics are more concerned with chucking out lots of papers and promoting said papers, to get more citations. Improving the state of affairs, or even coming up with something applicable, is secondary.
Speaking as someone who is hopefully soon to be a recovering academic, this is systematically true.
Your sole value as a researcher is measured in papers (weighted by the impact factor of the journals in which they're published). That you create something further is irrelevant; as I've been told, "there's no line item in the grant for lines of software developed."
If you expect to be employed as a researcher, you must produce papers. Everything else is secondary and, as I've seen discussed on ScienceBlogs, may also be viewed as detrimental to your prospects of securing tenure. As a graduate student and postdoc, the sole goal for which you should be working is to produce more papers to get a job. After you (after some number of postdoctoral positions) land a (hopefully tenure-track) job, your sole job is to produce papers to obtain grants and get tenure. I've seen the faculty hiring process from the inside and the first and primary metric is how many papers and in what journals. If you tie for someone else, teaching may be taken into account. Maybe.
That you produce anything else is purely secondary and often counterproductive. You need papers, not software or novel experimental gear.
Fools errand
Posted May 21, 2011 14:26 UTC (Sat) by Trelane (subscriber, #56877)
[Link]
(and your gender makes a huge difference when applying for faculty jobs, for completeness)
Fools errand
Posted May 23, 2011 11:38 UTC (Mon) by job (guest, #670)
[Link]
It's a sad state of affairs, but isn't it much like democracy in that alternatives have so far proven to be worse..?
Fools errand
Posted May 21, 2011 15:06 UTC (Sat) by mjg59 (subscriber, #23239)
[Link]
To be fair, this is pretty much the norm in all of academia. Universities traditionally existed to learn things, not to make useful things out of them. Turning a research project into useful code generally gets left to external entities or spinoff companies (Xen's perhaps the most notable example of this in the Linux world).
This doesn't excuse the fact that a great deal of CS research seems to entirely ignore real-world constraints - coming from a (non-CS) academic background, I try to keep vaguely abreast of relevant published work. And pretty much everything written on power management has been based on assumptions that are either untrue or entirely irrelevant in the modern world, or alternatively has had an implementation proof that turned out to work entirely by accident.