On Sponsored Open Source Development
This campaign on Pledgie is an experiment by Derick Rethans to find out whether or not it is feasible to expedite the work on feature requests in Open Source projects such as Xdebug. Since I more or less gave Derick the idea for this experiment, I will try to shine a light on our reasoning for this approach in this blog posting.
For quite some time now, Derick and I occasionally discuss how the collection of code coverage information in Xdebug can be improved so that PHP_CodeCoverage can provide more useful information when you are running your unit tests using PHPUnit, for instance.
At the moment, Xdebug only supports Line Coverage which means it can only tell us whether or not a particular line of code was executed or not. Since a line of code can contain more than one statement, the implementation of Statement Coverage in Xdebug would tell us whether just one statement in a line is executed (which would already count towards Line Coverage) or whether all of its statements are executed at least once while running the tests. Other code coverage metrics that are desirable include Branch Coverage, Path Coverage, and Call Coverage -- and we would like to have them supported by Xdebug and PHP_CodeCoverage as well.
Implementing the data collection for these more sophisticated code coverage metrics in Xdebug and adding support for them in PHP_CodeCoverage is not a small task. And while both Derick and I live and breathe Open Source and like to hack on code things like work and private life do interfere with the development of our Open Source software projects. So with development efforts like this we can either wait for the time when "we have nothing else to do" or try to find support from the people that use the development tools we create on a daily basis that allows to work on new features for said tools sooner rather than later. And although it would be awesome if a single company would approach us with "Hey, we would really like to pay the whole development of these more sophisticated code coverage metrics in Xdebug and PHP_CodeCoverage!" we realise that this is highly unlikely. A platform such as Pledgie, where many individuals can pledge small (and not so small :-) amounts of money could be the solution we are looking for.
Derick's first campain for Xdebug is about a bugfix. And at first glance it might seem rather odd to "demand" money for fixing a bug. As is the case with most complex issues, having a closer look usually clears things up. So what has happened? Xdebug's profiling functionality can dump its information in a format that can be processed and visualized with a tool called KCacheGrind. At the time when Derick implemented this functionality, the data file format used by KCacheGrind was not (well) documented so he had to reverse engineer it. In that process he overlooked the fact that KCacheGrind expects information that he did not provide (namely the
With regard to the more sophisticated code coverage metrics that I mentioned in this post our plan is to gather requirements and try to estimate the amount of time needed to implement what we want when I am in London next week. We will keep you posted!
For quite some time now, Derick and I occasionally discuss how the collection of code coverage information in Xdebug can be improved so that PHP_CodeCoverage can provide more useful information when you are running your unit tests using PHPUnit, for instance.
At the moment, Xdebug only supports Line Coverage which means it can only tell us whether or not a particular line of code was executed or not. Since a line of code can contain more than one statement, the implementation of Statement Coverage in Xdebug would tell us whether just one statement in a line is executed (which would already count towards Line Coverage) or whether all of its statements are executed at least once while running the tests. Other code coverage metrics that are desirable include Branch Coverage, Path Coverage, and Call Coverage -- and we would like to have them supported by Xdebug and PHP_CodeCoverage as well.
Implementing the data collection for these more sophisticated code coverage metrics in Xdebug and adding support for them in PHP_CodeCoverage is not a small task. And while both Derick and I live and breathe Open Source and like to hack on code things like work and private life do interfere with the development of our Open Source software projects. So with development efforts like this we can either wait for the time when "we have nothing else to do" or try to find support from the people that use the development tools we create on a daily basis that allows to work on new features for said tools sooner rather than later. And although it would be awesome if a single company would approach us with "Hey, we would really like to pay the whole development of these more sophisticated code coverage metrics in Xdebug and PHP_CodeCoverage!" we realise that this is highly unlikely. A platform such as Pledgie, where many individuals can pledge small (and not so small :-) amounts of money could be the solution we are looking for.
Derick's first campain for Xdebug is about a bugfix. And at first glance it might seem rather odd to "demand" money for fixing a bug. As is the case with most complex issues, having a closer look usually clears things up. So what has happened? Xdebug's profiling functionality can dump its information in a format that can be processed and visualized with a tool called KCacheGrind. At the time when Derick implemented this functionality, the data file format used by KCacheGrind was not (well) documented so he had to reverse engineer it. In that process he overlooked the fact that KCacheGrind expects information that he did not provide (namely the
"cfl=" lines that tell KCacheGrind the target of a function or method call). Versions of KCacheGrind prior to the current one used a too relaxed merging of symbols and so it appeared that there was nothing wrong with the data written by Xdebug. Current versions of KCacheGrind, however, are more strict and expect the aforementioned "cfl=" lines. Without them the visualization of Xdebug profiling information is useless. I noticed this last week and talked to Derick about it. Apparently others had experienced the same issue but he had not had any time yet to investigate it because he is, just like I am, too busy with paid work. Only half-jokingly I told him on Twitter to try Pledgie for this and promised him to pledge money for this if he did (I really need KCacheGrind to work for profiling PHP code). So now you know why we are experimenting with Pledgie at the moment.With regard to the more sophisticated code coverage metrics that I mentioned in this post our plan is to gather requirements and try to estimate the amount of time needed to implement what we want when I am in London next week. We will keep you posted!
17/02/2011 at 17:14 Permalink
For one, I see no indication anywhere of *when* this is promised to be completed. It would probably do me no good if I donated and the actual work was completed 5 years later. How can I be sure that it will be completed in a reasonable amount of time?
Likewise, what recourse do I have if Derick disappears in the middle of the night with all of the pledges? I have read the 'about' and 'FAQ' at Pledgie.com, but I cannot find any info relating to how and when the pledges are disbursed. What if the the dev marks the task as "completed", but there are blocking bugs or holes in the implementation that don't meet my expectations? Who is the final authority to say that, yes, this is complete and fulfills the Pledgie obligations?
What if the Pledgie goal is not realized? I also could not find information on Pledgie, xdebug.org or derickrethans.nl detailing exactly *how* Pledgie works (I've never heard of it and am naturally skeptical of such new "services"). Does the campaign owner receive the funds as they come in, or only once the goal is reached? What happens if/when the goal is not reached?
Now, I'm not saying Derick (or anyone) would do this, but without such information and guarantees, I have no way of knowing what to expect.
Reply
17/02/2011 at 17:21 Permalink
you raise valid points that I, too, think need adressing. This is why we are doing this experiment now: to learn about issues like these.
To be honest, both Derick and I expected Pledgie to work differently. I was surprised that when I pledged yesterday my bank account was immediately charged. I expected to be charged only when the goal is reached. Maybe there are other platforms out there that behave like that.
Reply
19/02/2011 at 01:46 Permalink
I will admit that I do not have much knowledge of xdebug's history nor its current development processes, but after a quick peek in the xdebug Mantis, it looks as if Derick is the only one making commits, and only available via his SVN (as opposed to a public github)? I'm curious, does he accept patches or allow others to make commits?
Reply
17/02/2011 at 17:37 Permalink
I recently found Fundry.com and Kickstarter.com and considered how that might fit into web2project development.
Reply
18/02/2011 at 11:08 Permalink
One more thing.
Money are the main currency. But in Open Source world, there is another currency - time. Time we developers spent on open source projects is no less valuable, nor less desired, then the money we would donate/pledge. I think this is obvious. Some people would rather fix the docs, then donate $40. Thus, while You try to find some money, don't forget that inviting people with time is equally important.
After all, in Open Source, it all comes down to the community.
Reply
18/02/2011 at 22:18 Permalink
Reply
20/02/2011 at 15:19 Permalink
Reply
04/03/2011 at 08:45 Permalink
Pledgie was fine for the time being though. I'm sure we can trust Derick to keep his word and follow through.
Reply