Of silos and samba

Somewhat administrative: Screw you Slashdot. You linked Mr. Allison's article, but not me directly. Classy. Maybe you don't want to be associated with me? Whatever, that's cool, I don't like you guys either. You guys are like the Al Jazeera of tech journalism. I don't really read you because I want to, it's just a good place to find material.

Anyways, real props goes out to Jeremy himself. I'm sure it took a lot of balls to post a link to this blog on such a legitimate forum. Respect. I also found it funny that you kept referring to me as "he or she". As it if isn't obvious. You see any women in the FOSS community? Just take a look around.

But anyways, in honor of the favor, I'll take you up on your topic suggestion: Samba.

I'd like to write pages and pages about how Samba is shit and should die a fiery death, but actually, I've found samba to be pretty solid code... when I can configure it. And that's what it really comes down to. The best code in the world won't change the world if people can't use it. If I could have a nickel for every hour that someone has lost trying to configure samba, I'm sure I could buy all the hard drives I need so that I never have to share anything over a network.

Want more specifics? Unfortunately, I don't think I have anything earth-shattering here. It seems to me like it's the config file (or more generally, the configuration mechanism). Yea, it's fairly simply formatted as far as config files go (and thankfully, it's not unreadable, un-typeable XML garbage). But when it comes down to it, I don't have hours and hours to read your man page to see how to set things up. And apparently, neither do my friends. I'm pretty sure I've had a good understanding of smb.conf at least 20 times in my life, each time lasting around 30 minutes. I'm sorry guys, it just doesn't matter enough for me to remember. And don't get me started about smbpasswd.

What are my options for configuring Samba using a GUI? Fedora's super simple tools? Webmin? Please. The former doesn't give you any options, and the latter gives you way too many options. I see a bunch of other things listed on your page, but nothing I recognize. And that's another indication of the problem too.

If you want to provide a feature as part of a platform, you can't just write the code and say "here's the config file! have at it!". When you do that, you get a bunch of other people who don't really understand the configuration space writing config tools for you that all suck in one way or another. If you want to introduce a core feature to the desktop "platform", you really have to make vertical integration easy, or even do it yourself. Samba, as far as I can tell, hasn't done this. They've written a solid engine with tons of features, but have ignored the the core problem that very few people understand how to configure the damn thing. They've effectively left it to others, and the others have failed. Where as Microsoft? yea, their server code might even be inferior, but configuring shares is pretty damn easy in comparison.

Which really brings me to the main topic of this post: the silo effect. As far as I can tell, the silo effect has been around since the dawn of software development. Most software needs to integrate with other software, yet most development teams communicate very little with the teams that write the software they need to integrate with. Perhaps samba could talk to the kernel people, and the fuse people, and the freedesktop people, and the kde people, and the gnome people, and engineer a top to bottom solution that makes samba usable for desktop users. Sure. As some of you flamers like to say, just wait until 2020, and it'll be there.

As far as I can tell, in the OSS world, the silo effect seems to be magnified. Which is ironic, since one of the things OSS was supposed to do is kinda solve this whole silo thing in the first place. Everyone can see each other's code. Everyone can modify each other's code. If the developers of some project didn't care about your goals, you could always take their code, and do it yourself. Right? There's open mailing lists and bug trackers so that communication is as easy and as smooth as possible, right?

Well. In practice, it doesn't work. It's obvious that forking every project you need to integrate with is untenable. Nobody can understand and maintain so much code. Besides, if you fork enough parts of the stack, in effect, you're forking the entire stack. Nobody's gonna ship your modified version of dbus, gtk, and the X server just for your silly app. As for bugzillas? Everyone knows that just because you file a bug against a project, doesn't mean it gets fixed. Mailing lists? I'm sure you'll get the friendly reply of "yea, sounds great! send us a patch!"

So what to do you do instead? As someone who develops a Linux desktop, how do you get samba guys to work on making configuration easy, predictable, reliable, and usable? How do you get them to write code that they don't care about? Write it yourself? Well that's great, except that it's really difficult. Just because you have the code, doesn't mean you can hack it. Even if you can hack the code, doesn't mean you can do it well, or in a way that the maintainers of the code will accept. You have to play by their rules, respect their priorities, and integrate into their development workflow. Multiply that by the number of projects you have to integrate with... and again, all I can say is have fun! see you in 20 years!

The saddest part of it is, society has developed a general solution to this problem a long time ago. It's called money. Can't seem to get someone to care about your goals? well it turns out that a few benjamins can usually change their mind.

Oh. Crap. Except in the OSS world, very few people have figured out how to make money. And those who have, have built their silo walls tall and thick that even the architects of the Great Wall would be impressed.

So we can't use money. What else can we use for motivation? Hmmm... Oh I've got it! Let's start a movement! People like freedom. People like feeling superior and righteous. If we can find a bunch of bored coders and tell them that they're coding for freedom, maybe they will do it for free?

And thus the birth of Free Software?

Too bad it wasn't Free and Usable Software. Free software is easy, you just have to write code and upload a tarball. Turns out usability requires complicated coordination between hundreds of developers all working together to reach the same goal. Try selling that to the Gnome and KDE crews. If you can get those guys to cooperate, I'm sure every Silicon Valley company will be knocking on your door with an offer to manage their R&D divisions.

As for Samba: my suggestion would be for the project to take more ownership of the usability aspect of the software. Some suggestions? Make it easier to configure. Or make it easier for others to write configuration utilities. Maybe a configuration API of some sort, so that others can write quick and reliable front ends. Also, document some best practices in terms of configuration. Or go even further, publish a configuration and deployment scheme that you guys think would be suitable for desktop use. Tell distros that you're not going to help look at bugs they find unless they follow the exact same scheme. Refine that scheme as you get more feedback from distros. You're already the central authority for samba code, why not play the same role for configuration? Produce a working and usable baseline that's easy for distros to deploy. Take them out of the equation. You'll always get some expert users tweaking your baseline configuration, but that's up to them. Don't sacrifice usability for the majority of your users by catering to the few tweakaholics.

But maybe samba just doesn't care about the desktop. I mean, it's not like anyone's making money there. On the other hand, I see a lot of useful shipping storage devices that have samba code.* I just hope the samba folks are getting a piece of that action.

* Though even on those devices, samba configuration interfaces are pretty miserable.