Hello. I represent a PHP web development firm that has been using PHP5 since the early betas and has now moved to it exclusively.
We are the owners of a number of colocation servers based around the FreeBSD/AMD64 platform. Unfortunately, Zend has chosen not to support their Zend Accelerator product on this platform. They claim they are willing to, if we finance the development.
We had previously been extensive users of turck-mmcache with PHP4, and had been testing it quite positively with PHP5 for some time. But, as you are all aware, development has langered and the lead programmer has now gone to work for Zend.
Having been told that Zend would only support FreeBSD/AMD64 if we financed the port, we decided that our money would better be spent on in-house development to make turck-mmcache a viable choice for PHP5. As all the code is GPL, our work would benefit the community and feed our own programmers. We are also considering a move to the soon-to-be-released Solaris 10, and financing a port of Zend Accelerator to the FreeBSD platform would leave us completely stranded following a migration.
We have two programmers in house who are skilled at C, as well as a highly competent project manager. Our original plans were to coordinate development entirely in-house while allowing as much community involvement as possible. We even had a name picked out :)
In our assessment of the codebase, we found that over 70% of the modifications needed to support PHP5 were already in place. However, we haven't audited the codebase and existing bug reports extensively enough to determine how much development work remains timewise, which is of course, contingent on community involvement.
But now it seems as if the community has already taken the initiative and begun a port yourselves. My hat goes off to you. We are now at a crossroads as to how to proceed; we were willing to invest our time and money into bringing turck-mmcache to full PHP5 compliance when we thought it had been thoroughly abandoned by the community, but now we see that when we are ready to make our fork announcement, one is already underway, with what looks like a rather competent project manager (franck34). My hat goes off to you.
So now we are uncertain as to how to proceed. We have several PHP5 applications already bringing our servers to their computational capacity and are desperately in need of a cache. We were willing to offer anything reasonable to expediate the development process, including two C programmers who can spend a fixed amount of time dedicated to the project.
However, I'm afraid we are open source users, not developers. We are used to commercial development tools such as Perforce and FogBugz, and would prefer not to use the antequated, insecure facilities provided by SourceForge. I'm certain the open source community is likely unwilling to use such tools, and would rather stick with SourceForge and open source tools such as CVS. We were also willing to offer project hosting on one of our dual Opteron servers burstable to 100Mbps, however it appears that franck is already providing hosting as well.
So, our plan for now will be to continue assessing and documenting the codebase. We've noticed this project has several issues with factoring... we would prefer to completely refactor the project into several, smaller, and simpler modules than the current implementation. Our goal would be to provide small modules with clear functionality upon which unit testing could be performed. We would then begin addressing the remaining requirements for PHP5 support. We also wished to begin implementing a regression testing process for the current codebase which we had planned to integrate into Perforce, and were hoping to migrate the build environment to Jam. I'm guessing the community won't be particularly supportive of these recommendations, which is certainly understandable.
So, for the time being what we would like to do is continue our own development efforts, unless the community wishes to migrate away from SourceForge and allow us to lead the project. We will check back on the status of this project at the beginning of 2005 to see if it's flourishing or faltering. If the project is doing well, then we will offer our services for regression testing and debugging, as we provide some mission critical PHP services and can't tolerate an unstable product.
So, my question to the open source community is what more can we offer in order to support the continued development of this product? As I said before, most of what we were willing to offer such as project hosting seems to already be taken care of. It also sounds like the plan is to eventually reintegrate the project into SourceForge, at which point our hosting would be totally unnecessary.
As it stands, we can provide you all of the documentation we have done of the turck-mmcache codebase as well as our design documents for our intended refactoring. We will continue refactoring the codebase ourselves and hope to reintegrate our changes back into whatever source code the community is willing to develop, if the fork flourishes.
So we will check back with you circa January 2005 to see what progress has been made. If the fork is viable, we will put our full support behind it and attempt to integrate the changes we have already made and provide as much regression testing and debugging assistance as possible. If not, we will solicit the open source community for assistance in developing our fork, that is, from anyone willing to tolerate Perforce and FogBugz :) They really are quite excellent tools...
The best of luck to you all!
Alan Haldeman - Perceive
I'd be willing to offer support as well in the form of development, testing, and website development. If we play the right cards, we can fork the project under a new name, keeping it open source, but also offer commercial support for it on as many platforms as possible.
I forget, Sourceforge is the base of numerous opensource project. Lot's of people use it, i think 'not sure' is not the good word to say that sourceforge need some others tools to be really great.
But i don't know Perforce and FogBugz, URLs are welcome, i'll ask google to learn me more about theses softwares.
I think Alan makes an excellent point that the turck codebase is in need of refactoring. The way the code is currently factored makes it more difficult to comprehend and makes unit testing impossible.
>I think Alan makes an excellent point that the turck codebase is in need of refactoring. The way the code is currently factored makes it more difficult to comprehend and makes unit testing impossible.
I better understand little sentences like this. Yes, i've seen that unit testing is impossible with actual source code.
For refactoring, segv74 say in a CVS commit message : "found bugs, which requires big changes. " (http://cvs.turckmmcache.exeprod.com/cvs.php/mmcache.c)
So I think it's VERY important that coordinators and developers of other potential forks speak together.
I've setup a mailing list and i'll give informations about this tomorrow.
I suppose that Segv74, the only one making public patches on turckmmcache, will be happy to know if the way he choose is a dead end or not. Patches on turckmmcache is a good way but i don't think he will make a full refactoring alone. So let's share !
I'll write a mail now to try to have more information about Alan project.
For eaccelerator, we are supposed to wait next week.
I should also say that the FreeBSD project is an extensive user of Perforce in addiction to CVS.
However, nowadays I think Subversion is the way to go... just a thought.
I begun to take a look at Perforce and as Alan said, it's seems to be very powerful yes. I'll take a look more deeper when i'll got the time.
>However, nowadays I think Subversion is the way to go... just a thought.
I think more people know/use CVS rathen than Subversion. But .... i'll try to see that. We could migrate little by little, and finaly keep CVS/readonly and use Subversion why not. First person concerned is segv74, let's see if he knows/wants to use Subversion.
Thanks for this important suggestions.
The nice thing about Subversion is that, for a most part, it's a CVS workalike, simply replace cvs with svn in the commands.
Is there really need for 3 forks of mmcache?
I would like much more to have one fork which combines the efforts of the multiple projects.
I guess the leadership of a commercial company isn't bad as long as it keeps mmcache as open-source-software.
Alans ideas sound very good to me and I would really appreciate if mmcache would go into that direction.
I would even contribute some money to *one* combined project as I played with the thought of using Zend-Accelerator but didn't like that I would need a dual-cpu-license just for a hyperthreading-cpu :).
Keep up the great work and thanks frank for trying to organize that mess ;).
i followed these forums with great interest and i should say i am very disapointed. i am that disapointed that i bought a small business license for the Zend package.
now i am even more disapointed, because somehow managed to bill me twice, but that issue will probably be solved with the Visa guys.
in the meantime, the accelerator works, and i will probably not pay anymore attention to the open source alternative until i see at least one real effort to fork and revive the mmcache project.
what i see now is some ego display and no constructive steps.
eaccelerator seems to be a search&replace (turck, eaccelerator) fork, while the others are just single-handed initiatives for personal fame and glory.
if someone wants to fund development here's what i suggest: setup a sourceforge project, release your alpha package based on the work of your existing (two!?) programmers so everyone can be convinced something is happening and then invite all other developers to join. i am sure they will if they like the roadmap.
then, if the new developers worth the effort and you have the resources to fund development, "fund" them so they can work actively until we have a stable version.
and yes, i wanted to erase everything above and forget about it, but the i thought maybe i should at least try to talk all of you into something that could be nice again.