1. Write less code and more documentation.
Whether you want people to use your software, or other developers to join in, the more you document your projects, the easier it will be for others to figure out what to do with them or how to extend them and contribute back.
I know it is a pain in the ass, but it's worth the effort when you have suddenly some people helping you out or cheering you up, because your documentation triggered the "ah, that's how it works" effect.
2. Communication is indeed the most difficult part.
I'd take it a little bit further though then Andres, it's not just soft skills, but also work on being conscious, tolerant and patient. Always remember:
a) eMail isn't the best and easiest way to communicate
b) People that write to you may hardly speak the language they used for the message
c) You may have received the same question many times, but for the other end it's a first. (Consider investing time in an FAQ if it repeats too often.)
Point out what might help people to solve their problem (see 1. Documentation), rather than trying to solve it all for them. Also, consider the use of alternative channels for communication (like Instant Messaging services), probably even invite developers to join for a real-life meeting. Also see 3.
3. Write code with style.
The syntax of a programming language tells you what code it is possible to write - what the machine will understand. Style tells you what you ought to write - what the human reading the code will understand. Code written with a consistent, simple style will be maintainable, robust, and contain fewer bugs.
(from "The Elements of Java Style", Vermeulen et.al., at Amazon)
I carry this little book practically everywhere.
4. Simple is beautiful.
"Make everything as simple as possible, but not simpler."
(Quote attributed to Albert Einstein)
KISS isn't quite the same, I for my part don't like things or people to be considered "stupid". Simple means also elegant, e.g. don't over-design and don't under-implement. The devil is always in the detail (which is an old german proverb).
5. Try to find a good balance between implementing yourself and adding dependencies.
You can't write everything on your own. Sometimes it is better to spend a little time to figure out if some external library may solve your problems, probably with a little bit of enhancement (try to contribute it back to the mainstream; also see 9.).
On the other hand too much libraries makes things harder for maintenance.
Try to find a good balance, or you end up with either writing too much code that reinvents the wheel, or too much libraries you have to track to be sure that everything is running smoothly.
6. You can't make everybody love it.
There will always be some people that are convinced that something else is better, because your project doesn't do a, or b or c.
No matter how much you try to explain that it doesn't make sense, they won't change their mind. My experience is, that if they are willing to contribute and enhance it, then take it seriously, if not, then ignore it.
Open Source software isn't a commercial product, but even if it would be, to endlessly add features isn't an answer, as Japanese car makers had to learn the hard way.
7. At the beginning, it is not just about selecting a license, also think about the decision making process.
Usually people think it is all about the license. I think that Apache is successful, because they have project guidelines and a well defined decision making process. This seems superfluous at the beginning when you are few (see 8.), but it may help the project to survive steady growth (also in numbers of developers).
8. Meritocracy is great, but it has some flaws.
a) It simply doesn't work when you are initiating a project, that's why they invented the incubation at Apache.
b) Don't underestimate the power of one-time unsolicited contributions.
c) Don't over-bureaucratize the decision making process, software development is a creative process.
9. Learn about licenses, copyrights and contributor agreements.
All this legal stuff is boring for the average developer. Nonetheless, if you are managing a project that is completely exposed publicly, learn how to protect your project and its developers from legal traps.
a) Netiquette: try to be kind and make clear how to be so. Sometimes we programmers like to channel our desperation into code comments, but it isn't such a good thing if certain offensive expressions end up in the code repository.
b) Licenses
Some licenses cannot be mixed, like GPL and Apache don't work together (LGPL does for some use cases). Understand what implications the license has, and make sure to pick and know the licenses of your libraries to fit with the one you use for your own work.
c) Contributor Agreements
Commitment is about trust and responsibility. Protect your project and your developers with individual and corporate contributor agreements. These agreements are not about taking rights from the developers, they are about the developers giving certain (usage) rights for their code to the particular project, otherwise completely reserving their right, title and interest.
10. Make friends, they may last for the rest of your life, projects are always time limited by definition.
While you are at it, make friends with fellow developers or contributors, or users. Not everything happens in the virtual world, bringing it to real life will greatly enhance relationships and communications. We are, by all means, human beings. We all make mistakes, we have good and bad days and we can always learn from each other in many dimensions, not just professionally by sharing code or documentation.
0 comments:
Post a Comment