It comes down to this: we’re in a scenario that most of us as professional creatives should recognize. When we’re working with a client on a design or a bit of writing or animation or music, our customers have great intuition about “feeling” when something is wrong or not working in the piece. However, they don’t have the tools, language, or experience to understand why a thing isn’t working. Very rarely do they have the right solution to effectively resolve the issue. As artists and designers, we have to take their feedback and translate it to understand the central nugget of the problem that they’re pointing out.
Likewise, in the case of being users of open source software tools, we are in the role of client. We know that there’s an issue and we know that it’s been solved in other contexts… but we’re not necessarily the best-qualified to express a solution in this particular context.
We should recognize this scenario, but often we don’t. And even more frequently, our colleagues in the closed source creative world fail to recognize it even more frequently. They often mistakenly consider open source software (and its development) as a public service and that their demands are right and good, and that there’s some obligation for developers to follow them. As open source creatives, it’s incumbent upon us to gently explain to them how things really work… without being jerks in the process.
That’s what I try to cover in this week’s show.
Oh… and as I mentioned, I do have a “Python Tricks for Artists” series over on Opensource.com. The latest article is on adding some basic interactivity to scripts that you’ve already written.
Catch you next week!