Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Software IT Technology

OSS from Non-Developers for Non-Developers? 45

Posted by Cliff from the open-source-from-all-kinds dept.
chrisatslashdot asks: "By training and title I am a Mechanical Engineer. I have never been involved with any serious software development although I am competent to develop quality code. Because the company that I work for will not purchase a canned software package, I am developing a web based CMMS (Computerized Maintenance Management System). I GPLed the project and put it on SourceForge hoping to help other people in my situation. The project is attracting much more attention than I anticipated. I have observed the development of many OSS projects but almost all of these have been by developers, targeted to developers. So what advice can you give a novice software developer on managing an open source project? What dangers and pitfalls await me? How does one foster more developer involvement? What resources should I exploit to keep from screwing this project up?"
This discussion has been archived. No new comments can be posted.

OSS from Non-Developers for Non-Developers? More

OSS from Non-Developers for Non-Developers?

Comments Filter:

  • Take a que from someone successfull doing it... (Score:3, Insightful)

    by HRbnjR ( 12398 ) <chris@hubick.com> on Thursday October 09, 2003 @11:44PM (#7179928) Homepage
    "My biggest job is to say 'no' to new features"
    -- Linus Torvalds

  • Remain Focused (Score:3, Interesting)

    by yancey ( 136972 ) on Thursday October 09, 2003 @11:44PM (#7179929)
    One danger of open-source projects is that everyone who gets involved wants different things from the project and begins to add features or change the design to meet their individual expectations. While you want to be open to ideas, you also need a solid and reliable working project when you're done. Don't let the peoject spin out of control.

    My suggestion is that you make very clear the goals of the project and the list of features that the software must have and then try to keep developers tightly focused on these things. Also make it clear that new feature ideas must be discussed and those in charge of the project must agree to add that new feature to the list before anyone starts trying to implement that new feature.

    If someone really wants to include a feature and you feel it's too much work or a feature you don't need for yourself, then you might say something like the following, "I like your idea and can see your need, but I need a working product first. Once we get my part done (version 1.0), then we can add your feature for future versions."

    Keep everyone focused on your specific goals and you shall have your project completed on-time and efficiently so. Otherwise, you run the risk of many developers adding whatever they want, whenever they want, and having lots of extra useless so-called "spaghetti" code that may or may not help you.
    • I would agree with this to some extent, but if new developers can't scratch their own itches, then they may just walk.

      One effective way of avoiding risks associated with feature creep is to use some form of plugin system. Some projects use this quite effectivly, so that each new feature dosent mess up the rest of your code base.

      This does all depend on how long and how many developers you have.

  • TODO immediately (Score:2, Informative)

    by Dancin_Santa ( 265275 )
    1. If you have a mailing list, find one or two developers or power users who you find particularly astute and sociable and ask them to become your program managers.

    2. If you do not have a mailing list, start one.

    3. Maintain control over the project at all cost by checking in all changes to the tree yourself and not allowing others to do so. If they want to fork the tree, it's up to them.

    4. Once #3 becomes too much work, ask one of the people you selected in #1 to become the project Boss and take over th
  • "Warning: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) in /home/groups/f/fr/free-cmms/htdocs/maint/equip_tr e e.php on line 52 Warning: MySQL Connection Failed: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) in /home/groups/f/fr/free-cmms/htdocs/maint/equip_tre e.php on line 52 Could not connect to the databse server"

    Okay, but seriously, the above is not such a big deal, except that you are able to read from the DB - one would t
    • <p>I know that the equipment selection does not work. It is fixed in CVS.</P>

      <p>Concerning quality code... I 'get' reuseabilty, modularization, configurability, consistency, and levels of abstraction. Mostly from reading about good software development practives and browsing sucesfull OSS projects similar to mine. Also I double majored in math. That seems to help.</P>

      <p>I tend to keep one eye on quality of code and the other on getting code working. I leave some code weak the
  • By training and title I am a Mechanical Engineer. I have never been involved with any serious software development

    By training and experience I'm a software developer. I've never been involved with any serious mechanical engineering.

    I plan to build a steam engine. I don't know anything about the tensile strength of the metals I'll be using, or how to calculate the steam pressure.

    But I figure, hey, it can't be that hard, right?

    So why won't anyone sell me life insurance once I tell them about my project?
    • Ignore the AC Troll - yeesh "I am 3l33t too!!" cripes.

      From what I have seen everyone here gives good advice - even the parent of my post. You are not a software developer - you admit this - (and *That Is Just Fine*)- dont get me wrong. What you will need eventually - as it looks like your project has some big aspirations - is a person who knows a thing or two about design. You being a ME can appreciate design. It (as the parent tries to comically point out) is tragicallly mis-understood about software. J
    • I'm not sure that your analogy is legitimate. You're comparing writing what seems at first glance to be an internal web-based app with designing a somewhat complex device that can, as you pointed out, kill someone. There are software projects like this as well (airplane controlling code, missile guidance code), but the story submitter is not considering writing these. He's taking on a fairly simple task.

      Will he have to learn? Sure. Does it compare with potentially lethal projects? No.
    • If you wanted to build a very simple boiler for a specific purpose and you had at your disposal the designs of scores of similar boilers and could converse with the designers of those boilers, then go for it.

      I know my skills and how not to exceed them.

    • Have you ever learned anything in your life? I know how to build a boiler that is safe. I know because I'm interested in that, so I learned something about it. I know you either build it for 1000 PSI, and then never run at 5 PSI (which is still a lot of energy) while encased in a strong building that you don't enter while it is on. If you don't want to do that you test it by filling with water, and then measuring how much more water you put in to get to 3 times (at least) the presure you want to operat

      • I don't build boilers not because I can't, but because they are dangerious (sic) enough to require more testing than I'm willing to give.

        And my point was that if the original poster wished to proceed with his programming project, he should educate himself about it -- and educating youself is a lot more involved than posting an "Ask Slashdot", (seekers of free legal advice notwithstanding) --, and having proceeded, not forget to do the required testing.

        You illustrate my point for me: you don't build a boi

        • I think the orgional poster showed himself perfectly capable of learning all he needs to know. He wrote the program, and it works. He is running into problems with project management that he didn't expect, and isn't sure how to deal with, so he is asking questions. Asking questions is a valuable tool for learning. I'd say he is doing a good job, of learning what he needs to know.

  • I'm from the art world as opposed to the programming world, so please excuse the terminology.

    You should storyboard your app and let people have a peek at it. One thing that bugs me about the OSS apps I've downloaded is that they never seem to have me in mind when they develop their tools. VirtualDub comes to mind. Very cool and useful app, but man, it's a list of commands under a file menu. Virtually no interface at all.
  • When it turns into an email client (aka Zawinski's law).
  • too many cooks spoil the broth. similarly too many programmers spoil the pizza (or maybe the application in this case) . I started a project when I was in university with XML. The whole technology stack was pretty complicated. At first no one was interested, but then there was a surge of people that wanted to participate. I thought the more the merrier. but then i spent first few months just explaning the technology (offcourse I myself was new to that stack) to everyone. no fun.

  • Communication (Score:3, Informative)

    by XBL ( 305578 ) on Friday October 10, 2003 @12:22AM (#7180156)
    I know that it becomes very tiresome to reply to e-mails of people asking the same questions, wanting to help (with no real skills), and requesting features. However, you must do your best to efficiently handle all of the communication a project needs to survive.

    Maybe you could set up times for people to chat (you included), and try to maintain an active and coherent mailing list. Instant messaging is also efficient.

    Also, prepare to be disappointed over and over again. People have good intention in helping out on these projects, but I bet well over 50% of the stuff that people say they will do never happens. I am very guilty of this myself.

    Finally, be sure to do *real* testing on the software, and try to maintain some sort of metrics. Ask people how much time they are spending on the project, and see if there is anything you can do to help them manage their time better.

    BTW, the best project management tool I have every used is Bugzilla. Use it, it helps a lot with dealing with the details of development, and actual bugs :-)

  • One word (Score:4, Insightful)

    by Pyromage ( 19360 ) on Friday October 10, 2003 @12:28AM (#7180187) Homepage
    Care.

    If you care about the project, you will do fine. The biggest problem is not technical. It is not of arguments, flames, and users. More commonly than any other reason for a project failing is that the author fails to maintain focus and follow-through.

    It's *your* project. You keep it alive by making it the best, and keeping it that way.

  • Hmmm. (Score:4, Informative)

    by The Cydonian ( 603441 ) on Friday October 10, 2003 @12:43AM (#7180269) Homepage Journal

    I don't know if you realise this, but just to point out:-

    a) There are MANY competent OSS programmers who don't have a CS degree behind them. I'm a subscriber to a GPL-ed software's mailing list, and the resident guru in that list is actually a political science professor from somewhere in the Mid-West; he's the sort of guy who has a (correct, insightful) answer to just about anything regarding the said software. And his case is not alone in the OSS world; RMS, for another, comes to my mind (he has a BS in Physics from Harvard, if I remember correctly).

    b), Your questions are mostly of the non-technical kind; you seem to be more worried about interaction and growth issues, than technical competency.

    So the good news:- congratulations, you've got what it takes!

    You've obviously got the enthusiasm (otherwise you won't Ask Slashdot, so to speak), you've got a base of developers who are keen to contribute, and finally, you've got the technical capability to understand and, perhaps, guide the project as it grows.

    I won't answer your questions directly, however, I'm sure there are other even more experienced programmers and lead developers here who can give you a better reponse. In fact, I think your questions are very legitimate and hit close to the heart, am planning to GPL a project as soon as it hits a certain code threshold, so will keenly follow the ensuing discussion.

  • Kibitzing... (Score:2, Insightful)

    by Ramses0 ( 63476 )
    IANASOSPL (I am not a successful open source project leader). I come from a technical background, with the computer science degree.

    I agree with some of the existing sentiment: Care! If you want your project to succeed, and your users also want it to succeed, it will succeed.

    In your situation, don't be 100% afraid of branches forks, and don't let yourself get pushed around by techy people who "know the right way to do things". Let them maintain their own branches (support the most serious ones if you ca

  • Some tips. (Score:4, Insightful)

    by Yaztromo ( 655250 ) on Friday October 10, 2003 @02:45AM (#7180754) Homepage Journal

    My project recently celebrated its first year o being Open Source (http://www.jsyncmanager.org [jsyncmanager.org]. While I've been working on this project for the last 6 years now, it's only been in the last year that I've had to deal with other people working with my code, and managing their efforts. A few things I've learned along the way which might be helpful:

    • The people who work with you on your project are volunteers, so you have to treat them as such. Sometimes they'll have more important things to do than work on your project, which can, at times, make deadlines a difficult thing to enforce. It alos means you have to show appereciation for their efforts -- if they don;t feel they're getting something out of their time, they'll drop whatever they're working on and leave the project.
    • Expect at least 75% of the people who offer to help to end up doing absolutely nothing. I've had lots of people with great ideas and apparant energy offer to help with my project. I'll take the time to get them setup with the various permissions and resources, and may then never hear from them again (some of the more polite ones will appologise for not being able to be active in the project). Don't take it personally -- when people aren;t getting paid, sometimes their excitement at joining an interesting project outweights their actual desire to do any work :).
    • If someone leaves your project, regardles of wether they contributed anything or not, thank them for taking the time to join in the first place. Even non-contributors have their hearts in the right place.
    • Try to build up a solid core of developers, and then delegate. If at all possible, put different people in charge of different areas, giving them as much creative control as possible. Make these people you "leiutenants". This is particularily important for those development areas you either aren;t good at, or simply aren't interested in.

      In my project, my core strengths are with the base synchronization protocol stack and engine -- the really low-level stuff. That's my domain. Some of the things that hold no interest to me include the user interface portions of the project. Thus, I put someone in charge of UI development, giving them full creative control (although I'n known to offer feedback :) ). I found someone who is an expert on UI design, and leave them to their task.

      Build a community, and build bridges to other development communities that may find your project useful in their own projects. You never know where it might take you, or who might discover your project through another project. The jSyncManager (my project), for example, has ties to the jUSB Project [jusb.sourceforgenet], and OpenOffice.org'q Glow Groupware Client [openoffice.org]. Scratch their backs, and they'll scratch yours (and if your project needs an open, platform-neutral Palm handheld data synchronization facility, let me know :) ).

    • Become a shameless promoter of your project. Bring aboard someone who knows a thing or two about marketing. Write up press releases every time you meet a significant milestone, or make a significant release, and send them out into the wild through every channel you know (just don't abuse them -- no spamming via e-mail or newsgroups, as that just pisses people off),
    • Write good documentation. Better yet, get a volunteer who can write good documentation :).
    • Have fun, and make sure your volunteers are having fun as well. Share the credit and prestige with everyone who makes a contribution, no matter how small or insignificant. Make sure people are doing the types of work they want to do as much as possible.
    • Have fun!

    I hope this helps!

    Yaz.

  • Learn to reject (Score:3, Insightful)

    by DarkDust ( 239124 ) <marc@darkdust.net> on Friday October 10, 2003 @04:06AM (#7180979) Homepage
    As project leader (I assume that you have that role in your project :-) you have to reject patches/feature requests sometimes to avoid creeping featurism. That is, too many fancy features can render your project a nightmare to program in and introduce even more bugs than is normal.

    I don't mean to reject really useful features, but if a feature is not obviously useful consider rejecting it in the name of code cleaness.

  • Just be helpful, up to a certain point (Score:3, Interesting)

    by AlXtreme ( 223728 ) on Friday October 10, 2003 @08:17AM (#7181738) Homepage Journal
    Another aspect is having a project leader that knows how to interact with users. It's a very simple way to either rise above otherwise mediocre programming skills, or to turn a perfectly good project into a deserted wasteland. People like enthusiastic or helpful leaders, not whiners or hermits. Running an Open Source project means more than just writing code.
    Was just finishing an essay [xs4all.nl] on the 'OSS development model', partly on my own experiences from my own projects. Although being an undergraduate AI, having a BSc/MSc really doesn't help you to lead an open source project. The only way you can learn to lead a project, is to learn by experience. If you lead a project that sticks out, it's very much a matter of having the right people-skills, imo...
  • "How does one foster more developer involvement?"

    Try couching your advertisement as a question on a major tech news site, that should do the trick. ;)
  • if you really care about your product, write a test for every feature you add or change or every bug you fix. This may seem like a lot of extra work, but it will pay out when you would otherwise be asking questions at slashdot how to keep the oversight on your complex project.
    Now use aegis to make you adhere to a sane development process instead of just flying by the seat of your pants. Most planes have bank indicators and gyro's too these days.
    And because it is so fashionable, get a wiki to so you have a s
  • I'm also not a developer by training or nature. I study philosophy and politics, and have a short coding attention span. I hate problems I can't fix quickly :-)

    My advice, after working on QuickRip for almost a year, is to get some developers on board as quickly as possible. I quickly found that I was adding lots of features without having the experience to keep the code clean, well structured and efficient. Once I got some developers on board who had more experience and training than me, things started to

Slashdot Top Deals

Math is like love -- a simple idea but it can get complicated. -- R. Drabek

Close