What Aspects of Open Source Projects Do You Avoid?

paulproteus writes "I'm a Debian developer and a part-time contributor to a few smaller projects. I do a lot of free software-y and open source-y things. Sometimes, though, I don't do them. I figure some other Slashdotters might have similar hang-ups — we contribute to a project, but there are parts that we really dread thinking about. So I wrote a post about having these hang-ups, and I made a place on the web to share how others can help your project. What are the parts that, in your projects, you would be relieved if someone else looked at for you?"

Comments

Re:Freedom is not binary

[sopssa]

GP has a point - BSD license doesn't restrict freedom of anyone directly. You can do pretty much what you want with it, even turn it into an proprietary project. That's true freedom.

GPL in turn directly restricts the ability of other people working with the code to do several things, including using the code in proprietary projects or whatever they want with it. That's not true freedom as it instantly limits a coder. When the BSD licensed code has been taken in to an proprietary project, it's not really BSD's problem anymore. That's why BSD itself doesn't restrict anyone.

If you want true freedom of code, you need to accept using code in a way you don't accept with. Otherwise it's not really freedom, is it?

Re:Ego

[digitig]

You need to remove or conceal the features that are rarely used.

Goodness, where have you been? If you conceal features then you get pestered with tech support calls and requests to implement stuff that's already there! What you should do is dump everything on the UI all the time in a ribbon across the top (remembering to license it from MS). The user sucks bigtime, but users can't complain about not being able to find anything because it's all there in plain view, so they know they'll be made to feel stupid if they query your design.