I’m not feeling your comparison with self-checkouts. In fact, I’d say it is a ridiculous comparison that pollutes the rest of the article. There are virtually no parallels worth commentary.
And are you seriously claiming that asking for C++ is too onerous for an open source development project? Sorry, Jeff, but being a C is hard! guy, it’s doubtful that you and people who agree with you have anything to offer these projects.
Countless open source projects are stunning successes (and few of the contributors are Scratching their own itch, which would justify your ridiculous analogy. Most of them are developing for the sake of the goal), despite incredible barriers to entry. You ignore all of those because they counter your absurd lesson.
Open Office is failing because developers aren’t excited or motivated by the project.
I hate the self-service checkout - on principle. I see it as a symbol of the decline of real customer service. I’m a New York shopper - I buy what I need for a couple days at a time, and I go to the store quite often. Most of the time, I find a long line at the self-checkout stands, and I go searching for a regular checkout, and will often find one with nobody waiting. Since I only have maybe 5 items max, I can get through and go on my merry way. And I’m always sure to give a big smile to the folks still waiting in line at the self-checkout.
So it’s in my best interest most days to have the store employees do their job. This is often how I feel about Open-source software. I often choose commercial software because I don’t want to have to service it myself. I’m a programmer and I love coding, but I want to work on my own projects, not on basic tools like Office software, or operating systems.
The best software is written by energetic small groups of people highly motivated by craftsmanship and money. What you get with OSS projects, especially big ones, is the spirit-deadening features of Soviet five-year planning, plus bickering. Crap on Adobe all you like, but they’ve got incomparably better alternatives to Gimp, Scribus, Quanta, et al. (Oh yeah, and they contribute to OS development in a very reasonable and rational way - just ask Mozilla; though they probably won’t tell you how much Adobe brains are behind Chrome etc.)
The opposite to the self-checkout has struck my local market. At the new Hannafords you can give your carriage of stuff to a checkout employee and then go out and pull your car up to a check out port. They scan and bag all your stuff and then bring it out to your car with a slip. You hand then cash/check/credit card and they go back into the store get your change/validate your check/process your credit card and then return with your slip.
Slow and inefficient but there are plenty of rich people who just love to be waited on.
What does this have to do with open source? Nuttin’
Here’s the biggest part I see left out of your analogy.
You generalize yourself to the entire population. At least in my area, the self serve kiosks are not heavily used (based on my limited shopping experience). I myself avoid using them unless absolutely necessary. Why?
Your average trained employee is faster than your average customer. Noone is more interested than me in getting me checked out, but the majority of that (unless I have 30+ items) is not check-out time. It’s line time. And in my experience line time is no better, and often worse, in those kiosks.
While you may be the most interested in checking you out fast, you may not be the most capable. And even if you are more capable, most customers aren’t. So you’re not really helping yourself.
This reminds me of the line problem. Lots of research has show that a single queue with multiple cashiers, is faster than multiple queues where the cutsomer picks one. So why does anyone have multiple queues?
Well it turns out that despite the proven suckitude of the multiple queue system, customers feel better about it. They have control. The fact that the control results in a lower quality product is irrelevant to them. In fact, most would vehemently argue that they have chosen the best way… but that’s another aspect of human psychology.
It’s the same with open source. Developers love it because it gives them that feeling of control.
When I read the store is making you do work they would normally pay their employees to do, I agree, this is obviously true, and I wonder what people think when they accept whatever.
But I’m not sure this example applies to OpenOffice.org : more not-Sun developers will understand OpenOffice.org source code, and more the code will become free for true.
Talking about something I know, since the Mac OS X port started, the not-Sun contributors like me progressively started to understand the -ocean of - source code, and now, there is a second step : they start adding features, and even more.
Just another point of view
@Bruno : excepted the micro cws in 1.1.x tree, I never seen any IBM code in OOo
Love the self serve tills in MOST cases - there are a few border cases at home depot that I avoid (nuts and bolts, linear feet of base board), and too many of them require everything onto the scale (got too much stuff? back to the traditional till…)
Fruits and vegetables? Work great at SuperStore. You get pictures. Works BEAUTIFULLY. Not sure how well it will work once I get past 3 bags. Walmart at least lets you take the bags off once weighted - Home Depot’s tills freak out.
Anyone remember the promise of RFID carts? Push them into a reader, bang, instant and total sum you could then pay for a pack? (or course, some ass will switch tags and suddenly 2$ items will be 20$ items and you would have no way to actually know unless the cart kept a running tally with rfid as well) There is the ultimate self checkout, no need to scan and weigh.
as for Open Source…
I’ve TRIED to get involved with a project or two in the past. What I found, even from other developers was a cuture of elitism whereby newcomers were -NOT- welcome, and even reported security concerns and changes were unwelcome because they stomped on someone’s feifdom.
The problems with open source projects go from top to bottom and most are doomed for failure simply because there is no apparent reason to tolerate the treatment. It is open source, its free, and frankly there are a million alternatives. As such, most projects eventually drive potential contributors away.
Linux is one of the few exceptions, but even then, you can see the power stuggles happen. The only reason it has held together this long is the cult of personality around Torvalds. When he is no longer available to reign over the masses, chaos will inevitably descent and no one else will have a clear enough claim to authority to keep things running and the standard pattern will repeat.
At least in closed source commercial development, who is in charge is ALWAYS clear - the guy with the money. While there are a million things than can kill commercial development, at least the final authortity issue is dealt with.
The self-checkout thing is more a social phenomenon than an economic one.
The relationship between service provider and customer at chain stores has already deteriorated to the point where they are little more than talking ATMs with fancy AI. They can’t accept tips, they aren’t allowed to have a conversation with you, and they’re judged on how fast they shove you through the line – being anything more than a vending machine with a smile is looked down upon.
Customers like that because it’s getting less and less common to see people treat each other as people, instead of resources to be made use of. Employers like that, because it increases efficiency. Tellers don’t get a say in the matter if they want to keep their jobs.
Putting in real machines, instead of people forced to act like machines is the next logical step.
Consider this: Excluding the lineups, it’s usually faster to go through a normal checkout than a self-serve one. The teller is much faster at processing CCs than you are with the stupid signature pad, and the physical setup the teller has (the belt feeding her your groceries) also improves her performance. But you will typically feel that it’s the other way around.
This is related to the old tests done in the 80s that show that using the mouse is faster than using the keyboard for equivalent tasks, regardless of what the user felt was faster:
Because of the context switches required to interact with a person, the fact that we have to wait on them for tasks to finish, rather than doing it ourselves (however slow), and that general social skills in this area have degraded to the point where interaction is awkward – all of these things combine to make it feel slower to deal with another person, regardless of the fact it’s almost guaranteed to be faster.
Regarding the even if I create a bugfix, I cannot publish it widely enough: yes, I think that’s a problem esp. if lots of scratch-your-itch developers make small fixes for some project. For example, I have some patches lying around (in a public personal repository) for a project where:
the original author hasn’t done anything for years (probably he doesn’t need the software anymore)
a Sourceforge page exists which has the latest code imported by the original author but no further additions
several discussion about this software are littered all over the net
code fragments, patches, VCS repos, or tarballs with patched sources can be found on the net
In summary, there are some people interested, and some people have contributed, but there is no leader anymore, and there is no central place which links to all these fragments.
So, what would be cool: some way to link these fragments. Maybe a special syntax which every developer can add to his software to link to other contributors, and then some web crawler (or a Google-based system) finds those links and automatically puts it together into a big repository view? Or some p2p net to find other developers and their code?
I think it’s important to not require the developer to join some group (or create a SourceForge/GitHub/Launchpad/whatever account; or use the same VCS; or take the other fragments into account). The developers should still be able to scratch their itch and then put the software or patch online in their liking (maybe in a repo, or in a blog, or on Rapidshare, or even in a pastebin); and some automatic system links it together and shows: hey, there’s ten people all working on this, and together they have already contributed three times more than the original author did! This project is alive!
Well, that would be cool. That, and having an infinite icecream box.
One more comment on open source in general. The main problem I have with most open source projects is that there are plenty of people involved and not all of them are good coders. The code is a mixture of people just started to learn the language, experienced programmers, and real pro-hackers. This mix usually results in a big ball of mud - or to put it in simpler terms: The code is a mess.
Whenever I just want to fix a tiny issue, I see the code and feel the strong urge to rewrite this whole piece of crap into something that deserves the name program code. The problem is: The tiny fix could be coded within 10 minutes, the whole rewrite takes several hours. I’m willing to spend 10 minutes on fixing the issue, I’m not willing to spend hours to rewrite other peoples mess. On the other hand I’m also not willing to add my well designed patch into this ball of mud… in some cases I can’t because what seems reasonable code on its own might break the existing code in so many ways, however, I can’t tell because working yourself through the code is so much PITA.
I end up just reporting the bug, giving some details on how I think it should be fixed, and leave the coding to someone else who is willing to dive into the mess.
Honestly, an online IDE would solve a lot of these problems. It would be great to have a Google doc type application with the features of a modern development environment. That would put everyone on the same page with the same software. No more compatibility issues and the bug repository could actually link directory to the problem source code.
‘I’ve seen plenty of customers in front of me struggle with self-service checkout machines, puzzled by the workings of this mysterious device that seems so painfully obvious to a programmer. I get frustrated to the point that I almost want to rush over and help them myself. Which would defeat the purpose of a… self-service device.’
So, so true. I’ve felt this way many times and can’t understand how something so painfully simple can be so misunderstood. Guess that’s just me thinking in a different way
It’s entirely possible that many people feel that it’s ‘good enough’ as it is. Most people want to write or open a document, or make a spreadsheet… that’s it. If it can do that, it’s ‘feature complete’ for most people - why bother adding to it?
The software in a self checkout system is a clear example of good software gone bad by silly requirements from clients.
Using self checkout systems around me, I can tell that the software was originally designed in a usable, painless manner.
Then, management was afraid customers would steal items, so they put in these HORRIBLE weighing systems that stops you from taking items off the bench early, or from setting them there before you have scanned them (which is often helpful for space reasons).
THEN, it was realized that everyone accidentally triggered this stupid weighing system, so the system would freeze constantly, which would require constant staff interaction to unfreeze.
To fix the above problem, the customer can simply press a button to dismiss the error and continue as normal.
So now, they’ve ended up with a system with all the annoyance and hassle of the weighing system, yet NONE of the intended security benefits, since a customer can just clear the error themselves. A once painless system is now cluttered with useless warning messages that simply frustrate, annoy, and slow down the users.
Oh, and don’t get my started on the fact that an employee has to key in a code for certain items like alcohol… they do it on a GIANT touchscreen keypad right in front of your face. If I was so inclined, I could easily enter the code myself, it’s only 4 digits.
If you let just anyone work on OO, there is a very good chance that the code quality will suffer. That’s the reason all of these restrictions are in place, to maintain quality. This is a good ambition, but totally wrong.
A concrete suggestion to OO is to stop focusing on bureaucratic QA and focus on techical QA. Spend your effort writing test cases, standards checking tools, etc… and leave just a few eyes to look at the code after it has been smoke tested to shake down if it’s worthy of inclusion. Kill the CCB. In this way, the barrier to entry is literally that which would not technically degrade the project, and we all win.
I also should have mentioned that RFIDs on items could totally fix the problem of checkouts… you could simply pass your cart through a gate, which would instantly recognize all of the items present in the cart.
From there, it’s a simple payment terminal, with a few extra checks like age limits for alcohol.
I’m a big Wal-Mart fan, but while I lived in Los Angeles I had to go to Target instead, mostly because of the checkout experience. Although the local Wal-Mart had plenty of self-checkout terminals, if anything those lines took longer than the two open clerk-served registers. One thing I know: asking the average Angeleno to operate a self-checkout is akin to asking her to operate the Space Shuttle.
