[doap-interest] DOAP and customers
Erling Wegger Linde
erlingwl at gmail.com
Thu Aug 14 20:06:31 CEST 2008
You might be right that this is out of scope of DOAP.
However, the client, customer or product owner is the most important
role/persons for many projects. So maybe one should consider adding
such roles to DOAP even if would be a bit complex.
The role I am mostly interested in is the product owner/client that is
monitoring the projects progress, prioritizing requirements etc. I.e.
the customers that the development team/project leader have a dialog
I believe that customers that buy products that are results of
projects, but doesn't get involved while the project goes on, is out
of the scope of DOAP. So maybe it is possible to narrow the number of
roles down to a few candidates for adding to doap.. What do you think?
On Thu, Aug 14, 2008 at 6:45 PM, James Howison <james at howison.name> wrote:
> Seems to me that a customer relationship to a project is not well defined
> (Software customer, support customer, contract customer, source customer,
> re-distributer ....).
> The range of types of commercial relationships is pretty large and a single
> word doesn't do much justice. Moreover it isn't clear what the customer is
> getting (what the object for a putative doap:customer would be).
> For example a Project can produce multiple pieces of software each of which
> might be the product. Perhaps it would help to think of parts of the doap
> vocabulary being products that a customer might purchase, then seeking a
> vocabulary better suited to describing the specific type of commercial
> relationship you are interested in. I rather think, though, that you'll
> find that a Project is something that is part_of a Company, a Product is
> released by a Company, and a Customer is customerOf the Company, in some
> On Aug 14, 2008, at 7:05 AM, Erling Wegger Linde wrote:
>> (I think somewhere this thread didn't continue on the doap-interest
>> list, but only between the two of us)
>> It would be great if anyone else would state their opinion on this.
>> Even if not every project, or even the majority of open source
>> projects don't need a "client" property, I still think it would
>> benefit DOAP, as it could more easily be adopted in commercial
>> - Erling =)
>> On Thu, Aug 14, 2008 at 9:54 AM, Stuart A. Yeates <syeates at gmail.com>
>>> On Thu, Aug 14, 2008 at 7:22 PM, Erling Wegger Linde <erlingwl at gmail.com>
>>>> I mean the party that you relate to when you develop your software. In
>>>> Scrum it would be the Product Owner for instance. I think that is a
>>>> very important role for a software project.
>>>> To give you some context:
>>>> We're developing an application where project information is stored
>>>> using DOAP. We want a customer to be able to log in and see
>>>> information for every project he is involved in, for instance mail
>>>> adresses to developers, project managers etc. (and much much more).
>>>> But somehow we need to link a customer to a project (so he cannot see
>>>> information about other projects, because such information can be
>>>> sensitive/confidential), and it just feels weird that we could use
>>>> maintainer, developer and the other properties to connect our own
>>>> people to a project, but not the customers.
>>>> So what I mean with customer, is the persons that can prioritize
>>>> requirements, monitors the process etc. Maybe customer is not the best
>>>> term in English?
>>> Thank you for clarifying your meaning.
>>> Generally when you have an on-going customer for whom you're building
>>> software the term in English would be "client" (at least in my
>>> experience). Unfortunately this term also has meanings in terms of
>>> software architecture (i.e. client-server archiecture).
>>> I'm also not sure whether all/many open source projects have people in
>>> this role. I'm aware that lots of developers of open source software
>>> have people in this role, but I'm not sure how many projects do,
>>> particularly under, for example, the ASF model of open source. While
>>> not all uses of DOAP are in open source, most of them are, which is
>>> probably why we don't have this role yet.
>>> Anyone else have thoughts?
>> Med vennlig hilsen
>> Erling Wegger Linde
>> doap-interest mailing list
>> doap-interest at lists.gnomehack.com
> doap-interest mailing list
> doap-interest at lists.gnomehack.com
Med vennlig hilsen
Erling Wegger Linde
More information about the doap-interest