OSS from Non-Developers for Non-Developers? 45
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?"
Take a que from someone successfull doing it... (Score:3, Insightful)
-- Linus Torvalds
Re:Take a que from someone successfull doing it... (Score:2)
Remain Focused (Score:3, Interesting)
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.
Re:Remain Focused (Score:1)
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)
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
Um...no you aren't...:-) (Score:2, Insightful)
Okay, but seriously, the above is not such a big deal, except that you are able to read from the DB - one would t
Re:Um...no you aren't...:-) (Score:1)
You'll note that your two useful points are not contrary to mine.
I think the underlying contention is between 'good hacker' (who can slap something together sufficient to solve a problem) with 'good developer' (who can do
Re:Um...no you aren't...:-) (Score:1)
<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
What's a pressure gauge? (Score:1, Troll)
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?
Re:What's a pressure gauge? (Score:2)
Your wit has disarmed me.
But I've seen too many (kludgy, non-scalable, spaghetti-coded) Microsoft Access "solutions" not to be somewhat skeptical of amateur programmers.
Re:What's a pressure gauge? (Score:2, Insightful)
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
It's not the Tower of Pisa (Score:2)
Will he have to learn? Sure. Does it compare with potentially lethal projects? No.
Re:It's not the Tower of Pisa (Score:2)
Good point. My analogy should have been better.
Re:What's a pressure gauge? (Score:1)
I know my skills and how not to exceed them.
Re:What's a pressure gauge? (Score:3, Insightful)
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
Re:What's a pressure gauge? (Score:2)
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
Re:What's a pressure gauge? (Score:3, Insightful)
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.
Storyboarding (Score:2)
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.
You Know It's Gone Overboard (Score:1)
Re:All OSS developers (Score:2)
Re:All OSS developers (Score:2)
My washing machine isn't OSS-capable either. Dirty scumbags.
too many cooks (Score:2)
Communication (Score:3, Informative)
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)
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)
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)
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)
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:
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 :) ).
I hope this helps!
Yaz.
Learn to reject (Score:3, Insightful)
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)
Suggestion (Score:2)
Try couching your advertisement as a question on a major tech news site, that should do the trick.
get Aegis, do NOT! use cvs (Score:1)
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
From a non-developer to a non-developer (Score:2)
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