I think that Oracle did a great mistake by suing Google. But after all, java is kind of open source, it’s mainly protected by trademarks and obviously some patents, which sun should have donated to a separate organisaion long ago… So what can we do? Maybe we should use the open source spirit and show oracle that a blade can have two sides and start a java fork.

After all, there are plenty of JVMs out there, the specification if freely available. The language itself is standardized. Why not create a fork and get rid of code and features that is blocked by patents and invalidate as many oracle java/jvm patents by prior art as possible. Put the new ecosphere in the hands of a foundation that is lead by the interested companies and highly rated individuals from the java community to ensure that the cancer doesn’t come back. I am sure that google would be delighted to help in this process and I guess that IBM wouldn’t mind either to get rid of Oracle as gatekeeper.

We all play in a publicly available playground that has been build by a (presumably) nice guy and then a bully comes, takes over the nice guys business and starts kicking out some people whose face he don’t likes. What do you think? Should we keep playing or show the bully that he may have bought the playground, but without us, it will be pretty boring?

I am preparing a talk, that I will give at an open source conference in august (http://www.Froscon.org). The topic is “agile open source development” and I’m looking for projects that like to participate and help me to gather some data about agile techniques in these projects.
Often projects don’t realize that they use agile techniques, so it would be nice if you and/or the team could answer the questions and send me an email to cornelis@pcornelissen.de and place your project name and “[TALK]” in the subject, so my mail filters can mark the mails accordingly.

There are no wrong answers and it’s completely ok, if your project does not use any of the mentioned techniques!

To be able to use the data for the talk it would be nice if you could send me the reply before the 20th of july. If you can’t make it for that date, I can use it nevertheless, because I’m going to write a blog entry after I gave the talk about the topic.

I’d like to thank you in advance for your time and effort! If you have any questions, feel free to contact me.

If you are involved in multiple projects, feel free to send me multiple replies to this mail. You may also send this to other people/projects you know, if you think they might want to participate.

BTW: I am also interested in negative experiences with certain techniques or agile development as a whole (in the context of open source projects).

The survey won’t take long and I’ll give credit to each project in the talk and the blog post, that I’ll write afterwards!

Let’s start:

1. Would you like to get your project mentioned in the talk? (Otherwise I won’t mention the project, just the results)

2. How many project members also work in software development in their “regular” job? (The regular job may as well be to work on the project)

3. Is your project based in a company?

4. Do you use agile project management processes like Scrum, eXtreme Programming, lean development or similar?

5. Are you using timeboxed releases? (Releases every x months for example like Gnome or Ubuntu)

6. Are you doing retrospectives after a release or at all in your project?

7. Are you using a version control system? (CVS,SVN,GIT,…) Which one? Are you using branches etc. or only one line for development?

9. Are you writing unit tests for your code? (junit, phpunit,…) Are you doing automated UI-tests? (With for example Selenium)

10. Are you doing peer reviews of new code? If this is the case, are you doing it only for new developers or for “old devs” too?

11. If you are writing unit tests, do you also do continous integration on a daily or per checkin basis?

12. Are you doing early releases or fast iterations to get your code as soon as possible to your users or do you have rather long release cycles?

13. Is there collective code ownership or do you have code that only one or a few people are “allowed” to touch? How many people are able to make changes everywhere? (how good is codebase known to the team)

14. Are you using a bug-/tasktracker to handle user requests like bug reports or feature requests? Which one?

15. How are you planning your releases? Do they just “materialize” or do you use user stories or similar techniques to plan your iterations/releases?

14. How are you documenting your project? (Inline documentation like Javadoc, Wiki, Tasktracker like Bugzilla/Jira,…)

15. Do you have regular team meetings like “daily standup” meetings (which are of course difficult in distributed teams)? Maybe scheduled IRC meetings or constant communication via chat,IM,Skype,…?

16. Are there chances for face to face communication in the project for example via team meetings in real life?

17. Are there developers who are co-located (or at least live close to another, so they can meet if necessary)

18. Are you using pair programming via internet or co-location?

19. Are there any other things you’d like to mention in context of agile development and your project?

Thanks for your time!

The talk will be in german, but after the conference, I’ll write a blog post here in english.

You can download it at:

ftp://ftp.stw-bonn.de/pub/froscon/2009/prerelease_please_do_not_redistribute/sa/hs12/…

It is a nice talk and worth watching! (Language is english!)

http://google-opensource.blogspot.com/2010/03/students-apply-now-for-google-summer-of.html

And check the available projects and tasks :-)

See the video here: Froscon “Open Source Projekte starten und am Leben halten” auf Vimeo

http://code.google.com/soc

Citation from the gsoc homepage:

About Google Summer of Code

Google Summer of Code is a global program that offers student developers stipends to write code for various open source software projects. We have worked with several open source, free software, and technology-related groups to identify and fund several projects over a three month period. Since its inception in 2005, the program has brought together nearly 2500 successful student participants and 2500 mentors from 98 countries worldwide, all for the love of code. Through Google Summer of Code, accepted student applicants are paired with a mentor or mentors from the participating projects, thus gaining exposure to real-world software development scenarios and the opportunity for employment in areas related to their academic pursuits. In turn, the participating projects are able to more easily identify and bring in new developers. Best of all, more source code is created and released for the use and benefit of all.

To learn more about the program, peruse our 2010 Frequently Asked Questions page. You can also subscribe to the Google Open Source Blog or the Google Summer of Code Discussion Group to keep abreast of the latest announcements.

Keep in mind:

Mentoring organization applications must be submitted by Friday, March 12, 2010 at 23:00 UTC.

I am really glad that oracle has decided in this way!

It’s more fun if you don’t do it alone

As mentioned in the second blog post, open source software exists because passionate people join in team and produce software. Working together is a great aspect of being in an open source team. If you have never worked in a small/medium sized team with nice people, then you’re missing a great opportunity. When you’re working in and with the team and you’re spending hours in mailing lists and chats, then you’ll have the chance to form friendships with your team mates. Team meetings are also a nice way of getting to know each other. I’ll write a separate article about this later. So please keep in mind: Working alone is boring. Collaborating is fun.

Training social skills

Rumors exist that IT affine people are socially “not that well educated”. Participating in a project is your chance to change that, if you’re belonging to this group. ;-) When you’re in a team, sometimes conflicts happen. Especially when you’re the project lead then you’ll have the chance to exercise your conflict solving skills. Small teams are normally pretty easy to handle, but starting at medium sized teams you’ll see several kinds of internal conflicts or struggles, which are perfectly normal when a group of people comes together. There are always some people who don’t like each other or can’t integrate in the group. If you notice that, then you can try to help in solving the conflict. This is great for training this kind of problem solving. Things like this will happen in your work life anyway, so it’s better to practice when your career is not in danger, when you mess things up. ;-) So as we all know, social skills were getting much more important in the last decade. In short: Being in team can improve your social skills – try it!

Communication training is expensive – helping in a project is free

All well running projects require a lot communication, either internal or external. Especially for non native speakers, it’s a chance to improve their English. Most projects use English as their default language to make it easy for developers from any country to join the team. If your project has no one who handles the external communication, it’s your chance to step up and do it yourself. It’s a good training and depending on your user base you even might get some constructive feedback on your announcements and other form of communication. Long story short: Communication is of great importance in every aspect of our daily life – take your chances to practice…

Conclusion

Working in a team is the fun part. Get something from your open source involvement back and improve your social skills. You can even train your other communication skills and your English, if you’re not a native speaker. Open source is not only for students and unemployed people. Improve yourself by helping others…

Disclaimer: I am not a lawyer nor a license expert. Use these information at your own risk. Corrections are welcome.

Don’t invent your own!

First I’d like to point out that it’s in most cases a really bad idea to invent your own license! It may sound easy to write your own, maybe it’s even legally binding in your country, but due to the internet, your users will be located all over the world. Creating a license that is legally binding in the most areas of the world is pretty hard. If you are not a lawyer that is specialized in international law, then don’t do it! There are many licenses available on the internet that should cover almost all needs. If you have more than one license that you’d like to use you can even do multi-licensing like for example Qt did for quite a while. A wrong written license may even turn out to be pretty expensive if you get sued. For example in Germany you may get sued if your software damages the computer of a user even if you have put it under an open source license. In short: If you think about writing your own license: don’t!

More restrictive licenses

The most known license is probably the GPL. It’s the license of the linux kernel and according to the wikipedia article, it’s the license of ~60% of all software packages under free/open licenses. The GPL belongs to the group of the restrictive licenses. They are restrictive in the way that the source has to be free. This is what you might want for your project if it’s a stand-alone application. When you’re writing a library of a framework, then the GPL might not be the best solution. The problem is the formulation that “derived work” of the GPLed product needs to be GPLed as well. This line between “derived work” and just using the software is hard to draw sometimes. So it may be that you force your users to a specific license, which is bad if you try to write a general purpose software. There are dedicated licenses like the LGPL which are made for these products. You can include LGPL software in your differently licensed software. To summarize it: GPL and similar licenses with their copy-left principle may be suitable for your project, but be aware of the consequences.

More freedom, but keep my name in – license

Another kind of license are the Apache style licenses. The key differentiation between GPL and the Apache licenses is that your users can use the software for everything as long as they keep the your source under your selected license and maintain the links/hints to the you (the original author[s]). The problem is that GPL V3 software is not compatible with the apache V2 license. This means that you can’t use any GPLed library for example for your project in this case. It was a goal in the GPL V3 creation to be compatible, but the end result didn’t achieved this goal. To summarize it: Apache style licenses are easier to use for users, but may be painful for you because of incompatibilities with GPL.

Do whatever you like – license

There are  a few licenses out there that are known as “really free” licenses. The BSD style licenses are the least restrictive ones. All they require is that the original source code remains free, but anyone can use the BSD licensed work, modify it and redistribute it under another license or use it in any other software, no matter which license it is placed under. The BSD style licenses a used in a lot of semi-propriatary products and in the *BSD projects like OpenBSD etc. So please keep in mind:  BSD licenses are focused on freedom, so things may happen that you don’t want.

Relicensing?

What if you want to change the license of your software after a while? This may be pretty hard, because you have to get the permission of every contributor whose contributions are still present in the project. It’s not easy but not that uncommon. To be able to do this, you have to track the contributions closely. It is effort, but it’s not unlikely that a license change may happen. What if a contributor is not agreeing to change the license? Then you’ll have to rewrite the contributions or cancel the license change. You can prepare yourself for this and ask a permission of each contributor to change the license later. Some projects do this and many commercial based projects too. Another way of dealing with this is, is to don’t include patches from people outside the project and rewrite patches instead of applying them. The disadvantage is that people won’t be as motivated to submit patches to your project. Be aware of that. Long story short: Changing the license is hard if you are not prepared for it. Better incorporate this soon in your patch applying procedures.

Conclusion

Which license you should take depends heavily on the kind of software that you are writing and the kind of trade-off you are willing to make between freedom and usability in the commercial space (or in differently licensed projects). It’s not an easy choice, because it will have effects on the libraries you can use, on the way you can deal with source contributions etc.

There are a few sites with more or less serious guides that try to help you in the selection process:

• http://pgl.yoyo.org/lqr/
• http://home.ccil.org/~cowan/floss/
• http://swan.iis.sinica.edu.tw/LicenseWizard2EN/LicenseWizard.cgi

(This is a reinstall of wordpress, because I messed something up in the first install…)