My own project, Double Choco Latte, has been through several twists in the development cycle. These are normally due to the direct influence of the company I work for requiring a new feature to be implemented in DCL. This also has an adverse impact on how readily the project can accept patches from the community.
As an example, I was developing the FAQ functionality of DCL (and is still unfinished) when the company suddenly had need for a trouble ticket system apart from the bug tracking. Rather than see them throw good money down the drain, I completely halted development of the FAQ system and shoehorned the TTS into DCL. Since then, some users have implemented the missing features on the FAQ.
Being that I am currently the sole developer, getting feature requests and bug reports can be a bit overwhelming and may take additional response time. I have also received a couple of patches that I didn't implement because they didn't fit in with the overall design of DCL. Admittedly, it's not currently perfect, but I make every attempt to at least remember the features that everyone has requested and *not* simply say "I won't implement that". Those unapplied patches will be reimplemented in DCL as they are common feature requests.
In the past, I had tried to proactively seek development/documentation assistance for the project. While I got several responses with interest, in the end it is still only me doing the development work. Parts of the project also suffer because of this since I have to ultimately prioritize the whole bug/feature list into a serialized, volatile road map. I would much prefer to do some development with a few more individuals so more ground is covered a lot more quickly.
So, that's my experience thus far with my own Open Source project. Collaboration is a two-way street that not only requires the cooperation of the project developers, but that of the community as well.
I've been hanging around these guys for a few months now, so when I read things like "vCalendar, POP, etc" are standards, I think the point is being missed.
The thing is, phpGW is at this very minute reworking much of its API to support vCalendar and other standards. Look at the IRC logs for #phpgroupware at http://www.phpgroupware.org/irclogs/ to get a better idea what is going on.
The point of this project is to establish open groupware standards that will be built on top of existing standards. At no point did any of us ever say "hey, let's make our own version of vCalendar" or any other standard. Why reinvent the wheel? This project will provide a common API that will hopefully be implemented in several languages, platforms, and environments (desktop/web).
My project, Double Choco Latte, will be ported to work within the phpGroupWare environment later this year. I think it is very important to provide the basics of groupware along with more specialized applications like project and task management.
As the author of DCL, I feel somewhat compelled to reply to this.
DCL was born out of a need for a configurable system that handled multiple accounts. It is in no way totally software centric, meaning it could be used to report on a variety of tasks where history is required.
Prior to beginning DCL, we had looked at Keystone (bad UI, bad license, says it's open source but only up to a point), Bugzilla (totally software centric), Jitterbug (too much reliance on email), RT (clumsy interface), GNATS (difficult to set up), and probably some others.
I am trying to push DCL towards IT management. I created a new release just yesterday that includes call tickets, partial FAQ support (all the pieces are there, just needs some flow), enhanced project management abilities, and a whole other mess of features. All of these were only available in CVS since the 20000905 release until
yesterday.
DCL is used by our call center, our development staff, our QA staff, and our hardware/networking department. It has proven its value time and time again. We have ~25 products, ~280 accounts, ~12,000 tickets (since Oct 17!!!), and ~6000 work orders in the system.
Another item to consider is that DCL (sometime this year) will be made compatible with phpGroupWare, so DCL will gain some groupware modules and be more extensible.
Anyway, if you haven't, I highly recommend looking at the latest version of DCL. I do encourage users to submit ideas, requests, code, docs, or whatever they feel like contributing. I have a vested interest in DCL (if you couldn't tell!) and I try to listen to the users and accomodate their wishes while not compromising DCL's flexibility.
Slashdot Mirror
As an example, I was developing the FAQ functionality of DCL (and is still unfinished) when the company suddenly had need for a trouble ticket system apart from the bug tracking. Rather than see them throw good money down the drain, I completely halted development of the FAQ system and shoehorned the TTS into DCL. Since then, some users have implemented the missing features on the FAQ.
Being that I am currently the sole developer, getting feature requests and bug reports can be a bit overwhelming and may take additional response time. I have also received a couple of patches that I didn't implement because they didn't fit in with the overall design of DCL. Admittedly, it's not currently perfect, but I make every attempt to at least remember the features that everyone has requested and *not* simply say "I won't implement that". Those unapplied patches will be reimplemented in DCL as they are common feature requests.
In the past, I had tried to proactively seek development/documentation assistance for the project. While I got several responses with interest, in the end it is still only me doing the development work. Parts of the project also suffer because of this since I have to ultimately prioritize the whole bug/feature list into a serialized, volatile road map. I would much prefer to do some development with a few more individuals so more ground is covered a lot more quickly.
So, that's my experience thus far with my own Open Source project. Collaboration is a two-way street that not only requires the cooperation of the project developers, but that of the community as well.
I've been hanging around these guys for a few months now, so when I read things like "vCalendar, POP, etc" are standards, I think the point is being missed.
The thing is, phpGW is at this very minute reworking much of its API to support vCalendar and other standards. Look at the IRC logs for #phpgroupware at http://www.phpgroupware.org/irclogs/ to get a better idea what is going on.
The point of this project is to establish open groupware standards that will be built on top of existing standards. At no point did any of us ever say "hey, let's make our own version of vCalendar" or any other standard. Why reinvent the wheel? This project will provide a common API that will hopefully be implemented in several languages, platforms, and environments (desktop/web).
My project, Double Choco Latte, will be ported to work within the phpGroupWare environment later this year. I think it is very important to provide the basics of groupware along with more specialized applications like project and task management.
As the author of DCL, I feel somewhat compelled to reply to this.
DCL was born out of a need for a configurable system that handled multiple accounts. It is in no way totally software centric, meaning it could be used to report on a variety of tasks where history is required.
Prior to beginning DCL, we had looked at Keystone (bad UI, bad license, says it's open source but only up to a point), Bugzilla (totally software centric), Jitterbug (too much reliance on email), RT (clumsy interface), GNATS (difficult to set up), and probably some others.
I am trying to push DCL towards IT management. I created a new release just yesterday that includes call tickets, partial FAQ support (all the pieces are there, just needs some flow), enhanced project management abilities, and a whole other mess of features. All of these were only available in CVS since the 20000905 release until
yesterday.
DCL is used by our call center, our development staff, our QA staff, and our hardware/networking department. It has proven its value time and time again. We have ~25 products, ~280 accounts, ~12,000 tickets (since Oct 17!!!), and ~6000 work orders in the system.
Another item to consider is that DCL (sometime this year) will be made compatible with phpGroupWare, so DCL will gain some groupware modules and be more extensible.
Anyway, if you haven't, I highly recommend looking at the latest version of DCL. I do encourage users to submit ideas, requests, code, docs, or whatever they feel like contributing. I have a vested interest in DCL (if you couldn't tell!) and I try to listen to the users and accomodate their wishes while not compromising DCL's flexibility.
PDF can also utilize Flate compression (zlib).
or (being that dot is wildcard)
:% s/\.gif/\.png/g