Analysis of Tyrant's code

  • cdesouza

    cdesouza - 2005-09-08

    Dear tyrant developers,

        I am a researcher at the University of California conducting a project about open-source software. Our ultimate goal is  to facilitate collaboration and coordination among open-source software developers through dependency analysis techniques. Because of the interest of my collaborators in Tyrant, we want to get your feedback on our initial analysis. We would appreciate any help that you could provide us.

        For now, your help consists in assessing the diagram available at
      This should take about 15 minutes of your time. Please reply to my email at All information that you provide is *confidential*.

        The diagram is a representation of the dependencies between software developers. That is, an edge from A to B exists if developer A's code makes calls to developer's B code. The other way of thinking about it is: whenever B's changes his code he can potentially impact A's code.

        The diagram was generated by analyzing tyrant's code and combining this with information from the cvs repository. In the diagram, two groups were identified: group 1 composed of chrisgri, cmuessig, jules_ve, mikera, and rickblai; and group 2 composed of itchykit, jicksta, pmularie, ppirrip, tdemuyt, trump-ca, and vicsot. Note that developers in group1 are connected to both developers in group2 and other developers in group1. Meanwhile, developers in group2 are only connected to developers in group1, but not amongst themselves. Note that I am *not* making any statements about the importance of any developer's code.

        The diagram suggests that when a developer in group2 makes a change in his code, he can ONLY impact developers in group1, NOT other developers in group2. On the other hand, developers in group1 can impact all other developers.

        My simple question then is: does this diagram and interpretation make sense? Do developers in group2 need to concern only about developer's in group1 code? Proving this "impact information" is useful in any manner whatsoever to open-source developers? Or, are we in a completely wrong direction? Feel free to elaborate in your answers.

        Thank you very much for your help,

            Cleidson de Souza

    • Mike Anderson

      Mike Anderson - 2005-09-08

      Fascinating analysis.

      However, you might find that Tyrant is particularly tricky to perform this sort of analysis on because so much of the code is data-driven.

      For example, Lib.init() only gets called in one or two places.  However, Lib.init() creates data structures that encapsulate code via Script objects. The Script code can get called in the future in many different ways through event handlers. Hence this code is dependant on code in Lib.init() even though you never see this relationship through the call graph.

      • cdesouza

        cdesouza - 2005-09-08

        Thanks for pointing that out. We plan to perform, in the near-future, run-time analysis of the code to avoid such situations.

        i am just curious: what you see in the diagram, seems correct, matches your intuitive knowledge about the code?

        feel free to email me privately at

    • Tom Demuyt

      Tom Demuyt - 2005-09-08

      In my mind, I dont like to touch the core of Tyrant which is what group 1 touches.

      This means that I indeed make sure that what I do impacts group 1 to a minimum and does not impact group 2.

      I guess you can identify group 1 as the core developers, as in 'touching the core of Tyrant'' but also pretty much the largest committers. ( Damn, I am not in group 1 ;)

      The danger you have here is that people will want to get in group 1 so they can be 'core' and thus commit on stuff they shouldnt commit on. Maybe this kind of analysis is dangerous for the health of a project. Or maybe it will help developers shy away from certain classes, which would be a good thing.



Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks