DPML Notify

[<wiki AT dpml.net>]

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/