What would make a design not open?

[mushon]

I recommend we start by describing what we think would make a design not open. Discuss…

[mushon]

Most design works have some means of inspection and reproduction that can be made available. If a design work does not allow open access to these means, then it is probably not open.

Example: An vector icon that is released in PNG format may be licensed under CC license but it is not open design since I have no way of inspecting or modifying it. For the work to be Open Design it would need to allow access to the vector source, for example in SVG format.

[Alexnoussias]

anything (for starters) with technical and legal restrictions..

[alex-kovac]

Hi Mushon, A vector icon which is released in a PNG format would cease to be a vector icon and would, from then on, be a proud bitmap icon. We cannot go into the teleology of why would someone release a bitmap vs. vector icon if that icon is under a open license. If bitmap icon is under a open license, anyone is free to modify it, redistribute it, etc. and therefore it is "open" for all purposes.

To look at this from another perspective, if the icon is released openly, the preference of PNG vs SVG format is purely personal. (I agree that having a vector icon would sometimes be more convenient)

[mushon]

So why wouldn't a software binary file be considered open source as well? I think sticking to the technicalities only beats the purpose entirely. It is one thing if the image is scanned and never had a malleable source. It is a different case when the source was simply not provided with the rendered "flat" version. If we stick to liberal licensing (as CC) as our cue, then why do we even need an open design definition? A I said before, I am not sure we actually need it, but I could be missing something. I asked this question to better understand what may I be missing. Not sure yet…

[bujatt]

I think the whole question is about being able to access the source design code. In case of a vector icon, access the SVG not only the PNG. In case of a 3D print, access the 3D file, not only the object itself. In case of a wooden table, access the technical drawings. In case of a poster, access the editable PSD and embedded fonts, not only the JPG.

Alexnoussias told not open means "Very general (for starters): anything with legal, technical restrictions."

The question is whether any restriction of accessing the source code disallows a design being open. And what makes the question more difficult, that this restriction can be conscious (the designer of the vector icon doesn't release the vector file just the raster image) or unconscious (the designer did release the technical drawings of a table but I only have the table itself).

For me real open design is when the source code is attached to or embedded in the object itself. I don't know how this could be done practically - like engraving a QR-code directly into the table body which points to a never-expiring link of the technical drawing files of the table - but that would be the real openness.

Maybe this is not part of the discussion about the definition but more the licences, but thinking practically, I could imagine several levels of openness:

• super-open: the source design code is hardcoded into the design object/output
• middle-open: the source design code was released by the designer but it is your job to find it (hopefully shared on thingiverse-like repositories)

Attila

Attila BUJDOSÓ : bujatt@gmail.com +36-70-2809137 http://bujatt.com

Kitchen Budapest http://kitchenbudapest.hu/ : Pecha Kucha Night Budapesthttp://pechakucha.hu/ : Remix Architecture http://remixarchitecture.org/

On 7 September 2013 20:18, Mushon Zer-Aviv notifications@github.com wrote:

So why wouldn't a software binary file be considered open source as well? I think sticking to the technicalities only beats the purpose entirely. It is one thing if the image is scanned and never had a malleable source. It is a different case when the source was simply not provided with the rendered "flat" version. If we stick to liberal licensing (as CC) as our cue, then why do we even need an open design definition? A I said before, I am not sure we actually need it, but I could be missing something. I asked this question to better understand what may I be missing. Not sure yet…

— Reply to this email directly or view it on GitHubhttps://github.com/OpenDesign-WorkingGroup/Open-Design-Definition/issues/7#issuecomment-24006659 .

[alex-kovac]

You are completely right, in the case of flattened bitmap icon, a CC like license would probably suffice and an open design license might not be needed. (unless someone uses that icon data as a basis for another design process, but that is a different issue) So, please disregard my comment above.

In my opinion, we need the open design definition to define the open design process and the elements of that process, too (and not only the final product).

On 2013/09/08, at 3:18, Mushon Zer-Aviv notifications@github.com wrote:

So why wouldn't a software binary file be considered open source as well? I think sticking to the technicalities only beats the purpose entirely. It is one thing if the image is scanned and never had a malleable source. It is a different case when the source was simply not provided with the rendered "flat" version. If we stick to liberal licensing (as CC) as our cue, then why do we even need an open design definition? A I said before, I am not sure we actually need it, but I could be missing something. I asked this question to better understand what may I be missing. Not sure yetc

\ Reply to this email directly or view it on GitHub.

[eldelacajita]

I think the underlying question in the debate here is to properly define the "source" of a design, so we can check if we are having access to it or not. And usually, in design there are different levels of "source":

Built object > whose source is > specifications/plans in read-only format > whose source is > specifications/plans in editable format.

So maybe openness of the source is not a yes/no question but a variable degree: If you only share specifications of an object in PDF instead of original editable format, I think you're still half way into open design.

Using that other example of sharing a raster file of an graphic design instead of the original vector file, I think that applying a CC license on a finished ("compiled", rasterized, etc) design cannot be described as "open source".

[mushon]

I'm beginning to like where this is going. Rather than a binary license I think what we're starting to define here is a scale of openness on what could be defined (!() as the Open Design Spectrum. That spectrum would not require a new (tedious / technical / boring / anal) license of its own, but a set of guidelines / best practices for pushing the dial on your design work from the closed towards the open. Legally-wise, I think we're quite covered by the pleura of CC and OSS licensing, but I do agree that when it comes to design there's one tool still missing, and that is for a methodology for going beyond licensing and towards a more explicit Open Design process where openness is not an afterthought (as in: "ok, I slapped an open license on it, and now it's open") but a way of designing that considers the openness and remix from early in the production of the piece.

[bujatt]

Yes, I also think open design can be defined better as a spectrum than a binary yes/no thing. I would like to share two references for this:

I really liked that someone (sorry forgot who) was referring to the 5 star model of rating Open Data http://5stardata.info/ at OKCon last year. For those unfamiliar, I paste it below:

★ make your stuff available on the Web (whatever format) under an open

license1 example ... ★★ make it available as structured data (e.g., Excel instead of image scan of a table)2 example ... ★★★ use non-proprietary formats (e.g., CSV instead of Excel)3 example ... ★★★★ use URIs to denote things, so that people can point at your stuff4 example ... ★★★★★ link your data to other data to provide context5 example ...

Actually, this revokes how Creative Commons license evolved in the history. While there are many permutations of the different conditions (allow/disallow commercial use, allow/disallow remix etc.) they ended up simplifying the different options in a 6-step scalehttp://jakfoto.com/wp-content/uploads/2011/06/creative-commons-license-types-pros-cons1.gifof license strength.

I think both references are really helpful and inspiring for us.

Attila BUJDOSÓ : bujatt@gmail.com +36-70-2809137 http://bujatt.com

Kitchen Budapest http://kitchenbudapest.hu/ : Pecha Kucha Night Budapesthttp://pechakucha.hu/ : Remix Architecture http://remixarchitecture.org/

On 22 September 2013 14:22, Mushon Zer-Aviv notifications@github.comwrote:

I'm beginning to like where this is going. Rather than a binary license I think what we're starting to define here is a scale of openness on what could be defined (!() as the Open Design Spectrum. That spectrum would not require a new (tedious / technical / boring / anal) license of its own, but a set of guidelines / best practices for pushing the dial on your design work from the closed towards the open. Legally-wise, I think we're quite covered by the pleura of CC and OSS licensing, but I do agree that when it comes to design there's one tool still missing, and that is for a methodology for going beyond licensing and towards a more explicit Open Design process where openness is not an afterthought (as in: "ok, I slapped an open license on it, and now it's open") but a way of designing that considers the openness and remix from early in the production of the piece.

— Reply to this email directly or view it on GitHubhttps://github.com/OpenDesign-WorkingGroup/Open-Design-Definition/issues/7#issuecomment-24881077 .

[openp2pdesign]

We can find a similar spectrum or range in Open Hardware as well (and maybe this can be an inspiration):

Patrick McNamara defined 4 possible levels of Openness in Open Hardware projects, that can help us understand them better:

1. Closed: any hardware for which the creator of the hardware will not release any information.
2. Open Interface: all the documentation on how to make a piece of hardware perform the function for which it is designed is available (minimum level of openness).
3. Open Design: in which enough detailed documentation is provided that a functionally compatible device could be created by a third party.
4. Open Implementation: the complete bill of materials necessary to construct the device is available.

[trox]

I would like to agree and disagree with the previous arguments

(1) agreement with the "spectrum" idea, agreement with some sort of "maturity" indication (the 5star idea) (2) agreement with extending the open design discussion beyond the product and into the process arena … that's where it gets really interesting, ihmo

(3) disagreement with doing away with a clear cut "gold" standard of what open design is … not in terms of a license (!!!), but in terms of a definition

my 3c / Peter

[trox]

Patrick McNamara defined 4 possible levels of Openness in Open Hardware projects,

interesting contribution … but very "factual".

• I'm missing the "why": why has the hardware been designed as is?
• I'm missing the openness in designing (although this might be implicit in the TAPR community with its purpose of advancing the radio art)

[openp2pdesign]

The spectrum/range is a good idea, but little reminder: we are not discussing a specific license but rather a framework for understanding/working with Open Design. So it is a good idea not to have a binary distinction, but it's not about a license. Please have a look at the Open Design and Intellectual Property section (it still needs further work, so any help would be appreciated!).

[openp2pdesign]

I've added a first version of 6 levels for the documentation of Open Design (our Open Design Spectrum) with commit bd7bfc42add5cd78d405a332449da6c57e5d5d2f. I've started from the 5 stars rating of Open Data), you can have a look at it here

1. make your stuff available on the Web (whatever format) under an open license
2. make it available as source file (e.g., vector format instead of bitmap format)
3. make it available as a human-readable source file (e.g. ASCII .stl instead of binary .stl, this would work better with version control systems)
4. use non-proprietary formats (e.g., .svg instead of Adobe Illustrator .ai)
5. add a documentation about the design process (how it has been designed, by whom, where, ...)
6. link your data to other data to provide context (e.g. Open Data regarding the design process, supply chain, manufacturing, distribution, end of life, ...)

[openp2pdesign]

I've marked this proposal as version 0.3, as it solves also some other issues..

[alex-kovac]

Hi everyone,

Besides it's narrative potential, I fail to see whether a spectrum/range or any other fuzzy way of defining (oh the oxymoron!) would be purposeful for open designing. Besides the fact that spectra merely state that there are "many sorts of many things", the issue with spectra, both as "levels of documentation" and "open design spectrum" is that they can be seen as normative and as such I see them in opposition with the open paradigm. A spectrum might be useful as an explanatory tool, or even better, as a rhetorical tool in theoretical hairsplitting - "mine has, like, mo', open-ness-icity than yours...". Still, we can imagine a design project that scores 10 stars (according to some spectrum) in practice fails to provide a piece of info that a third-party might consider "fundamental". Or, a project can provide so much information that it impedes the development.

There are no "end products" in the open paradigm, anyway. Projects come and go, some lay dormant, some burst with activity... they are far from centralized, managed efforts. They defy measuring. Open projects are there to be improved, ruined, but also forked, split, cloned, changed... If you release anything as open, anything at all, great that you did. Let's not split hairs. Whichever chunk you release as open is - open. And it will remain open. Thank you for that. No spectrum there. Some communities will provide more info, some less. Let others play with it, change as needed, share, do their magic and fill in the missing parts, if desired. Talk to the community, be active, gather/document/structure/share knowledge. Over time, these open design chunks will accumulate and allow many other, increasingly complex open creations to emerge. Again, no spectrum needed. This will inevitably result in a huge range of crazy projects and that is all good. Better ones will matter more and perhaps survive. The lame ones will be forgotten. I know it sounds simplistic, but let's give it time, and have some faith in community. ;) A proper way of doing things will find it's way no matter how we define it here.

Am I too naive? :)

Cheers.

[mushon]

I sympathize with Alex's sentiment. I cringe at the thought of tight rules constraining the design process and of technical trophies for designers to collect, distracting them from the actual goals of the design process. We are inspired by the Free Software movement and its (naturally) technical guidelines, and from the Creative Commons / Free Culture movement and its (historically) legal constructs. Design is a different beast and requires its own procedural aesthetics. I do see value in the spectrum as a possible tool for communicating the ideas behind Open Design and its possible best practices. I don't see this as a "you're open or you're not" thing, but more of a set of case studies: When you design _____ you might want to open __ so others could do __. If you add to __ by opening ____ as well, people could also do ____. And here are some examples for each of these recommendations: ____. This is how I can see the spectrum being useful, as an accumulative and leveled process of opening. I think that more than a binary definition, a legal framework or technicals requirements, Open Design should provide an inspiration for why and how to make my work more open, both after it's done and hopefully even during the design process.

I hope this is useful,

Mushon Zer-Aviv Mushon.com | Shual.com | @mushon

On Sep 26, 2013, at 13:46, "alex.open.design" notifications@github.com wrote:

Hi everyone,

Besides it's narrative potential, I fail to see whether a spectrum/range or any other fuzzy way of defining (oh the oxymoron!) would be purposeful for open designing. Besides the fact that spectra merely state that there are "many sorts of many things", the issue with spectra, both as "levels of documentation" and "open design spectrum" is that they can be seen as normative and as such I see them in opposition with the open paradigm. A spectrum might be useful as an explanatory tool, or even better, as a rhetorical tool in theoretical hairsplitting - "mine has, like, mo', open-ness-icity than yours...". Still, we can imagine a design project that scores 10 stars (according to some spectrum) in practice fails to provide a piece of info that a third-party might consider "fundamental". Or, a project can provide so much information that it impedes the development.

There are no "end products" in the open paradigm, anyway. Projects come and go, some lay dormant, some burst with activity... they are far from centralized, managed efforts. They defy measuring. Open projects are there to be improved, ruined, but also forked, split, cloned, changed... If you release anything as open, anything at all, great that you did. Let's not split hairs. Whichever chunk you release as open is - open. And it will remain open. Thank you for that. No spectrum there. Some communities will provide more info, some less. Let others play with it, change as needed, share, do their magic and fill in the missing parts, if desired. Talk to the community, be active, gather/document/structure/share knowledge. Over time, these open design chunks will accumulate and allow many other, increasingly complex open creations to emerge. Again, no spectrum needed. This will inevitably result in a huge range of crazy projects and that is all good. Better ones will matter more and per haps survive. The lame ones will be forgotten. I know it sounds simplistic, but let's give it time, and have some faith in community. ;) A proper way of doing things will find it's way no matter how we define it here.

Am I too naive? :)

Cheers.

— Reply to this email directly or view it on GitHub.

[eldelacajita]

I think Alex and Mushon made some good points for not adding "steps" of openness in the definition. That would make it become more like a (fixed) tool for measurement and evaluation than an inspiring and empowering definition.

Still, "open" will always be (mis)used both as an absolute term and as a spectrum... as any other adjective I can think of right now. So maybe yes, we can hold back our fears and let the community do their way.

Or we can add a hint of this debate in the definition, making it more visible in the form of a closing question. A question is usually more constructive and empowering than a statement, and it leads to reflection and (self)improvement.

'Now that you know what open design is, go ask yourself this question: Is your project as open as it could be?'

[openp2pdesign]

I think that @mushon explained why the Spectrum is important with these linese:

This is how I can see the spectrum being useful, as an accumulative and leveled process of opening. I think that more than a binary definition, a legal framework or technicals requirements, Open Design should provide an inspiration for why and how to make my work more open, both after it's done and hopefully even during the design process.

It is not the Spectrum that says what is Open Design or not, but the definition itself! The Spectrum actually helps in making the binary choice a more shaded degree. As @alex-kovac said, open projects continuously change and improve (if there's an active community or even few interested people, not necessarily always), but that means also that the Spectrum can change through time. So we shouldn't think the Spectrum as a mark that the project will always have, but something that can improve and actually, something that helps people understand how to improve it. FabLabs, for example, have a similar Spectrum called conformity rating, it is a bottom-up tool that is useful not for saying "my lab is better than yours" but "my lab is different, and there are aspects where it could change in the future". I do think that we need to be also critical of the quality of Open Design projects, but that judgment should be based on the quality of the design project, not on the Spectrum. So I suggest that we keep the Spectrum, and maybe explains how to use it and that it is not intended for judging the quality of a project.

[openp2pdesign]

I just improved the Spectrum by deleting the item about the process documentation. But since this is a very critical issue for me, I expanded it into another Spectrum regarding the whole ecosystem of Open Design projects with commit 16bb1e91c6ff7f6cac2cd164146e363a2394a3af. This is based on a discussion I had today with @almostserena and Zoe Romano from the DSI4EU project, and based on this publication: Menichinelli, M., & Valsecchi, F. (2016). The meta-design of systems: how design, data and software enable the organizing of open, distributed, and collaborative processes. In 6th IFDP - Systems & Design: Beyond Processes and Thinking (pp. 518–537). Valencia: Editorial Universitat Politècnica de València.

[openp2pdesign]

Interesting post about how to identify fake open source: https://hackernoon.com/open-source-is-everywhere-but-so-is-fake-open-source-jh8a33fi