Sound familiar?

1

Why I quit: Linux kernel developer Con Kolivas stated:

If there is any one big problem with kernel development and Linux it is the complete disconnection of the development process from normal users. You know, the ones who constitute 99.9% of the Linux user base. The Linux kernel mailing list is the way to communicate with the kernel developers. To put it mildly, the Linux kernel mailing list (lkml) is about as scary a communication forum as they come. Most people are absolutely terrified of mailing the list lest they get flamed for their inexperience, an inappropriate bug report, being stupid or whatever. … I think the kernel developers at large haven’t got the faintest idea just how big the problems in userspace are.

As a user, and not a programmer/developer, I must say I have seen a little of that here as well. If Haiku is to succeed, especially with our small user base, then we really must try to avoid the scenario described above. There is no bigger turn off to a new user (or an old one), than being looked down upon by the programming snobs whenever a suggestion is made or a question asked. Thankfully these experience are few and far between, but they do happen sometimes.

2

Snobbery is an universal issue these days. Every hack thinks he’s hot shit, especially if he actually knows more than the average Joe and in position to look down on others.

3

Haiku is different from Linux in that both kernel and userspace parts of the operating system are developed in-house, by a single group of developers. We don’t have that kernelspace/userspace division Con Kolivas talks about, which is software and project in nature, primarily, and only secondarily, or peripherally, about a division of people (e.g. developers/users).

But Haiku is similar in that our developer channels are separate from our user channels and meant for different topics, fields of interest and levels of expertise. This separation is on purpose. There is no reason to believe that the prerequisites for technical discussion on Haiku matters would be any lower than those necessary for Linux discussion.

The users channels are meant to be inclusive and non-judgemental. “Bad” suggestions will not be (or should not be) troutslapped as hard on a user channel as on the developer channel. It is primarily when users step into developer channels and misunderstand their own level of expertise or their current weight on the scale of open source meritocracy, that things go wrong.

Haiku suffers not from division, but from lack of division, not enough tiers. This is due to its small pool of users and developers. The kernel devs have to put up with the userspace devs, which have to put up with the noob devs. The users have easy access to kernel developers. Ideally the top talent would shielded by bug tracker staff, so that these can spend their time more efficiently, which is what benefits the whole collective the most.

4

The Dunning–Kruger effect

5

That and probably some Tribalsim.

6

I find snobbery more common at least regarding Haiku more common among people that are new to the project… that just drop by and expect thier ideas to be accepted and implemented.

As far as the developers go… in general they seem very fair minded and at least try to reward effort of newcomers that are producing good code for the project.

What more can you ask? If you want more than that I thin you are being unreasonable and the problem is all really just in your head. I haven’t contributed to Haiku with code but I may someday when I have time.

7

I agree that the devs are pretty fair minded and try to listen to other viewpoints. But what concerns
me about the current arrangement is the pretty strong tendency towards mono-culture when all the
decisions about what goes in/ what’s kept out/ what the direction forward is… all are made by a
small clique of programmers.

What we have is a group of bright, technically oriented guys who are
implementing a system that ultimately appeals to their own sensibilities… i.e. to other bright,
technically oriented guys. The views of Joe Sixpack just don’t enter into it.

Now, I don’t worry much about R1 in this regard, as that design is already done and is pretty
universally (well, almost) loved by the community. But there seems little to stop the OS from slowly,
surely, and progessively over time, tilting more and more to the geeky side and away from that wonderfully
user friendly experience the original BeOS was.

This is one area where a closed source, corporate designed OS actually has (or at least, could have)
an advantage. There, the programmers don’t rule the roost but merely implement what they’re told.
And the decisions about design are split between the upper levels of management, as well as various
other groups like quality assurance, human interface guidelines teams, creative/graphics types, etc.
When the boss sees work coming out that looks too technical (in his opinion) he can lay down the law
and tell the developers “try again, and make it simpler”. Kind of like Jobs was notorious for doing
to his development teams.

I remember in the early days of OpenBeOS there was a similar feeling about having a creative
"meeting of the minds" in mapping out the future of the OS, past R1. There were groups of creative
(musical and graphics) types, long time users and commenters, as well as the project management guys
and all the individual programmers that were to have an input in what direction the system would take. I liked that
approach because it seemed richer and wiser and more conducive to a fulfilling outcome.

But that seems to have melted away over the years. Now it seems more like, “hey if you want to contribute, submit
some code. Oh wait, you can’t code? Then shut up!” Ok, that’s way too harsh, It’s nowhere near that
bad – I’m just exaggerating to make a point.

I’m not trying to dig at the current core group of guys developing Haiku because they’re doing a great job.
I mean, damn – it’s here! Haiku actually exists! It got written. And it works. And it pretty damn sweet even in its
unfinished state. And it’s still being continuously tweaked, and fixed on, and amended. Awesome job.

But that’s my worry about the future. That the current arrangement almost inevitably leads to a echo chamber
of group think among the devs. There’s no counter-balancing force, that I can see.

8

I see often people approach Haiku with some weird stuff on their minds like “you have to port this, this, this and this if you don’t you guys suck and nobody would use this pile of shit of yours” or “you have to make a tablet OS out of it, maybe Android clone, otherwise you suck…” etc.

There is no way you could have any constructive discussion out of it, seriously.

9

My first thought
Did anyone contacted this guy to ask if he would like to help developing haiku os??

10

There are tasks related to Haiku that people without development experience could contribute but developing the OS (as in programming) is not one of those. There are a handful of members of the project I can think of doing tasks which are non-development in nature. There are many ways to contribute aside from pure development.

But those tasks are generally not the fun stuff like how some people imagine themselves contributing; some people seem to want to do interface mockups, or just name some sorely lacking feature and then have someone else invest months or years of their spare/family time to build it. People with such misconceptions on division of labor will be sorely put down by reality.

Being a open-source developer on a perennial project is not something you ask people to be. It’s something that must come from the person, in the form of self-motivation. It’s years of mundane, quite possibly unrewarding work for intangible social benefit. It’s an acquired taste.

Sure, the project could be more inviting and line up tasks for newcomers but the outcome of is generally low. People state their interest, expect to be sponfed task and most drop off without contributing much of anything else than their opinions.

Devs who have been with the project for years are probably too jaded by the high dropout that they don’t engage unless they see actual talent, an experienced developer (or possibly some other missing role, graphics designer, markerteer, quality/testing engineer, …), high motivation and a proven track record in related open-source projects.

11

Hello here,
Some words from one Haiku developer.

I don’t think the mentality is “you can’t code? then shut up!”. Even if you can code something, and come with a complete patch, it may be rejected as not being “the Haiku way”. This is not related to your ability to code.

Yes, your ideas will be rejected if you say something like “hey, you guys should do something more like Android, because it’s so cool!” (or we had the same with OSX, or whatever other OS). Yes, there is no boss, no QA, and no way to control what the developers do. So, if you want that to happen, what you have to do is explain the developers what they are doing wrong, why it’s wrong, and how they could do better.

We have some people doing that very well. I’ll cite the example of Diver, who is currently kind of the only member of our QA team. He spends a lot of time testing our apps, spotting all the bugs, and opening well-documented tickets with Debugger reports, steps to reproduce, screenshots, and everything. He also does mockups on how the UI could be improved. Without contributing a single patch to the code, he got commit access and a vote right on the project because this is invaluable work for us developers.

I’d love to get more people doing such testing, and taking the time to write good bugreports. Yes, this requires you to spend some time documenting the issue. Remember that this is time the developer doesn’t have to spend on it. Do 50% of the work, and you are likely to find a developer to do the remaining half. Do more, and the probability increases.

Also, I’d like to remember everyone that before being a developer, I’m myself an user. And no, I don’t want the system to be crazy complicated. I love the simplicity of Haiku and BeOS, and I do my best to make things jut work. The main difference is I spend a lot of time in front of a terminal or a text editor, where maybe you know and use some other applications. And this is where you can help: report bugs in those apps I don’t use often enough, and I’ll fix them.