[p2p-research] OpenKollab: Process & Platform
knuggy at gmail.com
Sat Aug 8 04:36:35 CEST 2009
I'm well rested now. Thanks ;)
OpenKollab needs an open architectural base so it can support a variety of
small group developers already at work on specific projects such as your
own. Now we need guys like you to focus on creating that center from which
all varieties might flourish. I am now creating a process model with this
group as a template to begin to see what people's needs are in forming
projects outside organizational boundaries.
Matt Cooperrider began a subproject within OK to create a
>From what I hear, and soon to explore further, is meetup.com is not just a
platform that builds face-to-face meetings, but a project tool as well, with
virtual conference features and such. My recollection of meetup.com is a few
years old, back when it was just a face-to-face tool. From what I gather,
Matt is forming this to surface a core team of developers for the OpenKollab
process and platform to better distinguish between discussion and
development. Matt has a contact within the meetup.com development team. That
should be helpful.
There are a few coders in this project, I just need to get in touch with
them directly to see what they want to do.
I also need to get in touch with everyone that wants to develop the process
And artists as well...
I have learned from constructing web based learning systems that the way you
> set out to create tools is not going to be universally re-usable, but
> instead will probably meet the needs of a significant niche in the long tail
> of needs.
OK must meet the niche and the entirety of the long tail of needs. The
models I am attempting to build with this community will simply be an open
template to inspire the do-it-all web-to-DIY to come. I'm only attempting to
get the ball rolling on presenting a better way to link everyone into one
open interface where everything is socially networked (people, interests,
projects, designs, land, materials, ecologies, ect). I really hope my
intentions are becoming clearer. I just want to see where you might fit into
this, because it seems what you're doing now, like with FLOWS, is vital to
OK without altering much of what you're already doing.
What this means is that you'll need to decide whether you want to dedicate
> to serving that niche, or if you want to help a broader base.
Both. I hope that is now clear.
> if broader base, your tools and processes and the way that they can be
> configured need to be highly adaptable and changeable. So, the above
> description does have adaptability and evolve-ability in some ways, but is
> tightly coupled and hard wired in others.
I agree. Like in terms of the consensus assumption I posed, groups should
decide whether consensus is necessary or not or of what form of governance
they want with each defined process. A consensus approach might be (a
potential 'is') default setting or template created by another community.
I really think we're on the same page here, Sam, it just seems I need to
better express the openness for a decision path after describing each
process. I've made the assumption the reader can pick or add to each
described process. I'll be sure to clarify this as we move forward. I
suppose in a way I have by describing these models as sessions. (See:
http://wiki.openkollab.com/wagn/Process_Model) The OK group did a process
session before I arrived previously titled spec and changed to Process Model
Session 1, so now on the wagn three sessions are listed. I hope this
representation will demonstrate the flexibility of the model without getting
lost or leaving something without a direction at all.
I hope you might attract some readings that relate to systems or process
modeling and development so that can improve that design if necessary. I'll
add them to Resources.
I don't want this group to end up like the Open Manufacturing list. This is
why I came aboard quickly while the iron is clearly hot, because I know
after a measure of time people will fall into assumptive traps and stagnate.
This is not to say I think the OM list is a failure or that the people there
are inept, quite the contrary. It is a really great list in terms of other
lists that came before it. Brilliant people are discussing brilliant things
and posting news and other media that relate to the subjects we've
discussed. Its now well established as a learning community and discussion
group with just a handful of highly active participants like Paul and Bryan,
(that may well have kept the list alive) but now as the group has exceeded
200 subscribers, more folk are coming into the discussive mix. The ideas I
wanted to pursue at the time when forming the OM list were too vague to be
of much help to anything like OK if it were to start then. By the time I
developed a pretty good idea in the direction OK is pursuing, the group had
already settled into a pattern that many other discussion lists have. What
I'm coming to understand by watching the OK community come alive is that
without "real time engagement" links within the group are diminished from
each other and the results are what you find in the majority of e-mail based
discussion lists today. I'm glad I started the group, its a great group, and
it will continue to add to the theoretical work now being applied to OK.
Now is the chance to note to Matt that a general discussion about this area
is already available and that we can keep the existing OK list development
focused. If we do sense more general discussion surfacing, we can start new
lists that distinguish between the two. I say this from experience, when
Bryan Bishop tried to establish a development discussion group for OM it
flopped. I could go into why, but that's fodder for another discussion, one
I'd rather have at OM. I'll start one if you're interested, but I'm more
interested in developing OK with you. ;)
> The metaphor for architecture for a malleable collaboration base is "small
> pieces loosely joined". Many small reusable and reconfigurable parts, all
> optional, and the whole systems itself optional. You want to make it really
> easy to add new tools, or for people to work with their existing tools in
> conjunction with yours. On top of that, I would not even start to design and
> build tools until you actually have some real world people to work with, who
> are asking for web based collab tools, and let them drive the design. But,
> that is just me.
I agree. Let the user's drive the needs, then develop solutions. In this
universal architecture there must be a series of "project templates" or
solutions that are stored in a user friendly directory to use and revise
when needed. These revisions then add to the template repository. This
process can apply not only to projects--but all things--anything imaginable.
So long as we keep it an open, transparent, and as gift economic as possible
I'm very confident the "anything imaginable" will be a good thing for more
people than what platform or "conditions creators" we have available today.
The 'people' >> 'interest' >> 'project' >> 'design' >> 'resources' as a
process formula (or something like that) will found the pursuit of the many
aims to come. Its just a matter of "what do you want to do and how can we
apply that to the OK platform." The user is maximized by OpenKollab--this
vital link--which connects the person to the world that person may have an
interest, and in easily pursuing these interests, when using this platform,
the actions benefit the world. We're already seeing this development in the
many process outlines that have come before as, Sam, you've mentioned--from
Memex before to Facebook and Deepqa today. If we, even as a small group,
keep our heads up, our eyes clear, and have an active sincere interest in
one another, the trust from within our group will spread to others to better
develop the OK platform as we call it presently, and so we have ourself that
little everything module in no time--safe and sound. ;)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the p2presearch