design with and within community

7/27/2019 Design With and Within Community

1/12

PREPRINT: Designing with and within a Community: Heuristic techniques for designing with and within Open Source Software Development 1

1. Introduction

e open source paradigm is described as a production paradigm in which all the in-ormation necessary to produce a nal product is reely accessible and redistributed [1].istorically, the concept o open access to inormation is well established and has alwaysbeen a undamental condition or the development o sciences, technologies, education,

art, cuisine and many other human creative achievements. espite its creative potential,creating and designing in the open source paradigm has not received the attention itdeserves rom the standpoint o design science or practical design methodolog y.

1.1. Current condition

e open source paradigm is particularly relevant and exciting today as it benets remark-ably well rom the digital inormation technologies and seemingly ubiquitous connec-tivity o the present-day. e ability o people to communicate and act online regardlesso their geographic location or cultural backgrounds presents a context or open sourcecollaboration that could not have been imagined ever beore. n this context, individualsand groups online can come orward with ideas and a means o production. ey sel-or-

ganize, collaborate and share inormation to create together. is kind o collaborativecreativity is especially vibrant in online communities gathered around open source so-

ware development (OSSD) projects.OSSD project communities can be generally described as online communities o an

indeterminate number o voluntary members assembled around the development o aparticular soware. Community members take on tasks by themselves, oen accordingto a personal eeling o un, contribution or accomplishment [2] and without detailedplans or schedules. n many cases, their work is made public only a-posteriori, i.e. aersubmitting it to the community or assessment. erited community members assesscontributions and decide whether to include them in the next soware version [3]. eethos [4] o open source development creates a meritocratic social context where disputesare resolved based on rational arguments and where ree experimentation, innovation and

collaborative approaches are welcomed and supported.

RERNT: ENN WTH AN WTHN A CUNTY

Heuristic techniques or designing with and within pen ource otware evelopment

Kova Aleksandar*, Kittiwongsunthorn Warruntorn*, Katsuhiko Kushi**Kyoto Institute of Technology, Sakyo-ku, Matsugasaki-Goshokaido chouKyoto 606-8585, Japan

Abstract: igital inormation networks have become a globally accessible space or meaningul social interaction and

collaboration. The nternet has enabled people to create and innovate together online, regardless o their physical

location, geographical boundaries or cultural backgrounds. These conditions are used to exceptionally good creative

advantage by online open-source sotware development (OSSD) projects and communities. OSSD communities

share a collaborative ethos and approach to sotware development, but even in such inormation-rich and openly

collaborative surroundings implementing design solutions is very challenging. Various design approaches have been

attempted with inconsistent success. This eld research investigates the social circumstances in OSSD communities

which inuence the implementation o design solutions, aiming to explain the observed ineptitude o designers to

contribute design solutions to OSSD projects. Thereore, aiming towards a methodology o design t or the open

source paradigm, this paper proposes a set o heuristic techniques to improve a designers ability to collaborate,

contribute and design with and within an open-source development community with a desired positive outcome.Keywords: community, open source, methodology, design process, open collaboration, social aspects of open source paradigm


2/12


3/12


2.1. Extraction Phase

Each triangulation cycle begins with a wider perspective on OSSD and relies on the GTmethod to extract candidate concepts rom data sources. Following the GT method, acandidate concept is a ormed statement or a direct quote extracted rom data sourcesrelevant to the eld o research. Early on in the research, candidate concepts were mostlyextracted key codes and concepts [Figure 2]. As the research progressed with new triangu-lation cycles, the candidate concepts allowed general categories and theories to be ormed.

For illustration, a candidate concept programmers code is easily tested, user experienceis not was extracted ollowing a comment by an OSSD project contributor stating thatocusing on user experience slows down the OSSD process since, unlike program code that

either works or not, it is not possible to provide an exact and universally acceptableevaluation o user experience. ince this topic seemed promising and relevant, program-mers code is easily tested, user experience is not was added as a candidate concept orthe next phase. is phase allowed the extraction o many other candidate concepts suchas ood design ideas can trigger code development, good looking projects are moredesirable or developers, etc.

Figure 2. A screenshot o encoded

data rom the OSSD mailing list during

the extraction phase. Columns, rom

let to right: e-mail message senders,

correspondence threads, tags and codes

attached to each message. The rightmost

area chronologically displays content o

one correspondence thread.

Figure 1. Conceptual diagram o the

triangulation cycle showing the three

phases (extraction, armation and

testing) and the research methods used

in each phase.

1. Extraction phase

2. Afrmation phase3. Testing phase

mini hypothesisrened concept

candidate concept

participatory

action

grounded

theory

case

study


4/12


2.2. Afrmation Phase

nce a candidate concept is extracted in the extraction phase, the triangulation cyclereocuses to arm the validity o that candidate concept relying on the case studies. A can-didate concept is considered armed i it can be ound to be true and applicable in variousreal accounts. Again, the transparency o the open source development process is essentialin this phase since it enables access to numerous real accounts. An armed and validatedconcept can then be carried into the next phase as a mini-hypothesis. ini-hypothesesare simple abstracted statements stemming rom candidate concept(s) but encoded romaccounts o similar and opposing opinions concerning this topic. Example mini-hypothe-ses: oing (A) will contribute to acceptance o the idea.; (B) reduces possibility or anideas implementation.; Approach (C) is an appropriate way to do () etc.

2.3. Testing Phase

o ar our insights, (candidate concepts and mini-hypothesis) although inducted romreal world circumstances, have remained in the realm o theory. For additional veri-cation o insights it is important to experience the designers role in the rst person,

utilizing these insights. ereore, it is necessary to reocus the research once more, todirect participation.

n the testing phase we tested the mini-hypotheses. rough direct participation,mini-hypotheses were introduced to a project community in the orm o: ideas, propos-als, questions or opinions. e responses rom the community usually arrived very ast. Arened concept that was accepted, then became a part o our rened data. An exampleo the verication process pulled rom the research involves the testing o the mini-hy-

pothesis: e success o ideas in open source depends on their articulation. n the GIMPdeveloper mailing list [8], a GIMP user started a thread that strongly demanded changesto the design (abbreviated) [9]:

...in act, make GIMP really easy to use, and powerul. make animation part o the package

instead o a separate piece. some o us are losing out. make menu items intuitive. ... adobephotoshop lters (ac or C) should be built in. ... people should have to install a plugin. (...)

GIMP without photoshop lters is practically useless (...) GIMP should be powerul.

e lack o a clearly articulated problem or possible solution by the user provided theopportunity to test the mini-hypothesis with the ollowing reply:

...The same actors that contribute to acceptance o some code, will contribute to the accep-

tance o your ideas. your ideas are articulated, presented and clear enough, and just work

or other people, (i.e. clearly indicate the excellence o your approach) they will be created/

implemented/ improved somehow somewhere by someone. Thats how open source works.

aybe am painting an idealized picture, here?

e answer rom a prominent member o the GIMP community armed the mini-hy-pothesis in his statement:

You arent. eter started the brainstorm blog exactly with intention to get input rom users

and see a bigger picture. ne o the points in that blog is that i you cant present your idea

in a clear concise way, maybe you didnt really think much about it...

n the previous example, it was possible to add the ollowing rened concept: esuccess o design ideas in open source depends on their articulation. At the end o thetesting phase, a successully armed mini-hypothesis, or a rened concept is then putback together with the GT data or urther iterative triangulation cycles or GT axial coding.


5/12


2.4. Research Frame

e main portion o this eld research ocused on online documentation and correspon-dences rom our OSSD project communities [able 1] over a period o 18 months, romApril 2010 through ay 2012. uring that period, over 11,000 messages were encoded.e ollowing period, rom ay 2012 until February 2013 was used to rene and veriythe ndings. Additional data sources included, but were not limited to: online documen-tation and correspondences rom other project communities, blogs, microblogs, varioussocial network groups, news portals and academic papers.

3. Findings

n OSSD communities, a designer aces social circumstances undamentally dierent romthe social circumstances encountered in conventional organizations. n conventionalorganizations, members communicate and act in adherence to recognized roles and plans

within a well structured production environment where dened methods, goals, sched-ules, etc. play important roles in achieving production goals. ereore, an organized andstructured approach in such organizations is commonly perceived as normal, desired or

expected. n contrast, only a ew simple cultural conventions maintain the ethos o opensource communities. Activities within OSSD communities are mostly individual, networkdistributed, asynchronous, unmanaged and concurrent. e conventional organizationalstructures necessary to support the conventional role o the designer do not exist and

without them the conventional design methodologies also ail.Using the research methodology described in the previous chapter, we were able to

code six categories o social circumstances that arise in OSSD communities and directly in-

fuence the acceptance and implementation o proposed design solutions in OSSD projects.t was possible to divide these six categories o social circumstances into two key groups:hindering social circumstances and acilitating social circumstances.

3.1. Social Circumstances Hindering the Implementation o Proposed DesignSolutions

indering social circumstances are social circumstances causing OSSD communities toreject proposed design solutions. e ollowing subsections seek to explain three catego-ries o hindering social circumstances involving designers and other contributors in theorder o occurrence, when contributing to an OSSD project. e categories are reerred to

as: disregard or apprenticeship, alien cultures and ragmented visions.

OSS project Description

yner[www.syner.org]

A project to develop a social network or social problem solving. e project experienced asurge o activity at its start. With the departure o the initiator and project leader, the projectlost its steam and is currently inactive. 11 members used oogle Wave or correspondence anddocumentation.

nkscape[www.inkscape.org]

A rich scalable vector graphics (V) editing soware. Community uses nine mailing listsand numerous orums or correspondence. e documentation is accessible on the website.e project is relatively mature with a stable community o more than ten thousand members.

GIMP[www.gimp.org]

A comprehensive bitmap image editing soware. GIMP developers use six mailing lists orcorrespondence. GIMP is a mature project with a stable community o developers and users

with immense amounts o documentation online.

ozilla underbird[www.mozilla.org/projects/thunderbird/]

An e-mail client. underbird, once a very popular e-mail client, has since seen its developmentwane. Faced with soware obsolescence, underbird users overtime transormed the existingsupport orum into a valuable source o comments and ideas on the uture direction o the

project. [http://getsatisaction.com/mozilla_messaging]

Table 1. OSSD projects whose online

documentation and correspondences

were ocused on during the main

portion o research.


6/12


3.1.1. isregard or Apprenticeship

e rst category o hindering circumstances may arise at the very onset o a designers eort tocontribute in an OSSD community. is is caused by a disregard or apprenticeship, i.e. a con-tributors unpreparedness or the task. epending on whether the contributor is a developer ordesigner the maniestation o the hindrance diers, but the eect on design implementation isnevertheless the same, it hinders a designer rom contributing in an OSSD project.

n the case o the designer, the cause is the designers ailure to exert the patience neces-sary to get acquainted with the open source paradigm or OSSD project they are attemptingto contribute to. Familiarization with the specic OSSD project that a designer aims tocontribute solutions to, will help them understand the appropriate modes o contribution.e ailure o a designer to observe the culture o the OSSD project they aim to engagein, eectively excludes proposed design solutions rom consideration by the community.

n the case o the developer, the cause is the developers ailure to exert the patiencenecessary to get acquainted with the range o topics that design commonly deals with.evelopers, or example, have the programming ability to implement user interaces, butrarely exert the patience necessary to consider human actors or the reusability o suchuser interace implementations. e resulting substandard user interaces are releasedand users become accustomed to them. nce this occurs, a designers proposal or a user

interace improvement will oen be seen as destructive and thereore not be accepted.

3.1.2. Alien Cultures

Alien cultures reers to hindering circumstances that arise when tools, methods, tech-niques and jargon used in one eld o expertise are not applicable in another, impedingsuccessul collaboration between designers and developers in OSSD projects. For exam-

ple, online tools or versioning and managing soware code do not provide support ordocumenting and managing data ormats or design development. Another example canbe seen in the implicit rationale behind design decisions that might be unintelligible insoware development and vice versa.

A discussion rom the GIMP developer mailing list [10] illustrates one instance romthis category. A potential contributor repeatedly urged GIMP developers to include hiscolor swatches palette as one o the deault palettes with the next version o GIMP. ow-ever, the need or this inclusion is not clear to the developers. ince the rationale or ithas not been clearly articulated by the contributor, the uture implementation o the

palette seems improbable. Aer the rst rejection by the GIMP community, the palettecontributor replies:

...beore talking about a product you have to try and design with it, is the best proo that a

product is good and consistent.

Verication that requires the direct experience o designing is not a rational one to thedeveloper. n addition, the developer has second thoughts whether the proposed color

palette meets the technical requirements or color management in the printing processand the conversion between additive and subtractive color models:

tried your swatches. didnt see anything else than just swatches. A lot o swatches. Now

you say your printed book (rom CYK swatches, using a hand-picked generic CYK prole)

has no relationship with your sRB swatches... What exactly should try?

ubsequently, the palette contributor ailed to produce a satisactory argument andthe initiative to include the palette was ceased.

esigners contributing design proposals are oen unable to develop soware codethemselves. As a result, design solution proposals depend on the developers acceptance oan idea in order to be implemented. ue to the eect o alien cultures, implementation

o a design solution proposal is hindered by misunderstandings and incompatibilitiesbetween designers and developers.


7/12


3.1.3. Fragmented Visions

OSSD community members come rom dierent backgrounds, thereore, it is inevitablethat community members will have dierent personal conjectures regarding various as-pects o the project. Fragmented visions reers to the inability to attain consensus indesign implementation due to dierences in personal visions that result in the rejectiono design proposals. Characteristic o the open source paradigm, ragmented visions arecommon among OSSD community members.

Fragmented visions may also hinder the implementation o design proposals when mis-inormed personal conjectures about the design process and its purpose have a negativeinfuence on the stance o the community members towards design [11]. n an examplerom the rupal mailing list, a developer communicated a personal conjecture suggestingthat designers that are not competent in template coding cannot help in developing therupal project. n this case, ragmented visions were potentially hindering the acceptanceo any design proposals made by contributors without coding experience, despite themerit o their idea.

o, my point is, that a designer who cant override a theme template is not a rupal designer,

and thereore he/she cant really help me with rupal development. The barriers to participa-

tion or designers are really low, but yes, there are barriers you just cant skip.

3.2. Social Circumstances Facilitating the Implementation o Design Solutions

Facilitating social circumstances increase the likelihood o design solutions being accept-ed by OSSD communities. e main characteristics o these acilitating social circumstanc-es are the clear articulation and ecient ltering o inormation in design proposals bycontributors. Articulated and ltered inormation benets all parties involved by pro-

viding a common ground where the communication and exchange o ideas can happen.An example o the importance o inormation articulation and ltration can be evi-

denced in their essential role in turning online support orums into a valuable re-source or both users and developers [12]. n these support orums, solution seekers andsolution providers have an incentive to be articulate in order to be understood. n turn,they must lter through other communications in order to extract relevant inormation.Users use support orums to articulate problems and lter relevant inormation in order toreceive solutions. evelopers lter questions and articulate answers to provide solutionsto user problems while gaining insights that aid them in improving OSSD projects.

e ollowing subsections discuss three categories o social circumstances that havebeen ound to acilitate the implementation o design solution proposals in OSSD. eyare reerred to as: design ocused eorts, hybrid approaches and concurrent eorts.

3.2.1. esign Focused Eforts

esign ocused eorts are individually or communally maintained websites (such asopen source projects, blogs or research websites) where designers openly present theirthinking, design development process and nalized design solutions. ese eorts adhereto the open source production model, with a ocus on design rather than coding. As aresult, it is possible or such eorts to advance work pertaining to design practice andtheory without introducing the hindrances described in the previous sub-chapter. Web-sites or design ocused eorts are an open source o both articulated and ltered designinormation. t has been observed that some design ideas that originated at such websites,spread very quickly and infuenced other OSSD projects.

pen design inormation was ound to include open design solutions, templates andtutorials, bootstrapping kits (e.g. witter bootstrap C and Java boilerplate or website

scaolding [13]). t also included the analyses o design issues in existing projects, explain-ing and emphasizing important design points and opinion pieces.


8/12


As a part o this research, a small, design-ocused website was created that discussespapercuts [14], which can be dened as trivial and easy-to-x usability bugs that theaverage user would encounter in everyday soware use. is website ocused on papercutsin nkscape soware [15] by providing an articulated and structured overview o eachpapercut together with a solution proposal [Figure 3]. Articulating design issues in thismanner succeeded in attracting and activating nkscape users and developers to partici-pate in solving design-ocused issues [16].

3.2.2. Hybrid Approaches

ybrid approaches reers to a category o social circumstances where the design processis partially or entirely perormed outside the open source paradigm, while its results arereleased under an open source license. esigning outside the open source paradigm in-troduces unique collaboration conditions (e.g. the enlisting o proessional designers) and

sacrices some o the advantages o open sourced production. n return, however, it bene-ts rom a structured and organized approach to the design process. ybrid approachesacilitate the implementation o design solutions in OSSD in two ways. rimarily, designsolutions are implemented or the purpose they were commissioned. nce implemented,solutions are within the open source paradigm and can be reely used and modied whichleads to urther implementations by other OSSD projects.

ybrid approaches in OSSD are common. For illustration, Canonical. td [17], thatleads the Ubuntu project (open source operating system) hired alton aag type ound-ry [18] to design the Ubuntu ont amily or the Ubuntu U. nce designed, theont was released under an open ont license [19] that unctions similarly to open sourcesoware licenses. ozilla Foundation [20], the non-prot organization behind ozillaFireox browser and many other OSSD projects, maintains their own design departmentand retains the nal design decisions. Nevertheless, design and production details are

openly available and in adherence to the open source paradigm. An independent OSSDproject, music player soware called ongbird [21], is an example o secondary imple-mentation. t uses ozilla developed XU (X User nterace anguage) or the designo its own user interace. Another example is the development cycle o oogle Android[22] where the codebase is opened by oogle only aer code stability has been reached.

3.2.3. Concurrent evelopment Eforts

Concurrent activities done in order to achieve a common purpose or result are a prom-inent characteristic o the open source paradigm that stems directly rom the denitiono open source [23]. n practice, OSSD projects rely on various version control systems to

support concurrent development eorts. Contributors are ree to choose tasks, pursue in-dividual approaches and reuse the existing solutions via branching, orking and cloning.

Figure 3. apercuts website screenshot

showing an initial design suggestion

and a short discussion that resulted

in successul implementation o the

suggestion. (http://cuts.thinking-

garment.com/273)

branching: parallel development on

revision-controlled version o code.forking:

starting a project based on a version o

the pre-existing projects source code,

cloning: developing a project to mimic

another project or product.

[avid A. Wheeler: Why Open Source

Software / Free Software (OSS/FS, FLOSS,

or FOSS)? Look at the Numbers!, Ch.

A.6 Forking. Retrieved rom: http://www.dwheeler.com/oss_s_why.html#orking]


9/12


ese circumstances oer a rich choice o openly shared solutions or OSSD contributorsto consider, acilitating the implementation and reuse o articulated design solutions, as

well as coding solutions, beyond the limits o the project o origin.For example, a multi-platorm toolkit or creating graphical user interaces GTK+ [24]

was created to assist in the development o GIMP, but it transcended that use and hasbeen implemented by other OSSD projects that need toolkits or multi-platorm Us.n another example, yde [25] a static HTML page generator written in the ythonprogramming language, clones the unctionality o Jekyll [26], a static HTML pagegenerator written in the Ruby programming language.

n comparison with OSSD projects, conventional organizations seek eciency and can-not aord redundant work. n such a setting, the economies o scale [27] and scope [28]matter signicantly. As a result, careul management o the production process is imper-ative or achieving protability. ere is no such imperative in the open source paradigm.

4. Adaptive Behavior or Designers in an Open Source Community

e open source paradigm presents many advantages or the design process. At the same

time, the hindering social circumstances are emerging, hindering the design proces andimplementation o design solutions in OSSD. Although these hindering social circum-stances have no critical eects on OSSD, they are detrimental to the advancement o opensource design. n conventional production models, structured organization can alleviatemost o the aorementioned hindering circumstances through ormalized communica-tions and procedures optimized or achieving clearly stated goals. e open source par-adigm does not provide an environment in which such structured organizational toolscan be applied.

n working towards a uture open source design methodology, the aorementionedndings provide a solid basis to propose a process o adaptive behavior or designersthrough which the eects o hindering social circumstances can be alleviated while re-taining the acilitating eects when designing in the open source paradigm. is process

ollows three heuristic techniques, reerred to respectively as: designers socialization, de-signers cultivation and designers initiative [Figure 4] through which a designer acquiresthe essential ability to collaborate, contribute and design in the open source paradigm.t is worth noting that this is not a set o heuristic techniques specic to any particularOSSD community to address design issues, but rather, a general model o social adaptivebehavior or a designer in the open source production paradigm.

Figure 4. Hindering and acilitating

social circumstances ound, inormed

three heuristic techniques o adaptive

behavior or designers in OSSD.


10/12


4.1. Designers socialization

esigners socialization is a heuristic technique aimed at improving a designers ability tocollaborate on OSSD projects. ocialization is a voluntary and oen independent process.t begins with adapting the designers mindset to the open source paradigm which involvesthe designer learning social patterns, techniques and jargon necessary or eective collab-oration. n adapting, a designer acquires an accurate personal conception about the opensource paradigm, along with various development and licensing models. e designerthen learns basic inormation about a project that includes, but it is not limited to: theprojects idea and purpose, the projects goals and visions and the process o submittingproposals. All o this is done by reading available documentation and taking part in theprojects discussions on mailing lists, ora, etc.

n OSSD, the designer cannot rely on a pre-dened role or status, as is typical in conven-tional production environments. rough socialization, the designer can gradually evolveher position while gaining the trust o community members; a process that compels thedesigner to be patient and acquaint themselves with the project. nline wiki documen-tation or the Celestia OSSD project describes this process and stresses its importance asa orm o apprenticeship [29]:

As with most sotware projects with established developer communities and protocols, apotential contributor to Celestia will have to undergo a orm o apprenticeship. The program

is large and complex and its underlying design philosophy has to be understood. t also takes

a while to gain the trust o the people currently working on the program. By themselves, pro-

gramming skills arent enough. Too oten individuals unamiliar with the program or with the

people involved have suggested signicant changes and have become discouraged because

their ideas werent incorporated immediately. ont let this happen to you. Read the orum.

Read the developers mailing list. articipate in discussions. Contribute ideas. Try out things

with the code on your own. Be patient. tll take a while.

4.2. Designers Cultivation

esigners cultivation is a process o acquiring and persistently improving a designersability to lter and articulate inormation, with the purpose o improving a designersability to contribute design solutions in OSSD communities. e cultivation process is nota normative process. Rather, it instills a designer with the sense, ability and experience toconnect and correlate knowledge and ideas; to act and design creatively and imaginatively

within the community. is is accomplished through openly and actively contributingknowledge and ideas to the OSSD community. (Example: Blender project leaders [30])ereore, the activities o a cultivated designer sustain or cultivate the open sourceparadigm itsel.

n practice, a designer becomes able to articulate design solution proposals and lterinormation in a way that makes sense to a coding-ocused community. OSSD projects

are oen initiated and maintained by developers who cultivate a programming-ocusedculture that benets programming eorts within the community. An uncultured de-signers eort to contribute design solutions rarely adheres to the programming-ocusedculture. ese eorts are perceived as being against the un o programming and thus,are considered a burden and destructive to the OSSD project. A developer rom therupal project describes this situation metaphorically in response to an uncultureddesign contributor:

Youve come into our ront room, and, while we were making a cup o tea, you moved all the

urniture around. Not only that, but you redecorated, changed the carpet, and removed all

o our belongings. [31]


11/12


4.3. Designers Initiative

esigners initiative aims to improve a designers ability to design within the open sourceparadigm in general and covers the widest scope o the three proposed heuristic tech-niques. is initiative reers to a designers ability to initiate and maintain open sourceprojects and open design processes o their own. e open access o inormation inherentto OSSD, allows design ideas to evolve and combine so that they may become a subject ordiscussion, modication and application and perhaps even a core or a new community.esigners initiative should be understood as a part o a designers general strategy; amethodological practice o allowing open access to design inormation.

5. Conclusions

n the open source, organizational structures necessary to support the designers roledo not exist and without them the conventional design methodologies ail. As a part oan ongoing eort to help explain, develop and veriy design methods or open sourceproduction models online and o-line, this eld research investigated the social circum-

stances in OSSD communities which infuence the implementation o design solutions,aiming to explain the observed ineptitude o designers to contribute design solutions toOSSD projects. Using the grounded theory method, together with case studies and directparticipation, six key categories o social circumstances infuencing the implementationo design solutions in the OSSD projects were encoded and presented. ere are threehindering categories and three acilitating categories o social circumstances. e socialcircumstances ound, emphasized that the way in which the open source unctions isinextricable rom the social conditions within it, us, the development o design meth-odologies or the open source paradigm compels a deep understanding o the culturalramework o open source communities.

Working towards a uture open source design methodology, the ndings provided abasis to propose a process o adaptive behavior or designers in an open source community.

is process aims to alleviate the eects o hindering social circumstances, while retainingthe acilitating eects when designing in the open source paradigm. e process consistso three heuristic techniques, reerred to respectively as: a) esigners socialization aimed at improving a designers ability to collaborate on OSSD projects, b) esignerscultivation aimed at improving a designers ability to contribute in OSSD communitiesand c) esigners initiative aimed at improving a designers ability to design withinthe open source paradigm.

We conclude that the designers role in an open source community includes not onlythe creative contribution o design solutions, but also being an active member o thecommunity and a catalyst or the wider implementation o design byopeningthe design-ers own design process. esigners are compelled to understand and utilize the socialcircumstances and social interaction when collaborating, contributing and designing

with a community. n other words, a designers mindset should shi rom designingor

a community, towards designingwith and within a community. Furthermore, heuristictechniques or the designers adaptation to the open source paradigm are relevant toeorts in other elds to adapt to the open source paradigm.


12/12


6. Reerences

Note: All web addresses were successully accessed on 2013-06-20.1. pen ource nitiative: Te Open source Denition, retrieved rom: http://opensource.org/osd2. eter ikking: ...at the moment there is no sense o un, contribution and accomplishment in the transormation tools

topic..... Retrieved rom: https://mail.gnome.org/archives/gimp-developer-list/2013-February/msg00102.html3. Yamauchi, Y., Yokozawa, ., hinohara , ., & shida, .: Collaboration with Lean Media: how open-source soware

succeeds, AC Conerence on Computer upported Cooperative Work (pp. 329-338). AC, 2000.4. bid.5. atthew homas: Why Free Sotware usability tends to suck. Retrieved rom: http://web.archive.org/

web/20041117091141/http://mpt.phrasewise.com/discuss/msgReader$173, (2002-04-19)6. ack, W., tienne, F., ucheneaut, N., Burkhardt, J.-., ahendran, ., & Barcellini, F.:A Methodological Frame-

work or Socio-Cognitive Analyses o Collaborative Design o Open Source Soware, Computer upported CooperativeWork, 15, 2-3, (J. . Atkinson, Ed.) Cambridge University ress. Retrieved rom http://arxiv.org/abs/cs/0703009,2007

7. Based on paraphrase o the rst chapter oMozilla Public License Version 2.0. Retrieved rom: http://www.mozilla.org//2.0/

8. GIMP project: GIMP developer mailing list archive. Retrieved rom: https://mail.gnome.org/archives/gimp-developer-list/

9. Jim ichaels et al.:suggestion or new versions oGIMP. Retrieved rom: https://mail.gnome.org/archives/gimp-de-veloper-list/2011-November/msg00050.html

10. iveieC, gespertino: givelie color system. Retrieved rom: https://mail.gnome.org/archives/gimp-develop-er-list/2011-ecember/msg00020.html

11. E. iles:An observation about Designers versus Developers [blog post], Angry onuts blog, 2009-08-28. Retrievedrom: www.angrydonuts.com/an-observation-about-designers-versus-developers

12. akhani, . R., & Von ippel, E.,How open source soware works: fee user-to-user assistance, Research olicy, 32(6), (pp. 923-943). Retrieved rom http://www.sciencedirect.com/science/article/pii/0048733302000951, 2003

13. witter Bootstrap project. Retrieved rom: https://github.com/twitter/bootstrap#readme14. apercuts,PaperCut, [project wiki], Retrieved rom: https://wiki.ubuntu.com/aperCut, (2011-02-15)15. nkscape papercuts. Retrieved rom: http://cuts.thinking-garment.com16. Aleksandar ova et al.: Tem Cuts!Guides around page to [web page]. Retrieved rom: http://cuts.thinking-garment.

com/14417. Canonical: What We Do Overview [web page]. Retrieved rom: http://www.canonical.com/about-canonical/overview

18. Ubuntu ont amily,About[web page]. Retrieved rom: http://ont.ubuntu.com/about/19. Ubuntu: Ubuntu Font Licence, Version 1.0 [web page]. retrieved rom: http://ont.ubuntu.com/licence/20. ozilla Foundation: Our mission is to promote openness, innovation & opportunity on the Web [web page]. Retrieved

rom: http://www.mozilla.org/en-U/mission/21. Songbird Music Player[web page]. Retrieved rom: http://www.getsongbird.com/desktop/22. Android project documentation: Frequently Asked Questions, Why is Google in charge o Android?[web page]. Re-

trieved rom: http://source.android.com/source/aqs.html23. pen ource nitiative: he Open Source Deinition (Annotated). Retrieved rom: http://opensource.org/

osd-annotated24. e GTK+ eam: What is GTK+, and how can I use it?. Retrieved rom: http://www.gtk.org/

25. Ringce: ++Crebits. is content is accessible rom: http://ringce.com/hyde26. om reston-Werner, Nick Quaranto, et al.:Jekyll. Retrieved rom: https://github.com/mojombo/jekyll#readme27. oore, Fredrick .:Economies o Scale: Some statistical Evidence. Quarterly Journal o Economics ( ress) 73

(2): 232245 (ay 1959)28. John C. anzar and Robert . Willig:Economies o Scope, e American Economic Review Vol. 71, No. 2, apers and

roceedings o the Ninety-ird Annual eeting o the American Economic Association (ay, 1981), pp. 268-27229. Celestia roject: Celestia/Development [project wiki]. Retrieved rom: http://en.wikibooks.org/wiki/Celestia/

evelopment30. ergey urdakov on Feb 26, 2013; 8:12am:Blender developer meeting notes, 24 February 2013, retrieved rom: http://

blender.45788.x6.nabble.com/Blender-developer-meeting-notes-24-February-2013-td104759.html31. Boulton, ., Design in Open Source, ch. esigners vs evelopers, para. 2., [online journal], retrieved rom: www.

markboulton.co.uk/journal/comments/design-in-open-source, (2009-08-30)

design with and within community

Documents