focus for this week: Why don't birds fly backwards ?
>1.1 mio views (popular pages, total: 2,030)

Open Advice/Do not Be Shy

From I ask questions
Jump to: navigation, search

Don’t Be Shy

by Máirín Duffy Strode
in: Open Advice


This text is available under the CC-BY-SA license. (see also: Open Advice/Info)


I knew about and used Free and Open Source software (FOSS) for a long time before I became a contributor. This was not for lack of trying – there were a couple of false starts, and I succumbed to them mostly out of being too shy and afraid to push through them. From the aftermath of those false starts and also from on-boarding other designers in FOSS projects, I have five tips to offer to you as a designer trying to ramp up as a FOSS contributor:

Contents


1. Know that you are needed and wanted (badly!)

My first false start happened when I was a first-year computer science student at Rensselaer Polytechnic Institute. There was a particular project I used a lot and I wanted to get involved with it. I did not know anyone in the project (or anyone who was involved in free software) so I was trying to get involved pretty cold. The project’s website indicated that they wanted help and that they had an IRC channel, so I lurked in there for a week or two. One day after a lull in conversation, I spoke up:

I said I was a computer science student interested in usability and that I would love to get involved.
“Go away” was the response. Furthermore, I was told that my help was not needed nor wanted.

This set me back a few years in getting involved – just a few harsh words on IRC made me afraid to try again for almost 5 years. I did not discover until much later that the person who had essentially chased me out of that project’s IRC channel was on the fringes of the project and had a long history of such behavior, and that I really had not done anything wrong. If I had only kept trying and talked to other people, I may have been able to get started back then.

If you would like to contribute to Free and Open Source software I guarantee you there is a project out there that really needs your help, especially if you are design-minded! Are you into web design? Iconography? Usability? Skinning? UI mockups? I have spoken to many FOSS developers who are not only desperate for this kind of help, but who would also deeply appreciate it and love you to pieces for providing it.

If you encounter some initial resistance when first trying to get started with a project, learn from my experience and do not give up right away. If that project turns out to not be right for you, though, do not worry and move on. Chances are, you are going to find a project you love that loves you back.

2. Help the project help you help them

Many Free and Open Source Software projects today are dominated by programmers and engineers and while some are lucky enough to have the involvement of a creative person or two, for most projects a designer, artist, or other creative’s presence is an often-yearned-for-yet-never-realized dream. In other words, even though they understand they need your skills,

they may not know what kinds of help they can ask you for,
what information they need to give you to be productive,
or even the basics of how to work with you effectively.

When I first started getting involved in various FOSS projects, I encountered many developers who had never worked directly with a designer before. At first, I felt pretty useless. I could not follow all of their conversation on IRC because they involved technical details about backend pieces I was not familiar with. When they bothered to pay attention to me, they asked questions like, “What color should I put here?” or “What font should I use?” What I really wanted as an interaction designer was to be privy to decision-making about how to approach the requirements for the project. If a user needed a particular feature, I wanted to have a say in its design – but I did not know when or where those decisions were happening and I felt shut out.

Design contains a pretty wide range of skills (illustration, typography, interaction design, visual design, icon design, graphic design, wordsmithing, etc.) and any given designer likely does not possess all of them. It is understandable, then, that a developer might not be sure what to ask you for. It is not that they are trying to shut you out – they just do not know how you need or want to be involved.

Help them help you. Make it clear to them the kind of work you would like to offer by providing samples of other work you have done. Let them know what you need so they can better understand how to help you engage in their project. For example – when you first get involved in a particular initiative for the project, take the time to outline the design process for it, and post it on the main development list so other contributors can follow along. If you need input at particular points in the process, flag those points in your outline. If you are not sure how particular things happen – such as the process for developing a new feature – approach someone on the side and ask them to walk you through it. If someone asks you to do something beyond your technical ability – working with version-control, for example – and you are not comfortable with that, say so.

Communicating your process and needs will prevent the project from having to make guesses and instead they will be able to make the best use of your talents.

3. Ask questions. Lots of questions. There are no stupid questions.

We have noticed sometimes in Fedora that when new designers come on board, they are afraid to ask technical questions for fear they will look stupid.

The secret is, developers can be so specialized that there are a lot of technical details outside of their immediate expertise that they do not understand either – this happens even within the same project. The difference is that they are not afraid to ask – so you should not be, either! In my interaction design work, for example, I have had to approach multiple folks on the same project to understand how a particular workflow in the software happens, because it is passed off between a number of subsystems and not every person in the project understands how every subsystem works.

If you are not sure what to work on, or you are not sure how to get started, or you are not sure why that thing someone said in chat is so funny – ask. It is a lot more likely someone is going to tell you that they do not know either, than they are going to think that you are stupid. In most cases, you will learn something new that will help make you a better contributor.

It can be especially effective to seek out a mentor – some projects even have mentoring programs – and ask them if they would not mind being your go-to person when you have questions.

4. Share and share often. Even if it is not ready yet.

Especially if it is not ready yet. We have also noticed new designers in Fedora and other Free and Open Source projects are a little shy when it comes to showing their work. I understand that you do not want to ruin your reputation by putting something out there that is not your best or even finished, but a big part of how Free and Open Source projects work is sharing often and openly.

The further along you have come on a piece before you have shared it, the harder others will find it to provide you actionable feedback and to jump in and get involved. It is also harder for others to collaborate on your piece themselves and feel a sense of ownership for it, supporting and championing it through to implementation. In some Free and Open Source projects, not being forthcoming with your sketches, designs, and ideas is even seen as offensive!

Post your ideas, mockups, or designs on the web rather than in email, so it is easy for others in the project to refer to your asset via copying and pasting the URL – especially handy during discussions. The easier it is to find your design assets, the more likely it is they will be used.

Give this tip a try and keep an open mind. Share your work early and often, and make your source files available. You might be pleasantly surprised by what happens!

5. Be as visible as you can within the project community.

One tool that – completely unintentionally – ended up helping me immensely in getting started as a FOSS contributor was my blog. I started keeping a blog, just for myself, as a sort of rough portfolio of the things I had been working on. My blog is a huge asset for me, because:

  • ˆ As a historical record of project decisions, it is a convenient way to look up old design decisions – figure out why we had decided to drop that screen again, or why a particular approach we had tried before did not work out, for example.
  • ˆ As a communication device, it helps other contributors associated with your project and even users become aware of what work is happening and aware of upcoming changes in the project. Many times I have missed something essential in a design, and these folks have been very quick to post a comment letting me know!
  • ˆ It helped me to build my reputation as a FOSS designer, which has helped me build others’ trust in my design decisions as time has gone on.

Do you blog? Find out which blog aggregations the members of the project you are working on read, and put in requests to have your blog added to them (there is usually a link to do so in the sidebar.) For example, the main blog aggregator you will want to join to become a part of the Fedora community is called Planet Fedora. Write a first blog post once you have been added introducing yourself and letting folks know what you like – all of the sort of information advised in tip #1.

The project will surely have a mailing list or forum where discussion takes place. Join it, and send an intro there too. When you create assets for the project – no matter how small, no matter how unfinished – blog about them, upload them to the project wiki, tweet/dent about them, and send links to prominent community members on IRC to get their feedback.

Make your work visible, and folks will start to associate you with your work and approach you with cool projects and other opportunities based solely on that.

This is everything I wish I had known when first trying to get involved in Free and Open Source software as a designer. If there is any one thing you should take away from this, it is that you should not be shy – please speak up, please let your needs be known, please let others know about your talents so they can help you apply them to making Free Software rock.

about the author

Máirín Duffy Strode has been using Free and Open Source software since she was in high school, and has been a contributor for the past 8 years. She is involved in both the Fedora and GNOME communities and has worked on interaction design, branding, and/or iconography for a number of prominent FOSS applications such as Spacewalk, Anaconda, virt-manager, SELinux and SSSD. She has also been involved in outreach efforts teaching children design skills using FOSS tools such as GIMP and Inkscape and is a fierce advocate for said tools. She is the team lead of the Fedora Design Team and a senior interaction designer with Red Hat, Inc.

Personal tools