Science, industry, and society are being revolutionized by radical new capabilities for information sharing, distributed computation, and collaboration offered by the World Wide Web. This revolution promises dramatic benefits but also poses serious risks due to the fluid nature of digital information. One important cross-cutting issue is managing and recording provenance, or metadata about the origin, context, or history of data. We posit that provenance will play a central role in emerging advanced digital infrastructures. In this paper, we outline the current state of provenance research and practice, identify hard open research problems involving provenance semantics, formal modeling, and security, and articulate a vision for the future of provenance.

Iterations are time-boxed periods with an intended outcome that is often a set of implemented requirements. Iterations are part of most common software development lifecycle models. Planning of iterations is a non-trivial task due to the multi-dimensional criteria. (1) The first dimension concerns the question what shall be completed in the iteration, also referred to as release plan-ning. Decisions in this dimension are based on criteria such as dependencies and priorities of requirements. (2) The second di-mension concerns the decision, which project participant should work on which task, also referred to as task assignment. Deci-sions in this dimension are based on criteria such as the expertise and the workload of the developers. The decisions in both dimen-sions are considerably complex. Therefore several approaches exist to semi-automatically support the decisions limited to one of the two dimensions mentioned above. None of the existing ap-proaches considers both dimensions at the same time. In this pa-per we propose a combination of approaches from semi-automatic release planning and from semi-automatic task assignment. This results in a semi-automated two-dimensional solution for the problem of iteration planning, We suggest the use of a genetic algorithm to optimize the resulting iteration plans in both dimen-sions of the problem.

Software correctness has bedeviled the field of computer science since its inception. Software complexity has increased far more quickly than our ability to control it, reaching sizes that are many orders of magnitude beyond the reach of formal or automated verification techniques.

We propose a new paradigm for evaluating "correctness" based on a rich market ecosystem in which coalitions of users bid for features and fixes. Developers, testers, bug reporters, and analysts share in the rewards for responding to those bids. In fact, we suggest that the entire software development process can be driven by a disintermediated market-based mechanism driven by the desires of users and the capabilities of developers.

The abstract, unspecifiable, and unknowable notion of absolute correctness is then replaced by quantifiable notions of correctness demand (the sum of bids for bugs) and correctness potential (the sum of the available profit for fixing those bugs). We then sketch the components of a market design intended to identify bugs, elicit demand for fixing bugs, and source workers for fixing bugs. The ultimate goal is to achieve a more appropriate notion of correctness, in which market forces drive software towards a correctness equilibrium in which all bugs for which there is enough value, and with low enough cost to fix, are fixed.

Successful programming languages change as they age. They tend to become more complex, and eventually some features become outdated or are rarely used. Programming tools for these languages become more complex as well, since they have to support archaic features. Old programs are hard to maintain, since these archaic features are unfamiliar to modern programmers. These problems can be solved by refactoring tools that can transform programs to use the modern form. We show that refactoring tools can ease the cost of program evolution by examining the evolution of two languages, Fortran and Java, and showing that each change corresponds to an automatable refactoring.