 |
|
 |
 |
|
|
 Daniel Brookshier's BlogDecember 2004 ArchivesGELC New Projects Nov 10thPosted by turbogeek on December 29, 2004 at 01:32 PM | Permalink | Comments (0)It's time to welcome new projects into the community. They need help and volunteers to get things going. Please email there owners and ask how you can help. Here are the links and descriptions to the latest additions to the Global Education and Learning Community (GELC). Please look through the summaries (from their project page). If you find something interesting, join their projects and help out. This is a place to share some of those funny and interesting code examples. If you have some of those examples yourself then you have likely forgoten some of them or would have liked a resource like this. If you are teaching a class or talking to a Java™ group then please come visit and share. What makes a good code example for codefun? It should be interesting or have and interesting story to go with it. The actual code should be good, bad, elegent, or funny. Where applicable compiler messages can be included. Our mission is to extend the SVS (student administration system) of our school (HTL-Leonding, Austria) This is an academic project for studying Java Refactoring in improving the software quality. Java Starter Kit is a hands-on project for java newbies. it covers all java api's & technologies. GeneticsJ is a metasuite to wrap around a multitude of applications already available under GPL, but also to provide extra functionality and seamless integration of these tools. The primary motivation is for the development of a population genetic analysis framework, but may also incorporate other fields in future.
JStateSim is a framework project for the execution of Discrete Event Simulations. Murphy's Law and Open Source Software DevelopmentPosted by turbogeek on December 29, 2004 at 09:31 AM | Permalink | Comments (6)Q: Why do open source projects fail? You may run an open source project or a part of one. Odds are, things are not as rosy as you expected. Where are the volunteers? Where is the community? How can I make this project succeed? The simple fact is that open source is not a guarantee of success. The real successes, like JBoss, Apache, Linux and others comes from the right mix of ideas, support and work done by members of the project. But what is required for success? To answer this question, let’s look at why open source projects fail. Using a Murphy’s Law approach can help get a grip on failures, their cause, and even a solution or two. Knowing what can go wrong or even how things succeed can be used to keep a project on track. With thousands of failed projects and new ones coming on line every day, finding failure is easy. Time to start listing the failures you see in open source software and looking for ways to get around or to avoid failure all together. Murphy’s laws lead to a preventative or at least failsafe solution based on knowing that failure can occur. So, if an airplane engine can fail because of one of a hundred possible reasons, odds are if you have two engines, only one will fail at a time or at least run long enough to get back on the ground. Knowing the failure gives you a chance to look for solutions, like an extra engine, over building, backups, alternative paths, etc. If it can go wrong, it will, so prevent or have a way to live with the failure. This is very simple logic that can be applied to open source development. Law Zero: People are the source of all failures, especially when they are perfect People do the work and people make the choices. If your tools are poor, that’s because people built the tools and people use the tools. People are not perfect and thus most things we create have a flaw or two. It is not just stupidity either. For the most part we are all quite smart. The problems come from assumptions, shortcuts, emotion, politics, and of course limited time and resources. Add to this an inattention to a missed detail and working past our limits, you get an almost infinite variety of errors. The worst offences are times when errors and the failures they can create are discounted. Looking at open source, we expect that because there are great projects like JBoss, we can expect the same for any idea. The facts however, from my point of view as a community leader at java.net, is the likelihood of any one project reaching greatness is very low. It is true for most communities and other open source sites like SourceForge.net. There are two ways to reduce human frailty: Reduce the involvement of people or use process. There is of course a hidden solution: Use people that make fewer errors. How do we prevent failures of open source projects? The answer is that it is a mix of things. Failures come from many sources for various reasons, therefore we need a mix to prevent a critical mass of failures from stopping success. The remaining laws should be looked at as a set. Each law is important in some way to a project. No one failure, once corrected, guarantees success. Also, some of these failures happen at different points in the lifecycle, so they are not as problematic at other times. Some of these are important throughout the life of the project and need to be a priority in the project’s management. As a project owner or a member, use this list to help start your project and throughout its life.
Law 1: The worst project starts with a good idea This law is so true it hurts. If you look at java.net or SourceForge, you will see the litter of hundreds of good ideas and no source code. At java.net, in general we approve most projects and many are based only on a good idea. Some succeed, but many more fail to grow. In the Global Education and Learning Community (GELC) we have an incubator area for new projects. We do this because of this simple law. It helps us manage the dead wood and isolate them from active projects. Most of the projects are dead soon after they are proposed. The primary reason is that many think that the community will come to their aid and help their project become a reality. The fact is that there is usually not enough of an idea worth considering. Why is a good idea a source of failure? There are quite a few reasons, all of which are based on human psychology. People in general hate the idea of work. Even worse they hate working without direction (many failed projects are proposed in less than one badly worded sentence). To add to the problem, many ideas are just that, an idea and nothing more. Very often the proposition fails to account for the fact that a solution to a problem has never been found and is likely impossible or very hard. Like proposing software to create world peace, nice idea, but how do you implement it? Developers are just not attracted to empty ideas. The best way out of this fact of life is to start a project out with an already working version or a detail design. Ideas alone will only attract flies. For many, what this means is that the originator need to build the first version or a very functional prototype. Law 2: Build it and they will come and do nothing
Admittedly, this law contradicts open source law 1. But if it is a good law, it is worth contradicting.
Ant is a simple idea, very useful, clear in its execution and its documentation. Better yet, Ant had the ability to be extended by adding new commands. Ant is now thriving as new technologies and techniques extend its usefulness. The open source community around Ant is now huge and quite successful. Not all projects will attract developers or even users. The simple fact is that we need several things to make a project inviting. One of them is that the software is useful and in a complete contradiction, annoyingly incomplete. Unless there is a need for growth, there is no reason to add code to an open source project. Ant is a great example of need and a place to hang the solution. Lots of volunteers have extended Ant to make it fit their needs. Without this need for change, there are fewer developers to be intimate with the code and thus fewer people to fix bugs and support users. It is a cascade of possible failures if there is no reason for developers to work on the code over time. There are also a slew of flawed applications that you would be insane to add to because of their complexity. Some open source is just plain garbage. Why would anyone want to make garbage smell nicer? It’s still garbage. So the code has to be worth fixing or extending in the first place. Good design, well-written code, clear documentation, a useful idea that people need, and room to grow. Together they will make a great open source project. Loose any one of these, and you are on the road that can lead to failure. Law 3: Membership has no privileges Many people believe that joining an open source project means that they can request new features, or even add the features themselves. In simple fact, membership usually means you have the right to complain. Of course, with most complaints, there is no guarantee that you will be heard. Most successful projects have hurdles to getting your way. Open source is usually controlled by a tightly knit group of developers. They usually have a process to review ideas and come to agreements before change is allowed to occur. Of course if you are a member of the ‘inside’ group, change is a little easier to do. But if you don’t play by the rules, you could be kicked out. The different levels of membership from observer to developer to project owner are a key part of open source development platforms. Projects that do not regulate privileges have two types of failure. First is the obvious one of uncontrolled change. The second is less obvious. People act differently when trusted. If you earn trust and are granted authority people act a little more responsibly because they fear a loss of authority. When granted authority without earning it, there is less value put upon it because there was less work to get it. Sometimes it takes years to get commit status on a project. The key is to follow the rules and work hard at gaining trust. This also ensures that you become not only familiar with a system, but that others can trust you and that reduces their need to micromanage your efforts. Law 3: Open source is closed until further notice The ‘open’ in open source software does not really mean open unless it’s what we want you to see. Open source has so many hidden rules that it is hard to play the game sometimes. It is a mistake to believe that there is a hippie like free love and software society behind successful open source projects. The fact is that ‘open’ only applies to your ability to read the code and to use it as you see fit. Modifying the primary code base is only at the will of the owners. Although we like free love, we use protection in the form of trust and rules to prevent unpredictable change. The problem is that when a project is popular, there are a lot of people that would like to add to it. The reality is that gaining trust is a long process so adding new developers to a project is not a viable solution. There is one way out of this dilemma. Simply you need to have an extension mechanism. This allows another developer to create their own project and just concentrate on extending rather than modifying the core code. Not all applications are capable of being extended, but those that do are better off with a strategy that offloads extensions to other projects. Look at NetBeans, Eclipse, and Ant for great examples of this. Law 4: Most volunteers are just lookieloos
A lookieloo is just someone interested in looking and providing nothing. The term comes from realty agents and refers to people that flock to open houses just to see what is inside without any intent in buying a house. It is also a term used on freeways as a term of scorn for those that slow down on the freeway to get a good look-see at a traffic accident, only to slow traffic for others. Simply, most volunteers to open source projects supply about the same value. They waste your time and provide nothing.
There is really little you can do about this problem. The key is to understand that lookieloos are real and that they do not represent true value. However, do not assume that they are permanent lookieloos. Some can become active members in the future. Thus, despite their annoyance, it is best to keep them around. Avoid having rules that cancel memberships for inactive members. Law 5: Managing open source volunteers is like herding cats If you look at the change logs of most successful open source projects, you will only see a few names and in many cases, just one name. The reason is that a small group or just an individual does all the work. The key reason is that volunteers are just plain hard to motivate. Motivation is hard! Back to herding cats, there is little that really motivates a cat that can be used to train it. People are really very similar to cats. Look at what open source participation offers: no cash, little recognition, and hard work. Not much more than a sense of accomplishment and many can get that from watching the 10th season of survivor. Where do volunteers come from? A lot of volunteers come to projects because they need something. They have a scratch that needs itching. Some are willing to contribute to make the changes they need. But this is a mixed blessing (see law 6). Law 6: Volunteers will work on really annoying problems – just not the ones you want them to work on The best work you can get from someone on an open source project is when the developer has a problem that affects them personally. The problem is of course is that it may not be your problem or a priority to you or a majority of users or team members. This is back to herding cats (law 5) because the cat is just going to go its way and is little concerned with your priorities. If you are managing the project, you got to take what you can get if you can. If a developer has working code and it does not get in the way of other changes, go for it. If you are in charge of an open source project, use barter to get some work done in trade for the developer working on a favorite addition or fix. Trade a developer’s ‘must have’ for something off the project’s priority list. If you are a developer trying to get approval for your off-topic fix, go for a similar offer to work a priority item. Law 7: A lack of documentation and examples will waste your time More work equals less work. The more you put into explaining an open source project, its design, its code, its bugs, its use, and its future, the less time you will waste managing developers and users. The problem of course is the most of you are coders and not writers of manuals. Worse still, though we may plan our development, we are bad about keeping design docs up to date (see law 8). One real trick is to write everything down and publish it as part of the project. A bit difficult to pull off for many, but it can be done if you have the will. There are a few possible ways to tackle this problem. First is the Wiki. A Wiki allows for more people to participate in developing the documentation. It is sort of documentation by opportunity. If you find something missing, it is simple to add a new entry or add/modify an exiting entry. Less trouble than checking in and out documents and no issues with incompatible editors, so a good solution for many. Wiki is catching on and becoming the primary way to document many projects. A side issue of course is that everyone needs to know how to use a Wiki (What came first, the chicken or egg? Why the egg, because it must first exist!) . Wiki is simple, but it is still a different medium that is in no way like using something simple like a text editor or as full featured as a word processor. Another way to document a project is with email list groups or forums. Usually there is enough dialog between developers and users to document both the code its use. As a searchable source they can help make a reasonable bit of documentation. However, the information should be moved out of these mediums to a Wiki or printable documentation. A person should be able to look at the relevant documentation (Wiki/html/text) for 95% of what they need. Law 8: Open source documentation is a death of a thousand cuts Open source documentation, for the most part, sucks. A large part of this is that open source projects are usually a moving target. Each change in the code may cause a change in the design, the code documentation, and the user documentation. Keeping the docs up to date is a constant problem. One way to get more documentation and to keep it up to date is to ensure that each change or added feature is documented as part of your process. Many projects rely on issuezilla or other issue management system to document changes. The problem however is that issue systems are usually not easy to search and rarely answer the questions asked by developers or users. Changes, if they change any behavior should cause a change in both design and user documentation. Law 9: Only a good process will create a successful open source project, but most open source developers hate process Many believe that anarchy is the norm in open source. The truth is that most projects are run by the owners acting as dictators (Linus Torvalds is an excellent example). The open source process in most projects consists usually of an issue, then a proposed fix, a review, and if the review is positive, the code is committed. In some cases there is more to this, like requirements to add to JUnit tests, documentation, and others. The owner (like Linus) and lieutenants (Linus has a group of trusted developers that have similar philosophies and are highly trusted by him), set these rules and act as the primary reviewers. Process can be complex or simple. A project might require UML documentation or to follow a specialized release schedule. The more process you see, the more stable the code is. This is something that is almost odd given that so some projects and the public perception of open source is anarchy. But projects based on pure anarchy are not successful. Why should they be? No one likes unpredictable change. But many hate process. We might think we are smart enough without getting approvals from the key developers or that certain rules do not apply to us or this or that change. A lot of developers are drawn to open source because they hate the slow process they are exposed to at work. We see open source as freedom. The reality is that process, even in small amounts, when added to software development can greatly improve things. Yes, a good developer might be highly productive without a process, but teams are less so. The simple reason for this is a way to increase understanding and ensure some unpleasant tasks (like documentation) are performed. A single developer might be able to keep it all in their heads. Add one or more people and you get a decrease in understanding. Add users and the problem gets worse. Include the fact that the team is geographically separated and face-to-face meetings are unlikely, Process is for groups. Discipline is for the individual. We need a lot of the first and enough of the second to ensure that the process is followed. But what of open source anarchy? Anarchy is often on the front end, with a person that sees a need, creates the first version and then opens it to the community. After that, process needs to follow if others need to be involved. Exceptions to this rule are abound, but these are projects that are still run by a lone developer. Isn’t anarchy what open source is about? The freedom to do what is right! Do what you want, ou are smart enough, right? Well, as said, anarchy happens, but look at the successes in open source and you will see leaders, communities of like-minded people, and process. The simplest process in open source follows this simple set of rules:
Law 10: Power corrupts and absolute power stagnates projects I hate to say it, but most lone wolf developers are horrible at understanding how other people think and thus end up writing for themselves which makes it even harder to understand (the worst is someone with a perfect memory!!!). The lore of the great hackers is filled with stories of the unencumbered developer creating a great piece of software. There are also horror tales about the teams that had to take over such software that was almost impossible to understand. It is the transition that can kill a piece of software. But in open source, it is possible that the great hacker never releases control of the project. I have seen dozens of projects that have just one person authorized to modify code, the original owner of the project. There are two reason for this. The first is many of the other laws is in affect and no other developers are remotely interested. Likely this is related to how the project is documented. The second reason is that the developer is not allowing other people to touch code in fear of change and fear of comment. I use ‘fear of change’ and ‘fear of comment’ because these are probably two of the most visceral emotions in developers. We hate it when someone changes our code and worse we when someone talks badly about our code. We have a fear that someone will find our inelegant hacks or destroy our elegant ones. Try it. Just pick a random piece of someone’s code and call it a pile of Christmas dog vomit and see what happens. This problem with change is we put our sweat into the code. Any change threatens our labor. There is inertia that makes us panic when someone changes the direction of our code. It could be good code or bad and we will avoid change before even considering why a change is being proposed. Look at most arguments from original developers. They are mostly negative about why a change should not be applied. The solution is to just not let it bother you. If you look at such change as improvements to your code, the changes are easier to take. The whole reason for opening up your source to community development is to get other peoples wisdom. Take it and use it to better yourself and your code. There is an opposite problem with this law as well. If you imagine we hate others changing our code, the other developers are often reluctant to make the changes. Simply, some people are afraid of our response. If you have been burned by someone maligning your changes as a knee jerk response (usually with a lot of venom), you are not likely to submit changes. The solution to this problem is to make sure there is plenty of commentary on your project about obvious changes and that there is always a need to improve the code. Make it easy for a developer to know that changes will be accepted if well thought out. It never hurts to assign an issue to get someone thinking that changes are acceptable. Summing up The difference between success and failure is sometimes slight. But I really am surprised by how many times the reason for failure is obvious. Recognizing the source of failure is just half the job though. Success takes planning and a lot of hard work. Luck is all about being prepared and ready for the good and prepared to dodge the bad. Some of you may disagree with some of my reasoning. I can almost guarantee that you base the disagreement on something that occurred in your past. Well, history teaches us many things, but it can lie when it comes to why things succeed or fail. Just because something happened in the past does not make it true in the future. There are too many variables. Basing a solution entirely on history is not enough. This is really another law: If it happened once, it is not going to this time – especially if you are sure it will. Look to what works most of the time, rather than single examples. But, be ready for new failures and try to predict them before they occur. That’s a start at the Murphy’s laws for open source. There are a lot more that we can get to later. If you would like to suggest a law of your own, please write me at Turbogeek @ cluck. com. Want more Murphy? Take a look at one of my older articles: http://www.informit.com/articles/article.asp?p=26441&redir=1 New projects at GELC: JXTA P2P Bioinformatics and Neural NetworksPosted by turbogeek on December 14, 2004 at 08:03 AM | Permalink | Comments (0)
Two more projects have been added to the Global Education and Learning Community (GELC) at java.net. This week we have a new project based on JXTA P2P for bioinformatics. The second project is neural networks that will help categorize poems after their authors. Take a look and see if there is a project you are interested in and email the owners on how you can help out. Remember this is a community and participation is what this place is all about.
Chinook is a peer-to-peer (P2P) bioinformatics service. The goal of the Chinook platform is to facilitate exchange of analysis techniques within a local community and/or worldwide. Chinook operates by turning command-line applications into services which are broadcast over a virtual network. Currently, there are over 25 analysis services that have been made "Chinook-ready". These range from alignment to regulation prediction algorithms. Furthermore, Chinook is designed to make it extremely easy to add new services. Chinook clients can be operated from Java, Perl, or within applications like Sockeye. (And soon Pegasys, and OrthoSeq). All user's guides and manuals are currently available via checkout of source.
GELC New Projects Nov 10thPosted by turbogeek on December 08, 2004 at 12:23 PM | Permalink | Comments (0)It's time to welcome new projects into the community. They need help and volunteers to get things going. Please email there owners and ask how you can help. Here are the links and descriptions to the latest additions to the Global Education and Learning Community (GELC). Please look through the summaries (from their project page). If you find something interesting, join their projects and help out. This is a place to share some of those funny and interesting code examples. If you have some of those examples yourself then you have likely forgoten some of them or would have liked a resource like this. If you are teaching a class or talking to a Java™ group then please come visit and share. What makes a good code example for codefun? It should be interesting or have and interesting story to go with it. The actual code should be good, bad, elegent, or funny. Where applicable compiler messages can be included. Our mission is to extend the SVS (student administration system) of our school (HTL-Leonding, Austria) This is an academic project for studying Java Refactoring in improving the software quality. Java Starter Kit is a hands-on project for java newbies. it covers all java api's & technologies. GeneticsJ is a metasuite to wrap around a multitude of applications already available under GPL, but also to provide extra functionality and seamless integration of these tools. The primary motivation is for the development of a population genetic analysis framework, but may also incorporate other fields in future.
JStateSim is a framework project for the execution of Discrete Event Simulations. New Education Projects at GELCPosted by turbogeek on December 08, 2004 at 12:14 PM | Permalink | Comments (0)Many more projects have been added to the Global Education and Learning Community (GELC) at java.net. Again we have quite a mix from a student's exploration into Java, a Tapestry project and even an attempt to create a web interface in the style of one of my favorite BBC programs "Connections" (have James Burke drop me an email if you know him). Take a look and see if there is a project you are interested in and email the owners on how you can help out. Remember this is a community and participation is what this place is all about. As an editor's note, I am writing this in Hamburg, Germany where I am teaching UML. Last week I was in Durban, South Africa and the week before in Pretoria, South Africa. I have to say that though there are slight differences in approach and assumptions, we all communicated quite well. Even in Africa, where many native Africans are catching up from the Apartheid days, technology and software is what makes the world work and is becoming a common way to communicate. If you are in Germany or South Africa, drop me a line and let me know how you are using java.net. I'd love to hear from you.
X-Log is a powerful blog and fotolog system based in Java.
Practice Java programming, giving a opportunity to grow up in Java. lobalcode turma3 Paladin's first Java project.
Tapestry web component examples
This project contains resources for learning how to use Tapestry's Java Web Components.
Argo Navis is a e-learning software developed with open source Java tools and frameworks.
This project creates detailed how-tos to help undergraduate students learn Linux system administration through hands-on exercises on Sun JDS.
meeting oriented personal organizer , it manages a contact list , a calendar , a meeting scheduler , an attachment manager and a mail module | |
 java.net RSS Feeds
|
