I proposed we discuss this subject in our FOSDEM panel session, more details on that in FOSDEM: OSD Panel
Some notes on the subject from MY experience:
- Some organizations don’t monitor the design issues. They value more the development issues, so some designers don’t feel appreciated enough and it’s hard to quantify the work they do. There is a cloud of mysticism if a designer’s contributions are //really// valuable for the project.
- The target of some applications / platforms is very generic, so it’s very hard to know who the software is address to. Even if you, as a designer, know the target, the decision makers are the developers, not the users, not the designer. This process can create some discrepancies between what should be developed and what actually is implemented. Also lots of politics.
- OS users are more concerned with bugs than with usability or design improvements. If your organization is using a forum for example, as a designer you publish a design and ask feedback on it, there is a limited number of users that will actually provide feedback on it. So the decision again comes down to the people that participate more in the product, and those are usually the developers. Without having a clear validation that your work is productive and useful, as a designer, you might feel frustrated because of lack of feedback.
- Very high level of technical terms and technical problems to solve. There is a lack of interested in making a designer feel welcomed inside an OS community. If the designer can survive, than “good for him/her”.
- Loneliness: there are very few cases when multiple designers are working on the same project. That’s why I felt the need to be part of OSD community. I had no peers that shared the same concerns regarding the OS project, someone to talk to, someone to give ideas that are focused on user, not on performance and easiness of development.
- As a designer, you mostly fight for your opinions. When you provide a design, you need to educate the developers why that design is good, why it will work, how fast it will work, etc. Instead of designing more, you need more to convince that what you produce will work. If someone from the community doesn’t like what you propose OR it’s HARD to implement, there are few chances that will get implemented.
- OS projects are for mature (highly experienced), independent (proactive), opinionated designers that play the long-term game. Designers can’t play the hit-and-run approach in OS, since the committers need to gain trust in them. Few people have and agree to invest a lot of their time in OS projects, since they don’t see the benefit.
- You need to share the OS values. You cannot think that you will make money out of OS. You need to have the same views in case you want to produce quality stuff that will be accepted.