Slashdot Mirror
EU-Funded EDOS To Simplify Open Source Development
An anonymous reader writes "a consortium of European research institutions and open source software companies have paired up to manage the complexity of large scale, modular projects by establishing a program called EDOS, Environment for the Development and Distribution of Free Software. Planners intend to move away from centralized builds and storage to a distributed process, form a language-agnostic bug testing system and turn to theoretical computer science to safeguard dependencies."
Please don't tell me that it's funded my Microsoft...
Bill Gates? That you? On a more serious note, an EU judge has upheld penalties against Microsoft.
IMNSHO, distributed revision control is something long past-due for wider adoption... be nice to see it used outside of Linus's BitKeeper adoption and the (reasonably large number of) projects using Arch.
The impact of distributed revision control is that someone doesn't need to be trusted with commit access to a repository owned by the maintainers to do revision-controlled work -- instead, they just make a branch inside an archive they control, and changes can be merged back and forth between that one, the "official" branch, and/or any other 3rd-party branches at-will. As a casual contributor to a large number of projects, I find this extremely useful -- I have my own revision-controlled archive containing only my changes, and I don't need to get the trust and/or approval of the project maintainers before getting started.
Personally, I like Arch, but it's not the only game in town -- Darcs, Monotone and SVK are all in the same problem space (within the Free camp), as well as BitKeeper (in the proprietary camp). I'd like to think that this is what these folks mean by distributed storage (as the revision control archive doesn't necessarily sit all in one place) -- the concept needs all the exposure I can get, so I don't need to go the $#%@ pain of maintaining my own branches (w/o assistance from my revision control tools) again!
I'm guessing that's because the original acronym is in French. It's Environnement pour le Développement et la distribution de logiciels Open Source, which makes a lot more sense.
Roberto Di Cosmo of University of Paris 7 claims that theoretical computer science is particularly strong in France and that its formal methods can be used to manage complex dependencies to create an "integrated, coherent whole."
In different words, people in France are jumping onto the open source bandwagon in order to squeeze out another few years of funding for the same old stuff they have already been doing for 30 years.
If you want to read more about formal methods, look here and here. You can judge for yourself how much relevance you think this is going to have for FOSS. I think its chances are close to nil.
I read the fucking article. You are correct; I was wrong.
Wow, you read our paper quite quickly. Impressive. You may have noticed the part where we described the paper as a "case study". I don't claim that we proved anything too generalizable with this work, although there are many such case studies in the literature that reach similar conclusions.
I also regret that space constraints precluded much of the reporting that you would have liked to have seen. Much of it was presented at the talk, but that is indeed insufficient. My apologies.
We resorted to the formal methods approach only after failing with most of the approaches you suggested. UML had nothing obvious to offer (according to my UML-skilled friends). The problem was a design problem: meditating over source code wasn't obviously helpful except to discover that a given design was flawed by observing it in the implementation. We were constrained to C in a POSIX environment, which was really at the heart of the problem, so changing languages or platforms wasn't possible. I was certainly paired with someone throughout the whole development process: sometimes an implementor, sometimes a formal-methods guy.
The effort the formal spec took us was about 4 weeks, most of it by me. The key insight actually only took a few days, the rest was just careful checking for other problems. Once we discovered our requirements were inconsistent, it took us another week or so to come up with relaxed requirements and a design that met them.
Ultimately, keep in mind that we applied formal methods to the problem only after failing multiple times to get a correct implementation using more conventional open source methods. You can quibble about whether it's science or not ("Computer Science : Science :: Plumbing : Hydrodynamics" --Strachey), but subjectively I solved a problem using Z that I and two other smart people working together hadn't solved without it even given a lot of effort. I'll mark this one in the success column.
As for your more general comments about Computer Science, let me observe that CS is pretty much the only science or engineering discipline without any generally-accepted formal descriptive and analytic notation. I'm using Z for this on occasion, and finding that I like it a lot: it helps me to clearly, succinctly, and unambiguously specify all sorts of things. I think that this is somewhat orthogonal from the "behavioral science" approach you seem to be advocating, but I think it is a legitimate need of the discipline. Your mileage, as always, may vary.