Hi all, Very interesting discussion.
> To be very honest here, we stuck to a traditional 'cathedral'-like model of > managing the magazine project, in that it's brought together by a central > team, accepting contributions from anyone. For the first issue, we're > sticking with what worked with issue #0. After that, we should definitely > discuss what can be changed and improved, but doing so now is, IMHO, > premature. We want to get stuff done now. OK, that’s cool. Here’s some conceptual input for the future, then :) Because I have to disagree with: > 'True' collaboration works with software because, for each problem, you can > actually find an objectively satisfying solution. >From two sides. 1) Software projects don’t do ‘true’ collaboration. There’s always someone (or a few people) in charge; a lead developer. Everyone can read the source code, but it’s the lead developer who determines which patch is accepted. 2) Objectively satisfying solutions do not exist in code either. Code is highly subjective. One programmer might think of a solution as an ‘ugly hack’ while the other might see it as an ‘elegant solution’. There is no objectively satisfying solution because every decision comes with a trade-off: like, do I make this more readable or do i make it more fast? Do I make the solution more general, or do implement specific functionality in the class itself? Than there’s different paradigms of programming: do you like functional or object oriented or declarative or whatever? Whether you prefer one over the other is a matter of taste. IMHO the main point of open source is not that everybody can hack on something together, but that through openness the code can so easily be repurposed across projects. Projects can use each others code to develop new functionality more quickly. And, if the developers and maintainers of a project are not going in the direction you like, you always have the possibility to fork it. This is a pattern you see in culture too: We don’t try to write one ultimate novel together, but rather each writer tries to do so for her or himself. No one starts from scratch: writers mix and match prior sources. And they ultimately offer the end result up as material for the next writer. This is why *distributed* versioning is such a natural fit for cultural projects. (No SVN! Git or Mercurial definitely :)) > That said, i'm totally unsure as to how we can find a 'real' collaborative > and decentralised model to make a magazine. But i would love to have an > answer for that, and hopefully we'll be finding out as we go through with > this project. I think a first, and manageable, step would be to figure out how you can offer up a repository with all the text and layout files used for the magazine, in such a way that it becomes easy to repurpose. This can even be done after the publication. That is, if the magazine is going to be cc-licensed which I kind of assumed would be the case. This might seem really easy, but since the file formats of desktoppublishing tools were not designed to be used in such a way this can already lead to interesting challenges. Subsequent effort might be applied to using such a repository as a collaboration tool. My proverbial two cents, curious what y’all think, and am looking forward to this awesome project :) Best! Eric _______________________________________________ CREATE mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/create
