openSUSE Summit Talk
I received some feedback yesterday about the talk I gave at the openSUSE Summit. Unfortunately there is no recording of the talk. I thought that it was being recorded, but it was not. That is why I am posting the full talk here as I wrote it before the presentation. Hopefully it makes sense and gives an idea of what direction we have for welcoming new contributors.
----------------------------------------------------------------
It seems like yesterday when I was finally able to hold a computer. I was fascinated by the shape of this instrument, the keyboard, the mouse and screen. In my mind there was simply too much genius into this machine that I could never be capable to invent something quite like this.
Back then, having an Internet connection was a dream. Playing with the regular default games like Solitaire were the most entertaining activities in my day sitting in front of the computer.
Although I always believed that computers were going to be part of my future my life took a different route later on. I became very interested in the arts and I became a sketcher, drawer, and painter. I also enjoy history and learning languages. In fact, I graduated with a history degree from college. I enjoy good design and clever organization.
However, my old Windows 95, wasn’t what I needed. I wanted to place the arts into the computer so I embarked in the search for an operating system that would give me the flexibility of working with my art and interests, as well as providing good design and powerful tools for the desktop.
I found a page on alternative operating systems and tried some free alternatives of the time; QNX, BeOS, a few others that failed and eventually I ended up in Linux. I started buying Linux magazines. They featured burned CDs with a Linux copy of whatever system was issued then. Dial-up connections took longer to get the ISO than the magazine shipped to my town, so I chose the magazines over the Internet. I tried installing Best Linux, Mandrake, Slackware, Suse, PC Linux OS, Ubuntu, Vector Linux, PC-BSD, and a few others. In spite of the hardware compatibility problems of back then, eventually Linux became more robust and it was able to work with all of my hardware was the one I would choose to use.
In this search Suse fit right in. I was able to work with all of its tools and the good ol’ KDE 3. I loved the KDE interface and the font system. I am sorry if there are any Gnome lovers in the audience and if this offends you. I loved the power configurations that you could do on KDE as well as some window style themes like Domino window style and others. I was able to use GIMP, Krita, Kaffeine and a few others.
Working with Linux filled my spirit with great enthusiasm. I realized that Linux was present in many places already and that the industry would eventually embrace Linux by porting applications to it. This time was when I started asking for support on IRC. I saw the good amount of people who loved Linux and how willing many of them were to help new users like me. IRC showed me that there are people in this world still who will donate their genius to the world. People who will use their free and busy time to code for an open source project. I decided to give back to the community. But the question was not about willingness, but about ability? Did I have what was needed to enter an open source community?
This is what brings me here today. Stories like mine are countless and yet it seems so refreshing to share them. Coming from the non-technical world, working with the community was a challenge. How can you, who only “uses” a computer, contribute in any meaningful way to the project that “codes” for computers?
As I mentioned, I used IRC to connect to some of the members. First asking some questions and then giving suggestions. But many things that “I” wanted were not so easy to do, therefore my suggestions went nowhere. A typical response from the community was, if you want to change it, do it yourself. While that sounds like a very good response that empowers individual users to work with open source code, there was little I could do to help or change what I wanted to contribute with. I tried long and hard for a while to convince some people to put into code some of my ideas but with little success.
I decided to reduce the scope of my requests. Little by little I realized that, instead of asking for changes, I needed to contribute. I could not make others contribute for me.
I decided then to create a blog. Just a simple tool to show others about my ideas on GUI design. The blog still brings some people to it. I am not the next Facebook but I do feel like my ideas posted there get some traction. I published ideas on how KDE could look on openSUSE. I focused my comments particularly on working with KDE 4 and openSUSE. I have always wanted a radical GUI change for openSUSE, and I still do.
I do not think that my comments got too far. The biggest thing achieved by my blog was when Aaron Seigo from the KDE project read one of the entries on my blog and decided to show a quick programing example using a desktop switcher idea that I wrote about. I didn’t even ask him to do it and it happened. My blog had reached further that I could ever do it on IRC.
I realized that I needed to speak the language of those who change the current in the Linux world, and that was by doing it yourself. But I needed to focus my contribution. I could not ask anyone to code for me but I could sway opinions about artwork. Overtime I have participated in creating some simple artwork for the distribution. Recently, we had a Novell conference in the town where I live. I was invited to it and met some of the people I mingled with on IRC.
My involvement with the openSUSE community could represent the involvement that many other non-technical contributors go through as they approach working with open source communities. I happen to be a historian and my training has made me take a more critical look at the events that lead up to my participation and the participation of non-technical contributors to the projects we love. When I mean non-technical, I mostly mean that I cannot program code.
Being part of an open source project is in its very nature a “public” event. Just like I had to become “public” with my blog, open source communities are not only open source but also public source. Meaning that the very nature of your contributions to an open source project are made publicly available. It is a meeting where the whole world is invited. Open source projects are perused thoroughly. Interestingly enough, in many instances when the solitary confinement of a home basement gives birth to wonderful open source projects that attract much attention to programmers who might not expect to be in the forefront of their project.
Take, for example, Linus Torvalds. By sending a simple invitation to write code for his newly developed kernel, Linus became a star ever since. However, Linus remains away from the spotlight, as much as he can, by avoiding large audiences and venues that place too much attention on him. Although Linus remains a fiery commentator, he has never liked the attention that his kernel brought upon him. This could be true of many other programmers who may be confronted with the publicity that their open source work generates.
The project created attracts people of all places and languages. Even people who who may not understand the complexities of the creation of such project. People who only see the end result, the non-technical user. However, the expectations vary from audience to audience as the open source project is made available. In the case of non-technical users, they may demand that the functions of the software be perfect. Many new users assume that the developer is completely in charge of the open source project when in most cases there may be many contributors to the project who do not have specific functions. This situation makes support harder to achieve on the end user’s point of view. Many of them will feel left out when trying to understand why a certain program does not run on their Linux computer.
Non-technical users who want to contribute will also assume many things when coming in contact with a technical open source community.
Recognition
Collaboration
Availability
Technical users on the other hand expect
Recognition
Collaboration
Availability
I categorized these priorities as the same on purpose. However, the interpretation of these terms is rather different depending of what end of the spectrum you are.
On the non-technical collaborator side, recognition means that non-technical user contributions do have weight and are understood by the rest of the community members. We may incur into thinking that our contributions are truly ground-shaking, earth-shaping, world-saviors. Non technical users will think that their simple ideas put them ahead of the thinking done by technical users. We have a better answer.
However, for technical users who can program, recognition starts when others understand the trouble, time and effort that they took into creating a piece of software for the world to use. Recognition that their work has class and it is relevant for others. Overstepping these ideas on both worlds could lead both type of community members to disagree in their views about a specific project. While technical users are contempt, for example, with the powerful features of Yast in openSUSE, some like me might be unhappy with the GUI design of it. We are speaking about the same project yet, I could miss the recognition solely based in my assumptions about Yast not being good-looking and missing the fact that it is a powerful graphical tool.
Similarly, technical users may focus on the programming strengths of their software and miss the graphical elegance that you could integrate into the program upon suggestions from a non-technical community member.
In these interactions both type of members may also misunderstand the collaboration that each of them can integrate into a particular project. While there is always assumptions about newcomers and over-stayers in an open source project, there is also a good amount of misunderstanding about one’s capabilities. If you are a newcomer to the open source world, being non-technical may brand you as someone who “does not understand everything” meaning that overall there are many things for you to learn before entering a project. On the opposite end there is also assumptions made by non-technical users about the technical users’ collaboration. Non-technical users assume that technical users operate much like a customer service department. They are part of a project only to help and fix problems. While some of this hints at the reality, it is only a partial picture of reality.
Non-technical users miss the opportunity of collaborating with the tech savvy because they only intend to drive the development of an app and rarely intend to do it themselves. Both parties then withdraw and little advancement and integration is made.
Availability is another convergence point for open source project members. They have, as experienced, expectations about the availability of each party. While technical users always seems to be ready to take on order on IRC, nontechnical users should join a project only if they are able to put in the time to work on it, or for it. Neglecting people’s availability is a major cause of project coding delay. Not understanding the work and part that each person takes in a project could result in a release that is half-way done. Often times new users in a project may assume that people are online 24/7 thinking that emailing will not take long, IRC chats and comments will be instantaneous, and that adding a line of code will be done telepathically. In reality, most of us do not work for the project. The project is a side note, unless you are apart of a corporation such as Canonical, or Novell, and people have been assigned to work for open source projects. This does not mean in any way that people who have been hired for a specific community project have a little less desire or time to work on it. The point is that the majority of us contribute with free time or do something on a whim. It happens to me personally, I get inspired to create artwork at random and suddenly this could be interpreted as me signing a life of devotion toward a project, when in reality I would only like to have my work be used and forget about it later.
This could also account for a high turnover of contributors to open source projects. Likely new users, technical and non-technical join a project with the fire of their desire to contribute with an idea. Suddenly they are confronted with the three misconceptions outlines before and realize that open source project completely depend on the voluntary contributions of its members. I highlight “voluntary” because this word shows elasticity in time frames, consistency and desire to strive with a particular project. Then, newcomers slow down, their fire goes out and eventually they could become a passive or completely inactive contributor.
Some may think that the project or the community will be magnetic enough on its own that people will join the community by its sheer weight, however this may not be the case all the time. Non-technical users get to feel the weight of the disparaging differences between how little they know about the community and what a tough relationship this could be when trying to make contributions to a community that is far more experienced in coding and other venues.
Eventually, a miscommunication between the technical community and the non-technical contributor could lead into the break between potentially great contributions and a project that could actually use the contributions. After all, the life of a community comes from its members, there is nothing done in a community project until a member contribution is made. Meaning eventually that not having any use of the new non-technical contributors makes the project slow down, and miss opportunities for change and advancement.
Willingness of new users to learn the ways of the community is also fundamental for the healthy relationship between the two. New users are to be much like a sponge when coming into contact with the community. There might be many instances when there were new members unwilling to learn the ways of the community. Unwilling to understand and follow established procedures as well as traditions. In this case it does not matter how brilliant a new community member might be, there is an element of personal appreciation in the community, the additions will not be taken into consideration. The technical community member will disregard your contributions as important.
Obviously, these are very general statements from personal observation throughout my time with the openSUSE community. Can or is this situation any different? of course. Is the community to do anything to keep or invite new members? Yes, definitely. There might be some programs, such as the ambassador program in openSUSE that empowers community members to participate in the community by adding what they can. But introducing people to the local community might not be as challenging as introducing a new community member to a global community. Then there is less to manage, less faces to see, and eventually, less work to be done.
The goal of this analysis is not to point fingers at community members for not understanding the non-technical population of their teams, but rather to understand the tremendous potential that their work can accomplish. Making ourselves cognizant of the tremendous reach that we can achieve with our communities by embracing non-technical users could be the biggest accomplishment of an open source community.
Some could wonder, how is it possible that a community that advocates the creation of code is capable of being so welcoming that even the least technical person can be part of it? This realization by the rest of the users and open source enthusiasts can eventually gather a swarm of strong collaborators to a project. Injecting the needed speed and expertise into a particular project.
Our aim however is the reach of harmony. While we all may be different species, we live in the same jungle harmoniously. What does it take for non-technical users to join the pack of technical users? A simple reminder of what we can do and the water we are trying to swim on. What does it take for technical users to understand non-technical users? It is to understand that we all need water to survive. Whether we like it or not, we will come to the river for sustenance. Some of us will likely stay next to the river for the rest of our lives.
Thank you
----------------------------------------------------------------
The Rest of Us, Open Source Communities and Non-technical Users
It seems like yesterday when I was finally able to hold a computer. I was fascinated by the shape of this instrument, the keyboard, the mouse and screen. In my mind there was simply too much genius into this machine that I could never be capable to invent something quite like this.
Back then, having an Internet connection was a dream. Playing with the regular default games like Solitaire were the most entertaining activities in my day sitting in front of the computer.
Although I always believed that computers were going to be part of my future my life took a different route later on. I became very interested in the arts and I became a sketcher, drawer, and painter. I also enjoy history and learning languages. In fact, I graduated with a history degree from college. I enjoy good design and clever organization.
However, my old Windows 95, wasn’t what I needed. I wanted to place the arts into the computer so I embarked in the search for an operating system that would give me the flexibility of working with my art and interests, as well as providing good design and powerful tools for the desktop.
I found a page on alternative operating systems and tried some free alternatives of the time; QNX, BeOS, a few others that failed and eventually I ended up in Linux. I started buying Linux magazines. They featured burned CDs with a Linux copy of whatever system was issued then. Dial-up connections took longer to get the ISO than the magazine shipped to my town, so I chose the magazines over the Internet. I tried installing Best Linux, Mandrake, Slackware, Suse, PC Linux OS, Ubuntu, Vector Linux, PC-BSD, and a few others. In spite of the hardware compatibility problems of back then, eventually Linux became more robust and it was able to work with all of my hardware was the one I would choose to use.
In this search Suse fit right in. I was able to work with all of its tools and the good ol’ KDE 3. I loved the KDE interface and the font system. I am sorry if there are any Gnome lovers in the audience and if this offends you. I loved the power configurations that you could do on KDE as well as some window style themes like Domino window style and others. I was able to use GIMP, Krita, Kaffeine and a few others.
Working with Linux filled my spirit with great enthusiasm. I realized that Linux was present in many places already and that the industry would eventually embrace Linux by porting applications to it. This time was when I started asking for support on IRC. I saw the good amount of people who loved Linux and how willing many of them were to help new users like me. IRC showed me that there are people in this world still who will donate their genius to the world. People who will use their free and busy time to code for an open source project. I decided to give back to the community. But the question was not about willingness, but about ability? Did I have what was needed to enter an open source community?
This is what brings me here today. Stories like mine are countless and yet it seems so refreshing to share them. Coming from the non-technical world, working with the community was a challenge. How can you, who only “uses” a computer, contribute in any meaningful way to the project that “codes” for computers?
As I mentioned, I used IRC to connect to some of the members. First asking some questions and then giving suggestions. But many things that “I” wanted were not so easy to do, therefore my suggestions went nowhere. A typical response from the community was, if you want to change it, do it yourself. While that sounds like a very good response that empowers individual users to work with open source code, there was little I could do to help or change what I wanted to contribute with. I tried long and hard for a while to convince some people to put into code some of my ideas but with little success.
I decided to reduce the scope of my requests. Little by little I realized that, instead of asking for changes, I needed to contribute. I could not make others contribute for me.
I decided then to create a blog. Just a simple tool to show others about my ideas on GUI design. The blog still brings some people to it. I am not the next Facebook but I do feel like my ideas posted there get some traction. I published ideas on how KDE could look on openSUSE. I focused my comments particularly on working with KDE 4 and openSUSE. I have always wanted a radical GUI change for openSUSE, and I still do.
I do not think that my comments got too far. The biggest thing achieved by my blog was when Aaron Seigo from the KDE project read one of the entries on my blog and decided to show a quick programing example using a desktop switcher idea that I wrote about. I didn’t even ask him to do it and it happened. My blog had reached further that I could ever do it on IRC.
I realized that I needed to speak the language of those who change the current in the Linux world, and that was by doing it yourself. But I needed to focus my contribution. I could not ask anyone to code for me but I could sway opinions about artwork. Overtime I have participated in creating some simple artwork for the distribution. Recently, we had a Novell conference in the town where I live. I was invited to it and met some of the people I mingled with on IRC.
My involvement with the openSUSE community could represent the involvement that many other non-technical contributors go through as they approach working with open source communities. I happen to be a historian and my training has made me take a more critical look at the events that lead up to my participation and the participation of non-technical contributors to the projects we love. When I mean non-technical, I mostly mean that I cannot program code.
Being part of an open source project is in its very nature a “public” event. Just like I had to become “public” with my blog, open source communities are not only open source but also public source. Meaning that the very nature of your contributions to an open source project are made publicly available. It is a meeting where the whole world is invited. Open source projects are perused thoroughly. Interestingly enough, in many instances when the solitary confinement of a home basement gives birth to wonderful open source projects that attract much attention to programmers who might not expect to be in the forefront of their project.
Take, for example, Linus Torvalds. By sending a simple invitation to write code for his newly developed kernel, Linus became a star ever since. However, Linus remains away from the spotlight, as much as he can, by avoiding large audiences and venues that place too much attention on him. Although Linus remains a fiery commentator, he has never liked the attention that his kernel brought upon him. This could be true of many other programmers who may be confronted with the publicity that their open source work generates.
The project created attracts people of all places and languages. Even people who who may not understand the complexities of the creation of such project. People who only see the end result, the non-technical user. However, the expectations vary from audience to audience as the open source project is made available. In the case of non-technical users, they may demand that the functions of the software be perfect. Many new users assume that the developer is completely in charge of the open source project when in most cases there may be many contributors to the project who do not have specific functions. This situation makes support harder to achieve on the end user’s point of view. Many of them will feel left out when trying to understand why a certain program does not run on their Linux computer.
Non-technical users who want to contribute will also assume many things when coming in contact with a technical open source community.
Recognition
Collaboration
Availability
Technical users on the other hand expect
Recognition
Collaboration
Availability
I categorized these priorities as the same on purpose. However, the interpretation of these terms is rather different depending of what end of the spectrum you are.
On the non-technical collaborator side, recognition means that non-technical user contributions do have weight and are understood by the rest of the community members. We may incur into thinking that our contributions are truly ground-shaking, earth-shaping, world-saviors. Non technical users will think that their simple ideas put them ahead of the thinking done by technical users. We have a better answer.
However, for technical users who can program, recognition starts when others understand the trouble, time and effort that they took into creating a piece of software for the world to use. Recognition that their work has class and it is relevant for others. Overstepping these ideas on both worlds could lead both type of community members to disagree in their views about a specific project. While technical users are contempt, for example, with the powerful features of Yast in openSUSE, some like me might be unhappy with the GUI design of it. We are speaking about the same project yet, I could miss the recognition solely based in my assumptions about Yast not being good-looking and missing the fact that it is a powerful graphical tool.
Similarly, technical users may focus on the programming strengths of their software and miss the graphical elegance that you could integrate into the program upon suggestions from a non-technical community member.
In these interactions both type of members may also misunderstand the collaboration that each of them can integrate into a particular project. While there is always assumptions about newcomers and over-stayers in an open source project, there is also a good amount of misunderstanding about one’s capabilities. If you are a newcomer to the open source world, being non-technical may brand you as someone who “does not understand everything” meaning that overall there are many things for you to learn before entering a project. On the opposite end there is also assumptions made by non-technical users about the technical users’ collaboration. Non-technical users assume that technical users operate much like a customer service department. They are part of a project only to help and fix problems. While some of this hints at the reality, it is only a partial picture of reality.
Non-technical users miss the opportunity of collaborating with the tech savvy because they only intend to drive the development of an app and rarely intend to do it themselves. Both parties then withdraw and little advancement and integration is made.
Availability is another convergence point for open source project members. They have, as experienced, expectations about the availability of each party. While technical users always seems to be ready to take on order on IRC, nontechnical users should join a project only if they are able to put in the time to work on it, or for it. Neglecting people’s availability is a major cause of project coding delay. Not understanding the work and part that each person takes in a project could result in a release that is half-way done. Often times new users in a project may assume that people are online 24/7 thinking that emailing will not take long, IRC chats and comments will be instantaneous, and that adding a line of code will be done telepathically. In reality, most of us do not work for the project. The project is a side note, unless you are apart of a corporation such as Canonical, or Novell, and people have been assigned to work for open source projects. This does not mean in any way that people who have been hired for a specific community project have a little less desire or time to work on it. The point is that the majority of us contribute with free time or do something on a whim. It happens to me personally, I get inspired to create artwork at random and suddenly this could be interpreted as me signing a life of devotion toward a project, when in reality I would only like to have my work be used and forget about it later.
This could also account for a high turnover of contributors to open source projects. Likely new users, technical and non-technical join a project with the fire of their desire to contribute with an idea. Suddenly they are confronted with the three misconceptions outlines before and realize that open source project completely depend on the voluntary contributions of its members. I highlight “voluntary” because this word shows elasticity in time frames, consistency and desire to strive with a particular project. Then, newcomers slow down, their fire goes out and eventually they could become a passive or completely inactive contributor.
Some may think that the project or the community will be magnetic enough on its own that people will join the community by its sheer weight, however this may not be the case all the time. Non-technical users get to feel the weight of the disparaging differences between how little they know about the community and what a tough relationship this could be when trying to make contributions to a community that is far more experienced in coding and other venues.
Eventually, a miscommunication between the technical community and the non-technical contributor could lead into the break between potentially great contributions and a project that could actually use the contributions. After all, the life of a community comes from its members, there is nothing done in a community project until a member contribution is made. Meaning eventually that not having any use of the new non-technical contributors makes the project slow down, and miss opportunities for change and advancement.
Willingness of new users to learn the ways of the community is also fundamental for the healthy relationship between the two. New users are to be much like a sponge when coming into contact with the community. There might be many instances when there were new members unwilling to learn the ways of the community. Unwilling to understand and follow established procedures as well as traditions. In this case it does not matter how brilliant a new community member might be, there is an element of personal appreciation in the community, the additions will not be taken into consideration. The technical community member will disregard your contributions as important.
Obviously, these are very general statements from personal observation throughout my time with the openSUSE community. Can or is this situation any different? of course. Is the community to do anything to keep or invite new members? Yes, definitely. There might be some programs, such as the ambassador program in openSUSE that empowers community members to participate in the community by adding what they can. But introducing people to the local community might not be as challenging as introducing a new community member to a global community. Then there is less to manage, less faces to see, and eventually, less work to be done.
The goal of this analysis is not to point fingers at community members for not understanding the non-technical population of their teams, but rather to understand the tremendous potential that their work can accomplish. Making ourselves cognizant of the tremendous reach that we can achieve with our communities by embracing non-technical users could be the biggest accomplishment of an open source community.
Some could wonder, how is it possible that a community that advocates the creation of code is capable of being so welcoming that even the least technical person can be part of it? This realization by the rest of the users and open source enthusiasts can eventually gather a swarm of strong collaborators to a project. Injecting the needed speed and expertise into a particular project.
Our aim however is the reach of harmony. While we all may be different species, we live in the same jungle harmoniously. What does it take for non-technical users to join the pack of technical users? A simple reminder of what we can do and the water we are trying to swim on. What does it take for technical users to understand non-technical users? It is to understand that we all need water to survive. Whether we like it or not, we will come to the river for sustenance. Some of us will likely stay next to the river for the rest of our lives.
Thank you
0 comments:
Post a Comment