?

Log in

Next Entry

Open Source Software Development

Google has a project, code.google.com, which grants users free project webspace with Subversion for use with OpenSource software development projects. The program is free, and is open to anyone who wants to develop an open source project.

Subversion (a proper noun, not be be confused with "subversiveness") is a software development tool that allows a development project to centralize source code changes so that multiple developers and/or developers in multiple locations can work simultaneously on the same project.

While browsing through the help documents on the site, I came across a page that linked to a free book, Producing Open Source Softare. In keeping with the open source atmosphere, the book is free and is licensed under a Creative Commons license. You can download it directly from the site.

The author of the book, Karl Fogel, was one of the core development team who worked on Subversion. I read through a great deal of the Producing OSS book (though not all of it, as it's rather dry, and some of it was not at all interesting to me). I learned a great deal about Subversion and the open source development project, and made various mental notes for later.

The book itself doesn't just deal with programming, however. In fact, it doesn't really deal with programming at all. Most of it deals with management, communications, community and project development, and other meta-themes that are related to software development. The target audience is obviously corporate developers who are making the shift from proprietary development to open source development, but it has a good deal of general information that's applicable to just about any public enterprise.

The Google Code site offers a low barrier-to-entry method of hosting your development project. Obviously, this is not going to appeal to very many people (because not many people write code, and even less write open source), but it's a great initiative. One of the senses I get, too, is that the engineers at Google who are developing this particular service are very interested in putting functional, easy-to-use tools into the hands of the people who write software with the hope that good things will come of it.

I started up a project of my own (nothing very interesting, really) to try out the service. The service is quite robust and includes various useful features that a developer would want. Some of these include:

  • Webhosting (obviously)
  • Download manager to manage file releases
  • Wiki site and software to aid in creating documentation
  • Bug/issue tracker
  • Source code repository, including Subversion
  • Integration with other Google services, such as Blogger, Groups, and Google Accounts

For some, the integration with other Google services may be too much in the way of branding, but the great thing about the whole operation is that it allows someone with zero financial resources to get a software development project up and running, complete with website, mailing lists, and newsfeed, for absolutely no cost. The requirement, of course, is that your software is open source. Still, this is a really amazing resource.

There are various other, similar resources available. One of the most prominent (and my personal favorite) is SourceForge. SourceForge hosts a vast array of widely-respected open source projects and even some Google code (Google sitemaps, for example, can be found on SourceForge). However, SourceForge has a much more professional feel and somewhat higher barrier to entry as compared to Google Code. There are pros and cons to each, obviously, but I think that Google Code can appeal more to a student or to someone who has slightly different demands of their service provider.

It was originally stated here that Google Code allows you to delete a project, while SourceForge does not, and that SourceForge provides a compile farm. cdibona provided several corrections and some clarification. Google Code allows you to delete a project up until a point at which it reaches a certain level of activity. After that point, you will not be able to delete the project. Both Google Code and SourceForge have similar philosophies on this issue: that, since the code is open source, people should have access to it in the long run. cdibona also pointed out that as of several months ago, SourceForge no longer offers its compile farm service, since it was not very popular.

Eventually, I'd like to put together a short tutorial on how to get up and running with an open source development project on Google Code. In the mean time, I'll play around and experiment some more, and continue learning about the various development tools available. One fun thing I learned, for example, is that Eclipse has a Subversion plugin which directly integrates with Google Code. These will be some fun things to play around with in the coming weeks.

Comments

( 14 comments — Leave a comment )
mialie
May. 15th, 2007 01:57 pm (UTC)
I've been poking through the less technical sections of the "Producing OSS" book, and even though the document makes some good points, I find it written in a pretty pessimistic style. Hell, the introduction begins with the words, "Most free software projects fail."

I understand that it's good to mete out advice cautiously (what he terms a "practical guide"), but it almost seems as though he's saying, "Unless you're Mozilla, don't bother." It'd be nice to see some enthusiasm. Maybe I'm just approaching it from too much of a Comms perspective, where it's as much how you say it as what you say, whereas a techie would be more inclined to appreciate a no-nonsense approach.

Myself, I'm more keen to read something like Kathy Sierra's blog. Too bad she's taken an extended hiatus due to drama-rama.
banzaimonkey
May. 15th, 2007 05:52 pm (UTC)
Hell, the introduction begins with the words, "Most free software projects fail."


Well, most free software projects do fail, generally because there's noone paying for development (among numerous other reasons). Contrasting with proprietary software where a company pays people to write the program; if the developer isn't doing his work properly, he gets fired and replaced. That doesn't happen with OS.

Keep in mind that the author's target audience is developers who are working for private companies who are thinking about migrating their projects to open source. What Fogel's trying to say is that making a doomed project open source won't save it from doom. In fact, making a good project open source won't necessarily make it better. If you don't do it properly, it could cause disaster and the death of the project.

The rest of the book is, essentially, a guide how not to fail, and it does have some pretty poignant directions. It covers all aspects of software development that a coder would not necessarily be aware of, such as management, communications, public relations, limiting control, how to work with people you've never met, etc. Each of these things is an essential part of open source development, and you'll see in various other places around the web that people who have been involved in OS development echo many of these sentiments as well.

As for Kathy Sierra's blog, she's got a target audience too. She's got a style that caters to that audience. I don't particularly like it, myself. Especially not now.

There may be a common misconception that Open Source is a liberal idea, or is somehow associated with a particular political view. It's not. Considering that, you'll get a full spectrum of people using it, developing it, and writing about it, and you'll get a full spectrum of crazy ideas.
mialie
May. 15th, 2007 06:51 pm (UTC)
"What Fogel's trying to say is that making a doomed project open source won't save it from doom."

You'd think that, given his technologically educated audience, they'd already know that. I understand the point he's trying to drive home (i.e. that walking the OSS path is a rough journey), but I think sometimes he overstates his case. He has the tendency to use adjectives like "slow" and "cumbersome" throughout, which (like I said) lend an air of depressed resignation to the document. At least the parts I've read so far.

I'm curious as to why you didn't like Sierra's style. Too "pop culture" for your tastes? (And what's with the "especially not now" comment? You mean post-death-threats?)

I would probably be inclined to agree with the idea that wiki is more of a "liberal" idea, at least in the way that the States has defined the left/right spectrum. Conservatism (aka The Right), as I understand it, is about individualism and personal independence, free from outside influence and intervention. "New Deal" liberalism (aka The Left) is the opposite, concentrating on community, shared experience, equality, etc. (Whether they actually do anything more than give those values lip service is to be debated.) But anyway. Even if the association is a misconception, it's pretty easy to see why people might make that mistake.
banzaimonkey
May. 15th, 2007 07:21 pm (UTC)
You'd think that, given his technologically educated audience, they'd already know that.

Not necessarily. The whole point of writing a book like this is to pass on the wisdom of your experience to others. You can't expect tech people to know everything just because they're tech people. There are lots of things they haven't done, and they come from all sorts of backgrounds. You have lots of people who have had careers (and lifestyles) dealing entirely with proprietary software and have no concept of the open source model. Even though they may be technically experienced (i.e. they can code well) it says nothing of their management experience in unfamiliar territory.

He has the tendency to use adjectives like "slow" and "cumbersome" throughout, which (like I said) lend an air of depressed resignation to the document.

I think in some ways this is a case of typical "technical" ways of communicating (which Fogel mentions in several places). Comms people have to package everything up in rosy packages. Tech people just say what needs to be said with a no-bullshit, no-pleasantries manner of speaking. Like I said, it's about target audience. Fogel isn't targeting the end-user who wants things in pink foil with bow; he's targeting the people who are putting the package together in the first place.

I'm curious as to why you didn't like Sierra's style.

One of Sierra's articles I read was discussing how best to leverage (read: exploit) members of your community by fostering elitism and exclusivity in order to get what you (the company) wants. That really rubbed me the wrong way. I don't contribute to a project to help the company. I contribute to a project to help the end-users. The company is a tool, and the product is a tool, and it's not about the tool; it's about how you use it. I'm not particularly interested in being leveraged, and in cases where I am (like Sitesled) I get fed up and leave. In addition to that, I don't think her advice on the subject was very good. It was overly academic and not very realistic.

The other thing that bothered me was the way she responded to the internet drama. Instead of standing her ground and fighting for her rights, she immediately folded. Not only is that a bullshit way to handle things, it ends up giving in to the demands of the aggressors. Terrorism wins today, apparently.

mialie
May. 15th, 2007 08:28 pm (UTC)
"Even though they may be technically experienced (i.e. they can code well) it says nothing of their management experience in unfamiliar territory."
I suppose I'm having trouble seeing how this type of sheltered techie could exist. The majority of comp sci nerds that I know (which, admittedly, is limited) all seem to have a fairly firm grasp on the pros and cons of OSS-type development, so I see his warnings as kind of redundant, at best.
"Tech people just say what needs to be said with a no-bullshit, no-pleasantries manner of speaking.
And most likely make a good deal of readers bristle in the process, just like the condescending "Comms people need rosy packages" comment above. I know you don't mean to offend, so I won't take that comment personally, but you seem (as do a lot of "technical writers") either resistant or oblivious to the role that tone plays in communication. "No-bullshit, no-pleasantries" writing can be the most efficient form of output, in terms of getting ideas down on paper, but that doesn't necessarily carry over into efficiency of imparting those ideas.

Look at it this way: you (the general "you", mind), as a bearer of knowledge, expect me to extend to you the courtesy of respectful attention. Yet you (again, general) see no need to extend me the similar courtesy of being sensitive to my reactions. Now, I'm not saying you have to couch your words in "maybe you could" or "if at all possible" or other wishy-washy language like that. But cold, hard statements are unlikely to garner you an audience willing to attentively consider your ideas, regardless of how good said ideas might be.
"Not only is that a bullshit way to handle things, it ends up giving in to the demands of the aggressors."
You've asked me not to take this any further in your blog, so I won't. Well, except for saying that I disagree with you. She could've handled it differently, true, but I don't believe that she should be required to serve as the Rosa Parks of the blogosphere.
banzaimonkey
May. 15th, 2007 09:42 pm (UTC)
I suppose I'm having trouble seeing how this type of sheltered techie could exist. The majority of comp sci nerds that I know (which, admittedly, is limited) all seem to have a fairly firm grasp on the pros and cons of OSS-type development, so I see his warnings as kind of redundant, at best.

I think you're not seeing the bigger picture, here. The majority of people you know, your peers, have grown up during a period of time in which the internet has been the driving force behind software development. Open Source, as noted by Fogel, is a relatively new PR term. Essentially, there's a generational issue here that you're unable to see because you and your peers (myself included) have grown up in the internet age of open source and music sharing.

The majority of corporate software developers, on the other hand, started their careers before the internet became the driving force that it is today. They started before Linux or Napster existed. They started before gaming was something the cool kids did. Many of them probably started before there even was an internet.

Even now, the vast majority of software developers do not work on major open source projects such as Apache, MySQL, etc. Why? Because open source is free. Noone pays for it. If you have a huge project like Apache, you can find ways to make money off of it, (usually consulting), but unless a company is going to sponsor developers to work on the project full-time, all of these developers will have to do something else to pay the bills. And what is that? It's working for Microsoft, Adobe, Corel, IBM, Apple, or whatever. What they do on a daily basis is not open source.

To be fair, anyone (in the field) who doesn't know what open source is today is a dinosaur. Just about everyone knows what open source is, and certainly, everyone has used it whether they know it or not. However, given that there is less money in open source, there are also certain less full-time open source developers, and less people who have worked in lead positions on projects like Subversion, the Apache Web Server, MySQL, etc. as compared to Microsoft Office, Adobe Photoshop, etc. These open source people are rare, and their experience is rare also.

banzaimonkey
May. 15th, 2007 09:44 pm (UTC)

The communications issue is one which, as I mentioned previously, is covered in the book. It addresses many of your concerns. The point I think you're missing, though, is the distinction between the target audience of the book (which is developers) and the target audience of the software (which is the end-user). All of that comm theory and fancy packaging is meant to appeal to the end-user. It is designed solely for that purpose.

The audience being targeted by this book is one which is not your typical end-user. They are a technical developer, and different rules apply to them. Take a look at page 87 of the book, a section titled "Tone", and page 88, a section titled "Recognizing Rudeness", for some examples of what I'm talking about. If Fogel were to focus on comm issues while writing his book, he'd be wasting time and obfuscating the point. The point isn't to put the book in a nice package and sell it to people. It's to educate developers. These are people who are going to look for the no-frills no-bullshit document in PDF form, read it, and come to their own conclusions. They aren't the type of people who are going to be attracted by fancy packaging and "buy" whatever looks nicest. They're going to use whatever is most efficacious for achieving a specific goal (provided they're any good at what they do).

...but you seem (as do a lot of "technical writers") either resistant or oblivious to the role that tone plays in communication.

There is a time and place for certain methods of communicating. When you are dealing with a technical subject, it is the time and place for technical discussion and information. Anything else gets in the way. If you've ever tried to explain something technical to someone, you know how frustrating and tedious it is; it would be even moreso were you to have to preface everything with some sort of apologetic remark.

Technical writers aren't trying to be rude. They're trying to be efficient when dealing with extremely complicated issues which rely on clarity and brevity. Patience is short with technical subjects to begin with, and most people just want it to work, whatever it is. The best way to get there is to give the person the steps they need to get it working and eliminate any excess verbiage. That's why you get terse questions like, "Is it plugged in?"

kfogel
May. 16th, 2007 08:19 pm (UTC)
We might be dealing with a difference in expectations. I didn't intend the book to be pessimistic. banzaimonkey is right about the the style I was aiming for; whether successfully or not I can't say.

mialie, you might be amazed at how little most technical people know about open source. They often aren't acquainted with the most basic concepts. I was also surprised to find this out, because hey, all the programmers I knew were very familiar with open source... But that turned out to be selection bias. If you just pick programmers or technical managers at random, the field will often be a complete unknown to them, or they'll believe things about it that no one with experience would believe.

By the way, for us non-specialists here, what is "Comms"? :-)

Best,
-Karl Fogel
mialie
May. 16th, 2007 08:36 pm (UTC)
"Comms" is short-form for "communications majors", that bunch of elite snobs that prefer to dissect tone rather than content. Or so Banzaimonkey would most likely say.
"mialie, you might be amazed at how little most technical people know about open source."
Well, then colour me surprised. Perhaps I run in very sheltered techie circles, or maybe it's a generational thing, as Banzai mentioned above. Either way, I'm enjoying the guide so far, despite my comments about pessimism. This whole debacle is simply due to my passion for picking fights with monkeys. ;)
banzaimonkey
May. 17th, 2007 01:48 am (UTC)
Actually, I'm also surprised to hear that most tech people don't know about open source. I would think that if anyone knew, tech people would be the ones to know. It seems that my dinosaur comment was a bit overstated.

In retrospect, though, it seems entirely reasonable to imagine that this is the case. Particularly in an environment in which technical positions are requiring college degrees and colleges today place huge amounts of emphasis on "Academic Integrity", the days of sharing code (at least in an academic setting) seem to be gone. Given that most programmers' formal educations will now be in settings like this, there's no introduction to open source unless they happen to stumble upon it in their own pursuits.

Even in the case that someone does bump into it, such as in the case of Apache or OpenOffice, they may only think that, "Hey, this is free! Neat!", and not ask any more questions. And even when it is free, people still use proprietary products for no reason other than it being more familiar.

I suppose in this sense, OS still has a ways to go. There're a lot of little pushes (such as Firefox, OpenOffice, and the backends like Subversion, Apache, and Google Code) working simultaneously, though, and and I think it's starting to build some momentum.

Thanks for taking the time to reply, by the way. I was quite pleasantly surprised to see that some interesting people found this discussion interesting. ;)
kfogel
May. 17th, 2007 07:00 am (UTC)
(Thanks, mialie, I hope you enjoy the book!)

Regarding people understanding open source:

More and more programmers are coming to the field by majoring in computer science in college; in a sense, the golden age of computer programming is passing, I think, in that it's slowly becoming a certified trade. But most of these courses do not expose the students to open source in a participatory way. Sure, the lab machines may be running Linux, or the course may use open source compilers, interpreters, and other software, but that's not the same as educating the students on what open source is actually about or how it works. I've talked to plenty of students or recent graduates who thought that "open source" just means you can see the source code.

I don't mean this as a criticism of the curricula. Time and attention are limited, and the students are often focused on getting jobs after graduation. But one result of it is that the percentage of tech people — including even programmers — who grok open source is probably not rising as quickly as the percentage of (say) running lines of code in the world that actually are open source.

Whenever I have a really random sample opportunity in a conversation (say, sitting down next to someone on the train who has a tech industry magazine or a computer science textbook open on their lap), I often learn that the person has no real understanding of what open source is. They have usually (though not always) heard the term, but they just think it's "Linux" and that it's "free", by which they just mean it doesn't cost anything :-). They have no clue that the Internet runs on the stuff, or that people are paid to work on it, or how the projects are organized.

So, although I don't have a formal survey or anything to back this up, I think banzaimonkey's "in retrospect" comments above are accurate.

Thanks for an interesting conversation!
cdibona
May. 16th, 2007 05:40 pm (UTC)
A couple of comments
Good post, Mr. Monkey, but I thought I'd point out a couple of things lest the world enjoy confusion:

WRT Deletion: Once your project reaches a certain level of activity, we disable the ability to delete the project. Since open source doesn't require that users upgrade, the presence of old versions of a program can be very important and so we take the position that to delete a substantive project shouldn't be done.

Secondly, SourceForges compile farm was officially shut down this or late last year due to lack of use.

Thanks!

Chris DiBona
banzaimonkey
May. 16th, 2007 10:55 pm (UTC)
Re: A couple of comments
Thank you for your corrections and clarifications, Mr. DiBona. I've updated the article to include the corrections, so hopefully it will not confuse or misinform.

I wasn't aware that SourceForge shut down their compile farm. I suppose from that it's obvious that I didn't use it either (or I'd have noticed a bit sooner ;) ), but thanks for pointing that out.
cdibona
May. 17th, 2007 01:26 am (UTC)
Re: A couple of comments
Great! I personally thought the Compile farm was a pretty interesting feature, but I guess I was in the minority :-)
( 14 comments — Leave a comment )