Overview and Context

The Open Source Ecology project (OSE) is really a collection of projects, each focused on a task that brings us close to the vision described in the OE Proposal. Many of these projects will be focused on the Global Village Construction Set, but smaller projects will likely be set up around component development and other tasks. OSE is in the process of setting up projects for all 50 of the GVCS Tools. This document and those related to the Guide to OSE Projects is intended to provide guidelines on how to manage an OSE project.

It is important to understand that OSE embraces Open Source Development, which means that many of the people working on OSE projects are volunteers donating their time, money, and labor to something that they believe in. The principles of open source have an impact on how open source projects are run. Transparency is important. The voluntary contributions of labor, time, and money influence how things can be done and how fast things can be done. Care must be taken with the intellectual property contributed to OSE. Even open source must be protected against those who might take it and lock it up (via patents, for example).

As the title implies, this document describes how to manage an OSE project. If you are interested in starting one up, please see Starting an OSE Project.

Roles and Responsibilities

Every OSE project is considered a team of people who have come together to design, develop, and build something that furthers the overall goals of OSE whether that is a GVCS machine, a new open source component, or an applications of existing technologies. Especially for GVCS projects, there are certain well-defined roles taken on by project volunteers. These include:

Project Manager and Sub-project Team Leaders
CAD Designers
Prototypers and Fabricators
Marketing Specialists and Fundraisers
Recruitment
Power Electronics Developers
Mechanical Engineers
Software Engineers
Metallurgists
Documentation Specialists and Videographers
Subject Matter Experts
Reviewers

Project Manager Duties

The OSE project manager is the key leader of an OSE project. Duties include:

Develop a plan and guide it's execute towards developing and delivering an OSE product.
Lead volunteers in the tasks needed to develop a product.
Recruit volunteers as needed.
Communicate project status through the wiki, forums, blog, and other channels.
Work with the OSE Director to coordinate this project with other OSE projects.
Ensure high quality product documentation that abides by OSE specifications.
Take responsibility for any money transactions that may be required.

Marketing Specialist Duties

Ideally, each OSE project (especially the major ones) will have a marketing specialist. The person is responsible for communicating the worth of this product to the rest of OSE and to the world at large. The marketing specialist works closely with the project manager to:

Develop and deliver product-oriented documentation and literature
Develop and deliver promotional material including web pages, blogs, announcements, press releases, photos, videos, etc.
Promote the product for recruitment purposes
Promote the product for fund raising purposes

Documentation Specialist Duties

The project documentation specialist is responsible for creating and maintaining all of the documentation associated with the project which include:

Research notes and links
All technical documentation
Fabrication notes, photos, and videos
Descriptions, photos, and videos of the product in use
Marketing materials
Educational materials

Subject Matter Expert Duties

A subject matter expert (SME) is (as the name implies) an expert in the subject area that the product is based on. Where more than one technology is used to develop a product, multiple subject matter experts can be brought in. So, for example, the welding table project might have subject matter experts in welding and numerical control devices.

Duties of the SME include:

Technical guidance and advice
Review of design and technical materials produced

Developer Duties

There are many different kinds of developers that can be associated with a project. They include CAD designers, product designers, artists, electrical and mechanical engineers, fabricators, makers, programmers, etc.

Developer duties include:

Work with the project manager to communicate availability
Completion of work tasks in a timely manner
Working with the process tools developed by OSE, such as Pivotal for project tracking
Communication of completion or development difficulties as they occur.

Working with the OSE Core Team

A high level view of OSE leadership can be viewed in Development Team. Among these is the "OSE Core Team". The core team is led by the OSE Executive Director (OSE-ED), currently Marcin Jakubowski who is also the founder of OSE. Reporting to him are several positions that ensure that the whole OSE project runs smoothly. These include a Media Director, Resource Director and Donor Relations, Business Consultant, Operations Manager, and Web Administrator. These people are there to support the work of the project manager, in addition to other responsibilities. While they can't do project work for you, they are a resource that can be tapped for ideas, etc.

At this time, all OSE project managers report to the OSE Executive Director (Marcin). This is likely to change over time since no one can easily direct the efforts of fifty separate (and interconnected) projects. The following things should be communicated to the Executive Director:

Major milestones accomplished
Major problems that have come up
Conflicts with other projects
Money related matters (TBD)

What he doesn't need to hear is all of the fine details going on in your project. It's too much information. The OSE Wiki pages are designed to give the Executive Director detailed insight as needed as well as providing information to developers, fabricators, makers, and consumers. He will be looking at certain pages to get a feel for progress, such as the GVCS Tools Status. Such pages need to be kept up to date and accurate.

Managing a Project

Delegation and Division of Labor

All of the GVCS projects are too large for one person to design, develop, and build. With that in mind, the project manager needs to recruit new people to his (or her) team and give them things to do. When the team is small (3-8), internal project communication can be managed. As the team grows beyond that, additional organization may need to be added. To some extent, this is a matter of personal management style: shallow structures vs. deep ones, report and status styles, hands-on vs. hands-off, etc. There is plenty of room in OSE product development to accommodate different approaches to product development and team organization. Ultimately, each OSE project will be judged on it's results: the product(s) that come out of it.

OSE Project Stages

Some OSE projects will start as new ideas and build their way towards being a full OSE project. OSE has defined four "stages" of projects:

Idea
Incubation
Development
Support

These are more fully defined, along with requirements and resources provided in OSE Project Stages.

The OSE Project Life-Cycle

Here is a diagram from the the OSE Development Strategy:

Design leads to drawings and material specifications. These are reviewed and spun out to fabrication bids leading to prototype assembly and testing. Eventually, the product goes into production.

Key Milestones

The following are some of the key milestones in all OSE projects:

Product Description and Rationale
Design and Specification
Part Sourcing and Build Instructions
Design Review
Fabrication
Prototype Assembly and Testing
Full Fab/Assembly Documentation
Production

Some of these steps may be iterative or broken down into smaller milestones as needed.

Project Tracking using Pivotal

Recently, OSE has started to experiment with a project management application called Pivotal. This tools has been made available to OSE based on it's non-profit, open source status free of charge. The Pivotal Task Tracker allows tasks (stories) to be defined, tracked, and managed using agile development techniques. Our current goal is to import the development steps of the GVCS Development Template into Pivotal - as tasks that can be taken on by people. The Systems Engineering Breakdown Diagrams should break technologies down into components, so these can be turned into tasks. The key is to break down complex development paths into small chunks - as suggested in this important writing.

All of the OSE projects are public to view, but you must be a team member to enter new stories or work on a task. To see the public OSE projects link to [1] and search for "OSE".

The GVCS Tools Status is also something of a management tool since it rolls up much of the status and high level progress of the various projects. You can more or less see what projects are active and what is being worked on (provided this page is maintained).

Organizing Information

The amount of information associated with an OSE project can be considerable. The GVCS Organizational Development Template has some information on project information and a more detailed view should be considered at GVCS Development Template. There is also a proposed organization strategy at Mark J Norton/GVCS Template.

All project information should be entered into the OSE wiki. At a high level, the following collections of information should be defined:

Overview - main entry point, define the problems to be solved.
Research - background, theory, interesting, links, etc.
Design - what is being built.
Specifications - part dimensions and sources.
Bill of Materials - list of parts and prices.
Build Instructions - instructions on building parts, modifying purchased parts, and assembly.
Development - project status, development activities, prototypes, etc.
User Manual - how to operate this product.

Documentation Standards

Documentation standards to describe and track OSE projects are still under development. Only one product has gone through the full project life cycle - the CEB Press, and others have several prototypes - LifeTrac, Microtractor, Power Cube,Torch table - and are under development. Have a look at how these pages are organized to get a feel for how to set up OSE project pages. All GVCS projects should use the Product Template, which is illustrated on Torch Table Intro. At a minimum, each GVCS project should have the following pages:

Intro
Development process
Bill of Materials
Build Instructions
Buy It!
User's Manual

Note: Marcin would eliminate the Buy It until AFTER clarity is attained on: the OSE Label, OSE Specifications, Fabricator Training, Product Standards and Testing, License - and other fundamentals of Distributive Enterprise creation. We are setting new standards for distributive enterprise, and this should not be taken lightly.

This organization is being discussed at the current time (June 2011) and may be revised in the future.

The Wiki_Templates describes the only real standard we have for project documentation at this time by the core team back in January, 2011 (Marcin, Isaiah, Floyd in a face-to-face meeting). Other templates have been proposed independently of the core team since then, and much confusion has arisen as many people joined development efforts. Mark Norton has proposed expanding the tool template to include pages for an Overview, Research, Design, Development, Specifications, Bill of Materials, Build Instructions, How to Buy, and a User Manual. See Mark J Norton/GVCS Template for details but be aware that this is NOT an adopted OSE standard.

Other pages related to project documentation include:

Wiki Documentation Standards

Team Dynamics

An OSE project team is assembled for the purpose of developing a GVCS Product, Part, or some other thing. How well the team works together will determine how effective and efficient the development process is. As such, the project manager sometimes needs to play the role of parent, stepping in to situations that might arise between members of the team before it affects overall performance. Ideally, participants themselves should be able to resolve disputes, but if not the project manager should guide them to a resolution. Get the issue out into a discussion. Clarify what the problem is and what the alternatives are. Then work towards a compromise.

When things are going well, there is an excitement and energy that can be sensed. There is a feeling of things moving along at a good pace, of things getting done. Development means solving problems sequentially. Marcin wrote an Essay on Creative Problem-Solving that is worth reading.

Dealing with Volunteers

Everyone involved with an OSE project should keep in mind that we are all volunteers. We are contributing our time to a project that we believe in. However, we should also remember that most of us have a life outside of OSE and that we need to be patient when that life conflicts with OSE development activities. Cultivate empathy, patience and understanding.

Recruitment

OSE already has many people who are actively involved in it and new people arrive nearly every day. Recruiting people for your project can be as simple as reaching out to people new to the project. Keep an eye on Recent Wiki Changes for new profiles posted. These will usually contain an email address. Welcome them to OSE, explain your project a bit and invite them to contribute. If they express interest, it's best to give them a small task first before bringing them on as a full member. This allows you to assess their ability to work and start to establish the trust that vital in a functional team.

Other methods of recruitment include posting a blog entry that calls for volunteers, announcing your needs in the OSE chat room, and tapping into the various pools of specialized labor (CAD designers, for example). The OSE Crowdmap can also show the location of OSE people geographically - which can sometimes matter if local prototyping is planned.

OSE is also in the process of developing a database tool that will enable project manager to search for specific skills among registered participants. This tool, once available, will be a great help in finding particularly needed talents.

Staying Focused

Staying focused can sometimes be difficult in open source projects. There is a tendency to be distracted by new ideas, other open source projects, etc. Sometimes a problem is overworked or too much detail added. It falls to the project manager to strike a balance on such things. Exploration of new ideas is useful, but if they are not relevant to the task at hand then the idea is not contributing to progress. Best to document the idea in the wiki and move on.

Lengthy discussion on how to solve a particular problem can also cause a project to lose focus. Look for circular arguments, the same points being repeated, extraneous information being added, etc. At this point, a decision is needed - bring the team to consensus or make a decision and move on.

Individuals sometimes need to be prodded a bit to stay on task. They may need the occasional gentle reminder that the team needs their work. Praise and recognition for accomplishments (even small ones) can go a long way to keeping people on task and focused as the project continues, so consider positive as well as controlling methods.

Disruptive or Harmful Behaviors

Occasionally, contributors will demonstrate disruptive or harmful behaviors. These include excessively critical comments, personal attacks on other people, disrespectful attitudes, etc. When such behaviors are exhibited, they need to be dealt with firmly and immediately. Explain that such behaviors are not acceptable. If it continues, consider easing that person out of the project. Naturally, this is not always so cut and dry. Somehow truly talented people are often socially maladjusted. It then becomes a judgment call on the project manager's part: is this person's contributions worth the disruptions he (or she) is causing? If yes, it may be necessary to isolate that person from the rest of the team and managed separately.

Time management - Yours and Theirs

Time management on an open source project can be difficult - especially if some kind of real time schedule is desired or required. It is very difficult to predict (and rely on) the efforts of volunteers. Time management is best done by keeping things agile (in the formal sense of that word). Tasks should be broken down into small, easily accomplished work objectives. Track them using the Pivotal web application.

Communication

Communication is an essential part of all open source projects and be broken down into the following:

Coordination between a project and OSE management
Coordination of project team members
Outreach - looking for more contributors
Promotion - making the public aware of your product

Communicating status is part of the project manager's responsibilities. The GVCS Tools Status should be kept up to date along with other status pages that may be created.

Coordination of project team members is done using the suite of collaboration tools made available to OSE project: a project forum, a Pivotal project, a project chat room, and the wiki. The forum should be used for general and specific discussion of project related problems and issues. The Pivotal project defines and tracks tasks (stories). The chat room can handle real time communication needs. Finally, the wiki has "Talk:" pages that enable discussions on project related wiki pages.

In addition to the discussion on recruitment above, you can use the Project Needs page to describe particular things that need doing.

If your project has a marketing person associated with it, then it falls to that person to promote the product. If not, then the project manager is called on to write blog posts to update the general public on project status.

Money Matters

Fund Raising

If money is require to develop this product, have a look at the following pages for ideas on raising money:

On-Site Fabrication at Factor e Farm for bootstrap funding
Business Plan
Incubator Business Plan
Lifetime Investors
Support Open Source Ecology

Keeping Track of Money

OSE policies on keeping track of money should be added here.

Transparency

OSE has a policy of full transparency. That means that all income, donations, material and labor expenses, and other expenses must be communicated publicly. This can be done in the blog and/or wiki.

Record Keeping

Keeping track of things will prevent problems later. OSE doesn't have any policies regarding record keeping at this time, so figure out what needs to be tracked and track it. The wiki is the best place for this.

Managing an OSE Project

Contents