Slashdot Mirror


Making Your Code OSS-Appealing?

goldcd writes "A while back I wrote some pretty reasonable forum code, a PHPBB alternative. A few years down the line it's pretty stable, I've stopped tinkering with it, and it's standing up by itself. I have neither the time, inclination, nor inspiration to do anything more with it, but would very much like to give the code to the world to use and expand upon. Now I could just upload it as it is onto SourceForge, but currently it's very specific in its usage and I'd be ashamed of what 'proper' coders would think of my amateur offering — I'm afraid it would be laughed at and ignored. On the other hand, I don't want to waste hours of my own time perfecting it for people just to 'rip off' as is, and never contribute anything. My question is, what do you have to do to make your code 'OSS appealing?'"

10 of 180 comments (clear)

  1. Just let them come by Anonymous Coward · · Score: 4, Insightful

    Post the code and let the people who want to clean it up clean it up. If people see potential in your existing code, that's what'll be done.

    1. Re:Just let them come by Anonymous Coward · · Score: 5, Insightful

      I agree wholeheartedly. Most systems fail to gain popularity not based on their code quality, but on their documentation. The more documentation, the better - especially for PHP projects, where documentation tends to lead developers by the hand, often spoon-feeding them.

      If there is guides on how to customise this, add things here, remove things from there, etc people will be more inclined to adopt the system.

      When checking out any software, I always check for documentation, from the specific itty-gritty (like API references), to tutorials, blog postings and articles on the system. It means if have problems, I stand a chance of identifying a fix by doing a quick Google search, instead of unnecessarily trawling through code myself.

    2. Re:Just let them come by Psiren · · Score: 4, Insightful

      Absolutely. Nothing wrong with constructive criticism. I was just trying to say that anyone that mails you to tell you your code is shit without offering any helpful advice is at best a juvenile arsehole and should just be ignored.

  2. Nothing by Anonymous Coward · · Score: 4, Insightful

    Well, I started in on a comment on this issue, but then I realized I was drunk and babbling on about some shit so fuck it...I've hit AC, and I'll just tell you to stop being self concious and release your code, open source isn't supposed to be a judgmental thing, release what you have and if there are improvements to be made take them as constructive criticism and learn from it.

  3. Release. by srothroc · · Score: 4, Insightful

    Well, you could just release it as-is and see if anyone's interested.

    Alternatively, you could go through and write up some documentation so that even if your code is messy and/or idiosyncratic, other people can find their way around with the help of the documentation. If they don't like the way things are set up, or if things are inefficient, they can fix it on their own -- isn't that a part of what OSS is about?

  4. Do you see a sign that says "dead code storage"? by ameoba · · Score: 5, Insightful

    If you don't want to put any more work into it, it's effectively dead. OSS isn't just about giving away the source, it's also about allowing other people to contribute - simply posting it on SF.net and walking away does nothing if you're not willing to review submissions, process bug reports and/or bring people into the project.

    --
    my sig's at the bottom of the page.
  5. It works? by fishbowl · · Score: 5, Insightful

    If it works, don't be ashamed of it.

    It you planned it, and then executed the plan to completion, there's nothing "amateurish" about that. This is one
    *definition* of professional work.

    --
    -fb Everything not expressly forbidden is now mandatory.
  6. Don't bother by Bloater · · Score: 4, Insightful

    > I have neither the time, inclination, nor inspiration to do anything more with it

    Don't bother uploading it. Without its primary developer being involved, unless you've got some users with a real care that they can keep using it *and* that it improves, and who are also skilled PHP dev's (enough to read through and understand somebody else's code on the timescale they need modifications done) nobody is going to pick up your code.

  7. Re:Do you see a sign that says "dead code storage" by Anonymous Coward · · Score: 4, Insightful

    One man's trash is another's treasure. Let the user frantically searching for exactly your code on SF.net decide if it is worth something or not, not some flippant opinion here. Even if it the project is no longer maintained, it's not dead, it's just coasting. It's only dead if you never let it out into the world and then one day the hard drive goes silent.
    Any who cares if people leech it and never give anything back? By a little act you just made someone's day.
    Rate of change is a poor metric of project health anyway. Small robust mature bits of code may stay the same for years but are used by thousands every day.

    -- AC as usual terminal HD catastrophically turned to metallic powder a few days back

  8. Don't forget the why! by achurch · · Score: 4, Insightful

    Documenting how things work, from both a user's and a developer's perspective, is certainly important. But it's even more important to write down why your program works the way it does. Any reasonably skilled programmer can reconstruct the "how", given enough time--it's in the code, after all--but nobody can read your mind to determine "why" you chose a particular method of doing things.

    Without the "why", another programmer may be hesitant to change your code, even if he sees a potentially better algorithm, because he won't know whether it's safe to do so: Did you use your algorithm on purpose, maybe due to some aspect of the program structure that requires it? Does the rest of your program assume that the function will operate in a particular way? (I'm not going to turn this into a lecture on encapsulation or anything; this is just an example of why the "why" is important.) It's okay if your reasoning is just "it's the only thing that occurred to me" or "I don't like doing this kind of routine so I just rushed through it", and in fact, that sort of note will help others fill in any holes in your design.

    As for the code itself, don't worry! Everybody's gone through more or less the same learning process, so most people will be perfectly understanding, no matter how your code looks. (Of course, there are always those who leave snide comments, but like playground name-callers, the best thing to do is just take them in stride.)