Document Actions
FOSS Knowledge Transfers
FOSS developers have a huge advantage over proprietary software developers in that you have access to the development of the tools and libraries you use. This includes bugs, project direction and insight from the main developers.
I'm getting back into development working with Plone and Zope3. So here's how I go about it, and like most others, there isn't anybody around me working with it.
I don't want to simply know how to use the tools, and libraries to write basic applications. You should be able to do that with the docs and tutorials provided by most projects. I want to understand best practices and the design of them. At first, to at least understand what the direction of the next version will be, and then to be able to contribute towards development and direction of the next version. Even if it's just at bug reporting and feedback on proposals.
Why is this important? Most serious projects need to be maintained and improved. If you're using frameworks and libraries, then if your project is not in line with upstream, you'll be losing more and more of the benefits of collaborative development of FOSS. You may end up duplicating work, or not be able to take advantage of the new features in new versions. If you don't even file bugs, then if nobody faces the problems, maintenance of them is all on you.
You also want to tune in, because there is a lot of tips, links and other experiences that other more experience developers share. You can then learn more about what tools they use, and their development environments.
So how do I start?
Subscribing to Mailing Lists
I will usually subscribe to a few project related lists:
- User lists if it's also used by end users, and for end user questions
- Developer lists (general and also components I'm interested in)
- Commits lists - a list of latest changes in the project code repo
The user lists is where you may spend a lot of time in, initially for basic knowledge of using the tools and libraries. It's a quick way to gain answers and insights to common questions, simply by lurking. You're also likely to get a favourable and insightful response to questions about basic understanding on how things work.
Developer lists provide a wealth of information on various bugs, design decisions and build failures of unit tests or compilation. This is where you get a better understanding on what's wrong or lacking with the tools and libraries you're using, and what the develoeprs are doing about it. Knowing about the problems in advance is also helpful for your own planning. Problem A is not going to be fixed until next major version, and since it effects my project, I'm going to need to do a workaround for now.
Commmits lists, are all the changes that are done to main repository and may also include latest issues. For large projects, there may be quite a bit, but usually a quick view of it, will allow you to grasp if there is anything of interest. I also find it fast to search locally and have ability to check revisions offline.
Wow this is a lot of email. Well you can filter them. I do it server side via procmail, others use gmail labels. Whatever works for you. I'll get back to how to actually read them later.
So for zope3 I have
- zope3-users
- zope3-devel
- zope3-checkins
Developer project pages
By this, I usually mean something like Trac, Launchpad or Sourceforge. Worth to bookmark this on your toolbar, as you'll need to access it often. These pages will give you a summary of the project, including milestones, design/feature proposals and most importantly a place track issues and make comments.
Planets
The collection of developer blogs is an awesome resource for understanding what more experienced developers are thinkinga about. From how they deal with some code problems or bugs, build development, tools they use, events happening, or just plain none-technical stuff.
For example in today's http://planetzope.org/ there is a quick comprehensive overview of Zope's build environment. "I want a pony: Django Cheeseshop".
An an example of none-developer related but interesting entry:
Kill Your TV by Alexander Limi
IRC
Of course there is IRC channels. These quite often are idle, but sometimes worth asking for quick directions or pointers when Google doesn't help. More importantly, you can participate in developer workshops/sprints virtually even if you can't be there, by being in the channel at the time.
Other Sources - Screencasts and Conference recordings
If you have access to broadband, these are also great resources. Most of us here in Asia are unlikely to be able to afford to attend conferences in Europe or North America where most of the developer conferences are. Luckily a lot of the presentations are recorded and we can learn from them.
Allocating Time
You (and project managers), need to be able to allocate time to be able to get the benefits of the above resources. A bad way to do things is when there are no branches. Everything is in trunk. Large projects run this way, are day to day things, badly planned and living on the edge. Quite often, they end up being abandoned as the effort to sync it to latest features in new framework (or worse.. even security fixes) become too difficult as you're 6 months behind.
Most FOSS projects are on a 6 months cycle. So it's worth developing on two branches, stable and next version. When next version of your framework/libraries are released, you'll be ready. It may also even include fixes to the bugs you had with previous version since you've submitted them either as an issue or an issue with patch. You're also able to learn and be involved in the development version. Repeat cycle. Time then needs to be allocated, to allow developers to be able to work on both branches, with priority of course on current stable branch which is usually in production use.
As for all the blogs, mail and so on. Some of them you'll deal with in day to day work, but some information such as links to video podcasts or a large patch may take longer than time available in your daily schedule. For projects I manage, I usually make sure that there is a few hours of "idle" time for people to allocat some time to reading, learning or to hack on some interesting problems. Set aside this time once a week at least to be able to keep your skills sharp and up to date. Also don't worry too much about not being able to read everything in the mailing lists, just make sure you've set aside this time each week to stay up to date on constant basis.
