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."
I just started a project on sourceforge, 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.
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. Also check out Brian Behlendorf's chapter 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 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>
Just be sure to wear the gold uniform when you beam down -- you know what happens when you wear the red one.
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.
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.
-BrentSpeaking of this, I'm preparing a slightly more generalized version of the forum at http://www.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,
:-) (that term is from 'the cathedral and the bazaar', a great article from ESR)
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). 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'
Greetings,
Ivo
eading your requirements, you should definitely take a look at how the Abiword 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 advocating to my colleagues that we open source our core Servlet toolkit. After some discussion they agreed, and the toolkit is now available here. 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. 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'm old enough to remember when discussions on Slashdot were well informed.
I particularly enjoyed the odd-numbered chapters of the paper copy of "Open Source Development with CVS," 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.
(Reality reasserts itself sooner or later.)
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.
Troll Like a Champion Today
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.
The heart has reasons that reason does not understand. - Jacques Bènigne Bossuet
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.
-BrentIt 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?
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
"And the meaning of words; when they cease to function; when will it start worrying you?"
Helloa zaar/ :)
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-b
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"
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.
Do something about world hunger. Click here
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.