Everything sucks, part 2

In my last post, I lamented how everything sucked. Or, phrased in a less exaggerating and sensationalist way, how the focus on individual features and the push to get things out in the wild quickly prevented us from having wonderfully well-integrated experiences.

A subsequent idea popped into my head that I want to explore. Complaining just generates a lot of noise without any action. But what if we could actually act on the things that's bugging us? What if we could develop and contribute changes to the products we loved, to benefit ourselves as well as other users of that product?

Open Source Software
Yup, that's pretty much what the ideal of open source software is. If you think something sucks bad enough, just fix it. Here's the program, here's the code, just fix it. If it's a product with ongoing development, then hopefully you can have some central repository to commit your changes to. And, hopefully, it's one such that future releases will contain your fix, eliminating the bad user experience for all of its users.

There are two problems with this approach. One, it turns out it doesn't actually succeed at making seamless user experiences (it can be argued that it makes it even worse). Two, everybody thinks they're special and they don't want to share.

No matter how well-intentioned the open source developer is, they can't build an experience. They can only build more features. Maybe it's a tiny bug fix, or maybe it's a full feature rewrite. But piecemeal additions to a larger codebase almost never have a unifying effect on the overall experience. In fact, they usually fracture the experience, forcing it into a mere collection of well-working features.

Invariably, to have a good overall experience, someone needs to have the oversight to see how each of the individual features contributes to the overall experience. This lends itself to some sort of leadership or management role of the project, rather than a fully distributed model of development.

Unfortunately, the projects that have this kind of guidance rarely favor releasing their hard work under an open source license. I can only speculate that the drive for such tight control over the entire product, which is the very feature that can breed a wonderful user experience, is the very same drive that makes them want to keep the innerworkings of their project under wraps. They don't want developers outside of their own to change things, because they could change things in a way that is poor to the overall experience.

Then there's the business and legal side. I think software development in general is crippled by legal decisions. If you release your code, others can copy it, sell it, and try to rob you of sales. I can't deny that this is a possibility, but it's unfortunate that the possible bad action of a few bad apples is preventing me from being able to contribute my skills to interesting projects.