Open-source software starts with developers, but there are other important contributors, too. Who exactly? Good question

Is Linus Torvalds important to open-source software? Of course. Guido van Rossum, who created the popular programming language Python? Sure! Michael "Monty" Widenius of MySQL fame? Certainly. OK, what about Robert Love? Eben Moglen? Or Jono Bacon? Who? Exactly. They latter three are, in order: the author of Linux in a Nutshell …

[Primus Secundus Tertius]

Sandwich students

A lot of the world's best software, proprietary and open source, comes from the "We had a bright sandwich student that year". Such programmers are often relatively free from the attentions of management; they are virtually ignored until it is realised they have written something brilliant, workable, and unachievable by "managed development".

[IGotOut]

There are two types of programmers...

... those that are "right" and those that listen.

Give UI's as example.

If you dare suggest a change that may make the product run better for the end user, you 99% of the time get one of the two answers.

From the listeners "Thanks for the feedback, we'll look into it". If they the choose not to, then that's OK.

Then there "I'm the programmer, I know best" is the "If you can do it better, it's open source, fix it yourself"

[doublelayer]

Re: There are two types of programmers...

And there are three kinds of suggestors: the interested, the motivated, and the demanding.

The interested describes their suggestion and leaves the programmers to think about it. Maybe it will get done.

The motivated makes the suggestion and takes up its case. If knowledgeable about the code, they may implement it themselves. If not, they still look for feedback, improve the idea, find developers who seem interested, and work to get the suggestion in there with their skills.

The demanding sometimes look like the motivated, but where the motivated interact with the other contributors, the demanding tend to have a more one-sided operation. If a problem's pointed out, they will dismiss it and tell the developer to do it anyway. If people are quiet, they will add more noise without finding out why. If they submit code, such things as reviews are beneath them.

It would help if more programmers were listeners, but there are reasons why they sometimes aren't.

[Kristian Walsh]

Re: There are two types of programmers...

I largely agree.

In the example of a UI change, the suggestions would normally be accompanied by a detailed description of what is supposed to happen, and when. Some go as far as providing graphical mock-ups.

That’s not a “demanding” suggestion, it’s one where someone is interested and motivated enough to design an improvement to the product, but lacks the technical skills to actually make that change. It takes a surprising amount of effort to define the behaviour of a graphical interface.

I’ve been on both sides of this, and the best results are when the person who made the suggestion and the person who would have to implement it engage in a dialogue to identify the original pain point and remove it in a way that doesn’t create a large amount of additional work for the developer, or create islands of “different behaviours apply here” within the application.

Sometimes, someone will insist that the one thing they use must work the way they want, even if that’s at odds with how everyone else expects, and a danger with the FOSS model is that if that pushy person can write code, then the change tends to get made to the detriment of the consistency of the product. This applies to all kinds of interface, not just GUI - we’ve all seen that one command-switch or API call that doesn’t follow any pattern established by the rest...

[steelpillow]

Users

Let us not forget the enthusiasts who work in large user organisations and go around insinuating open source stuff past the pointy-haired managers by fair means or foul. Without user adoption, there is no way to monetise. And without a bottom line, the corporately-sponsored senior programmers, GitHub maintainers and the like would be forced to go eat elsewhere.

[Anonymous Coward]

Re: Users

Amen. And even beyond getting around management, individual end users are important. Beyond the OS and browser, my most used program is KeePass which has an active user community and maintains its own forum where users and developers interact.

As a super satisfied user I am an evangelist and would consider myself and others as a volunteer PR department.

[Doctor Syntax]

A big omission: users.

If a project can't garner users it's pointless.

[karlkarl]

I'm not entirely sure on this (for some projects).

Looking at many Linux distros, they have lost a bit of focus chasing the dream of being "user-friendly". Users ask for things like graphical installers, more features, more, more but ultimately much of this is very superficial. It doesn't improve how the software is maintained, it doesn't help the fact that package managers are very tied to the internet, it doesn't solve the "billions of dependencies issue" that is cropping up.

Users also don't "get" UNIX. They want a free fun OS to play their Steam DRM Service games on. They don't really care about the quality of the OS itself. It is what has lead the OpenBSD project to say "we don't like users" ;)

Another thing is just look at Windows and macOS. They have billions of users but the software is *still* unusable for so many and getting worse.

[Doctor Syntax]

Some of us don't "get" Windows.

A Linux distro isn't a project as such, it's a collection of projects. But in terms of building a user community each one needs to understand what its particular user base requires. I've made a similar point in the past in relation to deskoip managers - an app-based manager such as Unity is useless to a user whose requirements are document based.

One thing I've never been able to understand is the number of distros claiming to be very lightweight. Is the hair shirt community really that big?

[steelpillow]

Equating GNU/LINUX with Open Source is not sensible. GNU may technically not be UNIX, but then Chromium, Apache, Firefox and LibreOffice aren't tied to GNU/LINUX either.

FLOSS apps such as LibreOffice and the GIMP (or whatever it calls itself these days) have benefited hugely by becoming more user friendly.

Moreover users are a varied bunch. Some may have befriended GNOME 3, SystemD and Wayland, others have not. Not for nothing has "enjoy the choice" become a hackneyed old saw.

[Zolko]

If a project can't garner users it's pointless.

the usual marketing bollocks: exactly what advantage is it for an open-source developer to have 10, 1000 or 1000000 users ? (apart from the dick-measuring contest POV) They don't pay so they only use resources. They complain about stuff not installing in some random setup (recently, a user wanted to run FreeCAD in Windows 8 through RDP and wondered why it didn't work !!!). They request features that some expensive proprietary software has ...

The correct thing to say is:

If a project can't garner users contributors it's pointless.

[Anonymous Coward]

The correct thing to say is: If a project is useful to 1 person it isn't pointless, even if that person is the developer. Useful could even just be as a learning mechanism, not even software that ends up doing anything.

[Peter Prof Fox]

Teaching collaboration

Should it not be de-rigueur that university-level students are taught collaboration as an important part of how to function in a rich environment? The open source-ness isn't important but knowing how to ask nicely, contribute and be a valued part of a software society are.

[Pascal Monett]

Re: Teaching collaboration

I like the idea, but schools do not teach basic human politeness, they teach technical expertise.

That may be something to change in the future.

[Version 1.0]

Re: Teaching collaboration

I wonder if I would think that the world would be a better and safer place if university students were taught how to create malware?

This could result in more malware but would probably result in an environment that was much safer because every graduate would know what is actually happening in the Internet these days.

[doublelayer]

Re: Teaching collaboration

Oh, they are. At least that's the word that gets used for it. It usually ends up boiling down to the following points, but at least you can guarantee to learn them nearly anywhere you study:

1. You will be assigned enough work for your team.

2. Someone on your team won't do any work.

3. Someone else will do work but not until the last minute.

4. Nobody likes having meetings to decide what they will do.

5. You will have to put together the pieces at the last minute from those who did it.

6. And also for those who didn't, so hope that those sections allow you to better glue together the disparate parts done in isolation.

7. Google thinks having a single document into which anyone can write helps. They are wrong.

8. If you have some mechanism for turning in members of the team who didn't work, it's easily abused to your detriment. On no account lead the unproductive one to the belief that you might use it.

9. Don't complain about points 1-8.

10. Don't complain about points 9-10.

11. Some people still think this works. It's too late to convince them otherwise.

[cornetman]

Re: Teaching collaboration

Oh God, "group work", the bane of school and university. I can't remember anything that pissed me off quite so much as having to participate in "group work".

The kids will attest to that as well having most of the experiences in your list, particularly the ones that don't want to do anything at all and leave it to the last minute.

I can see that they mean well, but they don't seem to understand what group work actually means, and the way that it is framed in schools is nothing like how collaboration works in the real world.

[Anonymous Coward]

Re: Teaching collaboration

I found this interview with Yulia Startsev about her work on TC39 (the JavaScript standard's body) interesting: https://www.youtube.com/watch?v=fEVhISYbmBQ&t=2629s

Early on in the interview she explains how critique was the fundamental way that she was taught in art school and how it was very different to her experience studying computer science that was mainly test oriented. There is a key aspect of "learning how to talk to each other" that may seem so simple yet also so difficult in times of conflict.

[_LC_]

Bug reporting and suggestions

Most software only becomes usable after ironing due to plenty of feedback.

[Will Godfrey]

Re: Bug reporting and suggestions

Yes and no. This only works if the bug reports are acknowledged - preferably with progress reports if this turns out to be a long running issue.

[_LC_]

Re: Bug reporting and suggestions

Indeed. There are not few projects where a single person guards everything and considers bug reports or suggestions a disturbance. Those projects seldom evolve.

There are bigger projects where people that can't code take over the position of guardians nonetheless. There, you can get blocked by somebody who doesn't even grasp the problematic.

[Anonymous Coward]

FSF?

> OCEAN also asks who the leaders are who actually, you know, lead the group – so that leaves the Free Software Foundation (FSF) out.

Since the article does not address licensing at all, I don't understand the need to mention the FSF? The FSF is not an umbrella gruoup like the Apache or Linux foundations, and has never positioned itself as an organization which provides leaders or management for software-development projects. The FSF's remit is to be a steward for a set of copyright licenses, that's all. You may as well call out your local ISP for not organizing programmers, writers, etc. for open-source projects either.

[Moonrunner]

How about the translators?

I've done UI translations for several projects, and even mobilised some people who knew nothing about open source software to do additional languages.

[cornetman]

Re: How about the translators?

^ This, in spades. Always in short supply.

[_LC_]

Re: How about the translators?

This is one thing that pisses me off. Translations could be made so easy. There should even be a proper web-interface for such things, in order to automate the task.

[Lars]

Re: How about the translators?

As a Finnish programmer (ex) in a country with two official languages, Finnish and Swedish I can assure you it cannot be automated and it's not so easy at all.

One of the big reasons for that is that when, what you want to "say" in one language is fine in 10 characters it's gibberish in that other language.

I got 40 years of experience in that particular problem and it's easy only if you accept the result to be as we say in Finnish - "kuin juosten kustu". And no Google Translate is not there jet but you could of course try it out to understand it.

[_LC_]

Re: How about the translators?

You misread me. I wasn't talking about automatic translation (which tends to produce the opposite of what was desired quite often). I was talking about providing the tools for translating to everybody, making them even available online.

I other words, you go to a web-page of your favorite project. Then pick your language and see where there are translations missing. Then you can simply enter your translations there.

[cornetman]

Re: How about the translators?

That would be a really cool idea.

It is also something that the FSF could facilitate.

[Anonymous Coward]

How about comments?

I enjoy reading The Register's comments more than the news articles

[Ian Johnston]

There's also the inverse problem: who has done most to damage open-source software, whether or not they code? I think it's obvious that RMS is well in the lead, thanks to his obsessive carping over the minutiae of licenses, but there must be many others.

[Anonymous Coward]

who has done most to damage

Well, there's a controversial suggestion. If only we had a system to identify such people, or at the very least knew someone with their fingers on the pulse, or whatever we needed ... or didn't need. :-)

[Ian Johnston]

Re: who has done most to damage

The people who knows what's needed are called "users" and are traditionally the subject of contempt among FOSS developers on the grounds that either (a) "I don't want to do that so you don't want to do that" or (b) "If you don't like it you're free to modify the source as you want."

Both of which are fine, but lose you any right to complain when your application fails to make a hit or, yet again, it isn't your year on the desktop.

[cornetman]

Erm what? Are you serious, or just trolling?

[Ian Johnston]

Quite serious. Zealotry is almost invariably off-putting and every time RMS says "That's GNU/Linux, thank you very much" or "I refuse to talk about open source software" a few more people start backing nervously away, looking for the door.

So yes, I think he has probably done more to damage the FOSS world than anyone else. Extremism is never a good look.

[cornetman]

My take is that most great social movers are usually zealots of one form or another and we don't have to agree with them 100% to align with their broad philosophical and political stance.

However, the GPL has been a founding bedrock. I don't think that we would have the free software movement at all without RMS and the FSF.

I think that most people don't really understand Richard Stallman's role in the movement. He is not supposed to be "the friendly face" of the Free software movement. It is his role to be an arse. The annoying yet consistent reminder of what the movement is all about. The FSF was *absolutely right* to take him back and he should never have left in the first place.

You may disagree with RMS on these points, but you surely would agree that he *has* been consistent in his stance on freedom, and TBH he was also right about free software. It really has won the argument and the fight, now that the big companies are moving to services rather than software.

[chuBb.]

Although i am biased being a developer, i would say a project lives and dies on its documentation. I have found that projects (everything from libraries to ui applications) which have exemplary documentation, also have the higher quality bug reports (they tend to be bugs and feature requests, not confusion over how to use the thing or triaged out of existence quickly with a link to the relevant doc/wiki/sample), a more active and invested community and generally a better time as a user/consumer of the code. There are some outliers namely audacity but thats more down to politics and doing silly things to annoy the community than anything else.

End of the day the better the docs, the quicker, easier and more predictable it is to use, the more its used the larger the "educated" userbase, the larger the educated userbase the greater the number of people able to authoritatively answer the "how do i" questions in the mailing list, stackexchange site, subreddit etc, which feed back into people using it. From good docs does all the other non code related roles spring

If your project lacks the info to explain the how, when and why you would use it, your probably missing out on a lot of people who would use and possibly contribute to it as your lacking the documentation for use.

[PerlLaghu]

Documentation for the Win!

YES! Documentation is massively important...

Good documentation stops idiots annoying you with stupid questions

[Binraider]

Objective/scope setters

Money men (at least for larger FOSS projects someone has to consider it)

UI Designers

Developers / Technical Specialists

Multimedia

Documentation / Translation

Office Fluff (admin/legal/marketing/property/yada)

Working code is, of course, a pre req to link all of the other elements together. But consider what proportions of Mozilla staff do "Code".

Ultimately, I think the objective/scope is the most important thing to define, for if badly the other elements simply cannot follow unless it's a one-man band with a very clear idea in their head of what they want.

The UNIX philosophy of do one thing well helps an awful lot with scope definition; and happens to also break many problems into chunks small enough for individuals or small teams to work on.

[Nightkiller]

Everyone gets a star these days.

[Anonymous Coward]

In a former life I was a deputy whip on a local council. This is back office admin and coordination stuff - think deputy head master. It was a lot more satisfying and productive than the politicking going on in the front office and in public.