schlitt.info - php, photography and private stuff ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ :Author: Tobias Schlitt :Date: Wed, 19 Nov 2008 23:29:46 +0100 :Revision: 1 :Copyright: CC by-nc-sa ====================== eZ components on Ohloh ====================== :Description: I tried a several times to get eZ components (and other eZ projects) into Ohloh. Ohloh claims to do "Mapping the open source world by collecting objective information on open source projects", which fits the website content quite well. If I got the basic project idea correctly, it should give managers an impression on the quality and usability of open source projects. Since managers usually want to have "hard facts", Ohloh tries to masure numbers it can extract from various public project data (e.g. from SVN). I tried a several times to get `eZ components`__ (and other eZ projects) into `Ohloh`__. Ohloh claims to do "Mapping the open source world by collecting objective information on open source projects", which fits the website content quite well. If I got the basic project idea correctly, it should give managers an impression on the quality and usability of open source projects. Since managers usually want to have "hard facts", Ohloh tries to masure numbers it can extract from various public project data (e.g. from SVN). .. __: http://ez.no/products/ez_components .. __: http://next.ohloh.net/ So, finally `Sebastian`__ managed to get eZ components into Ohloh and we can look at some interessting (and sometimes funny) stats about our enterprise PHP library: .. __: http://sebastian-bergmann.de eZ components consists of 171,025 lines of code (including markup and code itself). This may be a quite good estimation, but I wonder, where we have 43% of XML in it? OK, our `Template`__ test cases, for example, contain some XML (XHTML). Some other components use XML for storing data. The brand new `Graph`__ component can output SVG images, so its test cases contain a lot of XML. But is it really that much? I actually believe, that Ohloh masures correctly, but I still wonder. :) If you subtract the XML, eZ components consist of 96,424 lines of pure PHP code (no docs included, if I got it correcltly), which is rather much in my eyes. .. __: http://ez.no/doc/components/view/latest/(file)/classtrees_Template.html .. __: http://ez.no/doc/components/view/latest/(file)/classtrees_Graph.html Ohloh also tries to estimate, how long a project in size of eZ components would last and how much it would cost, if you hire a professional developer team to code it. Those stats are rather funny, since it estimated an effort of 43 man years and a price of $2,350,931 (based on a yearly salary of $55,000 per developer) for the whole eZ components trunk. Surely, you should not count most of the XML stuff here. The (I guess largest) part of XML that is used in the Graph test cases, for example, is generated and visually inspected for correctness, so there was not as much effort behind it as Ohloh thinks. But Ohloh offers you to also show these stats for the pure code only. For eZ components, this still means an effort of 24 man years and a cost of $1,332,868. If I look back, I estimate, that about 10 developers contributed to eZ components so far (the Ohloh stats say almost the same). At least half of those work only part time (half or even less of their working time) on eZ components and some already left the project completly. So I do a very sloppy guess and say we have 5 fulltime developers working on the project since its start. Roughly estimated, eZ components was started 1.5 years ago (including planning and design phase). This makes about 7.5 man years and tells me: Basically we are really good in writing high quality code extremly fast. ;) Ohloh also offers stats on a per-developer basis (like contributed lines of code, code to docs ratio,...) and much more interessting (and as you can see, sometimes funny) information about the registered projects. I think, it can become a really useful information source for managers, to get a rough overview on a project, as an evaluation basis. For this kind of tasks, facts like activity of a project, license, documentation status and so on are really important. Beside that, it can give a developer a quite nice overview if he wants to contribute or use a specific project. I really like the approach of it. .. Local Variables: mode: rst fill-column: 79 End: vim: et syn=rst tw=79 Trackbacks ========== - Ohloh becoming sensible on Sat, 16 Jun 2007 01:07:23 +0200 in Tobias Schlitt - a passion for php Almost 1 year ago I blogged about Ohloh, and eZ Components being registered there. Those days I just found it funny to see how they measure the project cost of open source projects based on the ammount of code contained and things. Recently I am actively Comments ======== - Andrei at Mon, 23 Oct 2006 17:53:29 +0200 LOC stats are pretty damn useless, IMHO. It's as if you were judging the quality of the code based on the number of parentheses in it, in which case any LISP-based project wins handily. - Toby at Mon, 23 Oct 2006 17:57:40 +0200 I fully agree with you. But at least, it gives you a rough idea of the size of a project. Additionally, stats like code-doc ratio give you some impression on the documentation state of a project. Surely, it does not work to only look at these stats to get an good impression in any way, but you can sort out some projects, that e.g. have just been started or have poor documentation. - Markus Wolff at Mon, 23 Oct 2006 18:25:26 +0200 Maybe they've used this tool for the LOC-based statistics: http://www.dwheeler.com/sloccount/ I've used it once for our customer portal project (which was coded by two people in less than a year) and it claimed the project was worth about 10 man-years. Well, there's that Mythical Man-Month again :-D - Henri Bergius at Mon, 23 Oct 2006 20:31:31 +0200 They're saying they wrote their own too instead of using sloccount: http://ohloh.net/wiki/blog/wheeler