So, in software development you don’t actually need “vector graphics editor like Illustrator, but gratis” or “instant messenger like Miranda IM, but for Linux”. Yes, people ask for those every frigging day. What happens however, is when you define the project that way, you start meeting requests to make 100% copy of UI or features or both.

And this is when things go terribly wrong.

Since you don’t have the resources of a big company, your copy is never better, and you end up with software that sucks, and users who absolutely hate it. And they never ever forgive you attempts to make something original, because it’s not how you positioned your project. So you become a grumpy overworked monster who is never happy.

I think Sven had more or less that idea in mind regarding GIMP and Photoshop when he wrote: “We need to define our goals but we should by all means avoid to define our goals in terms of competitors.”. And the final product vision, as you can see, honors that view.

But when you fail to understand that you need to make your software appealing on its own, all you can do is define your own project via disadvantages of other projects (imaginary and obsolete at that, too).

So whoever is reading this and thinking about starting his/her own project, if you expect this project to take off, think about how you present it.

• Are you solving an issue bigger than “Oh noez, they killed Amarok with this new UI, we need a new player”?
• Can you explain the point of your software in one short phrase?
• Are you able to talk to your potential users in the language they understand?

It’s really important to pick the right words and explain the core idea without abusing buzzwords. I, for one, was particularly stubborn when it came to Novacut first, partially because they did not immediately deliver a definition that was understandable (and partially because I’m just very stubborn on my own). But after I listened to them long enough, things began to make sense. I am now confident that what Jason, Tara et al. are trying to achieve is a serious project.

Also, think of the technical side. Will your software blend into the mix? Does it have an architecture that’s not like a fractal sandwich? What does it take to install and try it?

At this point you might discover yourself balancing between software development, project management, QA, marketing, PR and copywriting. And it’s good. It means your brain is actually trying to work. It means you are discovering new angles to look at things from.

This also means that the existing intro text at inkscape.org is going away any time now. In a manner of speaking, Inkscape is much like Adobe Illustrator or Corel DRAW. But that’s not the point, you see

Last week Bitwig folks finally announced upcoming beta of Bitwig Studio, a new commercial DAW for Win, Mac and Linux. As it often happens, some folks in the community started speculating how this is going to affect existing free software and the community itself. After all, it’s not that we’ve got huge teams slaving away to make music production a breeze on Linux, eh?

Well, one thing I really liked in the LAU thread is that most folks who cared to comment didn’t express extreme views. I seriously hope that it’s a sign of the community becoming mature enough to treat things in a relaxed, no-fanatic way.

What I’ve been seeing on the desktop layer is that free/libre and commercial software can perfectly coexist without kicking each other in the nadgers and turning half the city to ruins. Just a few examples:

• Bibble Pro (Corel AfterShot Pro since last week, btw) didn’t make any existing free software die. Instead we got darktable.
• A month ago BrainDistrict announced PaintSupreme. Can you see Pinta folks crying in despair, because noone’s gonna use it again?
• BrainDistrict has also been resurrecting MainActor, and yet commits to Kdenlive, PiTiVi, Novacut and OpenShot keep piling up.
• Renoise didn’t kill any free software project, and they even added support for DSSI, a (currently outdated) free API for virtual instruments.
• Mixbus folks have been contributing to upstream Ardour project for a couple of years now already, and aren’t they proprietary guys?
• Loomer is busy porting their commercial synths and effects to LV2, the state of the art free API for virtual instruments and effects.
• linuxDSP started with Linux support from ground up and has been supporting LV2 since day one.
• ..and the list can go on.

The only fluctuation I can think of is the 8 years old story with Jorg Anders overreacting and abandoning NoteEdit after hearing about a, frankly speaking, fantom possibility of Finale port to Linux. And he started NtEd few years later anyway. That he doesn’t get much acknowledgment for NtEd either is a whole different story.

And even if you could recall all the epic OMG!Ubuntu threads about likewise phantom possibility of Photoshop port for Linux, you’d soon figure out that most people who expressed their interest weren’t going to use GIMP anyway. No love lost.

So if you think that some proprietary app suddenly available for Linux is going to do BLOOD NEEDLESS VIOLENCE GUTS OUTSIDE CITY TAKEN OVER DEAD BODIES ALL AROUND to your favourite free application, stop worrying. Fire up that free app and do something awesome with it. Work on your skills, become damn good at using free software, and then share what you know. This is how you become your own John McClane.

I haven’t covered Oyranos and related apps in a while simply because I found it increasingly difficult to explain why anyone would need them in real life, except ICC Examin which is a nice ICC inspection software (fails to work on Intel GPU, but that’s another story). However, the more I observe the whole colord/oyranos situation, the less I wish to have anything to do with Oyranos. Here is why:

Colord developer on Oyranos:

I don’t think it’s likely we’re ever going to see any interoperability between the colord and Oyranos projects in the future. Not for any huge ideological reason, but just because the feature overlap of the two projects is too small. Colord is of very limited scope, is installed by default and tries to make things just work. Oyranos is a project of huge scope that wraps many other libraries and tries to be involved in every part of the color workflow. It’s kind-of orthogonal to what colord is trying to be, and that’s the main reason I chose to start a new project rather than trying to fix Oyranos.

Note the courteous tone.

And now Oyranos developer:

What counts today is a very different understanding about, what makes a good colour management system. The colord author has failed to meet many criteria and was so far not very cooperative to accept some very common demands from various people in the colour community…

Beside that I believe, Oyranos is from a architectural level much better designed, because it relies as good as possible on existing standards, which colord does not care about.

Here is a clue. Colord is catering to Linux users who want color management to just work and not be pain in the arse. Oyranos is trying to work on all possible platforms and support all kinds of workflows. Which is why colord is now becoming mainstream (recent Fedora and Ubuntu relases have it), while Oyranos can mostly be found in the upcoming new version of OpenSUSE. Hence the bitching.

This kind of childish behavior is precisely the reason I’m getting less and less involved with some projects lately.

1. GNOME3 is designed for tablets, not desktops.

This one is controversial. There clearly are mobile inspired solutions in the Shell. At the same time, GNOME 3 is designed for desktops and is tested on desktops by people who use desktops, including dualhead configurations (an older screenshot by Jimmac below).

Oh, and these people do some quite cool things with Blender, Inkscape, GIMP and FontForge. So we are talking about serious software, not just facebooking and instant messaging.

I’ve yet to see a tablet running GNOME 3. Yet all the time I keep hearing about people who were handed a desktop with GNOME Shell and were able to immediately start using it.

2. GNOME3 is designed for using mouse rather than keyboard and requires too much activity.

I dare say there is a nice balance between use of keyboard, mouse and a combination of both.

3. GNOME3 is not extensible, and it’s about dumbing down user experience.

Quite the opposite. A lot of work has been done to make GObject introspection usable. Hence you can write your own extensions to GNOME Shell, and there are 15 extensions coming in GNOME 3.2, including system monitor that quite a few people have been missing in 3.0. There’s also SweetTooth project in works that simplifies management and installation of extensions.

Quoting the very same SweetTooth page:

Using extensions should never feel shameful for the user: they should be branded and recognized as “things that can make your Shell personalized, cool and more featureful!” We cannot see them as hacks, workarounds, prototypes, or fallbacks but instead as pieces of functionality that users may enjoy using, sometimes even more than the GNOME UX. We cannot blame them for challenging “the divine GNOME UX, the holy and blessed way to do things,”

Does it sound like dumbing down the desktop experience? Think again. And here is some advanced info on customization.

4. GNOME3 is designed and developed by new people who don’t respect GNOME2 users.

Quite a lot of people who work on G3 come with extensive G2 participation background (Andreas Nillson, Lapo Calamandrei, Mairin Duffy etc.), and some come even from the middle ages, that is, GNOME 1.x: Jimmac, Owen Taylor… You know them all, don’t you?

5. GNOME3 designers don’t listen to users, and the process isn’t open, because they don’t care about you.

A quote Jon McCann:

Some of the feedback is certainly valid and we are going to use that to make informed decisions in the GNOME3 cycle – remember we’ve only had one release so far. In couple of the talks we pointed out that it took us eight, nine years to get to where GNOME2 ended up and we’ve had like four months of GNOME3. So there are plenty of things we still have to do. There are a lot of holes in our story. People will look at some things and say “Why is this there? Does this really make sense?”. And in many cases that’s because we didn’t get to really finish that off. And that will start to fill in, the story will become a little bit more complete as we go through this cycle. I’m not saying that all this people will be completely convinced and that’s unfortunate but I think over time people will realize what we are doing has been at least thought through.

A quote from Allan Day:

Feedback does get read and gets weighed up against the other evidence that is available. I think it would be great if we had a more visible process there, however.

A quote from Shaun McCance

Just because I don’t publish reports doesn’t mean I don’t do user tests. And the constant assertions that nobody is looking at feedback are getting a bit insulting.

What about typical polls and surveys? Shaun McCance, again:

All methods have flaws. But user testing, at least, gives results that are personal and actionable. When I get results like “all 5 users were uncertain where to click when instructed to click the ‘user menu’”, I know what to do. I have no idea what to do with “63% of respondents report they are less happy than they were a year ago”.

Finally, on the transparence of the design process. Back to Allan Day:

The challenges that GNOME design faces are the same as any other part of GNOME. Writing documentation and communicating your activities is always difficult when you’re busy and focused on other things. This isn’t to say that we don’t need to do better, of course.

Hopefully that clears things up for you.

*sound of a falling body*

— Son?

*curtain falls*

The legend runs, as an ill-informed Phoronix user recently suggested, as this: “Just think, its only been 11 years since the functionality was handed to them on a silver platter and they rejected it unanimously in favor of vapor ware. It has got to be one of the biggest boneheaded moves in software development.”

It has got to be one of the biggest boneheaded moves in software development indeed, except the author of the statement is out of touch with reality. Let’s go back in history.

Cinepaint is a new name of FilmGIMP, the project born out of “Hollywood” branch of GIMP which was started in 1997. The first commit by the joint username “People doing a 16 bpc version of gimp” (more on that later) was done on December 15, 1997, and the last commit was done on August 27, 2002. Got the dates?

Now move to GEGL’s commit log. It starts on January 2, 2000, with commit of the very same username, “People doing a 16 bpc version of gimp”. The last commit from that username in GEGL was done on December 22, 2003.

So the idea that the pro-Cinepaint folks are trying to sell is that GIMP developers refused FilmGIMP developed by R&H developers in favour of vaporware GEGL developed by the very same R&H developers. Amazing, isn’t it? That’s some unbeatable logic if I ever saw one.

And yes — “People doing a 16 bpc version of gimp” is the joint username of Jonathan Cohen, Calvin Williamson and Caroline Dahllöf, all of them being developers at the famous Rhythm and Hues company at the time.

If you really want to understand how the actual FilmGIMP/GEGL developers (not either project leads) felt around 2002 when the whole unpleasantness was unleashed, read Jonathan’s mail to gimp-developer from early December 2002. It also answers the “why projects did not converge” concern re Cinepaint/FilmGIMP and GIMP. Then compare it to what you thought you knew.

You can choose to believe, or you can choose to find out what things really are—it’s entirely up to you. Either way, don’t fall for politics. And it’s the best advice I can give you at this time in the morning

This time it started with Linus trolling on GNOME 3. It was quite clear from the very beginning that both GNOME 3 and Unity are going to be love-or-hate desktops. So it was only a matter of time till Linus spoke his mind. But ZDnet’s Steven J. Vaughan-Nichols picked the story and wrapped it in a dozen of layers of bullshit.

What the story actually boils down to is that a Linux celebrity (well, THE celebrity, really) is trying to tell us that his truth is better than someone else’s (especially since not all of that is truth), and everyone who disagrees is insane.

I think we have a problem with our celebrities. Linus is a troll, RMS is a big annoying baby, and both have a huge following. You think that doesn’t shape evolution of free software and the way we are seen by the world? Oh, it does.

What Mr. Vaughan-Nichols is trying to tell us is that an opinion of one celebrity should suddenly put a stop to ongoing development of GNOME 3. Because Linus says so.

So the other problem is that people who should be writing for Vogue or Cosmopolitan happen to be columnists of leading IT websites due to a fluctuation in time and space.

Edit. I can see now why Steven adores Linus’s point of view. In an earlier article he writes: “First, did we really need a “completely new desktop?” I don’t think so. I quite liked GNOME the 2.x series. It worked well for me and I didn’t need to learn anything new to use it.” Note how he jumps between “we” and “I” as if it was same thing.

Let’s make it clear: I don’t think there is such a thing as a perfect desktop environment. I’ve tried pretty much everything there is to try and I’m sticking to a combination of GNOME 2.32 + Docky + GNOME Do at the moment. I was rather annoyed by Unity first, but after a while I can see some of the points and I’m sure I’ll try it again after release of 11.10. I like many aspects of GNOME 3 and it’s quite possible that I will make a switch to it after release of v.3.2.

Both desktops are reportedly appealing to newly arrived users who don’t have particular habits and hence don’t have to go through mistakes and imperfections of early desktop metaphor implementations.

And yes, it’s entirely up to you whether you want to be a moron and dismiss both background and perspective of the story off-hand. Just as long as you understand that drawing conclusions has a prerequisite of studying facts instead of making things up.

There already is some design/UX work done by Jimmac, with some useful comments from Hylke Bons to take into consideration.

What’s more important, there already is real code by Peter Hutterer that basically lacks calibration part. So all it needs is someone (yes, jonnor, I’m looking at you) willing to take existing code and add few missing things.

Then we can all make artsy types much happier users of GNOME. Because you can’t possibly dive into matrix calculation and come out a happy (or sane) person

Last few weeks have been rather crazy here, and it hasn’t exactly stopped yet, but I’ll do my best to find some time and do a series of blog postings on Google Summer from the inside. Just to answer a potential question, in the past years I was primary and backup admin for Hugin, Audacity, Scribus and OpenICC, and this year I’m primary admin for darktable.

This year accepted projects were announced on April 25 (you can read more on the multimedia related ones here), and some students got a sorry-to-tell-you notification from Google. I think not everyone was happy with that, and some people would probably like to know how decisions on proposals are done by organizations. Let’s start with that.

During first several years (GSoC was started in 2005) many organizations lost students at various stages of the program: some dropped out after midterm evaluation, some never shown up even after being confirmed to participate. This was mostly due to a very simple reason: GSoC wasn’t and isn’t how people naturally get involved with free software projects. The natural way is having an itch to scratch, being personally motivated to do something useful, whereas in case of GSoC many potential participants are not exactly interested in serious involvement with the project and often stop maintaining their code after final deadline. Not being personally motivated means a GSoC project has a high risk of failure.

So before reaching a decision every organization member (i.e. both admins and all mentors) who acts sensibly answers a number of questions before rating a project proposal. Here are the most important ones:

Do I already know this student for his/her past work in the project? Potential students who already contributed code in the past usually get a fav, since they already know their way around codebase and aren’t likely to disappear, because they usually depend on the sofwtare in question. In other words, they (potentially) have more project related skills and are emotionally attached to the project. It’s also why organizations who ask potential students to submit few patches first get less disappearing students: they learnt it the hard way.

Does this student really have skills to succeed with his/her project? There have always been people who overestimate their skills. We all love when people contribute lots of useful features, but when a student proposes a bunch of new stuff, whereas each and every proposed feature is known to take a full GSoC, there is clearly something wrong. This is one of the reasons why many, if not all organizations demand discussing proposals with potential mentors before submitting them. And potential students who have no history of contributing to the project usually get asked for code samples.

Is this student really interested in the project (s)he proposed? This isn’t even about not having some skills. The thing is that organizations see a lot of applicants who just want to take a simple project and make $5000 easily. This is not exactly the kind of attitude that is expected from a serious student. A project that is not challenging for a student is too easy to leave behind unfinished. I’ve seen it way too often in the past.

Is this student good at communication with the team? Half of the potential students who submitted applications to darktable organization this year never shown up in either mailing list or IRC. I’ve seen this with other organizations before and I think I can safely extrapolate that on other organizations: people who don’t communicate impose a high risk of failure on their projects. I’ve even seen applicants who not just never shown up in communication channels, but also refused to answer questionnaire that is the primary way to find out anything about a first-timer. I’m not sure I’m prepared to put it down to cultural differences.

Every rating by organization member adds up, and projects with highest rating are picked for the program. The amount of such projects corresponds to amount of slots, that is, amount of projects the organization claimed to be able to handle, and Google agreed to provide.

So this is about risks. Least risky GSoC projects, therefore, are submitted by potential students who already have a positive track record in the software project (organization), are known to be easy-going, propose projects that are interesting and challenging for them and are likely to stick to organization after GSoC. It doesn’t mean that you will not be accepted, if you don’t match something of that, quite on the contrary. But there will always be competing proposals, so you will have to try harder.

Sometimes organizations go for risky projects, when proposals are previously discussed with potential mentors and are then written thoroughly, that is, when we [organizations] are sure that you fully understand the risk and are capable of dealing with that. But this is not something you should be counting on. Some things we ask you to do before you are confirmed to participate may seem too much, the carrot being too short, the stick being too long and nasty looking.

Well, this is not venture investment, when one of of ten successful projects covers all expenses. We treat your success as our success, and we treat your failure as our failure. We are emotionally attached to your project, and if you don’t feel likewise, perhaps there is a better way to spend your summer and maybe even earn more money than with GSoC.

There are, of course, cases, when there are too many interesting and well written proposals and too few mentors to deal with all of them. In these cases we ask you to be understanding. If your proposal didn’t pass, there can be different reasons for that.

Which is why I encourage other organizations to write short polite mails to every unsuccessful applicant explaining why his or her proposal didn’t pass. Like many other things in life, free software development is a social activity; good software happens when people build upon each other’s success, and that’s a call for being goddamn nice to each other, eh? That’s coming from a two-faced twisted bastard that I am, too (hey, I said it again ^_^).

See you next time about keeping and raising motivation of students.

Darktable is pretty much modularized, so creating new stuff is rather easy. We’ve seen a number of contributors who come up with a complete new darkroom plug-in in practically no time. Most recently it was Rostyslav Pidgornyi with his “low light” plug-in that reuses our spiffy curve widget to provide simple UI for simulating human vision adapting to various lighting conditions.

If you like the idea of doing a GSoC project for us, you have nearly three weeks (till April 8th) to think about a project, introduce yourself, get accustomed, prepare an application, discuss it with your mentor and submit it.