Slashdot Mirror
OSS from Non-Developers for Non-Developers?
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?"
"My biggest job is to say 'no' to new features"
-- Linus Torvalds
"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_tre 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 think you should be able to write. This implies to me that the code to do database work isn't split out into a testable and self-referential unit (I don't know this, guessing). It also implies you haven't tested it since you last updated it. (This one is less of a guess.
My issues with the statement "I have never been involved with any serious software development although I am competent to develop quality code." is that, unless you've walked the walk, "competence" can't really be said to be reached. You might be able to turn out okay code and pretty UI, but 'quality' is in a myriad of little things. Like the above. Like making it highly configurable, and meta-configurable, so it can solve more than one problem at a time. Like maximizing reuse and minimizing duplication of effort. Like knowing at what level of abstraction to code to. Etc.
That said, I do want to encourage you - it's an interesting project, of adequate use. There's already stuff out there that does stuff vaugely like this that could be adapted, but they tend to get large and complex. You seem to be shooting for simple system to solve a straightfoward problem that has a consistent UI - an admirable goal.
Given that, I'd start out by clearly defining your goals (things like: not that complex and have few dependencies, not a reimplementation of <some other thing>, simple UI, should send email, request types should be more heirarchical) and non-goals (while sending emails is an option, this will never be extended to allowing users to read their email, we will not be including a discussion forum, this will never be skinnable or templated, the low bang-for-the-buck of foreign language support is not desired, etc).
Define coding standards and stick to them (unless someone suggests a better one). I'd keep a tight control, and code review each change both for functionality as well as 'feel'. Keep things highly modularized, keep the interfaces consistent, and avoid monoliths (big sets of source that do lots of things) at all cost.
Try to keep it to a smallish team of motivated individuals - one or two like you, one or two who are very unlike you, one or two who do have more serious development background. Designate one person as 'infrastructure architect' (not you), and one as 'UI ombudsman' (also not you), and maybe some 'tech domain experts' (also not you, but someone with specific knowledge - like how to get it to work on NT or linux or how to import user lists from an LDAP directory, or something). You get to make priotizations of feature requests or suggestions, and then allow the other team members to pick what they want: you get stuck with the highest priority ones that nobody else wants to do. It's a good split, with adequate responsibility and interest levels for all.
My $.03.
-J
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.
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. Just like a good HVAC system needs a blueprint - so does software. One thing you want to do is find one of your contributers to be the Architect of your software - you can be the Overlord - deciding what does, and what does NOT go in - but let a pro, if you can find one, see to the nitty gritty of design.
"OK", you think, "but I get to say where the 'foo' button is - no damn designer for me there" - you are right. Much like a customer gets to tell you - "I want the 'On' button 'there' you still get say-so. But when it comes to code 'I think I have a shorter run time doing it this way' is all thiers. In short - what the parent tried to point out was - you are a professional, you have started a hobby project, you asked what does it need to be a professional job, the parent's answer - a professional.
Seraphim
Slashdot, where armchair scientists get shouted down and armchair theologians get modded up.
IANASOSPL (I am not a successful open source project leader). I come from a technical background, with the computer science degree.
s )
:^)
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 can) or encourage them to fork it (in a good way! Sometimes the most important projects fork and re-merge, it's a part of evolution).
If it is truly better than your way, reap the benefits and re-integrate, either you at the helm, or that other hacker now in control.
The CEO of a company doesn't know how to write code, or manufacture widgets, but he knows that it needs to be done. You should feel the same way abour your project. Past a certain point, it might "need" a certain feature, or technical requirement that you don't feel the need for, or can't implement yourself. Remember humility and ask them to take the lead and implement the feature. If *you* can't figure out how to use it, or if it breaks too many other things, or becomes too complicated, then that fails your acceptance criterion. Try to work with them in order to get it compatible with the "mainline" distribution. Otherwise, provide links to their work or host patches or alternate versions as well. See UseMod wiki as a great example of this: (http://www.usemod.com/cgi-bin/wiki.pl?WikiPatche
Read kernel traffic! (http://www.kerneltraffic.org/kernel-traffic/), it is the most shining example of the open source process at work. Big-name technical people have the interesting technical spotlight shone on them (weekly, no less!) by Zack Brown (THANKS, ZACK!). It is an excellent example of disparate people working together on a vital portion of linux systems, and how even though one person might not have all the answers, together, they are able to come to an acceptable solution.
Most of all, have fun! Fun is fun, especially when you can get paid to have it at work, and still be doing something that is helping you with your job!
--Robert
My project recently celebrated its first year o being Open Source (http://www.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, and OpenOffice.org'q Glow Groupware Client. 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.
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.
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 operate. Do that test monthly, and using formulas that are easy to find you quit using the boiler when it no longer passes. I also know that no matter what pressure you run your boiler at you need a license in my state which verifys that you know this.
Mind you, the above is over simple, but close enough for purposes of discussion. I learned all that. I'm a CS major, and I'm an expert programer, but I can build a boiler because I'm smart enough to learn all the details I need to know. I wasn't born with a CS degree, I had to learn that too. I have no doupt that a ME with expirence in boiler design can design a boiler that will be cheaper to build, and operate longer with less tests required, and can perdict when the boiler will fail. However I know my limits in compensate. I'm also well aware that I could learn strenght of materials if I wanted to spend the time to get a ME degree and design a boiler right.
The origional questioner gave evidence that he learned something about programing, and did a good enough job. He never claimed to be better than anyone else. He would likely agree that I could re-write his program and it would be better. However he has knowledge that about how the forumlas work that I would have to learn in order to make it right. My first try at a program like this wouldn't be as good as his because he knows something about ME, and you need to know something about ME to write it right.
If you do something without learning anything about it, and compensating for your limitations, then you will do bad. Smart enginners do not have to limit themselves to one area because they can think, learn, and are smart enough to find out where to compensate for their weaknesses. I don't build boilers not because I can't, but because they are dangerious enough to require more testing than I'm willing to give.
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.