Slashdot Mirror
How To Best Manage Open Source Projects?
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:
- various ESR documents from opensource.org
- Tim O'Reilly's "Open Source Revolution" article from Release 1.0 www.edventure.com/release1/1198.html
- Frank Hecker's "Setting Up Shop: The Business of Open-Source Software" from www.hecker.org/writings/setting-up-shop.html
and others), and feel I can articulate them pretty clearly, but that's not really what my question is about."
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.
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.
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.
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
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.
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*
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
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!
Visit
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.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
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 ;-)
Davis Ray Sickmon, Jr - looking for something to read? Check out my three free novels at MidnightRyder.org
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!)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
Information wants to be anthropomorphized.