Re: OpenP2PDesign
Suresh Fernando
Sorry for the delayed response. Here are a couple of thoughts about potential collaboration:
You say:
Working on the Collaborative Activity Source Code for mapping the nodes in the Ecosystem and their connections would be great as a collaboration: we could use it to describe single projects (their activity) and the collaborative activity of the Ecosystem as a whole.
As you have probably gathered by reviewing the OpenKollab emails, we are currently working on getting know projects in the Distributed Manufacturing space and 'mapping' this space. What exactly it means to map this space will be defined by what we do in the next while so ask me later ;-) Maybe your methodology could add some value to what we are working on. Let me know if you would like to explore this.
Another way that we might be able to collaborate is around the area of collaborative intelligence and research. Part of the longer terms strategy for OK will involved having research and analysis as a part of the OK ecosystem. This is to say that we are very open to collaborating on the development of a research and analysis group. Since you are already writing books and developing a lot of proprietary intelligence, this might fit with what we are doing.
Among other things, OK is very focused on building its communications infrastructure and associated channels. This will allow ecosystem partners (p2pdesign possibly) access to our networks, visibility etc.
Let me know what you think.
Suresh
There are at least 3-4 books planned for openp2pdesign.org, one of them will be a collaboration with another organization. I see them as projects because as a designer I always think in terms of "projects" and, you know, they are my open source code, I give them for free and then I can get paid with services (mainly workshops or lectures). And I believe that knowledge is a tool too.OpenKollab is very project focused. We obviously recognize the value of information and create quite a bit of it ourselves, but the primary objective of the group is to bring about positive social change by leveraging open collaboration principles to connect specific projects.
For unstructured informations there is the blog and twitter, but books are projects for me.
/I am wondering if you think any of the specific processes that you have identified/developed would apply directly to the work that we are doing?/
I should study more OpenKollab and think about it, but I already think there's at least one easy thing you can use and it's using some specific tools/visualization for describing the projects and their collaboration.
As with an Open P2P Design process one could co-design a collaborative activity, there is also a specific blueprint, an (open) source code for it I developed starting from Service Design and other fields. As for any blueprint or technical drawing it is useful for designing but also for analyzing and understanding any Open and Collaborative System/Organization.
I will try soon to summarize in English and publish an introduction to this "Collaborative Activity Source Code" I've been defining, so you may understand it better.Actually openp2pdesign.org is only me right now but I'm working on creating a group and on having more time to work on it.
With that in mind, we are interested in exploring collaboration possibilities with your group if you are interested.
Of course, yes, it will be great to collaborate but right now I don't have so much time. Let's keep in contact for this.
Working on the Collaborative Activity Source Code for mapping the nodes in the Ecosystem and their connections would be great as a collaboration: we could use it to describe single projects (their activity) and the collaborative activity of the Ecosystem as a whole.
/Are there any projects that you are working on, or have been contemplating, that might be worth talking about?/
Oh yes! I need more free time, not ideas for projects! ;-)
But yes, there is especially one idea that I've just started thinking about while preparing some Open P2P Design workshops in Asia.
I think that the tools and softwares we have right now are not ready yet for collaborative Open Design projects. They are great for working with code, but it's not possible to reduce every design projects to just human-readable code, and even if we manage to do that, only very skilled professionals would be able to work and collaborate on it. And I want to have more people as possible involved in Open Systems and Open Design.
During those workshops, students used Subversion (a Version Control System) and Trac (a Forge) for developing Open Design projects with the Open P2P Design methodology. And soon we realized that for design projects these tools are very limited; we don't need brand new tools, for the moment the only thing we need is having a Version Control System and Forge that work and show the diff and merge of binary files (images, CAD, 2D bitmap, 2D vector, 3D models) which is almost impossible right now.
So it's just a matter of adding some functionalities to already existing open source Version Control Systems and Web-based Forges; I've been thinking about it since some months, and I briefly suggested the idea in my Media Ecologies presentation.
This is a project that could be useful for everyone doing Open Design projects in a collaborative way, I would really like to start it (even using part of the Open P2P Design process to organize it) and I will need some coders of course, so this is a project that could be interesting for us. Just wait until I write down a proposal for the project, I'm very busy right now with the job and a lot of work in the backoffice of openp2pdesign.org, please just wait! :-)
Let's keep in contact on these ideas, and don't forget to add OpenKollab to the OpenBusiness/NESTA/TheGuardian Open 100 competition!
http://www.openbusiness.cc/open100/about/
See you soon,
Massimohttp://www.openp2pdesign.org/
--
Massimo Menichinelli
_________________________________________________________________________________
openp2pdesign.org
Metadesign for Open Systems, Processes, Projects.
Studying open collaborative projects and the systems that design them since 2005.
http://twitter.com/openp2pdesign
--
Suresh Fernando
WEBSITE: http://radical-inclusion.com
WEBSITE: http://wiki.openkollab.com
BLOG: http://sureshfernando.wordpress.com
TWITTER: http://twitter.com/sureshf
FACEBOOK: facebook.com/suresh.fernando
604-889-8167
Bryan Bishop
<sur...@radical-inclusion.com> wrote:
>> During those workshops, students used Subversion (a Version Control
>> System) and Trac (a Forge) for developing Open Design projects with the Open
>> P2P Design methodology. And soon we realized that for design projects these
>> tools are very limited; we don't need brand new tools, for the moment the
>> only thing we need is having a Version Control System and Forge that work
>> and show the diff and merge of binary files (images, CAD, 2D bitmap, 2D
>> vector, 3D models) which is almost impossible right now.
>> So it's just a matter of adding some functionalities to already existing
>> open source Version Control Systems and Web-based Forges; I've been thinking
>> about it since some months, and I briefly suggested the idea in my Media
>> Ecologies presentation.
Have you considered not using binary files? Instead of proprietary CAD
formats, just use IGES or STEP, which are not binary files.
Massimo Menichinelli
> currently working on getting know projects in the Distributed Manufacturing
> space and 'mapping' this space. What exactly it means to map this space will
> be defined by what we do in the next while so ask me later ;-) Maybe your
> methodology could add some value to what we are working on. Let me know if
> you would like to explore this.
>
> Another way that we might be able to collaborate is around the area of
> collaborative intelligence and research. Part of the longer terms strategy
> for OK will involved having research and analysis as a part of the OK
> ecosystem. This is to say that we are very open to collaborating on the
> development of a research and analysis group. Since you are already writing
> books and developing a lot of proprietary intelligence, this might fit with
> what we are doing.
>
Great, I think we have just found two directions for our collaboration! :)
Just let me know when you will define important deadlines for
OpenKollab, especially for the mapping activity, so we may organize
the collaboration better.
--
Massimo Menichinelli
Massimo Menichinelli
> Have you considered not using binary files? Instead of proprietary CAD
> formats, just use IGES or STEP, which are not binary files.
Yes, I considered them, I've been mapping open source softwares and
open file formats for Open Design projects.
I even suggested using SVG for this reason during the workshops. We
could have then human-readable files for 2D-3D drawings, that can be
developed collaboratively with diff/merge with existing programming
and version control system softwares.
But the problem is that this solution does not solve the problems and
it is a very hard one.
First, we still need to diff/merge bitmap/raster images (jpg, png,
...). Yes, some softwares like TortoiseSVN or Aptana can be used for
comparing images side by side, but it's not really a diff/merge
function.
And then, the main problem is that for being able to draw 2D-3D
drawing just with code, we would need very specific programming
knowledge. Very few designers know how to code, and very few ones have
enough knowledge of geometry, math and coding at the same time;
moreover, you can understand that even with this knowledge, it's more
difficult to code some complex geometries than to design them. I love
Processing and I think it will be even more important in the future
(especially for Generative and Genetic or Evolutionary Design), but I
don't think that Design as a whole will be only about coding in the
future.
And I want not only designers and hackers to be involved in Open
Design, but also everyone, so we will need more tools that facilitate
design activities and participation.
PixelNovel is the first interesting example of what we may need:
http://pixelnovel.com/
--
Massimo Menichinelli
Bryan Bishop
> 2010/1/20 Bryan Bishop <kan...@gmail.com>:
>> Have you considered not using binary files? Instead of proprietary CAD
>> formats, just use IGES or STEP, which are not binary files.
>
> Yes, I considered them, I've been mapping open source softwares and
> open file formats for Open Design projects.
> I even suggested using SVG for this reason during the workshops. We
> could have then human-readable files for 2D-3D drawings, that can be
> developed collaboratively with diff/merge with existing programming
> and version control system softwares.
I would love that. Yes please. That's kinda sorta what SKDB has been
doing. In the mean time though I always feel terrible committing
binary data, like a .png or a .stl file. :-(
> But the problem is that this solution does not solve the problems and
> it is a very hard one.
SVG solves a lot of the problems, I think.
> First, we still need to diff/merge bitmap/raster images (jpg, png,
> ...). Yes, some softwares like TortoiseSVN or Aptana can be used for
> comparing images side by side, but it's not really a diff/merge
> function.
I am not sure how you would merge algorithmically anyway.. it's not a
simple bit+bit (addition) deal, that's going to lose a lot of
information. For this reason maybe images shouldn't be the transmitted
data?
> And then, the main problem is that for being able to draw 2D-3D
> drawing just with code, we would need very specific programming
> knowledge. Very few designers know how to code, and very few ones have
Right. But can't they use tools like Inkscape for SVG?
Thomas Fledrich
> > First, we still need to diff/merge bitmap/raster images (jpg, png,
> > ...). Yes, some softwares like TortoiseSVN or Aptana can be used for
> > comparing images side by side, but it's not really a diff/merge
> > function.
>
> I am not sure how you would merge algorithmically anyway.. it's not a
> simple bit+bit (addition) deal, that's going to lose a lot of
> information. For this reason maybe images shouldn't be the transmitted
> data?
Hmm what exactly do you want to merge? Are the images something like lines on
a unicolor background and you need to get all the lines from two different
formats into a merged file?
Then I would just convert the source files into an uncompressed format (like
bmp) and then merge it bit by bit. Or convert them to different layers in a
format that supports layers (xcf for example).
But I agree that bitmaps are not quite optimal for digitalised blueprints, so
maybe it isn't worth the trouble.
Bryan Bishop
> On Wednesday 20 January 2010 11:33:55 pm Bryan Bishop wrote:
>> > First, we still need to diff/merge bitmap/raster images (jpg, png,
>> > ...). Yes, some softwares like TortoiseSVN or Aptana can be used for
>> > comparing images side by side, but it's not really a diff/merge
>> > function.
>>
>> I am not sure how you would merge algorithmically anyway.. it's not a
>> simple bit+bit (addition) deal, that's going to lose a lot of
>> information. For this reason maybe images shouldn't be the transmitted
>> data?
>
> Hmm what exactly do you want to merge? Are the images something like lines on
Let's say that Joe releases a new design of a bicycle. Amy and Sam
both like it and have ideas for improvement. They take the design and
make some modifications. Amy and Sam then meet up and realize that
they want to merge their histories of the repositories. But! Merging
lines directly on top of one another isn't going to give you a good
image, and on top of taht you lose a lot of engineering information.
> a unicolor background and you need to get all the lines from two different
> formats into a merged file?
> Then I would just convert the source files into an uncompressed format (like
> bmp) and then merge it bit by bit. Or convert them to different layers in a
> format that supports layers (xcf for example).
>
> But I agree that bitmaps are not quite optimal for digitalised blueprints, so
> maybe it isn't worth the trouble.
I agree.
Massimo Menichinelli
> Or convert them to different layers in a
> format that supports layers (xcf for example).
Yes, this is one solution I was thinking of, leaving the actual merge
action to the user, opening a multilayer file with Gimp or Photoshop
or whatever, and having the two versions as different layers.
> But I agree that bitmaps are not quite optimal for digitalised blueprints, so
> maybe it isn't worth the trouble.
>
Yes of course, bitmaps are not suitable for blueprints, only vector
file formats should be used. But what if you want to work
collaboratively on an image, a picture, a poster, or something like
that (this happened to me)? Usually a design project is not just a CAD
file, but there are also a lot of other files (materials, rendering,
...).
I'm not thinking about just product design but about bringing Open
Design practice in every Design field. And while more and more
designers are learning how to code for developing their project, they
still are a minority and I don't think Designers will be use only
coding and no drawings in the future. This is why SVG is not
enough...so rather than waiting all designers (and the users!!!) to
learn how to code it's better to develop specific tools that link
version control systems with some kind of binary files.
Thomas Fledrich
> file formats should be used. But what if you want to work
> collaboratively on an image, a picture, a poster, or something like
> that (this happened to me)? Usually a design project is not just a CAD
> file, but there are also a lot of other files (materials, rendering,
> ...).
As long as it's just 2D drawings, it might be possible to write a pathfinder
program that converts the drawings to vector graphics based on color
differences. I haven't looked into this field yet (for a lack of need), but
would be surprised if there were no pathfinders around yet.
Would be time to write one if this was the case. Too bad the day has only 24
hours and I'm also lazy sometimes. That makes it even more difficult ;-)
I know about ways to do this with altitude color coded 2D terrain maps, that
can be converted to a 3D vector terrain. This is not too difficult to do.
> I'm not thinking about just product design but about bringing Open
> Design practice in every Design field. And while more and more
> designers are learning how to code for developing their project, they
> still are a minority and I don't think Designers will be use only
> coding and no drawings in the future. This is why SVG is not
> enough...so rather than waiting all designers (and the users!!!) to
> learn how to code it's better to develop specific tools that link
> version control systems with some kind of binary files.
IMHO the first key issue we should solve in the open hardware movement would
be to set up efficient, standardized data exchange methods for all sorts of
files. Of course binary data has many uses, it wouldn't make much sense to
specify every pixel of a texture bitmap in a human readable format. Binary
formats have huge advantages in access speed if you know the format itself.
The advantage of xml like stuff is when there is at least a remote possibility
that a human would be interested in directly reading/editing the file.
But a good way would be to go with a dualist way. Set up standard, similarly
structured binary and readable formats for all kinds of stuff and always
supply it with a free converter that can convert in both directions without
data loss.
Bryan Bishop
>> Yes of course, bitmaps are not suitable for blueprints, only vector
>> file formats should be used. But what if you want to work
>> collaboratively on an image, a picture, a poster, or something like
>> that (this happened to me)? Usually a design project is not just a CAD
>> file, but there are also a lot of other files (materials, rendering,
>> ...).
>
> As long as it's just 2D drawings, it might be possible to write a pathfinder
> program that converts the drawings to vector graphics based on color
> differences. I haven't looked into this field yet (for a lack of need), but
> would be surprised if there were no pathfinders around yet.
> Would be time to write one if this was the case. Too bad the day has only 24
> hours and I'm also lazy sometimes. That makes it even more difficult ;-)
>
> I know about ways to do this with altitude color coded 2D terrain maps, that
> can be converted to a 3D vector terrain. This is not too difficult to do.
Have you tried Autotrace?
I hear it's in need of some extra developers. :-)
Thomas Fledrich
> Have you tried Autotrace?
>
> http://autotrace.sf.net/
>
> I hear it's in need of some extra developers. :-)
>
Ouch, more work. Ok, I'll have a look at the source, what they need to improve
and see if I can help.
Thomas Fledrich
I wasn't able to download anything, it seems to be not available. The last
update appears to have been in January 2004. Could it be that the project is
dead?
elifarley
There's this nice open source 2d vector graphics editor called
InkScape, which uses potrace ( http://potrace.sourceforge.net/ )
internally to 'vectorize' bitmaps.
Take a look at this tutorial on tracing with InkScape:
http://www.inkscape.org/doc/tracing/tutorial-tracing.html
See also
http://wiki.inkscape.org/wiki/index.php/Tools#Vectorize.2Ftrace
Maybe Xara LX and Skencil can do tracing too:
http://www.osalt.com/illustrator (open source alternatives to Adobe
Illustrator)
On Jan 23, 1:49 pm, Bryan Bishop <kanz...@gmail.com> wrote:
> - Bryanhttp://heybryan.org/
> 1 512 203 0507
Patrick Anderson
source is in CVS too.
We could start a fork somewhere else if there are bugs (seems there may be).
All developers need food and shelter, but users don't yet know how to provide.
Thomas Fledrich
So I've played around with Autotrace for a few times, this is how I see it
now:
It is able to handle simple files, but crashed when I tried to convert a
digital photo. This is still good enough for converting charsets and simple
black/white images, like scanned in blueprints tend to be (of course they
might need manual editing before or afterwards to remove unwanted lines)
The source did not compile error free when I converted the Visual C makefile
to Borland C++ Builder, the standard compiler I use at the moment.
Something Linux based would be better, but the standard editors that came with
my package are not as good as the Borland one.
I think I've found better Linux based editors but can't download them while
I'm here on the island. Will be back in Europe in about 3 weeks, then I will
be able to do it.
So if there really is a need for this, I guess I could make things like a
circle/ellipse finder. Even though it seems to be more urgent to me to help
create a good OpenSource CAD software or create parts for it. I would be able
to spend about a day a week doing these things at the moment.
> All developers need food and shelter, but users don't yet know how to
> provide.
Yes and balancing all the projects to fullfill these needs and still make
progress everywhere makes it even more difficult.