Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

How To Best Manage Open Source Projects? 73

Posted by Cliff from the stuff-to-read dept.
This member, from the voiciferous Clan Anonymous Coward asks: "I work for a fairly large company, and I'm trying to convice the senior management to open source a piece of internally developed software that we rely upon, but that we don't directly profit from. This software enables our business model, but the software itself doesn't offer any particular competitive advantage. (Actually, to be a little more accurate, we would like to develop a system that replaces a commercial off-the-shelf solution that we're less than happy with, and open source that, so if you have anecdotal evidence or other ammunition for that particular argument, I'd be glad to hear it)." And this is something that I think more businesses should look into doing. If you use a piece of software that your business doesn't depend on, commercially, why not free it? (Read more...)

"What I'm really looking for is advice on how to make the project successful as an open source intiative. Specific issues include, but aren't limited to:

  • Where/how should we host the project? Something internal? Something like SourceForge?
  • What management structures/tools are helpful? At minimum we'll need a source-code repository and a mailinglist/newsgroup, right? Anything else considered critical?
  • What are some effective control stuctures? Who should determine what makes it into an official release? By what procedure? Who should be able to add code to the tree? What kinds of resources do we need to commit to this project to make it effective?

In short, what advice do you have on the mechanics and management of open source projects?

I'm familiar with the standard technical and business arguments for open source software (including:

and others), and feel I can articulate them pretty clearly, but that's not really what my question is about."
This discussion has been archived. No new comments can be posted.

How to Best Manage Open Source Projects? More

How to Best Manage Open Source Projects?

Comments Filter:

  • Re:Making the code sanitary (Score:1)

    by Anonymous Coward
    "Sensitive data" is a relative word. Some companies might try to protect apparently non-sensitive stuff just so that other companies do not know what kind of work goes on. Extrapulation can be made by competitors if they know what kind of tools you are using. Determine what impact your potential open-source project has in relation to the above before you approach management.

  • Re:Think carefully before you do this... (Score:1)

    by Anonymous Coward
    Sure, Security through Inspection works better than Security through Obscurity in the long term. However, for large projects that grew up without massive inspection, the level of security drops during the transition from closed source to open source.

    Even if outside contributors do jump in immediately, how long would it take before every line of code is read by a benevolent programmer? How long before every line of code is reviewed by more than one benevolent programmer? The conversion process does not take zero time and in the interim, the company may be at greater risk if it does not have appropriate safeguards.

    Security concerns cannot be dismissed simply because you say that Security through Obscurity does not work. Depending on the situation, the short-term hit to security may even outweigh whatever advantages the company hoped to gain from open-sourcing the project. Security through Inspection works for the open source examples you gave because they were built from the ground up that way.

  • The development of the airplane has nothing to do with the development of the atomic bomb nor the chemical and biological weapons that have been developed. The Wright brothers developed an airplane, nothing more. They didn't "collaborate" with the developers of the atomic bomb to create some sort of ultimate weapon. The time frame isn't even correct. Even if the Wright brothers had been working with the developers of the atomic bomb, this has nothing to do with "open source" software. No one is developing "open source" nuclear or biological weapons that might be delivered by "open source" aircraft. Please try to keep your paranoia's to yourself. You might want to consider getting professional help. Derry Bryson
  • If you think it is worth something to someone, why not license it to them and make a few bucks?

    Because the potential boost in code quality or performance resulting from contributions may be worth more to your organization than the few bucks is, perhaps.

    If you don't think it is worth something to someone, why bother opening it up?

    Because you might be wrong. Even if you're not, 'worth' sometimes doesn't have anything to do with why a hacker might spend some time optimizing code or fixing bugs.

  • You know, I'm not completely buying this anymore.

    Open-and-secure is admittedly WAY better than secure-now-but-with-bugs-later-on. However, there are a HUGE number of exploits available now for Linux, far more than there are for Windows. The Open Source ethos is making Linux *less* secure than Windows for your average overworked admin, not more.

    Now, over the long term, I think this will change. Gradually, people will learn how to write secure code and will beter grasp security implications of the things they do. Linux and the other Open Source apps will get more and more secure, where closed-source apps like Windows will never improve very much.

    Eventually, code that is open to inspection will be a critical component to assuring that a system is actually secure (at least in terms of exploits and not human engineering.)

    But that doesn't change things now. Linux has bazillions of exploits, far more than what I've seen in Windows. I've been watching both over the last two years and I have to actively patch my Linux boxes a lot more often than my Windows ones.

    So why is this? I think it's because people don't yet know how to write secure software, and all that code is available to easy inspection. It's a lot harder to reverse engineer something through a debugger and packet sniffer. In REAL terms, Windows is probably a lot less secure than any of the Open Source apps, but in terms of actual available exploits, it's a lot safer than Linux is for the moment. (assuming best practices on the part of the admins running the boses -- an out-of-box Windows machine is a joke. But if you harden both a Linux and a Windows box 'properly', chances are there's going to be a new root exploit for the Linux box first.)

    I have arrived at the pet theory that ALL software is HORRIBLY insecure. I think in twenty years we will be laughing at the state of our networks today.

    For the moment, closed source may actually be better for many companies. Their apps are insecure anyway -- why make it easier on the guys in black hats? I am really starting to think that a good chunk of the full-disclosure-of-exploits, open-source crowd isn't pushing that idea for MY benefit but for THEIRS -- because they can spend more time studying new exploits and figuring out ways to get into my machines than I can.

    As the knowledge of how-to-program-apps-securely proliferates, it will be safer to gradually transition to a TRULY secure environment. But right now, opening apps written by desktop-trained programmers is just not a very good idea.

    I suspect that it'll take one more generation of programs and programmers before we can safely make the transition to a truly open-code environment. Once we get there, we'll be nearing the realm of 'real' security.

    But until then, the false security of no-working-exploits-for-my-machines will have to do -- and Windows has fewer exploits available.

  • When I was releasemeister for a project, we had a five-tiered system:
    - Major release number
    - Minor release number
    - Release revision number
    - Lab patch level
    - Field patch level

    Minor release numbers changed when we added significant new features, revisions were for maintenance releases (bug fixes only), lab patches were for hot fixes developed in the lab (which hadn't gone through a complete Q/A cycle), and field patches were fixes done on-site when we couldn't duplicate the problem in the lab. (This was software that interface with phone switches, so it was often necessary to tweak it in the field so it would work with someone else's tweaks to the switch hardware.) We never had development releases, all outstanding (reported) bugs had to be addressed before a release was frozen. Any experimental development work was done on code branched off from the main path, to be integrated (or not) back when it worked. We always released the X.Y.Z.0.0 version, but I remember our most long-lived release was 2.2.0.4.2.
  • Pewople seem to ignore that there's more than profit to a business, there's also maintenance just alike any sort of physical or abstract machinery.

    Since I'm not a suit, I've never heard the term "depend on commercially". To me, seemed logical that anything that a commercial entity depends on, whether for direct profit, internal infrastructure, or maintenance purposes, is something that it "depends on commercially". Apparently that isn't the standard definition.

  • Huh? (Score:1)

    by Zagadka ( 6641 )
    If you use a piece of software that your business doesn't depend on, commercially, why not free it?

    If you use a piece of software that your business doesn't depend on, commercially, why are you using it?
  • Here's a really contrived example... You open your code, giving your competitors an advantage, but making everyone more efficient and allowing the industry to expand the market.

    That really is a contrived example... :-)

    I don't think that if Nike gave Reebok a better accounting system (even assuming the relative scales you suggested) that it would "expand the market" in any way that would end up being beneficial to Nike. I don't deny that there may be other situations where this situation could be true. It would be interesting to determine how one could identify those pieces of software that would result in a mutually beneficial "market expansion", as opposed to software that would just give your competitors an edge.

    One area where this may be true is the area of "B2B middleware". (I may be seriously abusing some buzzwords here...) Another, hopefully less contrived, example: If Nike released the portion of their purchasing/inventory system that communicated with their suppliers, that might cause more suppliers to become "compatible" with that software, allowing Nike to more efficiently get supplies from more sources. The fact that Reebok would then also be able to use this software wouldn't hurt Nike as much as releasing the software for suppliers would have helped. By having it completely open, it would encourage more suppliers to use it, than if they made it available to suppliers only, because then suppliers would know they're not getting locked in to Nike.

    It looks like the key thing here (at least in this example) is interoperability. If you want the people you work with to be more interoperable with you, it might make business sense to release some code. By making it open, instead of on available to the people you work with, it encourages others to standardize on your interoperability layer. That in turn could expand the whole market.

    In any case, my whole point in this thread has been that you can't just blindly say "we don't sell this software, so let's just give it away", because giving it away can, in many cases, give your competitors an edge. Instead of being an open source zealot and driving your company out of business, you've got to think about what advantages you'll get from releasing the software. Hopefully, those advantages will be at least as great as the implicit disadvantage caused by your competitors getting a free ride. If not, however, it's probably best to keep the software closed.
  • Sure, other companies may be more efficent because of it, but I'm sure that they'd be putting as much time into supporting it as you are, so I don't see much of a difference there.

    Except you put a huge amount of time and effort developing it in the first place. Sure, you might get a couple of bug fixes, but in return for possibly enabling a significant improvement in the efficiency of your competitors. It's far less risky to just keep the code closed.

  • Ok, that's my... well, about $1.50, cause I can't call that $.02 ;-)
    Damn inflation these days ;-)

  • Re:?! (Score:1)

    by afc ( 12569 )
    s/idealogy/ideology/

    Now that our daily spelling nitpick session is over, we can proceed with our uncalled for advice: next time, kindly comply with your own precepts and keep your posting as a secret to yourself.

    Slashdot will thank you, I'm sure. Have a nice day.

  • Some time ago I wrote my experiences (with generic OSS project management) up. I don't know if much of the stuff in there applies to your situation, but there's also a good deal of links to other similar texts in there. Have a look at it: http://sunsite.auc.d k/lgdc/articles.php3?mode=body&articleid=1 [sunsite.auc.dk]
  • If a company wants to use your code internally and not publically distribute it, how can you "force" them to give you the updates?

    Hired goons? Hidden cameras? On-site audits?
  • If you use a piece of software that your business doesn't depend on, commercially, why not free it?

    Maybe becuase it could be valuable in the future? If you think it is worth something to someone, why not license it to them and make a few bucks? If you don't think it is worth something to someone, why bother opening it up?
  • Obviously, the examples used are lousy and you have never been authoring an open source project.

    No open source or even free software project has succeeded without a huge part of collaboration. Have look at a few of the absoluetly biggest ones: BSD, Linux, BIND, emacs, gcc. They all have a very large part portion of collaboration attached.

    Yes, most projects have a more or less strict dictator that runs the show, but without the support of the masses the project will never get ported to enough platforms, get all those shallow bugs fixed, get the nifty ideas, receive the cool support scripts, have support sites with various unsupported patches and more.

    If you're alone, your software will take ages to reach the state you do when collaborating.

    Comparing this with the atomic bomb or Newton's discoveries don't really apply.
  • Keep It Simple, Stupid! Feature-creep, bloat, complex code, etc, are all ways to create slow, unmaintainable, unusable, buggy code. If that's what you want, fine, but if you want something you can use, keep things simple.

    Yeah, definitely. Split the new application into two parts: a core open source project and then the extended functions. The basic stuff (accounting, mail, whatever your application does, defined broadly) may be of use to everyone, and they'll appreciate it. But if you're an oil company, releasing a bunch of ultra-specific sub-apps to calculate profit potential per barrel may be unnecessary. An additional benefit of this way of thinking is to protect any methods your company uses that could give others a competitive edge.

    That shouldn't stop you from releasing the basic part, whatever it is. Open source accounting with a well documented plug-in dev method would be great, for example. We sure could use one here in nonprofitville.

    -jpowers
  • If I recall correct the most dominant OSS projects always succeeded on these two premises: I work as if I have to do it myself, I coorporate as if I can't do it (all) alone.
    Most OSS failures have to do with the deception that "if I set up this big pot, people will be generous enough to put their stuff in it."
    Cook the soup. If people likes it, they will spice it up and keep the soup aboil. Nothing more, nothing less.

  • ?! (Score:1)

    by nphinit ( 36616 )
    Tech companies have no responsibility to act as open source charities...the phrase "there is no point in keeping it closed" is patently ridiculous. The first rule is to protect secrets from competitors; the default is NOT open, nor should it be. If there is no overt benefit FOR THE COMPANY to open a project, why should the company consider it? It costs many man hours...(the US Government still has things classified as "top secret" that are from the 1700s, no joke. It's just not worth the spent resources to divulge.) Maybe for public relations, but that's just showmanship. Companies will only open projects when there is a POINT to doing so. I'm so sick and tired of this "open equals good, closed is of the devil" idealogy.

  • The key to a successful open source project is getting people involved:

    • Keep the browsers coming back. Update your project's Web site frequently. Make a what's new page and keep it current. Submit your site to the search engines so that even if someone's not looking specifically for an open-source replacement for an existing system, they'll find your project. It's an evil marketing term, but mindshare is important to any open-source project. People who are just browsing one day might turn into users the next.
    • Give users something to use. Release early, release often. Put up screen shots so users get hooked. But it's best to underpromise and overdeliver. Don't put up a code baseline unless it compiles and (mostly) runs. Make it easy for users to try it out. Provide binaries for common platforms. Write some doc -- it won't kill you. Start a FAQ on day #1. Users are your best source of bug reports and suggestions for future releases; make them feel part of the process and grow them into coders who submit patches.
    • Remove road blocks for contributors. Avoid Inner Circle Syndrome by letting anyone submit patches and feel like they're actually considered for the codebase. Talk about issues in a public discussion forum. Don't hide what you're working on or where you want to end up -- remember the Cluetrain [cluetrain.com]! Put up a roadmap so someone new to the code has a chance to figure out how it all works. Ask for volunteers where you need them.

    I would be remiss if I didn't point out that my company [openave.com] is building an infrastructure to do all this on the Web. Next week, we'll be releasing Web-based submissions management and version control to take down even more road blocks.

    Bob Arnson, OpenAvenue Content Sheik [openave.com]

  • On second thoughts, I think the BSD license would be a better proposition.

    It also depends on the nature and complexity of the code as well a great deal. Still, perhaps it's something to bear in mind when the lawyers start to bite months (and mucho cash) out of a potential project.
  • Lets see: Henry Ford didn't get into the car biz until almost 20 years after Benz and Daimler built the first ones. Newton didn't exactly 'invent' gravity (unless things were just floating around before) (he did 'invent' calculus but then so did Libniz), Pistols had been around for several hundred years before Sam Colt was born.

    Maybe you should get out more 8^)
  • The security concern is probably reasonable.
    But having extra contributors is sure not the only reason that open source is of benefit. I would be happy simply not to have to reinvent the wheel and deal with serveral other peoples version of the same damn wheel. Every piece of code you open source is potentially a piece somebody else will not have to rewrite from scratch. Of course this still leaves the large and fairly intersting logistics problem of how you find out someone has already written something very much like you are considering. It would be good if we could answer that one all the way down to the function/method level.

  • If their inventory system (without data) fell into the competitors hands, I don't see how that can cause a heck of a lot of damage. If they were to go open source on an inventory manager software, they wouldn't necessarily have to include all the data, would they ?

    Data != code

    Open source (IMHO) does not require you to tell everyone WHAT you used it for...

    Just my thoughts..
  • Post it to sourceforge, sourceexchange, get in contact w/ people. The web is always going to be the middle of nowhere, you've got to announce it. Pick a license you're happy with. If you don't care what happens to it BSD or MIT it. If you depend on it... GPL it. Any changes and features a competitor adds come back to you if you ask for them. Further you could charge a fee to give out a copy that a buyer can relicense as they wish. That way you establish a value for the license in that it keeps your business oiled and you want to make sure you can survive in the market in order to compete. Then advertise it to other companies such as yours to use it. It's kind of like early farmers meeting to discuss crop failures and experiences so that all could survive individually. Make sure your CEOs understand that this isn't giving things away. Unless you BSD it.
  • it had to be explained. Pewople seem to ignore that there's more than profit to a business, there's also maintenance just alike any sort of physical or abstract machinery.
  • Well see that's just it :)

    There's this idea that everything can turned into liquid assets. That there's no stratification just numbers in the same sort of logic that gets us adjectives like ungood and doublegood. Value is a derived from a product not the other way around.

    You can make guesses about the future value of a product but beyond that you don't have value until you have the product. Kind of like how credit cards work.
  • You have to be kidding! How many times do people have to point out that Security though Obscurity _does not work_!

    If you keep the software closed, the bugs still exist. The people who know how to find and exploit those bugs still exist and are still trying to find those bugs. The problem here is that your company may not know about them and therefore probably won't know when they are being attacked.

    If that was open sourced you have more people reviewing that code than just company programmers. The likelyhood of someone finding and fixing (or at least pointing out) a security hole grows exponentially by the number of contributors you have. As long as your project will attract developers, your security argument doesn't hold water. Sure there are some people who may try and find holes in your software to exploit you with, but there are far more people looking for holes to plug.

    If your argument were true, then why do so many public websites/servers run on Linux/BSD/other open source OS. They have the same issues but continuously prove to be more secure. Ever wonder why that is?

    forgey
  • Good points, but they also work the same way when you talk about malicious people.

    How long will it take a malicious user to find a security hole? Why should I assume that the first time a malicious user looks at the code he will find a hole, but it will take multiple 'nice' users a long time to find/fix the same hole?

    Your point about my examples being built that way from the ground up is a good one, but everyone has to start somewhere. If a company has significant security in place beyond the application they are OpenSourcing, hopefully any problems they would incurr due ot Opensourcing that product would be caught before any damage was done. Or even better, if the app was to be hackable, hopefully they wouldn't be able to get at any useful information/resources.

    Of course we don't even know if this application is something that is accessable from the outside world. Perhaps this is simply an internally used application that can't be accessed remotely.

    forgey

  • "Who or what is GNU?"

    Gnu's Not Unix.

    Duh.!

  • collaboration. We cannot just say, Open source is bad because it could mean a destructive thing in the future.

    We adapt, if the future holds open source as the only way to go.... we will just adapt.... we've done if for the past 4 million years.
    Free Porn! [ispep.cx] or Laugh [ispep.cx]
  • If you think it is worth something to someone, why not license it to them and make a few bucks?

    Maybe his company has more important things to do than go door to door trying to peddle a piece of accounting software. The time and effort spent looking for someone who needs his software might be more than the money from licensing is work. On the other hand, by open-sourcing it, he gets improved code for free.

    The bus came by and I got on
    That's when it all began
    There was cowboy Neal
    At the wheel
    Of a bus to never-ever land

  • One obvious objection is that you couldn't then use that code in any other project, without that project being GPLed as well.

    Or am I getting the wrong end of the stick about how GPL works? AFAIK the BSD licence would be more appropriate.

    -Ciaran
  • I've been through a similar situation. My only consolation is that now I get to laugh at the management - not to their face, of course. I wanted to put a piece of software I wrote into open source, and they laughed at me. When I wrote the thing it was reasonably current, and now, two years later, because of management short-sightedness, it's badly out of date, and not extensible at all. HAha!!!
  • How do you test an open source project?

    When Bob submits a fix for BeOs, Carol submits a fix for AIX, Ted submits a fix for VxWorks, and Alice submits one for the Mac, well, how do you test it all prior to release?
    • Can you trust your alpha and beta testers to find enough bugs to release?
    • And what can you do when your outside community of testers is still small and you know they really aren't sufficient for the job?

    Must your company get testers for all of these platforms?

    When Paul submits a new feature for the Amiga, does that mean someone needs to provide code for Linux before you can release?
  • how would open soucing something not reveal what it is used for?

    It seems to me that if I see the code for an alogrithm, i will be able to see what it does.

  • This might be moderated down, but: Why does this comment get a 1, and the previous other reply get a 0. That makes no sense, this person really didn't say anything relevent to the topic, or to any topic for that matter, but the other reply actually made an inteligible comment. (0, flamebait)
  • The whole point is that this company is not the only one in its field. This custom program undoubtedly serves a purpose that is common to the company's competition and to other companies like it. Now, these companies employ programers to maintain the solution to this problem, therefor, there will be programers who have an interest in this program.
  • It does.. just select Plain old text instead of HTML Formatted.
  • "Where/how should we host the project?"

    Host it on either a mainframe, or on your internet server, using unique logins for everyone on the project, assigning proper permissions based on what each person is going to do.

    "What management structures/tools are helpful?"

    Visit http://www.download.com [download.com] and download a schedule program. There are a bunch of other little progs that can help you keep everything going. Also get a text replacer program that does find/replace over a whole directory or more.

    "At minimum we'll need a source-code repository and a mailinglist/newsgroup, right?"

    Absoloootly. Depending on how limited your budget is, you can host a repository by opening an ftp from your cable-based home pc. I use g6 server, which you can also get from download.com. You can burn off the source code in a dated directory and allow access to your coders so they can download fresh copies.

    Each time you compile your code, you can then post updated (and approved) copies to the ftp, so coders can grab them.

    "Anything else considered critical?" A web page is pretty critical, or at least you should have a scheduler program running where people can look up what's going on in your project. You can do this using a web format, or you could go all out and code up an ASP web page where users login, set their .plan files (or work logs) and also list what files are in play, and what objective exist upon each file.

    "What are some effective control stuctures?"

    Schedules are important, email lists will help control things and so will ICQ [icq.com] if you can get people to use it.

    You can go really fancy on the SQL or ASP functions if you want, making the whole project keep tabs on everyone. IF you have people upload their work logs or answer questions BEFORE downloading the recent code source, you can force people to do things your way, and collect data from them as you go. It doesn't take too long to do this either, and it can be done in any size shop.

    "Who should determine what makes it into an official release?

    Beta testers. If you want certain things in, you can say they go, but if you get any serious resistance, you should really focus on clearing the path with revisions.

    On early releases, it is the lead coder's decision, but after that, I would reccomend either private or public beta testing to determine what is really necessary.

    "Who should be able to add code to the tree?

    No one should be able to write to the source. I would have everyone write new code modules and then have one person splice them all together with the old code. IF you have to cut out old stuff, you may just want to go in and decide what goes, and then comment it out for your tests. If it passes, I would still keep the old commented code and list where your changes are in each case.

    Only after 'point O' releases, should you be using cleaned out code. ie: keep your backups but move the project to new fresh code bases after you clear bugs and add 1.0 or 2.0...etc features.

    "What kinds of resources do we need to commit to this project to make it effective?"

    When you have time, you need no money.

    "In short, what advice do you have on the mechanics and management of open source projects?"

    Stay on top of organization and keep your objectives clear. TOE charts are the best for this, in any language.

    Form and function are important, yet function should be the highest on your list.

    Keep it simple. Do not do anything you don't have to.

    Sometimes it's better to have a clunky program that works than a really fast one that is broken and keeps crashing... but I prefer the latter. :P

    You can always fix bugs, but you can't speed up a dead mule in a day.

    /d

  • Well, our business uses Quake III, but I dare say that we get a profit out of it...

    Wait, we don't have the source for that.

    The point is, if you look at the software that you use in a business, quite often MUCH of it will not be commercially depended on, but on the other hand is quite nice to have for YOUR business. If Nike's inventory system fell into Rebok's hands (just pretend), I imagine that could cause impact.

    Sic semper Microsannis... NOT
  • If you are going to be using the software that you are open sourcing with the software you are selling, you should be careful with what open source license you use. If you use open source code under the GPL [gnu.org] in your commercial applications, that software will also fall under the GPL. However, source code under the LGPL [gnu.org] which is typically for libraries, can be used without the license infecting the rest of your source code. Only direct modifications to source code under the LGPL inherits the LGPL license.

    I personally like the GPL and LGPL better than the BSD license, because it prevents people from usurping the popularity of your software, by adding features that they only available in their binary distribution, but BSD licensed source code is definitely the easiest to use without worrying about legal implications.

  • This is just a minor comment that doesn't really get at the heart of what you were asking about, but it does address one question you had--what resources are there to support development.

    I just started a project on sourceforge [sourceforge.net], and without sounding like sourceforge's advertising department, it rocks. I'm 'in charge' of the project, and my biggest fear was that the administrative BS would get in the way of letting me code. But sourceforge really addresses that problem well. I'm a coder, not a manager, but you couldn't tell that from how well organized we are after such a short period of time. If you do get your PHBs to bless the open sourcing of your code, you should give sourceforge a look.

  • There's a lot of useful advice in prior posts, so I won't try and rehash it; I'll just add a few additional comments. I'm assuming that you're mainly interested in creating and sustaining an open source alternative to the current proprietary software you're using, and you don't have any larger business goals related to the software. I'm also assuming that a primary reason you want to convert to using open source software is to share development costs, etc., with others; thus sooner or later you'll have to get other people actually working with you on the open source development project.

    You didn't say whether you planned to develop the software using only internal people and then release it, or whether you wanted to co-develop with some independent developers from the very beginning. This can make a big difference. If you develop everything internally and then release the software then you'll face the problem of interesting people in working on something that they didn't have any part in creating, and which appears on the surface to be a company-specific project of limited general interest. On the other hand, if you try and bring people in earlier on then you'll be in a situation where you won't have anything yet that runs and is usable.

    If you develop the software totally in-house and then release it, this is to some degree comparable to projects like Mozilla. In the Mozilla project the original Netscape developers started out as the designated "module owners" responsible for particular portions of the code, and then as non-Netscape contributors came on board they first contributed patches that were checked in by others, then they could get check-in access themselves (with their code being reviewed by module owners or others) and then finally they had the opportunity to become module owners themselves for particular components. So except for people in your company everybody else starts out "on the outside looking in"; this is unavoidable under this model, and has the effect of stretching out the period before the project is seen as a true open public effort (mostly) independent of your company. (Again, Mozilla is the classic case of this.)

    So there are some good reasons to try to get other people outside your company involved relatively early on. Then they can participate as code contributors and module owners for whatever part of the project interests them. As for exercising overall control, you can have a single person overseeing the project or you can try and do a committee-style structure like the Apache folks did.

    (The Apache project is one of the most formal ones in terms of their internal organization, and it's probably worth you're checking out what they did with the Apache Software Foundation [apache.org]. Also check out Brian Behlendorf's chapter [oreilly.com] in the "Open Sources" book, particularly the "Bootstrapping" section, for some information on the types of people you'll need in the course of the project, either from your company or from somewhere else.)

    If you want to get people involved early on then you'll need to find people who are motivated to participate at the design stage. You might try looking for existing open source projects that are related to the problem space that your planned software addresses; those projects might have existing software you can reuse, and even more important may have people interested in participating in your project starting at the ground floor. (Even if you develop the software internally you're going to want to do this sort of "market study" anyway, because there's no point in doing work and then finding out that someone else has created a project that duplicates yours and prevents your project attracting developers.)

    Another option is actually contracting with independent developers to work on the project in the early development phases, either to supplement your own developers or even to totally outsource the work. (For example, this is what Galactic Marketing did with the open source workflow project [sourcexchange.com] they're doing.) Even if you contract work out there's nothing to stop you from running the project "in the open" so others can check it out and provide useful feedback (as indeed happened with the Galactic Marketing project); whether you host the project yourself or somewhere else, you want to have some level of public access so interested observers have an entry point into the project.

    That's all the comments I have time for now; good luck with your project!

  • "Depend on commercially" means selling it to make a profit. Nike doesn't sell their accounting solution, but I dare say that their business would be in big trouble if they didn't use it.

    If that's your definition, then the answer to the original question "If you use a piece of software that your business doesn't depend on, commercially, why not free it?" the answer should be obvious.

    Using your example, if Nike spent years developing a very efficient accounting system, and then open-sourced it, a competitor (let's just say Reebok) might say "hey, that's a lot more efficient than the system we use". Reebok could then start using it, save a lot of money with the more efficient system, and put the money saved towards making themselves compete with Nike better (perhaps through advertising, lowering their prices, or spending more on R&D). As unlikely as it may seem that a competitor would just start using the software, why would Nike want to take the chance? (and if nobody is going to use the software, who cares if it's open or not?)

  • How do you test an open source project?

    You compile it. You run it. If it works, great. If not, you find the bugs and fix them. It's just like testing any other other software project.

    When Bob submits a fix for BeOs, Carol submits a fix for AIX, Ted submits a fix for VxWorks, and Alice submits one for the Mac, well, how do you test it all prior to release?

    This question is redundant. The answer is the same as the above.

    Can you trust your alpha and beta testers to find enough bugs to release?

    Your question sounds like you're saying you want to release bugs, but I think I know what you mean. The answer is, "you can't." You don't worry about it, because you're Open Source. You just assume that someone, somewhere is going to catch a bug, fix it, and then be benevolent enough to share that fix with you and the rest of that software's users.

    And what can you do when your outside community of testers is still small and you know they really aren't sufficient for the job?

    Nothing, really.

    Must your company get testers for all of these platforms?

    No. That's the point of Open Source. You save money 'cause you don't have to test on all those platforms yourself. If companies had testers for all those platforms, don't you think they'd still be writing code for all those platforms. I mean, you'd still see commercial products that have versions for MacOS, Windows, Amiga, AIX, BeOS, and so on all the way down the line. Corps don't do this because it is too expensive.

    When you free the code, you let others write and test the Amiga version and they become (more or less) responsible for the Amiga version. Open Source really allows a product to proliferate onto multiple platforms more than anything else will. As evidence of this assertion, I give you NetBSD, which runs on more hardware platforms than any other. Though, IINM, Linux is quickly catching up.

    When Paul submits a new feature for the Amiga, does that mean someone needs to provide code for Linux before you can release?

    Not unless you absolutely insist on having the Linux version match the Amiga version feature for feature. This is more a management issue than anything else. You shouldn't have rogue developers adding new features that are platform specific without having those features first discussed on the mailing list. Off hand, I can't think of anything that would be platform specific enough to warrant inclusion in the Amiga code and not the Linux code. If Paul has written a new feature for the app and done it in a way that only works on the Amiga, then Paul should be asked to reimplement it in a way that works on all the supported platforms. If he can't, then perhaps that functionality doesn't go in, or someone else gets to implement in a platform-independent way. I would not ever allow something like that to hold up a release. You can always exclude that feature from the release, or just choose not to document it.

    <flamebait>Anyway, I wouldn't be worried about features on the Amiga, myself. If igure anyone who still uses the Amiga would be eccentric enough not to notice that their version has additional features. If they did, then yippee for them. They have cool features no one else does.</flamebait>

  • Don't forget liability. Your errors may or may not be disclaimable. However, by providing the source, you have a stronger case to disclaim responsibility for errors, since the user has the same opportunity to find them, and the same risk, as you do. Also, if you get lots of submissions and use a Linux-like model where the authors retain ownership, you get dilution -- there are many eyes on the code and many are responsible for the bugs.

    We do this with other States (I work for North Carolina) on a share-by-request basis. We get the benefits of other States' and public instituitons' contributions to the project, and they get a leg up on the project by borrowing our code. If this software is something that could be widely used in your industry, open source could be a way to get free developer time on the project, in return for the donation of a part-time project manager. Chances are you have a person assigned to the project anyways, so you're getting a lot for a little, provided everyone plays fair.

  • Reebok could then start using it, save a lot of money with the more efficient system, and put the money saved towards making themselves compete with Nike better

    Put it under a license that prohibits other companies from 'hiding' their code. That way when bugs and security holes are fixed, your product gets better. That's why you want to release the source code. Sure, other companies may be more efficent because of it, but I'm sure that they'd be putting as much time into supporting it as you are, so I don't see much of a difference there.

    -Brent
  • Mailing lists or a SLASH-like page

    Speaking of this, I'm preparing a slightly more generalized version of the forum at http://www.hatelife.org [hatelife.org] for consumption - I'm using it in a couple of non-angst-related projects and it works out really well (even though I'm calling it "the hate engine" ;) .) It's simple enough to be super-straightforward for general consumption, and it's pretty decently organized.

    Sorry, just had to plug it. :)

  • Hi,

    some time ago, we developed a time tracking tool for our organisation. The company I work for is very pro-open source, and so we decided to open source the program (it's on www.achievo.com [achievo.com]). One of the main reasons being: this program could be really cool, but it could be even cooler if people can contribute to it.

    And it works.. 4 hours after we had released it for the first time on freshmeat, we already got a german translation from someone. Now, some 7 weeks later, we have our program available in 7 languages, had lots of bugfixes and contributions and we even redesigned the backend after some discussions with other users.

    The great thing is that it's also a source of income. We give support to the program and develop on demand (someone can pay us to develop extensions that are not yet in the program).

    Now to answer your questions:

    Where/how should we host the project? Something internal? Something like SourceForge?

    I think sourceforge is great, and it's especially conveniant for all those open source developers out there who don't have the ability to host their own project. Since we can host our project ourselves, we don't need to use sourceforge.

    What management structures/tools are helpful? At minimum we'll need a source-code repository and a mailinglist/newsgroup, right?

    Definitely a mailing list. For us it's our main communications channel with our users.

    What are some effective control stuctures? Who should determine what makes it into an official release?

    I think you should just use common sense to make decisions about that. Is feature X or Y beneficial to all my users, or is it specific so that noone can use it. You can always find out by communicating with your users.

    Who should be able to add code to the tree?

    We don't have cvs yet, and the way contributions are made is mostly by sending me patches through email. Also, I made the software as modular as possible, so people can contribute and/or workon separate modules.

    What kinds of resources do we need to commit to this project to make it effective?

    Keep it going, please your users, and be a good 'benevolent dictator' :-) (that term is from 'the cathedral and the bazaar', a great article from ESR)

    Greetings,
    Ivo

  • eading your requirements, you should definitely take a look at how the Abiword [abiword.com] people approach this.

    This project is going well in that they have succesfully attracted people from the community into making serious contributions, as well as a core group of employees who spend a varying amount of time on the project. If your project could reach this stage then it would make sense for your company financially as some of the development effort would be coming from volunteers in the
    community.

    I think that "the community" is naturally suspicious of companies going the open source route -- are they genuine or are they just jumping on the bandwagon? -- and if you expect serious contributions you'll need to do it on the community's terms: Go with the GPL, or some other well known license.

    The way that the AbiWord people approach this is that the code is GPL but they (the company) retain the trademark so that only their releases may be called AbiWord.

    As for who gets to submit code: run it as a meritocracy. Initially only your employees have access, and others may only submit patches. Regular submitters of quality patches should then be considered for full CVS access.

  • Last summer I wrote a paper [weft.co.uk] advocating to my colleagues that we open source our core Servlet toolkit. After some discussion they agreed, and the toolkit is now available here [weft.co.uk]. The paper is a purely business argument, and you might like to consider whether any part of it would be useful in your case.

    The point at which we finally announced it as Open Source on Freshmeat and on the Java newsgroups was only a month ago, so we haven't really much experience yet; we've had some hundreds of downloads, but as yet absolutely no feedback.

    Do I regret open sourcing? Not at all. The only regret I have is that we didn't do it much earlier. In some sense our competition is Lutris' Enhydra [enhydra.org]. We started work on our toolkit before they did on theirs, and were, at the time, a similar sized team. By open sourcing early, and proselytising widely, Lutris have not only gained themselves huge visibility (and apparent success), they've also been able to develop their toolkit a lot further than we have ours, partly because other people have contributed to it but also, I suspect, because they've got a lot of business as a result of their visibility. This isn't sour grapes - I respect those people, they've started from the same place and been more successful than we have.

  • I particularly enjoyed the odd-numbered chapters of the paper copy of "Open Source Development with CVS," [red-bean.com] by Karl Fogel, from Coriolis OpenPress. These bonus chapters give an excellent feel for those devilish details that make an open-source project succeed or fail.
  • Thats helpful for other programmers, but not much of an arguement to the higher ups to release something already written.

    The question is a little vague in explaining why anyone would want to work on this project, while at the same time not saying why it won't hurt to release it.

    It probably took a bit of effort / man hours to write, and its going to take more to establish as open source as per described in the question. Without sounding adverserial, what exactly is the benefit of releasing the code to the company that already wrote it?

    Who wants to work on something open source, if it is not depended on by the company releasing it?

    I'm having a hard time saying it, but something here doesn't add up.

  • The question is: can I find people who want to work on my open source project?

    The open source movement has received a lot of press over the past couple of years, which is great. There are a lot of good open source projects that deserve recognition and adoption.

    However, I think that there are a fairly limited number of people who are have enough passion for software development to work on projects for grins. As open source development models gain mind share, and as more projects are opened up, I'm guessing that there's going to be a shortfall of competent, willing participants. If you're the kind of person who would want to participate in that kind of project, you probably already are, and you're not likely to want to take on much more. The number of participants will continue to grow, but I'm guessing the number of projects will grow faster.

    So before you press management to let you open your code, ask yourself if your project is useful enough or cool enough to draw people in.

  • Re:Huh? (Score:3)

    by bmetzler ( 12546 ) <bmetzler AT live DOT com> on Thursday June 08, 2000 @11:27AM (#1015563) Homepage Journal

    If you use a piece of software that your business doesn't depend on, commercially, why are you using it?

    "Depend on commercially" means selling it to make a profit. Nike doesn't sell their accounting solution, but I dare say that their business would be in big trouble if they didn't use it.

    -Brent

  • Re:Huh? (Score:3)

    by Disco Stu ( 13103 ) on Thursday June 08, 2000 @03:24PM (#1015564) Journal
    It depends on your company's position. In most markets, yes, you don't want to give your competitors an advantage. However, in companies that already dominate the market you are less focused on defeating your competition and more focused on expanding the market. Here's a really contrived example:

    You sell 100 million shoes/year. Your competitors sell 2 million shoes/year. You open your code, giving your competitors an advantage, but making everyone more efficient and allowing the industry to expand the market. Now, you sell 150 million shoes/year, and your competitors sell 4 million shoes/year. Your competitors now have a higher market share, but you're still making more money. And that's what it's all about, isn't it?

  • what about this for a business reason? (Score:3)

    by gilgongo ( 57446 ) on Thursday June 08, 2000 @12:57PM (#1015565) Homepage Journal
    One area where open-sourcing might be a business advantage is in code ownership diputes.

    I work for an agency that takes on large web projects for clients. The contract we get the clients to sign says that we own all the copyright on the code we create for them. If they want to own it we can license it to them for a fee.

    Most clients are happy with this, since they can't maintain the code themselves. They simply commission us to make changes to is as part of the project's maintanance.

    However, from time to time a client won't sign until we let them own the code. This is bad from our point of view because we want to be able to re-use the code on other projects, etc. This is also bad because it can delay the start of a project while the lawyers bicker over the whole thing.

    Now, we've not actually done this yet, but we could, I suppose, suggest to the client that wants to own the code that we make it open source. That way, we all "own" the code, and if they want to use it under the terms of the GPL then fine, 'cos we love the GPL too. We might also hope that making it open source might actually make it better.

    I've not really thought about this idea very much so there might be some fatal flaw in there somewhere, but so far it seems to make sense to me.

    JJ

  • some books that could help you (Score:3)

    by m4gnus ( 150840 ) on Thursday June 08, 2000 @11:55AM (#1015566) Homepage
    Hello
    I suggest you to read, if you didnt read yet, The Cathedral and The Bazar from Eric Raymond.
    http://www.tuxedo.org/~esr/writings/cathedral-ba zaar/
    I have just finished to read Open Sources, Voices From the Open Source Revolution.
    Take a look at chapter "Open Source as a Business Strategy" wrote by Brian Behlendorf.
    http://www.oreilly.com/catalog/opensources/
    It compares Software Development in "Close Source" projects and "Open Source" projects, maybe it can helps you to design a model business model.
    But to really convice the "managers" you should focus in "lower costs" :)

  • The best distributed development model (Score:3)

    by ZikZak ( 153813 ) on Thursday June 08, 2000 @12:46PM (#1015567)
    Take all project notes (print everything).
    Put them in a box.
    Put the box in your car.
    Drive your car really really fast through California.
    Throw handfulls of notes out the window at random intervals.
  • In the open source community possibly the most important thing is the interconnectedness of the users; open source ventures only work when they have a user base that feels informed and is willing and able to help out if necessary. The best facilitator of this is a public forum. It doesn't have to be slashdot-like (although this is pretty ideal) as long as it is easily accessible and it's easy to browse through past communications to make sure that you don't have to keep facing the same problems over and over again.

  • Beware the Source, Luke. (Score:4)

    by Anonymous Coward on Thursday June 08, 2000 @11:48AM (#1015569)
    I know this opinion isn't going to be popular on Slashdot, and particularly not in this thread, but I'd like to warn people about the dangers of open source software.

    The danger isn't really in the free availability of source code, or even in the license. The real problem is that open source leads to a very dangerous situation ... collaboration. History is littered with examples of how collaboration between great minds has lead to untold destruction and loss of life. The nuclear bomb was the direct result of collaboration between scientists; the airplane (used to drop the nuclear bomb) resulted from the collaboration between the Wright brothers; and all of todays weapons of mass destruction such as chemical and biological weapons were created due to co-operations between scientists.

    However, history has shown that people working in isolation is much better for the common good. For example, Isaac Newton invented gravity entirely by himself; Henry Ford invented the car - think how much worse our lives would be without Henry Ford's dream to provide cheap and safe transportation for all; and Sam Colt invented the handgun - the efforts of this man allow us to defend ourselves in a world where the failed collaborative effort known as society fails to offer us protection.

    I am sure you can now see the dangers which collaboration presents to mankind. Open source is a noble aim, but without proper safeguards in place, it may end up destroying the human race.

  • Think carefully before you do this... (Score:4)

    by Malor ( 3658 ) on Thursday June 08, 2000 @11:41AM (#1015570) Journal
    One of the side effects of open sourcing a product is that you get an unintentional security audit.

    If your app is net-based, and it hasn't been written with security in mind from the very start, there are going to be holes in it. By publishing your source, you have just advertised those holes to people who know how to exploit this sort of thing.

    Unless you happen to be scratching an itch that a lot of programmers (not COMPANIES, PROGRAMMERS) have, chances are that open sourcing your product won't give you many new contributors. You need to evaluate the benefits versus risks carefully; is your app of such compelling interest that you're going to get loads of contributors? And does that offset the security risks?

    There is definitely room in the world still for closed-source apps. A custom-written business app is one of the best candidates, IMO.

  • absolutely critical stuff (Score:4)

    by trance9 ( 10504 ) on Thursday June 08, 2000 @12:06PM (#1015571) Homepage Journal
    Here are the golden rules:

    1: release early, and release often. don't hold your source code internally until you think it is a perfect expression of your great coding skills. release it while it's still a pile of junk, and let everyone help you turn it into something truly useful.

    2: admit outside developers into your team ASAP. you don't have to trust them early on: give them an opportunity to prove their track record by submitting add-on modules, patches, etc., from outside the core before letting them further into your source tree.

    3: create a mailing list on day one and thank everyone who contributes to it for helping you

    4: make your CVS archive available for anonymous checkout for everyone to access, not just developers.

    5: make snapshots of the source tree on a regular basis for people who can't/won't get it by CVS (in other words, do everything you can go provide people with access to the code, no matter who they are)

    6: run a bug tracking system publically, like bugzilla or scarab or some other.

    7: interoperate with as many other opensource projects as you can. You will start out as a lonely independent but if you can combine with the efforts of other projects (by using them as modules, by encouraging them to use your code) then you'll grow faster.

    8: show that you appreciate help--accept and incorporate people suggestions as soon as you can. help people to feel THEY own the source as much as you do.

    9: refactor on a regular basis. oss projects get a lot of contributions and a lot of ideas put into them--that don't always jive. DO NOT be afraid to rework your basic design to make it all simple and sensible again. DO refactor constantly.

    10: later, when you ahve more developers involed, encourage everyone to hang out on an IRC channel when they're coding, using, or working on the project. use communication tools like irc to grease the wheels of progress :-)

    Do all that and your project should work out reasonably well--assuming you have a good idea to start out with.

  • Making the code sanitary (Score:4)

    by seizer ( 16950 ) on Thursday June 08, 2000 @11:10AM (#1015572) Homepage
    One of the problems is of course that with an internally developed project, there will be many eccentricities, code that depends on other proprietry code, and perhaps even sensitive data within the project as a whole. If the company is to open source a project, it will probably have to remove these, and this could turn into quite a lot of work. Which would then be judged too costly.

    Just another obstacle... :-)

    --Remove SPAM from my address to mail me

  • A Central Person (Score:4)

    by debrain ( 29228 ) on Thursday June 08, 2000 @11:45AM (#1015573) Journal
    Now, don't get me wrong, but I believe most projects require someone central to the system. Linus Torvolds, for example, are central to the Linux Kernel, and David Dawes is central to XFree86, and Miguel de Icaza is central to GNOME. Now, this isn't to say that these are the most important people there, the best developers, etc.. Not at all. But, they are key players in maintaining and updating releases of the software, and are integral to the project in management, programming, and communications. Somewhat like a volunteer COO.

    On large enough projects (like the ones mentioned), the division of operations can be divvied up, like with Alan Cox on the Kernel, etc.. But for projects just starting out, or for smaller projects, like Blackbox's Brad Hughes and Jeff Raven, where they codeveloped the whole system (other credits acknowledged, of course), it is imperative that there be a real person at the centre calling the shots, and that a real person make the code usable on several platforms, if it is demanded on several platforms, and that someone be there to answer the other free-world(tm) developers questions, when they come knocking with their "what the hell is that?" and "why not do this, instead" type questions and comments.

    Many projects fall by the wayside, or are forgotten altogether before they are really picked up en masse. Many people do not feel comfortable contributing to a project that may disappear in a few days, or weeks, or even months. The stubbornness of the person at the wheel and their determiniation and grit will bring new people on, and that will lead to a healthy development environment.

  • Open source still has a long way to go. (Score:4)

    by devphil ( 51341 ) on Thursday June 08, 2000 @11:40AM (#1015574) Homepage
    Since I contribute to GNU projects, the FSF wanted the usual disclaimer from my employer (since I also happen to be employed to do programming). So I asked my manager, and he asked the local contracting people.

    Two days later, it had been kicked all the way up to the head office, hundreds of miles away, and the corporate lawyer was freaking out. He drew up some questions and handed them back down the chain to me.

    The first one was, "Who or what is GNU?"

    *sigh*

  • Release issues (Score:4)

    by chandler ( 98984 ) on Thursday June 08, 2000 @07:48AM (#1015575) Homepage
    To decide what makes it into a release/what designates a release, here's how I would do it (which is how most projects work):

    There is a three-tiered numbering system, X.Y.Z, where X is the major release number (and indicates large changes in the software), Y is the minor release number (and whose evenness/oddness determines whether this is a stable release or a development release, respectively.) If you're on an even branch, the Z number represents a patch level or a bug fix level. Only features that affect bug fixes are added between Z numbers in stable releases. If you're on an odd branch, Z numbers represent many bug fixes and feature enhancements or additions.

    Once the development branch has enough features, a "freeze" is put in place that prevents adding of new features. During this time the release may be called X.Y++.0pre1, or X.Y++.0test1, or a X.Y.99pre1. When the "freeze" is complete, features are migrated into a X.Y++.0 release. No new features (unless they are bug-affecting) are added until the next even release.

    Usually projects have one-or-more releasemeisters who manage when releases happen. For the kernel it's Linus, or in his absence Alan Cox.

    And don't forget: Use the source, luke!

  • Answers to good questions (Score:4)

    by xant ( 99438 ) on Thursday June 08, 2000 @01:37PM (#1015576) Homepage
    Does this add value to our company? If so, what are the specific benefits?
    Yes, if the project has appeal outside the scope of your commercial enterprise. (This may include other commercial enterprises, including your competitors, especially if they have a similar product in the same status as yours: not sold, but maintained internally.) Open source projects benefit from free contributions and maintenance from the outside community, if they are maintained. That means bugfixes and new features to code you're using. In effect, instead of paying all the cost of maintaining the product yourself, you're deferring some of it to the world at large.

    Can the value of these benefits be measured?
    Buggy software is anything but cheap. It is possible to measure the cost of a bug in terms of both manhours spent working around it and manhours spent fixing it, and from there, you can calculate a dollar value if you're so inclined. Adding new features is also not free. If you can get the community to shoulder any fraction of these efforts, in return for being allowed to see and use your code, you've got a quantifiable win.

    How much is it likely to cost?
    Well, open sourcing the product won't be free, unless you unleash it on the world and refuse to maintain it, which trashes both the creditibility of the product and the likelihood that anything comes of releasing it. (This is known as abandonware.) If you do choose to dedicate personnel to maintaining the open source product, you will need people in charge of building it, incorporating contributed code, and packaging new releases, as always, plus as many people as you care to keep contributing actual code (optional). The number of people in each category depends on the size of the project, but it is likely to be a smaller number of people than were required to maintain the software entirely in-house. At some point in the future, if the project is especially popular, someone else may be willing to take over these maintenance tasks for you, but for the near-term, plan on having a few maintenance people. There will be one-time costs associated with switching the software from closed to open. Finally, if you physically host the source as a service to the new community of developers, there will be the cost of the webserver/CVS server. Except for the one-time costs, all of these costs will scale up with the popularity of the project, but you will derive more benefit from having opensourced as it gets more popular (to a maximum benefit of however much it would have cost to maintain it in-house). As a bonus, if you choose a standard license for the open-sourced product such as the GPL, you effectively outsource most of the legal costs to the FSF.

    Are the potential benefits likely to justify the trouble?
    This one, at least, is difficult to answer without knowing the product. Open sourcing something is neither difficult nor costly, but as I already mentioned, it isn't free if you ever want to realize any benefits. It depends on how big a project it is, how much you depend on it, and how popular it is to the outside world. Open sourcing software that has no relevence outside your corporation is likely to cost money and benefit you nothing. Open sourcing software that is difficult to maintain internally and would be well-received by the outside world is likely to cost you a little and benefit you a lot.

  • I managed to convince my day job to found an Open Source project. We do a lot of Industrial Controls stuff, and routinely spend $3200 per runtime, $7900 for development packages, and of course yearly support costs for our in-house development packages. Needless to say, that drives the cost of a job up quickly if you have 6 or 8 runtime stations and a development station that you are bidding for a customer. And yearly support costs have always been a sore point...

    I wrote up a very descriptive paper on the current costs we pay -vs- the cost of developing a brand new Open Source MMI (Man - Machine Interface) system. The cost of development -vs- the potential savings on just two jobs made things quite worthwhile from the standpoint of sheer cost.

    The real clincher was the fact that we controlled our destiny with an Open Source project. If we need new features, we aren't at the mercy of the developer. If we find a bug, we can squash it quickly (or at least we hope ;-) and not have to wait until the next 'Service Release' of a product. It also gives our customers piece of mind because they aren't locked into a situation where they are at the mercy of a integrator (us) and a developer (the MMI manufacturer). (BTW: The company in question, Creek Electric Inc. has always been a supporter of the Open Source concept, BEFORE Open Source was a buzz word. When we develop a product for a customer, it has always been an un-written rule that they got a copy of the PLC program, and a copy of the MMI, and any other programing that goes on. There's nothing proprietary or hidden. I assumed that was an industry standard in Industrial Controls until recently I found a company who DIDN'T do it, and I had to fix some of thier work... *SIGH* Rant over...)

    Anyways - development progresses as I have time to do it. "Why not release the source now?" you ask? Simple - I've never believed in the "Release Early, Release Often" theory. Instead, I believe in having a working model before releasing anything - it may not be robust, but, it should work and be useful. In my case, both the development tools and the runtime libraries should be working and useful. Again - "Why?" you ask? There's three stages to this: Vision, Internal Development, and Full Development. I've already been burned over an Open Source project that opened up too quickly. If you have an idea, the Vision stage, you need to set down, and document it to at least a degree. It's ok sometimes to program and document at once on smaller areas, but the big picture needs to be done. Have a complete goal in mind. Then move to the Internal Development stage. In this stage, get at least a working prototype done. While it's nice to announce a new Open Source project, people get disappointed (or worse) when the check closer, and notice theres no code, or there isn't anything to at least play with. have something for people to play with - it's the quickest way to get people's attention, provide them with a glimpse of your (or your team's) Vision and get them to contribute further to the development. Keep in mind - Internal Development doesn't mean it's completely closed - just that you normally invite the people you know who are interested in. Even the Vision stage can be that way too - get people who know, and are knowladgable about the subject. But, don't get too many. Design be committe doesn't work very well - I'm familiar with the concept all too well!!! Set a goal also for the Internal Development stage - decide ahead of time what point at which you are going to release inital version to the public. Finally, Full Development is the point where you show it off, and let others begin contributing to the project. Some people call this a Release, but, I prefer the term Full Development because it acknowladges the fact that development is what's really going to be going on :-) Have one person that s a head, who resolves any 'deadlocked' debates, and hold general responsibility for making the project continue on.

    Some people will disagree with me, but, hey - I've been involved with it twice now, one of them being a complete failure, and the other one is still in development. This is my third project (Jaguar MMI), and I've learned enough from the other projects, and from other people's projects to know what's right and wrong part of the time ;-)

    As for resources - there's the normal stuff that everyone suggests: reading some of ESR's work, etc. My personal preference for who hosts the web pages, CVS, etc. is if you found the project, and you got the money, host it yourself. SourceForge (and anything like it) is a great service - but I really think that if you have the resources to do it, handle it yourself, and leave SourceForge for projects that can't afford it themselves (this way, there's one less project on there, which means there's just a little more room for more projects by people who can't afford it.

    Ok, that's my... well, about $1.50, cause I can't call that $.02 ;-) Others can produce some flames about what they disagree with in this, but, unless they tell me the founded an Open Source project, and it did work out for them, well, I don't hold much stock in thier opinions (That's only 1/4th serious ;-)

  • Suggestions (Score:5)

    by jd ( 1658 ) <imipak@yahoGINSBERGo.com minus poet> on Thursday June 08, 2000 @11:53AM (#1015578) Homepage Journal
    • Appoint a "Benevolent Dictator" for the project. They, and they alone, have final say on what goes in. If the project has multiple applications, it may be better to appoint a BD for each.
    • You ABSOLUTELY need a repository from which you can access any version of the software.
    • It is STRONGLY recommended that you have some kind of bug-tracking system, so that bug-fixes don't clash more than they absolutely have to.
    • Release Early, Release Often. RERO is the only way people will know your project is alive and well. Too many projects die from their maintainers trying to get the release "just that little bit better". Forget it, throw it out, and let people find the bugs. Driving yourself mad earns you nothing.
    • Set Deadlines and be firm about them! If people want to add unstable/untested stuff, fine. Just make sure it's possible for users to not have to contend with it. Then IT DOESN'T MATTER!
    • Announce on Freshmeat, for the project AND the code.
    • Pick a SUITABLE licence, but don't invent your own. GPL, LGPL and BSD will cover 99.999% of all cases.
    • Keep It Simple, Stupid! Feature-creep, bloat, complex code, etc, are all ways to create slow, unmaintainable, unusable, buggy code. If that's what you want, fine, but if you want something you can use, keep things simple.
    • Loose-Coupling is Good. The more tightly coupled two routines are, the more fragile they are. Any slight change in one can wreck the other, without warning. Not only that, but you can't do anything new with the code. Loose coupling allows you to move into distributed code, parallel processing, etc.
    • A bird in the hand is worth two in the bush. If a routine works, can be compiled as a library and has a well-defined interface it, FREEZE IT! Get everything that stable, before doing anything further. The fewer unknowns you have, the better.

    If this goes against what anyone else has written, pick who's advice seems to be the most sound and go with that.

    If the above is not what you wanted to know, then take what you like and leave the rest. (Hmmm. Open Source is programming's own 12-step group!)

  • You are asking the wrong question (Score:5)

    by Golias ( 176380 ) on Thursday June 08, 2000 @11:46AM (#1015579)
    If you are trying to persuade management to open source something that they spent money on developing, the question they will expect you to be able to answer is not "how" but "why".

    They really won't care what your model is for managing the long-term growth of the project. Instead of reading about how the GNU team runs things, start thinking about these questions:

    "Does doing this add value to our company?"

    "If so, what are the specific benifits?"

    "How can the value of these benifits be measured?"

    "How much is this likely to cost?"

    "Are the potential benifits likely to justify the trouble?"

    If you go into a meeting with the PHB's, and don't have specific details of the reasons for doing the project, the goals of the project, how the goals can be evaluated, and the costs... they will pretend to listen to your presentation, and then move on to something else.

    Knowing this kind of stuff is supposed to be management's job, but they didn't get where they are today by doing their own research. If you want the project to happen, it is up to you to do the thinking for them.

Slashdot Top Deals

"More software projects have gone awry for lack of calendar time than for all other causes combined." -- Fred Brooks, Jr., _The Mythical Man Month_

Close