1. Objective ICT-2009.1.2: Internet of Services, Software & Virtualisation FLOSSEvo some preliminary ideas

2. Target Outcome b) Highly Innovative Service / Software Engineering  Service / Software engineering methods and tools covering automatic support at run-time for decisions and changes that are currently adopted at design time. Focus is on innovative approaches to very large, dynamic open service networks, user development of services/software, systems evolvability and acquisition, reasoning and incorporation of domain knowledge in all phases of the service/software life cycle. High-level description and executable languages for services/software with support for adaptation and technologies for improving system response time, performance and throughput are in the scope of the research  Verification and validation methods, tools and techniques assuring the quality of open, large-scale, dynamic service systems without fixed system boundaries, addressing the complete service and software life cycle.  Methods, tools and approaches specifically supporting the development, deployment and evolution of open source software. Investigation into the use of open source approaches for improving service engineering, deployment, management, evolution and take-up.

3. Main target  To drive maintenance effort to where it is most needed  Focus on large FLOSS projects  Use of all available data sources to predict where maintenance is needed

4. The problem  Effort (specially experimented effort) is limited and (in many cases) voluntary  Some parts of the code, some feature requests and bug fixes, some refactoring, etc are more in need of effort than others  Developer (neither project leaders) have a clear idea of what is more important, or how to assign their own effort  It is also not obvious how much effort different actions would need

5. The solution  Study past actions: commits, bug fixes, refactoring, etc.  Analyze factors for evolvability (eg, size or complexit, community, etc.)  Study relationships, correlations, estimate effort, etc.  Provide with ways of estimating effort needed for future actions  Provide with ways of priorizing requested actions, and detecting needed actions  Provide a “status and control panel” to visualize the status of a project, the available effort, the recommended actions, etc.

6. Relationship with call  “Methods and tools specifically supporting the development and evolution of open source software”  Quality improvement, over the whole life of the project  Evolvability and sustainability: helping FLOSS projects to evolve better

7. Techniques: data sources  Analyse and combine many different types of data sources. We need to study the entire “ecosystem” of open source software development, consisting of  source code  byte code and executable code  mailing lists  version repositories  bug tracking information  software models  (tests and test suites? documentation?)  information about the developer community  user community (who is using the system, why and how? Is the system being reused itself?)  …

8. Techniques: analysis  Analyse the development process of FLOSS systems by using generic analysis techniques that can be applied on (combinations of) different data sources  measurement techniques (e.g. source code metrics, profiling metrics, versioning metrics, metrics about mailing lists, code coverage metrics, and so on)  visualisation techniques (for visualising software structure, dynamic information, software evolution in terms of commits or time, mailing lists, developer community, user community, …)  pattern detection techniques (for detecting all kinds of relevant patterns: "design patterns", "communication patterns", "evolution patterns", "smell patterns" and so on)  Dynamic analysis (e.g. profiling, benchmarking, code coverage)

9. Techniques: outcomes (1)  Sistem providing suggestions to what is needed for the healty funcitoning of the FLOSS ecosystem (e.g. refactorize some code, fix some bug, reduce the complexity of some code, assign a developer to some code, discuss more in mailing lists, etc.):  software improvement techniques (e.g. refactoring)  communication improvement techniques  To improve the communication between stakeholders (developers, users, other involved persons) based on antipatterns detected  improving the metadata (and the way it is stored) in the version repository  Improving the community  E.g. reassigning roles of persons, suggesting "conventions" to be used by the community to become more effective, …

10. Techniques: outcomes (2)  Sistem providing evaluation of efforts needed for pending tasks, helping to schedule them:  Characterize tasks  How much effort (and time) is expected to take every pending task  What tasks should be accomplished sooner  Evaluation of the impact of pending tasks  Differential evaluation (depending on who performs the task)  Tasks are not only fixing bugs, but everything from refactor some code, to reduce complexity, to redefine an object, to send some mail message, to look for duplicate or obsolete bugs, to produce a new stable release.

11. Some research questions  How can we characterize all actions in a project, and estimate the effort (for past actions)  How can we identify relationships, patterns and impact of past actions?  How can we link general parameters (such as complexity, OO metrics, bug fixes, bug reports, development messages, etc.) to decide when to recommend some action?  How to link information from regression tests, user experience, bug reports, etc. to future actions?  How can we decide when a major action (refactoring, code reuse, fork, new release, etc.) is needed?  How do actions on a project depend on its community structure, past actions, past patterns, etc.?

12. Open questions we still need to discuss  How does this fit into the "service engineering" aspect?  Maybe this is a non issue, maybe it suffices to only address the “software engineering” aspect? To be asked to the EU officer.  Is the proposed research proposal "highly innovative"? I guess it is, but...  Is this doable? Can we reasonable do this in two-three years?  Do we need some more expertise?  Should we focus on a part of this? Maybe prediction and effort is too much?

13. Industrial partners (tentative list)  Large FLOSS projects (could some of them collaborate without being partners?)  ZEA Partners (Zope, Plone)  Mozilla Europe (Mozilla, Firefox)  GNOME  Apache  Companies in the business of analyzing software development (all of them?)  SIG, http://sig.nlhttp://sig.nl  Antelink, http://www.antelink.nethttp://www.antelink.net  Programeter, http://programeter.comhttp://programeter.com ...