3 ms·

Why your open source project isn't getting attention

20 points by chmike 18y ago

khill 18y ago
"My eyes! The goggles do nothing!"
orib 18y ago
In general, you'll be working on your own on an open source project until it's actually useful enough for someone to want to try it, but just barely broken enough that they want to contribute a patch.
pmjordan 18y ago
There are some very valid points in there; the inability to perform a successful build locally has caught me on a couple of projects. Unfortunately, as the number of dependencies increases, this inevitably becomes more difficult. If the project depends on more than 2-3 libraries, I think it's reasonable to include the more obscure (obscure = isn't supplied with the top 5 Linux distros & OSX; slow release cycle) in the source code repository, and maybe supply the more mainstream ones in one ready-to-use .zip for those poor Windows folk. The lack of infrastructure (version control, bug tracking, mailing lists) around open source projects is a real issue as well, and one for which there are no excuses, as sourceforge etc. will supply you with said infrastructure for free. (in money and time) It can seem somewhat silly when it's literally just one guy churning out the odd release, but I think it's appropriate even then. The main barrier to entry I've encountered is just reading my way through the code so I understand it well enough to be confident enough to change anything. Yeah, documentation would be nice, but let's face it, it's never going to happen. I've found the best way to get started is to reserve a free weekend...
- orib 18y ago
  Really? On my Debian system, at least an old version of the software is in the repositories 90% of the time, and simply doing: sudo apt-get build-dep $PACKAGENAME gets all the stuff I need to build the software, and then all that's left is ./autogen.sh --prefix=/local/test/prefix make make install and things Just Work. I've never had a big problem with dependencies -- other than Xorg, where the issue wasn't with obscureness. The issue was with requiring a number of dependencies from git. That sort of problem really isn't something you can resolve by anything other than documentation. As for Sourceforge.net, it's bug tracker software has the worst UI I've ever seen. Even email beats it, IMO. But I agree with you about the need for easier code browsing and documentation. Still, tools like 'cscope' go a long way to figuring out what's going on with the source, and grep + ctags in vim will take you the rest of the way. edit: fix formatting

20 points by chmike 18y ago

khill 18y ago

"My eyes! The goggles do nothing!"

orib 18y ago

In general, you'll be working on your own on an open source project until it's actually useful enough for someone to want to try it, but just barely broken enough that they want to contribute a patch.

pmjordan 18y ago

There are some very valid points in there; the inability to perform a successful build locally has caught me on a couple of projects. Unfortunately, as the number of dependencies increases, this inevitably becomes more difficult. If the project depends on more than 2-3 libraries, I think it's reasonable to include the more obscure (obscure = isn't supplied with the top 5 Linux distros & OSX; slow release cycle) in the source code repository, and maybe supply the more mainstream ones in one ready-to-use .zip for those poor Windows folk. The lack of infrastructure (version control, bug tracking, mailing lists) around open source projects is a real issue as well, and one for which there are no excuses, as sourceforge etc. will supply you with said infrastructure for free. (in money and time) It can seem somewhat silly when it's literally just one guy churning out the odd release, but I think it's appropriate even then. The main barrier to entry I've encountered is just reading my way through the code so I understand it well enough to be confident enough to change anything. Yeah, documentation would be nice, but let's face it, it's never going to happen. I've found the best way to get started is to reserve a free weekend...

orib 18y ago
Really? On my Debian system, at least an old version of the software is in the repositories 90% of the time, and simply doing: sudo apt-get build-dep $PACKAGENAME gets all the stuff I need to build the software, and then all that's left is ./autogen.sh --prefix=/local/test/prefix make make install and things Just Work. I've never had a big problem with dependencies -- other than Xorg, where the issue wasn't with obscureness. The issue was with requiring a number of dependencies from git. That sort of problem really isn't something you can resolve by anything other than documentation. As for Sourceforge.net, it's bug tracker software has the worst UI I've ever seen. Even email beats it, IMO. But I agree with you about the need for easier code browsing and documentation. Still, tools like 'cscope' go a long way to figuring out what's going on with the source, and grep + ctags in vim will take you the rest of the way. edit: fix formatting