Introduction

You have heard about it, you have probably tried it out and you definitively use it unknowingly every day for services like email and the web: Open Source Software. Even Microsoft is now tipping its toes in the open source waters, donating code and igniting new projects at SourceForge. So what does it take to do open source correctly? Better yet, how and when do you get the most out of it? Whether you are 1) simply going to use open source Software as a consumer, 2) start participating and contributing to an open source project, or 3) start a completely new project altogether, or 4) release an existing project into open source, this article should cover what you need to know. In this article I’ll briefly introduce you to how I think the open source ecosystem works, how to find what you need and how to behave yourself. I’ll tell you the minimum that you need to know about the open source licenses and we’ll take a look at some .NET and ASP.NET related open source projects.

While working as a research assistant at my university, I proofread an article a colleague of mine had written. My friend was participating in a newly formed cross-disciplinary research group. According to the article, the research group had taken inspiration from the open source community, in that the participants would openly share ideas with each other. I explained to him that the sharing of ideas is an ancient academic practice and what they were doing had nothing to do with open source. For instance, it was not allowed for someone to copy his article and use text from it in some other article (which would have been kind of open source-ish). He removed the sentence, but later I saw that it had found its way back into the published article. I suspect the professor leading the research team had heard about open source, decided it is hip and cool, and wanted to join in. The fact that his work had nothing to do with open source wouldn’t let him down.

The professor was I believe right about one thing though. I too subscribe to the belief that Open source really is hip and cool, and everybody is doing it. Even Microsoft is carefully tipping it’s toes in the open source waters, donating code and igniting new projects at SourceForge. (The three first ones were WiX, WTL and FlexWiki.)

So what does it take to do open source correctly? Better yet, how do you get the most out of it? In this article series I’ll take you through what you need to know in order to create or use open source projects.

• Understanding the Community and Starting a New Project . In this article I’ll show you the things you need to consider when you are deciding whether to go open source – that might mean creating a new open source project, contributing to an existing project, or simply downloading and using a project as a consumer. There are times when going open source can help your business, and other times when it won’t – I’ll explain the factors you need to consider to decide whether open source is suitable for what you are doing. And, assuming you decide that it is worth while your going open source for some application, I’ll work through the steps you need to consider in order to make a success of the project. Along the way I’ll briefly introduce you to how I think the open source ecosystem works, how to find what you need and how to behave yourself.


• Evaluating and Joining an Existing Project . The second article will examine the issues surrounding joining an existing open source project. I’ll show you how you can evaluate which of many competing projects is most likely to be suitable for your business, and I’ll run through some of the useful places to look for .NET-related open source projects, as well as discussing a few of the more well known and useful projects that are currently around.


• Licensing . In the third article I’ll tell you the minimum that you need to know about the open source licenses and discuss what factors you should consider in choosing a license for your projects.

What is Open Source?

First I want to correct a common misconception – that open source software is not commercial. It very often is commercial. The point is, "commercial software" is not an opposite to open source Software, in fact I believe the majority of open source Software today is commercially developed or sold. A good name for the opposite of open source is "closed source" or also "proprietary software". (The first being technically more accurate but the second is used just as much.)

Later in this article you’ll learn that there actually is a document called the Open Source Definition, which very well draws the boundary lines about what is open source or not. But to get started I think it suffices to say that open source is software where the source code is available (obviously) but more importantly, it is available with some rights which make you a potential participant, not merely an onlooker. Whether or not the software is free or must be purchased is irrelevant to whether it is open source. As a counter-example, Microsoft’s Shared Source is a program where it is possible to get a "look but don’t touch" access to it’s source code which therefore is not open source. (Confusingly, there are a few applications in the Shared Source program which in fact qualify as open source.) And finally, open source licenses don’t put restrictions on copying the software. In practice most open source software is freely downloadable from the internet, but this is actually not a requirement at all!

At this point I might just as well introduce two other terms you will have heard, freeware and shareware . Both of these refer to software that is freely downloadable from the web, but which is not open source. Typically source code is not available at all, but even if it were, it does not comply with some of the principles of open source as discussed in these articles. The "free" in freeware, actually means "no cost". For shareware you are usually expected to pay sooner or later.

Then again open source is so much more than just a license. The license is a license, and while it makes all the difference, it is not the real difference. There are many reasons to get involved in open source, whether as a developer or a user, whether you are joining a project or starting your own.

Why Use Open Source?

Let’s start off by looking at some of the reasons why you might choose to run a project on an open source basis.

Reasons for Participating in an Open Source Project

There are many answers to the why-question. But one good answer is simply: Why not? Especially now that we have the Internet, sharing of source code (just like any other information) is so simple and effective, it’s often a natural choice. Just like our mothers shared recipies, we share code. I bet many of you learned HTML just like me: using the blessed View source menu option. Lot’s of handy JavaScript snippets certainly spread the same way. Sometimes the code even contained a copyright notice allowing you to use it. Sometimes you just used it anyway.

For many open source developers programming is a hobby. They are students or even if they do programming for work, they can’t help but code a little bit on their personal project at home. Actually, a Linux programmer who has invented some incredibly novel scheduler algorithms, Con Colivas is a practicing doctor for day work! For these people sharing code makes a lot of sense. For any hobby, it’s great to show others what you’ve done and listen to people telling you what a good coder you are. More importantly, working together with others on a project, you’ll get so much more done than you would alone.

But there are also many valid business reasons to participate in open source. Very often the software you need to have developed, is just a means to some other end. If you run a web-shop, you need an eCommerce site, but you’re really interested in your actual products and selling them. Or, you might be running an eCommerce site for shops that pay you a monthly fee to be using it. In either case, you just need an eCommerce site. If you can find one that is open source and freely available, all the better.

It’s important to note that open source isn’t just about finding free stuff on the net. Say you didn’t find a suitable open source eCommerce application, or you might have found one that is decent but not perfect. In that case you still have the option of doing everything yourself, or you could share your work on the net and hope someone who is also looking for the perfect eCommerce site finds you and joins you in developing it. You weren’t going to sell the application, so you haven’t lost anything by sharing it, but you’ve gained free workforce!

At my work, we actually happen to be at such a situation right now. We are working with a technology called Session Initiation Protocol ( SIP ). SIP is one kind of Voice over IP and I’d boldly suggest it is the most open kind. It is defined in an RFC (3261) and follows the Internet philosophy very well, in fact sometimes I think it’s like somebody has mixed HTTP and SMTP together. There are other VoIP technologies as well, for instance the H.323 protocol family is defined by the International Telecommunication Union (ITU) and the popular Skype uses it’s own proprietary protocol. After evaluating the current situation, we have come to the conclusion that all of the free standards-based SIP clients currently available for Windows are really, really bad (and those that exist for Linux are only slightly better). This is particularly true when compared to the proprietary Skype, and is a serious problem because with these clients, no one is going to use the kind of SIP based VoIP we are interested in working with. Making our own client is an option, but this is something that is going to be freely downloadable from the Internet, so owning the copyright to the client is not that interesting. The important thing is just that we need such a client to exist, in order to get into doing all the other stuff we want to do. So my superiors have made the logical decision to invest some serious man months of work into an existing open source client, to really make it good. More importantly, we believe that if we "push a little", others looking for a good client will join us in the project, and it will end up being the best VoIP client on the planet.

Another interesting angle and a good example on a business reason to go open source could be found with Microsoft and ASP.NET. As we’ll learn later, many open source ASP.NET projects exist. Apart from FlexiWiki mentioned above, it doesn’t seem that Microsoft is actively promoting them or igniting new such projects. For Microsoft, that would however have made a lot of business sense. The more ASP.NET (or even .NET in general) projects out there, the more you can easily get done on the platform and the more developers will get involved in .NET. And that means more customers will be running Microsoft’s platform instead of competing alternatives like Java. Coincidentally, I believe one of the most important reasons to the continued success of Java, are the many open source projects hosted by Apache and elsewhere. Without them Java standing on its own feet would certainly be inferior to the .NET platform, especially in the area of web development.

When to go Open Source

Putting the above reasoning into a more concrete and compact form, I’ve put down a list of good reasons to invest your time and effort, perhaps even money, in an open source project, or to release your own source code as open source:

• All kinds of altruistic reasons .


• Or if that is not a good business reason, call it PR .


• The business model . Owning, or rather controlling, the source code is secondary to what your business model is really about. You may have thought your business model is selling software, but then you realise it really is consulting, providing a service (ISP, ASP…) or even a close personal relation with your customer. Hardware vendors – IBM and HP are big contributors to Linux – fall into this category. Book publisher O’Reilly once sponsored Larry Wall, creator of the programming language Perl to work on the next version of Perl, because then people would buy a new edition of the Perl manual, which Larry was also hired to write for them.


• Supporting other software . Releasing some software as open source, will help drive the sales of some other software you are not going to give away for free. (Releasing Eclipse supposedly is benefiting sales of IBM’s Java platform.)


• Can’t do it alone . Your need is bigger than your resources. Many others have the same need as you. Together you could achieve so much more than you or your company alone. And even if it is true that someone else might benefit a little from the code you are giving away, you will benefit from others joining you. Most importantly, there will still be a big enough piece of the pie for you to take away.


• Do it before someone else does it . When IBM released Eclipse, there were half a dozen decent Integrated Development Environments competing for the mindshare of Java developers. Today, Eclipse has surpassed all of them, some have even ceased to exist. Sure, IBM had to "give it away", but the alternative, some other IDE taking home the jackpot, would have been even worse.


• Dual licensing . has proved to be a very successful model, bringing the best of both worlds. Releasing the software as open source (using GPL or a similar license) brings attention and the all important developer mindshare to your offering. In the best case, outside developers get involved and start contributing code to your product! For those that need to do something the open source license doesn’t permit, you sell commercial licenses. (The idea of dual licensing will be covered in the third article of the series when I tell you about the open source licenses.)


• Ethics . Finally it should be pointed out, that many people believe and often strongly advocate their opinion, that any other form of software than Free Software is unethical. I have to say that in my view, their arguments have at least some weight to them, being based on principles like altruism and inclusion instead of exclusion. (Using the synonymous term "free software" instead of "open source", is usually a sure sign that the person holds this view.)

I should also point out that there are some reasons against going open source:

• Software Sales . Your business model really is geared to selling software in a box. A good example is Microsoft, which has focused very hard on a business model based on software licensing, leaving everything else mostly to partners: re-selling, consulting, support, training, hardware manufacturing, etc. Microsoft would have a difficult time going open source.


• Control of Technology . Via your software you control some important piece of a puzzle which gives you leverage, and giving up control of your software would leave you in a significantly weaker position. For instance, Sun is not considered to be a remarkably important player in the Java world anymore. But they are still the only provider of a complete Java environment and somewhat in control of defining the APIs for new versions. Should they let go of this control, they’d risk being sidestepped completely as IBM, the Apache Foundation and others would probably take more of a leadership role. There has recently been many appeals for Sun to release Java as open source. It is easy to see how that would be good for Java, but it is not as easy to justify how it would be good for Sun.


• Niche Market . You serve a small niche market with very proprietary, unstandardised technology. There is only a small audience interested in your technology. In particular you don’t expect any outside volunteer developers to join you. There are little or no competitors in your niche. Releasing your code as open source would not give you anything back, but would require extra effort from you (in maintaining a project website and so forth). And most importantly you’d also risk losing paying customers who’d take the open source code and install it for free. (This last bullet point is a consequence of Eric Raymond’s reasoning, see below.)

Long before me, Eric Raymond wrote a famous essay about open source called The Cathedral and the Bazaar. In it he gives a good rule of thumb of when to go open source and when maybe not to:

1. The more users some application has, the more likely an open source solution will arise (and succeed). Conversely, the more specialized a function is, the more likely you can successfully sell a proprietary solution.


2. The more some application is based on open standards, the easier it is to build an open source solution.


3. The older the technology, the more likely a good open source solution will exist or come to exist.

These rules are good to consider, when you ponder whether to release your code as open source. Also combine them with my advice of doing it before someone else does.

Reasons for Consuming Open Source Software

I have now presented some reasons why a developer or other participant might get involved in open source. That also provides an explanation as to how open source software comes to exist; that’s an important topic because quite often somebody’s first reaction to open source is to dismiss it on the grounds that it cannot really exist (i.e. it can’t be professional) because they don’t understand why anyone would invest in developing such software.

But let’s look at reasons to start using open source Software. After all, there are more users than developers. Come to think of it, developers are users too!

There are the obvious reasons. Open source software is often free of charge or at least the cheapest alternative. You can download it from the web and just install and get going. In fact, you should not underestimate the importance of the low barrier to using an application due to a permissive license. The key point is that a permissive license that makes it easy to redistribute an application, which in turn reduces the effort and time involved to install and configure it – perhaps to zero. For example a Linux distribution is able to pack thousands of applications, readily configured to work on that distribution: No installation wizards or anything needed. This is made possible by open source licenses: it would not be feasible for a distribution to pre-negotiate the terms to do this for thousands of applications. I remember a personal experience, when I was working at the university and was to make a flashier than usual seminar report. So I realized I’d need a desktop publishing application. I was depressed by the thought of spending days roaming through the corridors of the University, trying to get a license to install Pagemaker or Indesign. Then I remembered I had heard of a program called Scribus, a desktop publishing application for Linux. Even if it was then only in early beta stage, I thought it was worth trying it out. Since I was already on a Linux computer, I just typed the command urpmi scribus (I’m a devote Mandrake Linux user) and a minute later I had Scribus running, realised it could do what I needed, and could start working without having lifted my butt from the chair I was sitting on! In fact I have also heard of people who have somehow managed to loose their activation code for Office XP, which means they are looking at a pretty useless office suite. While looking for the code, they install OpenOffice to get their work done, and when they eventually do find the activation code they might not care about Office XP anymore.

A good business reason to choose open source software is also continuity. When you decide to become a user of a software, you invest not only money in acquiring it, but also time and effort in installation and learning. And eventually you accumulate a lot of documents or other data in that software’s format. The worst thing that could happen is that the company providing the software goes out of business and you are forced to start upgrading to some other alternative. Now granted, with Microsoft Windows and Office that is perhaps not such a big risk, but with smaller companies the risk is significant. If you choose an open source application, your provider might still disappear, but you’ll still be left with the source code and the right to use it. It is then up to you to decide, which is more desirable, to start maintaining the software yourself, or just switch to an application that isn’t dead.

Security is also often quoted as a benefit of open source, in that you get to verify the source code. More precisely, most users never want to go and read the source code of the applications they are using, but the fact that there are people who do exactly that (some of them are geeks doing it out of interest, but some are paid security consultants) is good to know even for us who have better things to do. The fact that Microsoft has granted governments access to the source code of Windows is testimony to the fact that these concerns are legitimate.

Users of open source obviously also claim that open source Software is better, more secure, more user friendly and all of those things. But, that’s up to everyone’s individual taste, so there is not much to write about that. But the point is, a wast majority of open source users, including myself, do not use open source out of principle, but because of the software itself.

Understanding the Open Source Community

If you are going to go open source, then you’re going to be interacting with people on a slightly different level – and you’re going to find that some of the expectations of how you interact with people are different from what you’d be used to in the closed source world. That’s important because as any good marketing department will tell you, not conforming to the cultural expectations of the people you’re working with can destroy your chances in the market. So I’ll take the chance here to point out a few of the rules and pitfalls you need to be wary of.

The Community

Let’s say in one way or another, you have now decided to become active in open source, if only as a user of some application. Very soon you’ll hear about The Community . The open source community is everybody who develops or uses open source software. Big companies, small companies and individuals are members of this community and you are the newcomer. While this community is completely undefined and almost abstract, you will feel that you are warmly welcomed into something . If you have released some source code under an open source license, your gift to the community will usually be highly appreciated. Overall, you’ll experience a sense of us doing it together .

The community consists of personal interactions between human beings. Even if many open source developers do their coding as a day job for some company, they typically participate in the open source projects as themselves. People sign emails as themselves, not behalf of their company. (Often in the closed source world, people add a disclaimer to their emails: "My opinions are my own and do not necessarily represent those of my employer." You won’t see many of those in the open source community, because that is taken for granted.) You’ll appear with your true identity using your real name – don’t use a nickname. Consequently, the work done by an open source developer, even if his employer might be the owner of the copyright, is his personal work of art, something he enjoys and is proud of.

The personal touch is a truly remarkable difference to the corporatespeak you might otherwise be used to in the IT sector. For instance, some years ago, I was at work on one of the last days before Christmas and I had finished everything that needed to get done. A beta version of Mono (I’ll introduce you to Mono in the next article of this series), I think it was version 0.17 which was the first to support ASP.NET, had been released, so I decided to test how it would run under Linux. My colleague quickly tossed up a couple of simple ASP.NET applications, I remember one being a simple calculator. All of our .NET gurus gathered around my desk to see them run under Linux. They ran, but not surprisingly, the alpha version had some bugs. Since I was just killing off time anyway, I decided for once I would be a good citizen of the community and report the bugs to the developer. Mono, like most open source projects, uses a web based application for tracking bugs – in fact, Mono uses the original and still rather popular Bugzilla , born as a side product out of the Mozilla project. There anyone can give a (hopefully) detailed description of a bug they’ve found. I reported 4 different bugs. (You can still find them in the Bugzilla.) The day after New Years Day I got email from Gonzalo, the Ximian developer (Ximian is the company that started the Mono project. It has since been bought by Novell.) working on Mono ASP.NET. He thanked me for sending the bugs, told me that they were now fixed in the CVS version of Mono and wished me a happy new year. It has also happened on other occasions, that I have exchanged personal emails with people like the lead developer of the Apache Tomcat server. I cannot remember experiencing that kind of thing when sending bug reports to a big traditional software company like Microsoft, Adobe and so forth.

For us developers, this is a great thing. You get to be yourself and don’t have to watch out for some company guidelines all the time. You get direct feedback from your users, which is usually highly encouraging and motivating. And you get to take credit for your work, something that is often not the case when software is released under your company brand – in some cases you signed an NDA and cannot even tell your wife what exactly you are working on!

Language

Even as Open Source has now become a mainstream thing and the corporate world has joined in developing the vast open source codebase, the community has been very succesful in resisting any pressure towards a more formal style. So don’t be surprised if you find that supposedly formal documentation contains clever word plays, irony and sarcasm. And don’t feel offended if it seems that no one is being serious, they are, this is just their style. In particular don’t make a fool of yourself by being too serious – and make sure your PR department also gets this message, there is a section especially for them later.

A great example of informal community style is Linus Torvalds himself, who’s essay Linux kernel management style is in my view one of the best and most humorous pieces of literature I’ve read. It is a text that is part of the official Linux documentation, yet contains statements such as ~ First off, I’d suggest buying "Seven Habits of Highly Successful People", and NOT read it. Burn it, it’s a great symbolic gesture. ‘ The document was written by Linus to the kernel project’s other leaders, so you might compare it to a memo sent by the CEO of a 1000 person company to his vice presidents. Another example of typical informality is provided by Figure 1, which shows an open source developer environment, SharpDevelop. Can you imagine a closed source application providing this message for features that are planned but yet to be implemented ? (I’ll discuss SharpDevelop in more detail in the next article).

Figure 1. SharpDevelop, displaying information about features not yet implemented.
This figure has been reduced in size to fit in the text. To view the full image Click here

So don’t make an ass out of yourself, be relaxed and informal, in short be yourself. That being said, good English language is held in very high regard. When posting messages to mailing lists and forums, make an effort to explain clearly what you want to say and try to get rid of most spelling errors. Phrases such as " quez 4 u " might sound cool and informal but shouldn’t be used because they are not good English and will not be understood by some people – and by implication suggest that you don’t really care about the reader.

You don’t by the way need to worry if English is not your native language (If you want to, you can say so up front.) The important thing is to show that you’ve tried to make an effort in your writing, that you care about the reader.

On a related note, when asking questions or asking for help, it is good to make it known that you have tried to solve the problem yourself and only then resorted to asking for help. Actually it is a good idea anyway to list all the solutions you have already tried but failed. RTFM is an acronym for Read The Fine Manual , and is the answer given to questions where it is apparent that the person asking for help has not even read the basic instructions. (Which is probably the reason he is in trouble anyway, so it is also the right answer.) On the other hand, if you really have tried to solve a problem yourself, you could say that you already have RTFM, and it didn’t help.

Leadership

The different open source projects, as well as the community in general, will have persons in leadership positions. Although some projects have formal procedures for electing leaders, any leadership will be based on merit . Although there are exceptions, merit is usually determined by amount and quality of code contributed. Often a person is the leader of a project by way of also being it’s founder, like Linus Torvalds is for Linux. By joining him, others have already acknowledged his leadership position.

Again, a leadership role and all other roles as well are always attached to the person, never the title he has in the company he works for. If he switches companies, his role in the community follows him.

Starting your own Open Source Project

Let’s now examine some of the issues you’ll need to bear in mind once you have decided to start a new open source project (either from scratch, or by going open source on what was previously your business’s private code).

Designing your Publicity

A very common mistake when going open source is for the developers to forget to educate the PR department about the open source community. Introducing your sizeable contribution of code with the standard press release of "[Company name] is the leading provider of…" , as PR departments are often by default inclined to do, is sure to backfire. (Although, it is comforting to know that we in the open source community also are a kind and forgiving lot, and you wouldn’t be the first to make that mistake.) Instead, remember what you’ve just learned. You are not here to save the world, we are doing it together. More importantly, you are the newcomer joining the party, so right now you are not the leader of anything (other possibly than your own project once you’ve got it off the ground).

To really make an impression, the more informal you can make your press release, the better. Sometimes you might even want to pass on the press release and write a personal email on an appropriate mailing list instead. Or since the press might be confused if you do that, it is also usual to do both the press release and the informal email.

One of the better announcements I’ve seen was the announcement of Roswell, a beta release of Red Hat in 200; this was a mailing list announcement that is full of irony and parody as it makes its point. Granted, this was a beta and is as such oriented more to the insiders of the open source community; for the actual releases Red Hat does in fact issue rather standard press releases in a language that the mainstream press and seasoned CIOs will understand. But the Roswell announcement is a good example of successful interaction with "The Community".

Getting other Developers on Board

The key to a successful open source project is to attract as many users as possible and hopefully even many outside developers. Free beta-testers and even free workforce is out there waiting for you. Finding them is worth an investment.

Try to actually make an effort publicizing your releases. Freshmeat.net and SourceForge.net are two good sites to do that. If your project is ASP.NET related, you should also consider websites like CSharp-Source.Net and ASP.NET web.

Release early, release often , is an oft cited open source mantra. Publicity is actually one important reason to release often, you’ll get more opportunities to publicize your project. Of course that’s not the only reason. By releasing new versions regularly, you’ll get better interactivity with your user base, which are the ones providing valuable feedback and even bug reports.

On the topic of etiquette, do not spam! This is the same community that created the Internet and standard netiquette will be strictly enforced.

An open process

Open source is not just about the code being open, it is about an open process. Once your project gets publicity, make sure you have a mailing list interested people can sign up for. Make sure there is a bug tracking tool where your users can report bugs. You might want to have web based forums as well. The more communication the better.

One very important piece of advice is for projects where all or most of the developers are from the same company. It is very important that all discussions regarding the project are conducted on the public mailing lists and message boards, where outside developers are on an equal ground. Discussing the project during lunch breaks and at the water cooler should be outright forbidden! This is especially a challenge when some previously proprietary software of some company is turned into an open source project. Not heeding this piece of advice is a sure way to make a project fail.

Source Code Management

Finally, in addition to making an effort to open up your communications, you obviously need to have the infrastructure in place to open up your source code. Just making releases and publishing the source code alongside will not make a successful open source project. The open source developers will be interested in the bleeding edge, the code you are developing right now. And since you are interested in those developers, that’s what you have to provide them. Just like all of your discussion is now in the open, so must be your source code management ( SCM ) system .

The two popular open source SCMs are CVS and Subversion . They are both very similar, but Subversion is newer. In fact, it is a better replacement for CVS. CVS is still used in a majority of open source projects, but at the moment Subversion is taking over. If you are starting a new project, you will choose Subversion.

A word about Visual Source Safe (VSS). It is good to remember, that one reason you are interested in open source, is to get involvement from as many other developers as possible. Developers on the other hand have certain skills, which influences what projects they are interested in. As such, an important criteria when choosing your tools is to pick the ones that as many as possible are familiar with, so as not to limit your pool of potential developers. Since VSS is largely unknown in the open source community, that is one good reason not to use it. (That being said, many open source projects depend on using Visual Studio 6 or 7 and their developers are quite okay with that. When developing software for .NET and especially ASP.NET or a Windows GUI program, using Visual Studio is a very well motivated choice, but using VSS for source code management would most likely be a very bad choice – you’ll severely reduce the numbers of developers contributing to the project.) Another problem with Visual Source Safe, is that it is based on locking individual files a developer wants to work on, whereas all alternatives presented here are based on the notion of diffs and patches , which lets the SCM do away with locking altogether, and instead just intelligently incorporates the changed parts of each file as the developer commits it to the repository.

CVS and Subversion are both centralized systems, which means the source code is stored in a database somewhere, and users will check code out and in from that system. Usually everybody will be given read access without a password, but obviously only trusted developers can be given a user account with write access. If someone else wants to contribute enhancements to the code, they will have to send their patches via email to one of the trusted developers or to a mailing list and then the trusted developers can apply the patch and store it in the centralised SCM. This works just fine for thousands of open source projects.

Distributed Source Code Management

The real buzz this year however has been about distributed version control . In distributed version control, there is – by definition – no central storage. Everybody maintains their own version of the source code repository, and commit their changes to that. As a consequence, there is no need to divide developers into trusted and others . You can give free read access to your repository and you yourself will decide which other repositories you will be pulling changes from. If a new developer wants to join in, he just sets up his own repository and starts making changes to that. If the changes turn out to be good, the others will surely start incorporating the patches from his repository to their own. (This setup is somewhat similar to the World Wide Web compared to a traditional database. On the Web, anyone can setup their own website, and if it is any good, others will start linking to it.)

By now you should realise that distributed version control is a model that fits open source development much better. Indeed, development in this area is very active right now, and currently it is impossible to say which tool or tools will be the one everybody ends up using. The Linux kernel developers seem to have decided to use their own, git, (a name picked by Linus – another example of open source humour. I believe the reason for this choice was that the early versions of this software weren’t that intelligent) so git should be a sure bet to survive and mature to a great tool. But it can very well be, that git ends up being very specialised to the kernel project’s needs, and one of the others becomes the one to be more widely used. So keep an eye on Monotone, Arch, Bazaar, Bazaar-NG, darcs and SVK. (And that was just to name a few!)

Conclusion

This article has been an introduction to open source, especially from an ASP.NET viewpoint.

I’ve tried to outline reasons to go open source. As a general rule, open source is a good idea whenever your core business is anything other than selling software licenses. And even if it is, dual licensing might be an option. Even I had to admit, that there are also some reasons against going open source.

Since you already are a developer, you know how to program. That won’t be any different in the open source world. However some things are different in the open source community and I’ve tried to pinpoint some of them. The open source community works with personal relationships. Be yourself, do not hide behind corporatespeak. Watch out for standard press releases and remember to keep an informal and personal style also when promoting your project. Organization and leadership tends to be very unbureaucratic and lightweight. Leadership is directly or indirectly based on merit.

For an open source project to be successful, you do not just release your code under an open source license. You want to encourage participation of all kinds. Therefore mailing lists, web based forums, a bug tracking tool, etc… are important. If many developers in your company participate in the same project, make sure they do all of their planning and discussions publicly, where outsiders are on equal ground with them.

And most importantly you want to provide access to your source code repository where the latest developments can be found. At the moment Subversion is the most popular source code management system, but distributed source code management is the way of the future.

The two following articles in this series will examine how to evaluate existing open source projects that you might wish to contribute to, and will guide you through the issue of licensing models.