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.
Proprietary Software Development
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.
Debian
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).
Nice article, I completely agree.
One thing: do you have a link to the discussion happening in Debian?
It’s a private discussion so there is no link. But I don’t think that particular discussion is anything special, no-one said anything that hasn’t been said before.
It was just the last example of a series of discussions I’ve been seeing for ~20 years that inspired me to write.
You overlooked another advantage of using open source tools:
1) documentation is (usually) readily available, and if it’s a popular tool (eg. git) it’s available in a wide variety of forms from O’Reilly books to websites to blog posts to stackoverflow Q&A. If it’s less popular you might be forced to read the code to figure out the corner cases, but… you *can*. Though ideally you should then write up your findings into some documentation (or even just a StackOverflow Q&A) somewhere.
2) time spent learning a FOSS tool doesn’t become completely worthless if you switch to a job where they’re not using that tool – you can continue using it yourself, privately, if you wish – an option not available without spending $$$$ on ClearCase or other proprietary tools. Also, FOSS tool skills are, IMO, more likely to be re-used in the future if only due to their low cost.
pjz: While the availability of documentation is a good thing it’s even better if people already know how to use a tool. For example I would be much more productive on a Linux system with all the man pages deleted than on a Windows system with full documentation.
I agree that for the employee it’s better to gain skills that can be useful elsewhere. That can be a feature that attracts talented staff (companies using strange and unusual products end up hiring a lot of people who have no career aspirations). But the benefit is less direct for the company.
For a FOSS project the benefit of using common tools is greater, as there is no money on offer it has to be fun and easy.
There are some projects, like the BSD-based privoxy-squid-surfwall, or making the cucumber-linux metapackages in order to set up a reasonable Debian-software-selection for running on thin-clients, which is interesting, because it’s related to embedded-linux, both are pretty much stalled currently.
The cheapest way to become a full member is probably learning to do packaging-work. Most people rely on ready made packages, I do myself most of the time.
At the local Linux-User-Group we are going to have a project to build our own drivers for Miracast. The Linux-Drivers, for Miracast screencasting-devices are called Miraclecast. See there:
http://www.freedesktop.org/wiki/Software/miracle/
The details there told me, it requres systemd version 209 at least, which should become available as an experimental build very soon.
Maybe when we succeed to build those drivers, I will try to make Debian-packages from them, the requred library also. It would be a good thing, that really adds functionality to Linux, that ist currently available for Android only.
Other ideas are packaging gnofract4d, which is easy to build, or RPCEmu.
Andrew: Interesting comment, but how does it relate to this blog post?