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
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.
Ouch! The truth hurts!
You might want to use POST variables instead :)
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 the responsibilities in #3.
5. Keep a close eye on the project, even if you are no longer the Boss. Your initiative in creating the project will not go unnoticed, so your voice will have a lot of weight in settling any important project directional matters.
6. Require all patch copyrights be signed over to you or whatever entity you establish as the owner of the copyright to this product. (this will come in handy later when you turn around and make the project closed and screw all your non-paying customers) Ask for an affidavit for every patch proffered.
7. Don't be an ass
8. Don't be an ass
9. Don't be an ass
10. Don't be an ass
"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
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?
Opinions on the Twiddler2 hand-held keyboard?
u suck at programeing
I think you're right. But thank God he's good at programming.
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.
"Derp de derp."
When it turns into an email client (aka Zawinski's law).
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
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.
Consensus is good, but informed dictatorship is better
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
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.
Perhaps you need to open your mind to the experience.
Ouch! The truth hurts!
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.
More than mere navel gazing.
Oh, like what, copying and pasting code from SCO innovative blueprints?
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
Nothing open source ever works on my machine.
Have you tried plugging it in?
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.
May we never see th
Nothing open source ever works on my machine.
My washing machine isn't OSS-capable either. Dirty scumbags.
May we never see th
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.
This sig is intentionally left blank
"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.
It's 10 PM. Do you know if you're un-American?
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 spot where feature requests can be ignored.
This space is intentionally staring blankly at you
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 improve in QuickRip, and my coding improved.
The other thing is to make good use of alpha and beta releases, something I've failed miserably on. Release an alpha if you just want feedback on ideas, and release a beta once you think you've got a proper release ready. If you're anything like me, you'll have left a few silly bugs in, so giving the beta a week or two will make sure these bugs get squashed and your release looks professional, and doesn't annoy users. That, and it saves you spending hours responding to the same support requests for the same old bugs!