A couple of points.

Volunteers

Open source, crowd sourced, etc. efforts rely on the contributions of volunteers and contributions of time.  For efforts like wikipedia and crowd sourcing, the relative inexperience of contributors cancels out - providing the process encourages a trend towards excellence. In a technical project like OSE, this is more difficult.  Ad hoc, piecemeal, incremental development efforts are difficult to coordinate.  They tend to diverge rather than staying focused.  On the other hand, the "let a thousand flowers bloom" approach can eventually yield high quality results.  OS software often works this way.  The trade-off is time.  The anarchistic approach follows a kind of genetic algorithm, but is almost impossible to predict.  It can take months or years to produce an acceptable outcome.  OTOH, managed projects require leaders, processes, organization, protocols, etc - many of which do not appeal to some kinds of contributors.

As I see it, the trick is to strike a balance.  I would encourage people to pursue any idea even vaguely related to the overall project goals.  As a new idea gathers substance (and other contributors), it could be incubated as an early project.  As the project matures, additional resources could be applied that include money, computer support, specialists, etc.  Even with all that, some project will take a long time to come to fruition, because skills sets either have to be re-learned (steam engines, for example), or you have to local subject matter experts willing to contribute.

Attracting, encouraging, and nurturing volunteers would be at the heart of the organization.

Dispersed Organization

Personally, I favor the idea of a truly dispersed organization.  Rather than having an FeF, I would encourage the development of many such places, labs, shops, etc.  Most won't be able to do all, but taken together they are a much bigger source than any one installation.  Such an approach needs coordination.  Think about having a central resource that describes how to bootstrap the development of a personal fablab.  Tutorials on metal and wood working - not necessarily developed in-house, but drawing on the resources of the Internet.  Past the bootstrap lay the tools in development, the GVCS in OSE's case. It's easy to see how local chapters of makers could come together to pool resources and create their own local FeF's.

This approach also encourages outreach to other parts of the globe.  Any such project should, from the very start, be global in nature.  Diversity is an essential strength.  Materials and tools available in one place will be rare in another.  Scarcity of labor in one place is commonly available in others.  That said, there are challenges to coordinating things on a global basis.  Timezones usually prevent synchronous meetings shifting actual work into forums and the like.  Language is another consideration - not everyone speaks English.

Transparency

I agree that transparency should be present, but there is no need to take it to an extreme.  Posting every receipt seems silly to me.  I'd rather see such things be summarized in monthly reports from any project, chapter, branch, or group that the organization funds or is generated by them personally.  Summaries can be better organized, whereas posting everything individually leads to a sea of information that is impossible to understand or manage.  The big picture is hard to grasp.

This all just a matter of establishing accepted procedures and processes.  Effort should be made to minimize and simplify them while maintaining the qualify of information.

--------------------------------------------------------

There is more to this subject, but this are the quick thoughts off the top of my head.

- Mark

I've been a contributor to several open source projects (all software related) - some big, some small.  The small projects are often clustered around a single leader who is the "vision holder".  Successful projects on SourceForge follow this path.  Any project formed with or grows to more than a dozen or so people require at least some kind of organization and administration, in my opinion.  If you look at any of the successful, large OS projects, you will find some kind of organization behind it:  Apache, Mozilla, Wikipedia, Eclipse, etc.  The really good ones keep the staff to a bare minimum and actively foster a volunteer effort that work collaboratively towards overall project goals.

Collaboration is at the heart of all such efforts.  The tools exist to make this almost painless:  a wiki, a forum, a chat room, blogging, and possibly a content repository.  Setting up the tools is also a simple process.  Most commercially availalble website packages either include these tools or are very simple to extend to include them.  Furthermore, the monthly cost to operate such a site is very small:  $50 a month will get you a fairly powerful site (and you can go much cheaper, too).  You'll need disk space, since collaboration tends to eat up storage.  Bandwidth is less of an issue if you use third party video repositories like YouTube or Vimeo.

No, the rub comes from coordinating the actions of a very dispersed group of people with very different ideas on how things should be done.  If you gather three people into a room and ask them how to do something, you'll get four opinions, two of which will be mutually exclusive.  This is where administration and leadership come into play.  If we suppose that all projects will pass through four stages:  idea, incubation, mature, and retired, then different kinds of mediation are used at each stage.  The idea stage, by definition, is wide open.  Pretty much anything goes (subject to cultural conventions).  If two people disagree on an idea - let them go their ways and compete.  Other contributors will be attracted not only to the idea, but to the people who are participating in the early stages.

Once the umbrella organization starts contributing resources (especially money), it gets more of a say in how things are run.  This would include, for example, transparency reporting requirements.  Incubated projects would be run by a group of people and might have an obvious leader - or perhaps not.  Incubated projects are still exploratory, but they are now working towards creating a design that can be moved (eventually) into production.  There would be organization standards around how this is done including documentation standards, CAD and CAM standards, etc.  At this point, if an individual strongly disagrees with the direction of the incubated project, or is disruptive of the project, discipline can be applied in varying amounts.  It is no longer in the general interest to disrupt progress, but there is certainly room for creative criticism leading to improvements in the design (etc).  Note that disaffected people are free to fall back to the idea phase and form a new project, but also note that the umbrella organization won't allocate resources to competing incubated projects.

Restrictions become even tighter once the project enters the mature phase.  In this phase, the project goes into production.  That means that the design is solid, has been prototyped, and most problems worked out.  At this stage, major design changes are considered disruptive since it impacts not only the developers, but users in the field.  The mature project is focused on improving the quality of documentation, promoting the product(s), customer support, etc.  Changes are carefully manage via a change management system.  Team members of the mature project may changes at it moves into this phase.  There is a need for different skills.  Often, the developers will have ideas for a next generation of the project and fall back to ideas and then incubating an NG project.  Leadership at this point is done by an appointed Product Manager.  This role is a bit different than the Project Manager role that might be present in an incubated project.  The Product Manager is concerned with marketing, packaging, customer support response, and other issues unrelated to development.

Retired projects are at end-of-life and no longer require management.  There might be some minimal support for backwards compatibility or to support products in the field.

-----------------------------------------

I have already put forth some of these ideas for OSE.  Indeed, there really isn't a need for an OSE 2.0 - the 1.0 organization could be made to work, but some changes would be needed.  I have been criticized as being too "corporate".  Guilty, for good reasons.  First of all, there are elements of the corporate approach that do work.  Granted there are many excesses that should be avoided, but hierarchical management structures work well - as long as there is a shared culture, a shared vision, patience, and good will.  Most of this structure will be volunteers themselves, charged (in part) with maintaining morale, focus, energy, and (if possible) fun.  Also, in spite of our shared desire for a post-money economy of abundance, we still have to work under existing laws - where ever we choose to operate.  Corporations, especially non-profit ones, are part of that picture.  There are two ways to change any system:  work within it towards incremental change or revolt.  Personally, I am not prepared for revolution at this point.

- Mark

@nick

There a number of ways that paid collaborators can be used effectively:

1.  Ask them to produce a research report for a fixed price.
2.  Create a retainer with some number of hours that allow them to respond to questions posed by team members.
3.  Ask them to bid on the design of a particular machine - fixed price works best here, but many won't go for it unless the results are well specified.
4.  Hire them for n days/week to be a project team member.
5.  Ask them to bid on a design created by others.

The trick is to be specific.  Know what you want these people to do.  Open ended collaboration is the most expensive route and bound to lead to disappointment.

- Mark

mjn,
I agree completely with your suggestions for paid collaborators, when dealing with pay deal with spelled out specific terms.  All methods of pay 1-5 are valid, but mainly after you have a clear project trajectory.  When dealing with more open ended problems, like how to design a resilient open source solar energy system how do you reward and or test good designs?
I think a series of crowd funded paid competitions would provide interesting results and ensure that the crowd was polled for best ideas before proceeding.  Of course OSE and the vision holder could always retain veto and judging power, but seems to me this might be a better way to make certain the best ideas are pulled from the crowd.

>Still, you'd have to create a project to define the terms of the competition and the design requirements. 

Right, the scope of which really sets the stage for the results you'll get.  Thats where it gets very complex IMO and probably why there will tend to be a single vision holder for many of these projects.  There are so many divergent approaches that it becomes impossible to comb through them all.  I think that is why at some point Marcin simply had to nail done 50 designs, and dictate the approach on several of them, otherwise the thing would never gain the direction and focus needed for liftoff.  As we are seeing many have a beef with that approach, but in Marcins defense I'd say that one guy keeping a vision has a better chance of coherency than multiple, often divergent views fighting for an angle.

I'm rambling a bit, but what I'm realizing is that there is some legitimacy in having something of a benign dictator in the early stages of project formation.  The complexity just does not allow for group consensus decision making, that comes later, after the attempt to break through chaos. 

Having said that I think it would be awesome to see many other OSE type projects emerge taking different trajectories.  IMO there is just so much complexity involved in something like this, that the results are far from guaranteed and the more experiments out there running in parallel the better.  Yes I realize that you potentially diffuse resources that way, but look at it this way we have a global economic system going down the drain and millions of potential contributors to draw from, if you can compensate marginally you do not need to worry about a collaborator resource shortage. This would give participants better options for finding a group/project they agree with and also the whole field more info and results to work for. 

robotjosh,
Sounds like an interesting idea. Have you had pretty good luck freelancing so far?  I looked into it a while back for engineering design work, and it looked like the work options in that area were pretty sparse.  I'd certainly be interested in elancing though, especially if it let me earn a living online and freed my location up.  My skillset is probably a bit off right now (limited programming background and in need of a good review of CAD and Pro-E), but I have a BS in Mechanical Engineering, and am adaptable and very willing to learn.... 

It sounds like it would be a sort of an open source firm.   I like the concept, maybe its worth a separate thread to discuss more?

Excellent analysis, throughout this thread! Let's see if I can summarize, and build on the meta-structure of system needs and pressures:

Mark has a handle on the main developer schemata - Ideation/Development/Production/Support. Idea-creation is wide open to all, and is the fall-back for differences in vision; don't try to convince the folks who disagree with you. Just move forward with those who do, and support a climate of diversity and insight. Development requires a small team of motivated experts, and is focused on gathering resources, laying out a standard, and building models/data sets. (I'm not sure if detailed accounting makes sense for all such development, but Nick's crowd-funding, and other forms that require money to change hands, would definitely require it.) Production has to be accountable and focused; a Product Manager is key, and the skill-sets required will shift toward meeting the needs of the end users. Finally, Support works to integrate the product, and the sites with production capacity, into the whole. This requires a periodic update, and the support staff can manage all the products as a bundle, calling upon sub-tasks as appropriate. On top of that, Mark mentioned: Volunteer Pull/Quality Filters/Coordination/Transparency. Nobody will start helping, if it's too much work to enter the system, so heavier management costs should by applied only as you dig into the deeper layers of activity. Getting started should take less than 5 minutes. And, Open Source requires a structure for 'a trend toward excellence' - bluntly, we need to have a way to filter, to avoid dilution by endless commentaries. The average YouTube video isn't of the same quality as the average Wikipedia page, because YouTube doesn't have a strong quality filter. Distributed networks have higher coordination needs than local groups, and should keep pushing to lower the cost of interactions. There are myriad issues to coordination, and they'll come up as we try to get things done. Flexibility, and experimentation, are the only ways to build a good fit without bogging down communication with reports and scheduling (and translation!). Transparency is important, but should fit the scale of the activity, from individuals tossing in 2 cents, to small teams, all the way up to production facilities and the organization as a whole. The bigger it is, the more you should keep track of its activities.

Nick's crowd-funded prizes, Josh's open source firm bidding, and personal incentives in general, are all really smart. :) Similar to kickstarter's model, but content-specific, we could gather a single, central crowd-fund for paying out prizes, upon task completion and after review by Marcin's team. (I doubt crowd-allocation of prize funds would be effective. We'd end up funding pet favorites, not system-wide bottlenecks.) We have to remember: folks want to help, even if they don't profit, but the barrier to quality assistance (versus pooled marginal input from volunteer crowds) is often the risk and opportunity cost of not being paid. I'd love to see a simple, easy-to-enter, easy-for-proposals prize model. In line with Mark's bidding outline, Josh's 'affiliate-firm' concept could manage extended contract work and quality accounting, so that OSE funds wouldn't be squandered on half-baked initiatives.

David's 'hobo-hobby' offer (no offense! I'm all about it) is critical for the spirit of OSE. Especially in developing regions, (Angola?) a lot of the locally available energy and talent will be untrained and unorganized. We have to be willing to receive those 'unwashed masses' and 'passers by', or risk becoming an elite of technicians, however dispersed. ("I can't build a CNC machine, but I'll help you lay CEB bricks for a meal.") Marcin's vision of the 200-person village isn't composed entirely of engineers, so we'll have to draw the rest of the folks in with other kinds of opportunities. Most importantly, this becomes the access point for those migrants to begin developing their talents, within the FeF context. Long-term commitments from the surrounding community grow out of the appreciation for our welcoming natures and the opportunities for personal growth that we provide.

And Gregor's vision of chapters and pods is spot on, for the scales of activity that fit it. Same with templates, and assigning task components. Here in Oakland, CA, Tom Fitzpatrick is already rallying for a chapter, and I've been talking to the crew down at All Power Labs, in Berkeley. I could see tons of little 'shop assist" roles playing off each other, experimenting with design and organizational techniques, and collaborating/trading for rapid development beyond Missouri. (Yeah, I want to head out to FeF in a month or two, but how many visitors will come from Brazil?) This works for small-to-midsized operations, but isn't feasible for individuals, and may be clumsy for larger initiatives. Similar to Josh's firms, these local hubs could trade tasks components, sourcing work to teams with the skills and equipment that best fit the task. This minimizes skill and equipment redundancy necessary for the design process. ("I work in a bakery, and built my own brick pizza oven... but I don't have a machine shop, or any interest in making one.")

Generally, I'd prefer to see all these options 'stay on the table'. As activity scale, design life cycle, and the user base's motives change, this lets success flow to the structures that fit at the moment. Best to have a meta-structure for all the main components of each, as a template of ways to organize. Let each person choose their preferred law, and the 'winning' ways will continue to develop, insofar as they work. (Lao Tzu: "Heaven prefers no man, but a sensible man prefers heaven.") We simply develop those ways that have immediate demand, and keep expanding the list of interface options.

Other aspects to consider: Deterrents/Local Optima 'Traps'/Marketability/Adoption Cycle. If there are hurdles, risks, or up-front costs to involvement, that 'enormous talent pool' evaporates. And, if a certain structure inhibits growth of scale, even as it spreads globally, we'll become the next Ashram. 'Marketability' isn't about profit and advertising; it's about making the technologies attractive to people with viable alternatives. Newcomen's genius (aside from the steam engine, itself) was a simple leasing program, which allowed mine operators to 'try our product, virtually risk free!' The adoption cycle is related to all of these aspects: early adopters have different needs and pressures that they apply to the technology, and if those conflict with the needs of the primary user group, the early adopters will inadvertently 'out-class' their product from public demand. That's actually why GVCS is possible, in the first place: agroindustry's take-over (I'm shaking my fist at ADM, you just can't see it...) meant that high capital-input farm equipment was a 'good' thing to them, reducing labor costs, and pushing demand for farm equipment toward a market that didn't fit small farmers. We're not headed in that direction, but there are plenty of adoption-cycle cul de sacs left, for us to get lost in. Being attentive to our potential markets, not just the current user/developers, is key.

Any main points I missed? And who'd like to lay these concepts out, in a framework we can elaborate? (Moving from Ideation to Development, of OSE structural interfacing & S.O.P.s...)