joint copyright assignment

Many open source projects, including the Free Software Foundation, Red Hat and OpenOffice.org require that contributors assign their copyright when they contribute code. Sun, the NetBeans project sponsor, has come up with an innovative Joint Copyright Assignment (“JCA”) that allows contributors to retain their own copyright while sharing a joint copyright interest in the contributed code. This way contributors retain all the rights granted by copyright law while sharing those rights with the open source project sponsor so that the code is protected by both the Sun Public License (“SPL”) and copyright law.

interesting option. we are trying it out with the xaraya project.

openoffice blogs

openoffice 1.1.1 is out (557 bug fixes), and oo.org is slowly starting to spread its memes with a weblog list. hopefully, with more to come. or as tim put it:

My agenda in visiting OpenOffice was all about blogging and RSS and so on. First of all, I was trying to convince those guys to start hanging out on the Web. This is now one of the world�s largest Open-Source projects (Sun is paying several floors in a big building full of people to work on it, and there are tons of other contributors), and it has really lousy visibility. These are interesting people and they know more about XML and portable on-screen rendering and struggling with print drivers and so on than just about anybody, and the world needs a few voices out of North Germany writing about all this stuff and also about what it�s like to compete with Microsoft Office.

open source trafficking

i just got this from the sourceforge site update email newsletter:

According to Alexa, SourceForge.net is now ranked #258 (out of 100,000) in the world in terms of sheer traffic. To put this fact in some
perspective, during the past 12 months, SourceForge.net has surpassed
IBM.com, Sun.com, and Cnet.com in daily page views. A graph from Alexa can be viewed here: The blue line, representing
SourceForge.net, is the one to focus on.

wow.

getting it done

i have observed different projects and their inability to get a release out. the strive for perfection is one easy culprit. ever a man of advice, doug has this to say:

apakuni: too bad they do not think like mothers
apakuni: after 9 months of gestation, they want their babies out
gregorrothfuss: LOL
gregorrothfuss: good point
apakuni: we need to engineer a DNA modification that equates to labor in software devs
gregorrothfuss: lol
apakuni: a) water breaks (release .9.9.8)
gregorrothfuss: LOL you are too funny tonight
gregorrothfuss: are you inebriated?
apakuni: b) labor (release .9.9.9)
apakuni: c) birth (release 1.0.0)
apakuni: nope .. i am at work

the spirits i called

Someone built the system, they assumed certain user behaviors. The users came on and exhibited different behaviors. And the people running the system discovered to their horror that the technological and social issues could not in fact be decoupled.
this strikes home with my experience helping to build different tools over the years.
i finally got around to read shirkys longish essay about groups being their worst enemy. there is too much good material in the piece to give it justice with commentary, so i will just quote interesting paragraphs instead.
People who work on social software are closer in spirit to economists and political scientists than they are to people making compilers. They both look like programming, but when you’re dealing with groups of people as one of your run-time phenomena, that is an incredibly different practice.

It’s very difficult to coordinate a conference call, because people can’t see one another, which makes it hard to manage the interrupt logic. In Joi’s conference call, the interrupt logic got moved to the chat room. People would type “Hand,” and the moderator of the conference call will then type “You’re speaking next,” in the chat. So the conference call flowed incredibly smoothly.

1.) If you were going to build a piece of social software to support large and long-lived groups, what would you design for? The first thing you would design for is handles the user can invest in. 2.) Second, you have to design a way for there to be members in good standing. Have to design some way in which good works get recognized. 3.) Three, you need barriers to participation. This is one of the things that killed Usenet. You have to have some cost to either join or participate, if not at the lowest level, then at higher levels. There needs to be some kind of segmentation of capabilities. 4.) And, finally, you have to find a way to spare the group from scale. Scale alone kills conversations, because conversations require dense two-way conversations. In conversational contexts, Metcalfe’s law is a drag.

consulting times on oss dev

How to Misunderstand Open Source Software Development
Open Source development provides us with a way to use our existing talents and skills while increasing our productivity. Many people with whom I work consider this development model as mainstream. I experienced personal growth as a result of my involvement with Open Source projects and find it as acceptable at a cocktail part as working as an auditor for a major accounting firm.
eep. i am not sure auditing is all that accepted, but then again i am trying to unlearn my 5 years of KPMG :) good intro article though.

oss research

monday night was spent at HSG talking about open source, community dynamics, reputational games, marketing strategies, scalability issues, entrepreneurial aspects, parallels to the scientific process, open source versus open standards, and many more which i since forgot. in attendance were.

after a blogging pitch, michi and myself demonstrated the use of blogs for scholarly communication. with success, it seems, some are already toying with blogs, and with luck we will get blogs.ifb.unisg.ch up and running soon.

dependencies

Behlendorf: One of the key insights of open source is that there are good reasons to attach people to code. Apache isn’t just a Web server, it’s a Web server with a community around it. To treat software like Legos, without thinking about the context and the community, is a losing proposition. There was a lot of noise a couple of years ago about building corporate component libraries. But the problem is that by simply having that code there, you didn’t have the context.
software is plentiful these days, talent to make heads and tails of it not. who wants to write software from scratch? not me. i always found it more interesting to stitch something together from existing parts, usually losing interest after a solution started to manifest itself.
Behlendorf: What always frustrated me, in computer science, was how we learned all the low-level things — which we have libraries for nowadays — but we didn’t learn large-scale integration. What’s the skill set to be able to jump into the code base of something like Mozilla, read the architecture docs, and figure out the makefiles? Computer science classes don’t teach you how to dive into foreign code bases.
you need capabilities to:

  • analyze and visualize a code base
  • identify the community leaders
  • learn the community customs
  • understand the real scope of a piece of software

It’s becoming a game of free agents, and by operating in this public and transparent way, free agents advertise themselves — as a brand — along with the products and components they have expertise with.
right on. no longer is software production a solitary discipline, with engineers huddled over manuals and out of sight in some cubicle. rather, in a world where you cant possibly write a significant portion of the code you gonna need, the person with the best social skills wins.