The main thing I'm doing here Savio is coining terms to refer to groups of stakeholders as perceived by executives. I'd found that people in Sun were referring to the (widely understood) groups of participants in varying ways, so I decided to assert how I would refer to them as a reference point. There's a parallel set of terms needed, as Ron Goldman points out, so that within a community the different stakeholders can be identified unambiguously. I'm surprised you are trying to score competitive points on something so innocent, actually.

@Simon,

>I'm surprised you are trying to score competitive points on something so innocent, actually.

I'm sorry you feel this way. I include the IBM disclaimer so folks know these are my personal views.

I'm really of two minds here.

Evil Savio: Does the world really need a(nother) definition of OSS stakeholders? Don't we as a 'community' spend enough time talking about what is/isn't X?

Good Savio: Hey, it couldn't hurt, so readers, please go and provide your input to Simon.

The only competitive motives here are amongst Evil Savio & Good Savio :-)

If I'd found everyone was using consistent terms I certainly wouldn't have bothered coining new ones :-)

Hi guys,

From my experience in open source and professional open source (which I assume is the relevent model here) the range of contributors is wider than listed above. In many open source projects most or all of the code is written by a few core developers. In the case of professional open source most or all of the code is written by full-time developers employed by the company. In either case developers represent only a small (sometimes the smallest) fraction of the community.

A longer list of contributions:
* Testing. In the course of trying to use the software people encounter and report implementation defects.
* Platform coverage. The community has a wide range of hardware, OS, RDBMS, app servers etc that they run the software on.
* Documentation. People provide improvements to the documentation by reporting inaccuracies and providing 'how-to's etc.
* Forum help. People outside the core team become active on the forums and help other community members overcome hurdles.
* Use cases. People with unique use cases contribute by identifying defects in the requirements and design that prevent the support of their use case.
* Peer review. People with experience in many different aspects of the software will ask why certain design patterns or achitectures or technologies are used and suggest other ones. People will review the code and provide feedback about performance or security etc.
* Translation. People localize the software and documentation into other languages (their own) so their users can use the software.
* Features and Bug fixes. The group already identified above.

For an easy to understand (even for executives) model of how professional open source works try the Beekeeper model: http://wiki.pentaho.org/display/BEEKEEPER/The+Beekeeper

James Dixon
CTO, Pentaho