|
Knowledge management for development team.
Any of you crack coders have the silver bullet for growing and managing the intellectual capital, lessons learned, how-to technical notes for a 7-person development team?
Currently two years of 1/2 finished design docs and some other nuggets of software wisdom live in Windows file folders, and that is our only knowledge management besides between the ears. This is often sufficient but we're looking to find that a way that encourages more use both contributing and consuming. Is the answer a Wiki? A blog? A portal? Has anyone used, built, or dreamt of the perfect solution. Please share any thoughts or experiences on the topic.
Love, JoS newbie
JoS Newbie
Wednesday, January 7, 2004
We have had great success with a wiki. Of course, one needs the discipline to keep entering data into it, but that applies to anything, such as commenting code. Which is also an excellent idea :)
One of our bigger clients is an engineering firm, and a huge amount of their knowledge is in hardware, and they appear to keep a large number of very formal specifications and such. That works well for them, but then, they are a fairly large shop, with a lot of corporate overhead. I get the impression that a lot of formality is necessary in that sort of environment.
Mike Swieton
Wednesday, January 7, 2004
SHAREPOINT!!!
[grinning, ducking, running]
Philo
Philo
Wednesday, January 7, 2004
I've implemented a sharepoint 2.0 system, and it is a pretty good way to manage developer information, especially if you are already using all the other microsoft office stuff. The portal server + indexing service can just index all your existing files.
If you aren't heavily invested with microsoft, probably a combination of developer blogs (.planfiles for the 90s ) and some indexed file system is what U need.
sharepointed
Wednesday, January 7, 2004
A combination blog (for each developer) and wiki would seem to hit a sweet spot for this sort of task. We use TWiki at work but not everyone has grokked it yet. ("Slowly gaining acceptance...") Merging the two would give you a combination of organizing ideas chronologically and spatially. Some examples off the top of my head are Martin Fowler's bliki [1] and sites using SnipSnap [2].
[1] http://martinfowler.com/bliki/
[2] http://snipsnap.org/space/start
Chris Winters
Wednesday, January 7, 2004
Philo,
We currently run Sharepoint Team Services on a Windows 2000 Small Business Server. It is working well for our small dev team of 7, but now the whole company wants to get in on the act so we want to update this to the full Sharepoint 2003 Product (Whatever the latest one that came out is called) in order to have the workflow management to control what documents are reviewed etc. Can you answer 2 questions for me before we spend a month trying to figure out ourselves?:
1. We need to run it on Windows 2003? But our fileserver that gets backed up nightly is a Windows 2000 server(Small Business Server), can we run the Sharepoint server on the Win2k3 server and store the document repository on the fileserver? How would this handle if either one of the machines blew up? Would it be impossible to recover from?
2. Does it really need a dedicated server for less than 20 users? The server I am planning to put it on is a 1.6GHz P4 with 1Gig of RAM. The only other things we want to run on the machine is a demo of our application (very light load and only a few users a week) and our support website (mostly straight HTML with very few page views at the moment - 0 to be exact, but probably less than 100 per day in the foreseeable future) - These 2 sites are on a IIS Web Server set to a different port, the default IIS Server is still running on port 80, and is the one we plan to run Sharepoint through.
And maybe another question - Once this is up and running (even if we have to get a contractor in to install it for us) would it be much work to maintain on an ongoing basis? (By much work I would compare it to exchange and SQL on the SBS which we manage quite fine with on our own since we got a contractor in to do the initial setup.)
Chris Ormerod
Wednesday, January 7, 2004
You will have potential problems.
Me as an example. I'm generally a senior developer of some sort, but there's no way I'm going to write a blog. I hate wiki's too, so I'm not going to contribute to (or use) one of those.
I probably need a stern talking to from my manager. I won't change though.
Wednesday, January 7, 2004
- Yes, Sharepoint Portal Server 2003 has to run on Windows Server 2003. However, it does not have to be a dedicated server - your loading sounds fine.
- I'll have to check on backup strategies. SPS has a backup tool, and I'd think you could simply run Sharepoint backups to your file server, but I have to verify that.
MS' Sharepoint page has a lot of info, and there's a 120-day eval available (or it's on MSDN Uni)
http://www.microsoft.com/office/sharepoint/prodinfo/default.mspx
The document management stuff *alone* should make it worthwhile - the collaboration capabilities (you can have a team site for each project, a QA site, common calendar for maintenance windows, etc) just make it an even better solution.
Sorry to gush,
Philo
Philo
Wednesday, January 7, 2004
Philo, everybody avid web consumer knows what wiki is.
Everybody has gone to http://www.wikipedia.com every once in a while.
So - when you talk about Sharepoint, please give us an example - can you show us something interesting?
Thanx!
Avid web worm
Wednesday, January 7, 2004
Sharepoint is a good tool for managing Office documents. So if you have a lot of Office documents, or your team enjoys writing documents with Office, it may be a good choice.
If your team is reluctant to write, I'd definatly aim for something light-weight like a wiki. Or a blog. Or an email archive system--you can use it like a blog, just archive notes about the system and ask people to email articles once a week.
A wiki amplifies ad-hoc structure. A blog (or email archive sytem) amplifies momentary bouts of lucidity. A combination, I don't know about.
Mr. (or Ms.) unsigned, why do you dislike blogs and wikis? Because you don't like the particular format? Because of the tools? Because you prefer to keep all your knowledge in your head? Something else?
A bit more about sharepoint: backup strategies are (or were) terrible, I think there are hooks for third party vendors, which do exist now. You can back up the entire database. Restoring is quite difficult. (We tried after accidentally deleting a server with a few important files on it. I ended up writing my own simple recovery tool to pull the files out of the MDB files, which we did still have.)
Of course, blogs and wikis will have backup issues, but most write (or can write) to a single file, you could always create a template with an RSS (or Atom, which is designed for this purpose) feed of everything.
mb
Wednesday, January 7, 2004
Sharepoint V2 stores all it's information in a SQL server (that doesn't have to reside on W2003) so if you know how to back up a MS SQL Server 2000, you know how to back up your Sharepoint data. (At least until you start mucking around with customization and apps written under Sharepoint and such - and by that time if you can't figure out the last bit, you won't suceed in getting those customizations and apps and such to actually work either.)
Unfocused Focused
Thursday, January 8, 2004
Our team is also trying to setup an infrastructure for this.
Right now we have a shared file folder and a forum. However, we're thinking of converting our forum to a full-blown portal site - such as Project Hurricane (http://www.projecthurricane.com/) where you can post articles, have a blog, and other stuff.
The shared folder would act as a repository for shared code and dev tools as well as storage for formal documents.
At least that's the idea :).
Fry
Thursday, January 8, 2004
Whatever solution you find it needs to be viral, it needs to be second nature that whatever mechanism for capturing knowledge there is, is used.
Simon Lucy
Thursday, January 8, 2004
I totally agree with you Simon. I guess the key phrase in the original post is:
>we're looking to find that a way that encourages more
>use both contributing and consuming
How do you encourage contributing and consuming?
Fry
Thursday, January 8, 2004
"Philo, everybody avid web consumer knows what wiki is."
With all due respect, no.
Do *not* fall into the trap that "because the people I talk to know something, and the communities I hang out in know it, EVERYONE knows it." I've been constantly amazed at things *I* thought were well-known that nobody had heard of.
(How often do you hear from a friend some nugget of news they obviously just got off CNN that you've known for 18-24 hours?)
I might go with "a large number of 'net geeks have heard of wikis", but even that sounds overly optimistic. I'm pretty sure I wouldn't have heard of them if I wasn't on JoS.
Also, the original poster said he has a lot of documents to gather. Wikis, to me, are about linking and displaying text-based information; not about organizing documents (how do you upload or attach a document in a wiki?)
Philo
Philo
Thursday, January 8, 2004
If you just want to organise documents, that's what the file system is for.
Sharepoint is overkill and counter-productive if that's your main goal.
I don't see how it will help people contribute more. We have sharepoint set up at work, and I hardly give it a second thought. It's just not somewhere I think to look for information. I'd hit the windows shared folders, source control and our bug database first, since that's where the actual first hand info usually is.
Sharepoint has basically died off after initial enthusiasm, due to it simply being more cumbersome than these other technologies.
Sum Dum Gai
Thursday, January 8, 2004
Philo
It can be done with a wiki. Google found me this:
http://superwaba.sourceforge.net/cgi-bin/twiki/view/TWiki/FileAttachment
As to whether that's more appropriate than Sharepoint is a whole different question, which I imagine depends more on budget and customer skillset than features.
(disclaimer: I use neither wiki nor Sharepoint, so I'll shut up)
A cynic writes
Thursday, January 8, 2004
To the original poster: If you'd rather avoid MS SharePoint and go for something lighter, you could also find a utility to batch-convert all those DOC/XLS files into HTML, and feed all those files to a good CMS (Content management system). As far as open-source CMS's go, users recommend Mambo, Drupal, Typo3, and eZPublisher.
More and more, those tools also provide an XMLRPC-based interface, so we're beginning to see some light dedicated clients to allow users to contribute using a tool a bit more user-friendly than a web interface. Take a look at http://wbloggar.com and http://www.farook.org/Downloads.htm for illustrations.
Remember: Most people don't like contributing (either don't like writing docs, aren't good at it, or figure it's more power to the company if they share their knowledge), so you must provide a tool that is very simple.
Frederic Faure
Thursday, January 8, 2004
Has anyone else had a hard time setting up a personal wiki?
I can't seem to get it configured properly. Is there a step by step guide besides this one: http://www.flexwiki.com/default.aspx/FlexWiki.QuickSetup
I tried that, and the troubleshooting guide. The troubleshooter says my Wiki is totally setup properly [config.aspx]...
I created a content base but when I try to go to my flexwiki home [http://localhost/flexwiki/default.aspx], I get "Key cannot be null. Parameter name: key".
Is there something I'm missing? Should I be going to a different directory?
I searched and couldn't find anyone else as silly as me who couldn't get a FlexWiki setup...
Anyone else using FlexWiki? I feel I'm so close...Maybe just my URL is wrong?
Can anyone help?
Rick Watson
Thursday, January 8, 2004
I've probably recommended this before, in lieu of anything I develop in this line which tends to be specific to a kind of domain knowledge, and that's Fogbugz, or Bugzilla or whichever variety of issue tracking you prefer.
No it doesn't have to be just about bugs, issue tracking software can track anything you care about and as one of FogBugz' claims is that its viral (and I've no reason to think it isn't), I'd probably give that a go. Bugzilla is a pain to install.
You get people to contribute by rewarding them with responses. I'd probably disallow any use of any in house irc or yahoo or whatever instant messaging, disallow any use of email outside of the issue tracking system and consider a reward scheme for contributions that had some tangible value.
Simon Lucy
Thursday, January 8, 2004
Philo, I think you're right that Avid overstates things when he says that every frequent web user knows wiki. But since the topic was *programmer* knowledge capture, that's a much narrower population than Avid suggested, and one for which it's probably rather true.
Every single really good programmer I've meet during my career has been involved part of a programmer community outside their workplace, at least by attending local user groups and talks by luminaries, if not joining study groups, regular attending important conferences like OOPSLA, etc. It would be hard to be in these communities very long without hearing something like "take a look on Ward's wiki, under KentsBook". Even good programmers who might live out in the sticks without access to a strong local programmer community would have seen references to wiki in books and articles. (I think it's safe to say there are no good programmers who don't read voraciously.)
veal
Thursday, January 8, 2004
Most of the really good programmers I know have either written books or articles, or aspire to. Off the top of my head, I really can't think of anyone I've worked with worth their salt who didn't chomp at the bit to talk and write about the cool software they've written, or a neat idea that's given them good results, or the disasterous mistake they'll never make again.
When I hear of programmers who don't like to write, I get suspicious about them. Although given the worthless crap that most IT shops force their manacled oar teams to excrete, I can understand some aversion. Nothing that starts from a template is worth reading or writing.
veal
Thursday, January 8, 2004
I wrote a long post an I'm scrapping it in favor of this:
Slash
Run the Slashdot software. This way it's easy to post something new like "revised terminal.cpp lines 355 - 400 based on requirements doc 433 attached."
This will get comments, and the important ones will get moderated up, and most important: Because the homepage changes every day people will visit it. Because it's interactive, people will use it.
Wikis and Blogs are lonely places. Slash is group blog, half forum and extremely social.
Now everything will in one place. The new guy can read the archives to get caught up, and you can search (or askSlash) for specifics.
www.MarkTAW.com
Thursday, January 8, 2004
Peversely I like the idea of the CVS suffering a melt down because of an internal slashdot storm.
Simon Lucy
Thursday, January 8, 2004
WakkaWiki runs on PHP and is a breeze to install. I did it yesterday in about a half hour, including looking up the password to my database.
www.MarkTAW.com
Thursday, January 8, 2004
> Peversely I like the idea of the CVS suffering a melt down because of an internal slashdot storm. <
OMG.......... That's the funniest thing I've heard since... We should Offshore discussions of Offshoring 15 minute ago.
When did JoS get funny?
www.MarkTAW.com
Thursday, January 8, 2004
Look, its always been funny, you just haven't been reading it right.
Simon Lucy
Thursday, January 8, 2004
WakkaWiki -
Taking one look at this, it just doesn't fit with what we have for the rest of our organization.
We don't have the experience to manage Apache and MySQL.
Any IIS based Wikis ... or someone familiar with FlexWiki to help me out?
I don't want to get into any Unix Windows debate here, just trying to find a solution that our existing Windows IT organization can maintain.
Rick Watson
Thursday, January 8, 2004
I've been here 2 years and you're only just NOW telling me it's been funny all this time?
www.MarkTAW.com
Thursday, January 8, 2004
Sorry.. I didn't think it was LAMP dependant.
www.MarkTAW.com
Thursday, January 8, 2004
I just resolved my own problem. Try out OpenWiki.
Run an install and it works the first time. I love software that "just works".
http://www.openwiki.com/
Rick Watson
Thursday, January 8, 2004
Could use one of the clones of this forum if they're still around.
A Mad Cow
Thursday, January 8, 2004
Talk to each other.
Leave comments in code.
Mr Jack
Thursday, January 8, 2004
We use OpenWiki here as well, and I'd give it a big thumbs up.
It runs from the box.
The source is clear and easy to adapt for your own use.
It can handle attachments if you want.
As a side note, personally I like to avoid attachments. It you allow attachments then you'll just get lots of Word documents or PDFs attached. Better to take a few minutes effort to cut and paste the text and a quick bit of formatting.
Ged Byrne
Thursday, January 8, 2004
.. Run the Slashdot software. ..
ayii! Nothing against slashdot, but their software isn't designed for the scale that an issue/knowledge management system would have. Its designed for millions of page views a day. I wasn't too impressed when I used it (admittedly a couple years back) because it was overkill for what we needed -- a simple knowledge base.
Checkout some of the lighter weight clones of slashdot:
http://www.drupal.org/ is a good one, from talking with the developer and hearing other people say good things.
Disclaimer, I developed a slash alternative for a couple years: http://scoop.kuro5hin.org/ , but I consider that a little too heavyweight for these purposes as well.
Andrew Hurst
Thursday, January 8, 2004
sum dum gai makes a good point regarding sharepoint for a DEVELOPMENT team. the sharepoint system I set up is used much more by non-developers. the developers use mostly CVS and bugzilla to keep track of what they are doing. each development project has its own sharepoint site, and the only thing that the development teams put in the site are rather unfrequently updated powerpoint presentations and whatnot. the built in lists for task management and forums are not so hot, so no one uses them.
he makes another good point when he mentions that his sharepoint site is off in the corner with no one using it. sharepoint is not something you can just install and excpect people to be happy with it. it took me about 5 months worth of document migration, planning, and training pain to get the office where i'm working (about 60 people) using sharepoint effectively. and as I point out above, the development guys don't really use it for much - they do get random news via the portal, but they don't use the sites to manage the development projects.
I think you will have the problem of getting people to use your system, no matter what system you choose, if no system is currently in place. unless you are working at a top notch shop with a lot of eager beavers who love their jobs, any thing percieved as extra work (keeping a dev journal) is usually avoided with minor hostility.
sharepointed
Thursday, January 8, 2004
Andrew, Kudos on Scoop, I'm a big fan of Kuro5hin. I'm sure you'd know a LOT more than I would about the nuances of the slash variations.
www.MarkTAW.com
Thursday, January 8, 2004
I've had good luck with Plone (http://www.plone.org/) for managing project information. It has a low learning curve, lower than most wikis, and is *very* easy to get running.
Colin Evans
Thursday, January 8, 2004
Maybe I'm ignorant, but I can't see how a Wilki would work. I've only just played with Wikipedia once.
It seems that a wiki would be so ad hoc as to be useless for knowlege managment. And, I understand the programmer who says he's never going to write to it. He's got work to do. What benefit does he get to put something in a wiki?
One of the tough things in whatever you set up is ingraining it in the culture to 1) first look in the reference before asking questions and 2) write enough in the reference so that questions can be answered.
Most of the times I've seen this type of thing set up people fail to use it because it's not usefull enough!
pdq
Thursday, January 8, 2004
pdq, I agree.
I think a Wiki is bad because in order for it to be useful it has to reach a critical mass of usership. It will never reach that critical mass because before it gets there it doesn't have anything in it.
Blogging also didn't seem like the right solution to me because blogging is:
1. A thankless task - it's solitary, and therefore not really conducive to group knowledge.
2. Anyone whose job description includies "Blogging about the work I'm doing" is likely to be resentful for having to justify their work in a brand new way and an ongoing basis.
So I decided Slash would be a good way to go because it's social from the beginning, the constantly changing homepage keeps people coming back for updates, people can go there with questions as well as with knowledge dumps.
www.MarkTAW.com
Thursday, January 8, 2004
Good points regarding putting document content in the system instead of content, and also regarding the difference between devs and managers.
But that prompts the question - how many successful development efforts operate in a vacuum? The two major process-oriented teams I've been on had a *lot* of documentation to keep track of. We had:
- specifications document(s)
- emails
- visio diagrams
- powerpoint presentations
- PDF's
- Excel spreadsheets
- use cases
- database schemas
- Project files
In addition there was (and should be) communication between management, devs, QA, sysadmins, etc.
Yes, data homogeneity would be awesome. So would users that don't change specs. None of this is true - a major software development project is simply going to have a ton of files associated with it that should be aggregated and maintained.
[obSalesGush]
I push Sharepoint because I wish I'd had it when I was on team projects. Then I would've made the team use it. We're using it on projects internally here at MS and it's a godsend. If someone knows of an equivalent product that integrates with Office as well and allows easy team interaction, site creation, and document management, let me know.
My advice - install it. Get a copy of Virtual PC or VMWare, install Win2k3 and Sharepoint Portal Server. Play with it for an hour or so. If you're serious about collaboration, then you'll know pretty quickly if it's what you want to deal with. If not, then move on and evaluate something else.
I know, I'm a sales guy and not to be trusted. But this is Philo saying "it's something that's really worth looking at"
Philo
Philo
Thursday, January 8, 2004
Philo, you don't normally "upload" a document when you want to refer to it. You simply link to it. It's not clear if wikis require homogeneity.
In theory, wikis could operate on all sorts of objects, such as PDFs, searching and version controlling them. In practice, it's not clear that any are getting the funding to support these features. So Google and Microsoft are worth looking at if a solution is needed Real Soon Now.
I hear the WWW is a really bad implementation of hypermedia. Perhaps wikis can do something about all the hardcoding and write-only nature that cast decisions into stone.
Tayssir John Gabbour
Thursday, January 8, 2004
you don't normally "upload" a document when you want to refer to it. You simply link to it
******************************
If I have an Excel document forwarded to me in an email that I think should be available for the entire team, how do I wikify it? I mean, what would the steps be?
Philo
Philo
Thursday, January 8, 2004
Philo,
My answer would be "You upload it" - Otherwise, if you are out on the road and looking at the wiki, which conveniently has been setup to allow (authenticated) public access you can't get to that document you linked to at \\FILESERVER1\Docs\.
I setup an OpenWiki about 8 months ago and after an initial spurt of activity it died away pretty quickly, and now I am the only one who uses it in the whole company the reasons are simple (I think):
- The sales guys keep saying "How the f*ck do you format stuff on this thing. What in the hell are those stupid codes for?"
- There are only 13 people in the company at the moment so it hasn't been able to reach critical mass yet. I.e. if we had 130 people in our organisation we would all have to write ten times less for the wiki to reach critical mass, but we don't, we have 13 so we all have to write 10 times more.
- Following on from that, it just isn't organised enough, we wanted to use it to keep track of customer specs and information (word docs), but it is too difficult to update docs on the wiki - you have to download, edit, reupload.
Now, I setup a Sharepoint Team Services site nearly 3 years ago now, and it is still going strong. The reasons for this:
- I made it a group policy enforced home page setting.
- We use it to keep our timesheets - i.e. enforced use.
- If you upload a document, you can edit it directly from within word, no need to download, edit, upload etc.
- It looks pretty, the sales guys can just upload their PPTs and DOCs and add a comment. No need to no wether to use '' or * or / or -- or whatever to make a bold heading.
We are going to get rid of the wiki and STS, and go for Sharepoint2003, we did try using the document repositories in STS, but they don't let you do anything much more than upload docs in one big folder, we wanted to be able to categorise stuff (in multiple categories and folders, rather than upload it twice).
Chris Ormerod
Thursday, January 8, 2004
Are you asking about a particular wiki implementation, or how a wiki could implement it assuming funding like the Sharepoint team has?
As a Microsoft salesperson, you're absolutely right in arguing your product exists right now, and furthermore actually looks in your inbox or whatever voodoo it does. Hopefully I made it clear your company has a product ready. But since the original poster was also asking about what we dream of, the wiki way would apparently be to "put it into the system." Whatever storage media the wiki can refer to. You would be able to link to and search for it.
I wrote up a recent lecture someone gave, and what sucked was that he couldn't host his PDF slides, so I put it up on my server and linked to it from the wiki. That's not great integration. It can be better. But wikis are often Free Software projects made to scratch an itch. So it's somewhat pie-in-the-sky now, though probably there's some people working on it somewhere.
But I wouldn't define wikis as being something that only has a web interface; it's just the cheapest and most crossplatform way right now. There can be more than one way to operate on objects within the system.
Tayssir John Gabbour
Thursday, January 8, 2004
Oh, I don't want my tone to sound like a criticism of the fact you're an MS employee plugging his product. ;) I don't normally mind product placements on shows I like, as long as they do it obviously and honestly enough. I'm just pointing out that I'm talking more theory, and you're talking about a concrete product.
Tayssir John Gabbour
Thursday, January 8, 2004
Tayssir, and *I* apologize for appearing confrontational. (I thought it might be taken that way, but I was in a rush)
I wasn't trying to be huffy - I was sincerely curious as to how it would work, since I haven't worked with wikis much at all. The phrase "you link the document" is *very* ambiguous, and I wanted to be sure I wasn't misunderstanding.
I also think I got sidetracked by the term "design docs" in the first post, which immediately reminded me of *my* design document days, where the stuff that had to be kept around was more than just text [see my list above].
However, upon reconsideration, if we're just talking about a knowledgebase for developers, then I'll say that yes, a wiki would probably do the trick, mostly because of the ability to quickly edit stuff in-place.
But, for overall *project* knowledge management, I think SPS brings a lot to the table that a wiki can't offer.
I'd be interested to try a wiki/Sharepoint hybrid - probably with the wiki linked from the team's Sharepoint homepage.
Philo
Philo
Thursday, January 8, 2004
Somehow the discussion got sidetracked from "knowledge management for a dev team" to "project management" - which are distinctly different things.
Fry
Thursday, January 8, 2004
Are they really distinctly different? My thoughts are that those two areas probably overlap to a great extent. You need to manage the development "knowledge" as part of the development "project" managment process.
Just my opinion of course
Chris Ormerod
Thursday, January 8, 2004
Not necessarily.
Say you learned that Reflector was a really cool way to look at .NET based DLLs or the core of the framework. That's knowledge which you want to pass on to your team.
Or that you have tools stored on file server XXX.
Neither of these are associated with a project.
mb
Thursday, January 8, 2004
Forgot to add:
One of the best ways to build a document is to have the new guy do it. As they start into a project, they need to ask lots of questions. If you can get them to write to a blog/wiki/email/word document, then you'll have a base to start with.
I like wikis because they're so easy to edit. So when the next guy comes, or someone notices an error, the barrier to edit is so low it gets fixed then and there. The lowering of the barrier by a tool is important, otherwise everyone would have full wonderful websites edited in notepad.
(Sharepoint is better than a plain file or document server for Office documents for similar reason--you can look at additional attributes, look at versions, edit, search, etc, more easily than on a plain 'web server')
mb
Thursday, January 8, 2004
From my experience (and I've been using weblogs for more than two years, Wiki for almost three years, SPv1 for about a year (and v2 even when it was in beta), briefly Plumtree, and many other collaboration/KM tools), SharePoint v1 is little bit more than a document repository. The simple task of creating a page with two links to posted documents and one external link requires to use either FrontPage or Word document + Save As HTML. v2 is much better, but still, it's not a knowledge management tool.
Document upload is not the only way to share documents online. SP uses WebDAV to allow easy access to its folders and manipulation of posted documents. It can also be achieved by configuring Apache server (or any other webserver that has WebDAV support). The configuration is as easy as <Directory "Foo/Bar">Dav On</Directory> in your httpd.conf file. It allows you to save files to that folder directly from any MS Office applications, open that folder as a web folder, delete/update files in that folder. If you save a file as HTML, you'll get an HTML page without any additional effort.
We use a combination of blogs, Wiki, SP, and WebDAV folders. The biggest advantage of Wiki is the ability to link to other pages easily (both MyNewPage and [[My New Page]] will link to the same page) and to create new pages as needed. In some (if not most flavors) you also get version control, forms, metadata, skins (you can have different representations for your content), plug-ins, backlinks, attachments, and other features (like links being automatically updated when you move/rename your page). Definitely there is some learning curve, but it's not as steep as I originally thought.
Weblogs (we use MovableType) can be managed from the web interface or from Oulook (for example, using newGator plug-in that allows reading and posting messages without leaving familiar Oulook interface).
To summarize: there is no one tool that does everything; people don't use all capabilities of tools they already have; people who're willing to contribute/share will use almost any tool to do that.
Paul Kulchenko
Friday, January 9, 2004
> To summarize: there is no one tool that does everything
You see, and we said there were no new ideas. It looks like this space is ripe.
I think I said that about this space about a year ago in another thread.
www.MarkTAW.com
Friday, January 9, 2004
It is one of the hardest application areas to freeze a product around. In some ways the operating system should just do it for you, its not just developers that need this, all organisations need to manage and maintain their knowledge.
Simon Lucy
Friday, January 9, 2004
Wow, what an awesome thread, I have plenty of good leads, so many great opinions on this board I haven'e even digested it all yet. I will report back on some research as it goes, I'm grateful for your insight.
JoS Newbie
Friday, January 9, 2004
Philo,
Your wiki/SharePoint hybrid idea is exactly what we're doing.
Our wiki is linked from our Intranet which is a Sharepoint thingy...
It's hard to beat a Wiki for modifying and adding web pages to a site. It's hard to beat Sharepoint for sharing documents and being able to index and search on them rather than having them in a set of shared folders.
We do both. Actually even more than that, we have company forums for different topics. I think these are for more transitory conversations.
Rick Watson
Saturday, January 10, 2004
 Recent Topics
Fog Creek Home
| 
