Skip to Content.
Sympa Menu

notify-dpml - [DokuWiki] page added: misc:cbd_analysis

notify-dpml AT lists.ibiblio.org

Subject: DPML Notify

List archive

Chronological Thread  
  • From: <wiki AT dpml.net>
  • To:
  • To: <notify-dpml AT lists.ibiblio.org>
  • Subject: [DokuWiki] page added: misc:cbd_analysis
  • Date: Fri, 20 May 2005 10:57:48 +0000


A page in your DokuWiki was added or changed. Here are the details:

Date : 2005/05/20 10:57
Browser : Mozilla/5.0 (compatible; Konqueror/3.3; Linux) KHTML/3.3.2
(like Gecko)
IP-Address : 219.95.130.42
Hostname : 219.95.130.42
Old Revision: none
New Revision: http://wiki.dpml.net/dokuwiki/doku.php?id=misc:cbd_analysis
Edit Summary: Copied in the Post on dev-dpml from Claude
User : niclas AT hedhman.org


====== Part 1 - Situation May2005 ======
Hierarchically speaking, stakeholder representatives will put down the
project vision, describing the business objectives. Some thoughts are given
here.

The user viewpoint draw the business needs and requirements of metro/FT or
metro/classic users. Those requirements are first derived from the vision.

The developer viewpoint draw the requirements of DPML developers to address
users needs and requirements through software solutions, support, education.


- Who are stakeholders in this project? DPML founders, DPML community,
Steve+Niclas+Peter, donators ? In my experience, it is not easy to determine
clearly the members, but we know that they are represented by staff group or
comittee, who can : bring the ressources(cash, development time, ...) and
take critical decisions. The staff group usually work to fullfill the
stakeholders objectives (And they have to know and understand those
objectives if they don't want to be fired, or to have no more stakeholders to
represent)
- stakeholders IMO are dpml community wich contains also founders.
- stakeholders are represented by which staff group ? Theorically a staff
of 3 persons (founders) but IMHO, effectively by staff group of 1
person (Steve). This can work if the staff group understand and fullfill the
stakeholders aims and objectives.
- It don't work to much, as many community members (stakeholders) are
starting to quiet, as they can't fire the staff group
- Do the staff group knows and understands the stakeholders aims and
objectives ? NO ! Don not exist !
- WHY ? At start, they decided to bypass that step, and planned that after
the first release.
- Many members are now asking for a vision document ie. aims + objectives
reflecting dpml community needs.
- We are then on the right way of creating the DOCUMENT VISION, and all
members are asked to contribute !
- IMHO, a new comittee (staff group) must be created to really represent
the stakeholders :
- the comitee must have a well defined repartition of interrests
represention and take in account founders interest, old veteran members
interest, newbies interest, futur members interest ...
- Rules must be set to overcome any intellectual dictature like
approach.
- decisions must be taken after real understanding and consensus of all
members
- calling to vote on not well defined subjects or without giving other
members time and enough materials to understands the interrest of
represented community members is dictature
- I agree with niclas, that situation is dictatorial based, but it's not
only caused by steve rushing & reverse approach.
- dictature is reforced in this situation by the unvolontary commitment
of all others members, acting as observers, because they don't actually catch
anything, and have decided to wait the end of the tournament, and have a hope
of holy release solutions to learn at their speed.
- will the solution be conform to their particular aims and objectives ?
maybe - But IMHO, the solution will only conform to those who steve aims and
objectives.
- COMMUNITY AIMS and OBJECTIVES are not steve aims and objectives, but
steve can contribute greatly to construct community aims and objectives.
Please note the real distinction here!
- IMH Observation, Steve have not allready sense and adhere to dpml
community aims, and his aims are mostly drived by personal interrest and
challenge. I can understand that, and probably I would have do the same,
after the bad end of Avalon project. But If steve is left to him, he will
end with a solution that nobody in the community will be concerned with.
- Community interrest are based on simple aims, which can be trivial for
guys like steve, niclas but which can also be very difficult to address
because community is not smart and the solution must also address that points.
- The recommended approach is to list all community aims that are
trivial and create a solution for that: Solution must also contains
trivial/intermediate/advanced samples. After or before a release, a new
roadmap is draw to show next generation (evolution) step. The next step will
add some more expressed community aims (trivial or not). Those expressed aims
are in majority formulated from previous release experience + some new
innovatives propositions.
- Aims and objectives may give and indication on his target market :
- This can result in taking out many actual dpml community members as
they dont see their interrest in the orientations, but it will confort and
fidelise all other members
- The target market can grow progressively, with new releases adding new
capabities, and interresting new members
- dpml target market can be well defined simply by describing the
targeted applications type, metro/FT and metro/classic can support in
building/executing/hosting:
- supported applications domains (businnes, telecoms, banking, ...)
- applications architecture (global/by domain/by technology ...)
- supported technologies (dpml containers, ejb/servlet embedding,
remoting, ...)
- dpml target market can be extended by specifying the comnponent based
development process :
- component development tools characteristics and functions (magic,
transit)
- component/service hosting containers characteristics and functions
- dpml component concepts and dpml development process advantages

====== Part 2 - Open Source Software in the Real-World ======
In the enterprise project where I borrowed the concepts of "Stakeholder -
User - Developer" viewpoints,
the representative of the stakeholders is not the company, but the Direction
Staff. Their job and
main mission is to propose(and realize it) a plan to generate substantial
revenues, using company assets
and targeting a growing market. The main job at the startup of the company,
is to gain a market share
(via marketing & commercial actions), and create viable products and services
for their customers.
At that stage, stakeholders are mainly founders and current investors
(powered stakeholders).
If success, The staff can create shares and give opportunities to more
shareholders (unpowered stakeholders)
to join the company venture. The company Direction staff is there to
represent stakehoders interrest, and
will have to continually elaborate company vision (aims and objectives) in
garantee of that.
Shareholders check to see that the company will success and pay back their
investment. In doubt, they quiet
or try to change the staff.


- Where do the "Stakeholder-User-Developer" 3 viewpoints theory came from
? Origin of "StakeHolder-User-Developer" viewpoint analysis. To understand
this in detail, I recommend somme readings : <James L. Heskett - The service
profit chain.>
- Is it really interesting to apply this therory to an OSS based
organization ?
- If yes, how to apply it for OSS based projects organization ?

I am very surprise that people don't even spoke about value, profit,
satisfaction, loyalty of customers as if
those terms where taboo in OSS organizations objectives and aims. At startup,
Profit and interest of OSS
organizations are not fluid cash, but valuable assets like : # of active
members,# of implementations, quality of
software/source/support/documentations, technologie, procedures, etc. ...
Those assets at some treshold will generate high interest on Commercial
companies and investors willing to tranform those assets in more liquidity
financials assets. Taking a look at JBoss Inc. evolution, you see that they
started with no liquity. The grow of his community and adopters, make that
their # of implementations and references growed effectively and gave them
the oportunities to sign big european contract. As I watch their activities
on the net, they act now more and more as commercial profit oriented company,
while their main activity still been in OSS area (considered as non profit
environement).

- Centrality of value : Costumer value(1) equation suggest that the value
of goods and services delivered to customers is equivalent to the results(2)
created for them as well as the quality of the processes(3) used to deliver
the results, all in relation to the price of a service(4) to the customer and
other costs(5) incurred by the costumer in acquiring' the service.
- Customer value : depict the value as perceived by any
client/prospect/person interested by the dpml service.
- results : are artifacts produced in the dpml environment (software,
documents, ...)
- delivery processes : deal with all the internet delivery capabilties +
support + forums ...
- price of service : $0 for the software and/or $fees/day for a dpml
software consultant
- incurred cost for acquisition : based on learning curves + quality
standards + procedures + capacity
- What is DPML customer profile ? Any organisation must be able to
identify and control by some way, his target market: DPML products can
interest differents type of customers, but the classification can be tricky
because many segments share common customers. these segmentation can help
figure how to do it, but I am not well versed in DPML technologies to be able
to depict it. But I know that they can come from many domains: Enterprise
solution Developers - Architects - embedded solutions - banking solutions,
J2ee etc, ...
- As I can see on the support-dpml and dev-dpml many Developement leaders
are subject of interrest in what we can say a new tool for Component-aware
environment development. Some are interested by tools like Transit and Magic,
and others are looking for containers or both. Those High end developers are
the first customers and are those which would create the futur acceptance of
dpml products in enterprise projects. At that point, dpml activity can reach
a treshold that permit interrest of more companies in regard to the good
references he allready have via those leaders. Those lead developers can
actually bypass the need of dpml software consultant but will have more
requirements on the incurred costs by asking more standards adoptions and low
cost procedures.
- The OSS project internal organisation element. To reach the treshold of
commercial companies interest, dmpl organisation must work to grow the
comunity members. Let's depict the community members group/categories and
their roles:
- Founders group : active participants in dev, admin, comities
- Users group : members consist of any person/company using dpml
products for software solution develop.
- Developers group : members consist of any active developer of dpml
products, admin and comities
- Customers group : members consist of users group + users of dpml
based software solutions
- Operational group: any indentified group of active members dealing
with particular dev or delivery process.
- The market shift via Customer growth. Customers group will grow fast, if
dpml organisation have the capacity to catch newbies interest at the fisrt
attempt. A newbie is any high end profile developer which join the dpml site
to evaluate and the adequation of metro products with his futur projects
devlopment. The guy is only newbie in the dpml dev context, and so will first
look for all known standards used by dpml. This is to lower his acquisition
cost. If there are many clear samples, tutorials and roadmap, he will take at
the second evaluation stage. If there is an enterprise level sample
application, he will compare the requirements of that application to his
futurs projects requirements, and project to use the sampleas a fast
prototype start of his project. At stage 4, he will begin to contribute by
suggesting other ways to develop solutions with dpml software tools. Any new
satisfied member is willing to bring his company teams and friends to join.
At the same time, the Dev group must grow to maintain a good ratio of
developers/users. This can append by natural implication of power users and
by the open participation rule. The treshold will be reach very quickly and
investors will begin to evaluate the permanence of the dpml products.
- Employee/customer satisfaction & loyalty theory in service profit chain
In OSS project organisation, employee don't really exist as in business
companies. But the operations are mainly done by members of developers group.
There is 2 distinct levels of service delivery to considere:
- service level 1: dealing directly with dpml products, customers come
and serve themselves on the net guichet. Those users are satisfied if they
can develop easily using dpml tools or be supported anytime by dpml
developers group.
- service level 2: concern customers who need more advanced dpml
support. Those customers will ask for dpml consultant to join their teams and
help in building enterprise solutions using dpml products. The customers at
this level are more commercial companies who will necessary ask and pay for
more specifics components development and garantie on the futur releases
compatibility. The delivery process at this level will be more complex and
need substancial backup and support from the internal dpml developers group.
The positive feedback of customers/users on the net, are the primary
developers satisfaction and motivation as this how the image of the OSS
organisation is best reflected. The level of activity in mailing list and
congratulations from anonymous users are the best way to mesure the
satisfaction in both ways.
- Adaptation to Stakeholders-User-Developer viewpoints. Stakeholders
viewpoint will constraint representative to draw down a vision taking
diverses community interest in consideration. This vision like in commercial
companie address most risk aspects and elaborate budget. The most important
asset to manage is development resource time, as some minimal cash investment
is necessary to hire permanent developers who can maintain substancial
activity.
- The Stakeholders are all community members (founders + active
developers + Community users) represented by the founders + some active
developers. The representative staff must regulary sound the aims and needs
of the community, to draw the roadmap of services and produtcs futur
releases. It is the stakeholder viewpoint, which must be follow strictly by
user and developer viewpoint.
- The User viewpoint usualy depict de process delivery (based on
employee tracking activities). For service level 1: it is not easy to present
user viewpoint, as company use cases and delivery processes are not known.
Standard common specifications/use cases can be used do drive the tutorials
and samples that community users will use as model and/or starting point. for
service level 2: dpml consultant, after some project in companies, will have
more experience to specify users requirements.
- The developer viewpoint must adhere to the user viewpoint and take
technology requirements into account. Adhering to User viewpoint, consist
mainly to address use cases specified in user viewpoint. But this is a
generic approach in the sens that the use cases are in dpml situation, based
on common standards spec, or also generic use cases.

The main advantage of "Stakeholder-User-Developer" viewpoints is all the
benefits of Separation of Concerns ... The difficulties are in the
elaboration of generic use cases as typical samples for dpml tutorial.




--
This mail was generated by DokuWiki at
http://wiki.dpml.net/dokuwiki/



  • [DokuWiki] page added: misc:cbd_analysis, wiki, 05/20/2005

Archive powered by MHonArc 2.6.24.

Top of Page