Linux, politics, and other interesting things
On many occasions I’ve seen discussions about the background knowledge that people are expected to have to contribute to FOSS projects. Often the background knowledge is quite different from the core skills related to their contributions (EG documentation mark-up skills required for coding work or knowledge of code required for writing documentation). One argument in favor of requiring such skills is of the form “anyone who’s good at one aspect of the project can learn skills for the other areas”. Another is of the form “anyone who has time to contribute in one area has time to learn all the other areas, anyone who doesn’t want to learn is being lazy”.
I think it’s reasonable that someone who is considering donating their time to a project would want to start doing something productive immediately. If someone has to spend many hours learning how things work before contributing anything of value they may decide that it’s not a good use of their time – or just not fun. Also if the project is structured to require a lot of background knowledge then that will increase the amount of time that long-term contributors spend teaching newbies which is another way of sucking productive energy out of a project.
I don’t think it’s lazy to want to avoid learning unusual tools before starting a project. Firstly there is the issue of wanting to make productive use of your time. If you have a day for FOSS contributions and you can choose between spending 6 hours learning an environment for one project or 1 hour for another project then there’s a choice of 2 hours or 7 hours of productive work. Someone who has the luxury of being able to spend several days a month on FOSS projects might think it’s lazy to want to make effective use of 1 day, but there are a lot of people out there who are really busy and can only spend a few days a YEAR contributing, spending half a day learning an obscure development environment or documentation system can take a significant amount of someone’s yearly time for such work. To make things even worse some of the best programmers are the ones who have little free time.
For documentation MediaWiki (the software behind Wikipedia and Wikia.com) has a lot going for it. While it’s arguable that it’s not the best Wiki software out there (many people have wanted to argue this with me even though I don’t care) it’s obvious that MediaWiki is the most widely used Wiki software. If you have documentation stored in MediaWiki then most people who have any exposure to the IT industry, the FOSS community, or the Internet in general will already have experience using it. Also Wikipedia serves as a large example of what can be done with MediaWiki, there have been more than a few occasions when I have looked at Wikipedia for examples of how to layout text. Some people might think I’m lazy for never reading the MediaWiki documentation, but again I’ve got lots of other things to do and don’t want to spend a lot of time learning about MediaWiki instead of doing more useful things like creating content.
Project source code should be as consistent as possible. While large projects may have lots of modules and dependencies it’s best to try and keep them all in one place. If your project depends on libraries of code from other sources then it’s helpful to distribute copies of those libraries from the same location as the project source – particularly when the project depends on development versions of libraries. Then if there’s any mismatch between versions of libraries it will be a clear unambiguous bug that can be reported or fixed instead of being an issue that requires checks of what versions everyone is using.
One thing we should aim for in FOSS projects is to get the “long tail” of contributions. If someone spends a day fixing bugs in a dozen projects to get their own system working as desired then it would be good if they could submit patches without excessive effort at the same time.
This doesn’t just apply to FOSS development, it also applies to a large extent to any collaborative project on the Internet. For example if I was to start a Wiki for fans of a sci-fi series wikia would be the first option I’d consider because most potential contributors know it.
I’ve seen all the same problems when developing proprietary software. The difference is that money and morale is wasted instead of contributions. Often in commercial projects managers choose products that have a good feature list without considering whether all their staff need to be retrained. Programmers can usually train themselves so it’s often a hidden cost, the training is paid for in lost development time (both directly in time spent learning and indirectly when people make mistakes).
One significant advantage of using free software on Windows is that programmers can play with it on their own. For example I’ve never done a fresh installation of SourceSafe or ClearCase, but if I was going to work on a project that involved Git or Subversion on Windows then I could play with it and learn without risking disruption to the rest of the team. If commercial software is to be used then being common and relatively cheap is a significant advantage. MS SourceSafe offers significant benefits over most version control software on Windows simply because the vast majority of Windows developers have already used it and because it’s cheap and easy to setup a test instance if necessary.
I don’t care about the success or failure of proprietary software projects in general (I only care when I’m paid to care). I also don’t expect that people read my blog with the aim of getting advice on running successful proprietary software development projects. This section is merely to illustrate the general nature of such wasted effort on collaborative projects – and I should put my observations of failing proprietary software development projects to use.
Some Debian Developers are having a discussion about such things at the moment. That discussion inspired me to write this post. But I’m mostly writing about my experience over the course of 20+ years working in the IT industry and contributing to FOSS projects – not in a direct response to the Debian discussion (most of which I haven’t yet read).