Archive

Posts Tagged ‘Open source software’

Open source project hosting options

September 8th, 2013 2 comments

So you want to host an open source project using one of the many free services available but can’t decide which one to use? If only someone would put together a quick summary of each of the major offerings…

Hosting providers covered in this post:

  • Bitbucket
  • CodePlex
  • GitHub
  • Gitorious
  • Google Code
  • Launchpad
  • SourceForge

Bitbucket

Bitbucket is a hosting site for the distributed version control systems (DVCS) Git and Mercurial. The service offering includes an issue tracker and wiki, as well as integration with a number of popular services such as Basecamp, Flowdock, and Twitter.

Features:

  • Supports both Git and Mercurial
  • Allows private repositories for free, up to 5 users
  • Unlimited repositories
  • Has JIRA integration for issue tracking
  • Has its own REST API

Downsides:

  • Only allows up to 5 users for free (a user defined as someone with read or write access)

CodePlex

CodePlex is Microsoft’s free open source project hosting site. You can create projects to share with the world, collaborate with others on their projects, and download open source software.

Features:

  • Supports both Git & Mercurial
  • Integrated Wiki that allows to add rich documentation and nice looking pages
  • Bug Tracker and Discussion Forums included

Downsides:

  • Often times feels more like a code publishing platform than a collaboration site
  • Primarily geared toward .NET projects

GitHub

Build software better, together. Powerful collaboration, code review, and code management for open source and private projects.

Features:

  • Supports Git
  • Powerful and easy to use graphical tools
  • Easy team management
  • Integrated wiki, issue tracker and code review

Downsides:

  • Only supports Git
  • Quite a few ‘dead’ projects on the site

Gitorious

The Git hosting software that you can install yourself. Gitorious.org provides free hosting for open source projects that use Git.

Features:

  • Supports Git
  • Free project hosting
  • Integrated wiki
  • Can download the software and install it on your own server

Downsides:

  • Only supports Git

Google Code

Project Hosting on Google Code provides a free collaborative development environment for open source projects.

Features:

  • Supports Subversion, Mercurial Git
  • Integrated wiki

Downsides:

  • Not very pretty

Launchpad

Launchpad is a software collaboration platform.

Features:

  • Supports Bazaar
  • Integrated bug tracking and code reviews
  • Ubuntu package building and hosting
  • Mailing lists

Downsides:

  • Only supports Bazaar
  • Geared toward Ubuntu (which can be a downside depending on your project)

SourceForge

Find, Create, and Publish Open Source software for free.

Features:

  • Supports Git, Mercurial, Subversion
  • Integrated issue tracking, wiki, discussion forums
  • Stat tracking

Downsides:

  • Ads
  • A lot of ‘dead’ projects

 

Now obviously I’ve missed some things and glossed over others but my goal here was to provide a quick ‘at a glance’ summary of each. Check the individual websites for more. Thanks to the people over at Stack Exchange for doing a lot of the legwork.




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).
Check out my profile for more information.

One license to rule them all? Noooooooooope!

August 20th, 2013 No comments

Lately I’ve been taking a look at the various open source software licenses in an attempt to better understand the differences between them. Here is my five minute summary of the most popular licenses:

GNU Public License (GPL)

Requires that any project using a GPL-licensed component must also be made available under the GPL. Basically once you go GPL you can’t go back.

Lesser GNU Public License (LGPL)

Basically the same as the GPL except that if something uses software licensed as LGPL it also doesn’t need to be licensed the same. So if you write a program that uses an LGPL library, say a program with a GTK+ user interface, it doesn’t need to be licensed LGPL. This is useful for commercial applications that rely on open source technology.

v2 vs v3

There are a number of differences between version 2 and version 3 of the GPL and LGPL licenses. Version 3 attempts to clarify a number of issues in version 2 including how patents, DRM, etc. are handled but a number of developers don’t seem to like the differences so version 2 is still quite popular.

MIT

This license allows for almost anything as long as a copy of the license and copyright are included in any distribution of the code. It can be used in commercial software without issue.

BSD3

Similar to the MIT, this license basically only requires that a copy of the license and copyright are included in any distribution of the code. The major difference between this and the MIT is that the BSD3 prohibits the use of the copyright holder’s name in any promotion of derivative work.

Apache

Apache is similar to the BSD license in that you have to provide a copy of the license in any derivative works. In addition there are a number of extra safeguards, such as patent grants, that set it apart from BSD.




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).
Check out my profile for more information.

Do something nice for a change

October 6th, 2010 1 comment

Open source software (OSS) is great. It’s powerful, community focused and, lets face it, free. There is not a single day that goes by that I don’t use OSS. Between Firefox, Linux Mint, Thunderbird, Pidgin, Pinta, Deluge, FileZilla and many, many more there is hardly ever an occasion where I find myself in a situation where there isn’t an OSS tool for the job. Unfortunately for all of the benefits that OSS brings me in my daily life I find, in reflection, that I hardly ever do anything to contribute back. What’s worse is that I know I am not alone in this. Many OSS users out there just use the software because it happens to be the best for them. And while there is absolutely nothing wrong with that, many of these individuals could be contributing back. Now obviously I don’t expect everyone, or even half for that matter, to contribute back but I honestly do think that the proportion of people who do contribute back could be much higher.

Why should I?

This is perhaps the easiest to answer. While you don’t have to contribute back, you should if you want to personally make the OSS you love even better.

How to I contribute?

Contributing to a project is incredibly easy. In fact in the vast majority of cases you don’t need to write code, debug software or even do much more than simply use the software in question. What do I mean by this? Well the fact that we here on The Linux Experiment write blog posts praising (or tearing to shreds supplying constructive criticism) to various OSS projects is one form of contributing. Did I lose you? Every time you mention an OSS project you bring attention to it. This attention in turn draws more users/developers to the project and grows it larger. Tell your family, write a blog post, digg stories about OSS or just tell your friends about “this cool new program I found”.

There are many other very easy ways to help out as well. For instance if you notice the program is doing something funky then file a bug. It’s a short process that is usually very painless and quickly brings real world results. I have found that it is also a very therapeutic way to get back at that application that just crashed and lost all of your data. Sometimes you don’t even have to be the one to file it, simply bringing it up in a discussion, such as a forum post, can be enough for others to look into it for you.

Speaking of forum posts, answering new users’ questions about OSS projects can be an excellent way to both spread use of the project and identify problems that new users are facing. The latter could in turn be corrected through subsequent bug or feature requests. Along the same lines, documentation is something that some OSS projects are sorely missing. While it is not the most glamorous job, documentation is key to providing an excellent experience to a first time user. If you know more than one language I can’t think of a single OSS project that couldn’t use your help making translations so that people all over the world can begin to use the software.

For the artists among us there are many OSS projects that could benefit from a complete artwork makeover. As a programmer myself I know all to well the horrors of developer artwork. Creating some awesome graphics, icons, etc. for a project can make a world of difference. Or if you are more interested in user experience and interface design there are many projects that could also benefit from your unique skills. Tools like Glade can even allow individuals to create whole user interfaces without writing a single line of code.

Are you a web developer? Do you like making pretty websites with fancy AJAX fluff? Offer to help the project by designing an attractive website that lures visitors to try the software. You could be the difference between this and this (no offense to the former).

If you’ve been using a particular piece of software for a while, and feel comfortable trying to help others, hop on over to the project’s IRC channel. Help new users troubleshoot their problems and offer suggestions of solutions that have work for you. Just remember: nothing turns off a new user like an angry IRC asshat.

Finally if you are a developer take a look at the software you use on a daily basis. Can you see anything in it that you could help change? Peruse their bug tracker and start picking off the low priority or trivial bugs. These are often issues that get overlooked while the ‘full time’ developers tackle the larger problems. Squashing these small bugs can help to alleviate the 100 paper cuts syndrome many users experience while using some OSS.

Where to start

Depending on how you would like to contribute your starting point could be pretty much anywhere. I would suggest however that you check out your favourite OSS project’s website. Alternatively jump over to an intermediary like OpenHatch that aggregates all of the help postings from a variety of projects. OpenHatch actually has a whole community dedicated to matching people who want to contribute with people who need their help.

I don’t expect anyone, and certainly not myself, to contribute back on a daily basis. I will however personally start by setting a recurring event in my calendar that reminds me to contribute, in some way or another, every week or month. If we all did something similar imagine the rapid improvements we could see in a short time.




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).
Check out my profile for more information.