I need your help for my question.
I need to build a web based application that should perform some activity of document management. I'm evaluating existing document management solution and I need a solution that expose api via rest or other protocol, so that I can interact with them from my application.
I read about alfresco, sharepoint and knowledge tree but I find difficult to understant prices for commercial use. Can someone help me with a comparison of function/prices for a commercial use?
Alfresco is available in two versions, Alfresco Community Edition and Alfresco Enterprise. Alfresco Community is under the LGPL license. Assuming you want to use it in-house (not distribute it to others), you can use + customise + extend Alfresco Community to your heart's content, without restriction or charge. (LGPL/GPL/etc are distribution licenses, not use licenses, so only kick in when you redistribute). However, Alfresco Community comes with no commercial support, only support provided by the community. For a lot of uses that's good enough, but for other cases you'll want to be able to ring someone for support / get hotfixes backported to your version / etc. In that case...
Alfresco Enterprise is paid for, coming with commercial support (including SLAs, pick up the phone and talk to an expert etc), along with a handful of features that matter in big deployments (clustering being one). Pricing depends on a few things, mostly around size of deployment and SLA, but for small deployments isn't too bad. For big deployments, it can be a huge saving over other systems! Give sales a call, they're very friendly, and only rarely buy me beer ;-)
If you don't want to run your own repo, there's also the Alfresco Cloud version, which comes with a public API. With this, Alfresco themselves run and maintain the instance for you, and you can use the public API to store / retrieve / manage / etc your content. It's much simpler to get going with! But you don't quite get as much control or customisation as with the on-premise versions.
SharePoint might already be covered by your existing Microsoft licensing deal, if you have one. If not, you'd need to decide between licensing on a per-server or per-user basis. See Microsoft pages like this to get an idea of the options, then ring your Microsoft sales rep to get an idea of the pricing. In many cases, you'd need to pay someone else for support, so you'd be back to a similar thing as with Alfresco Community vs Enterprise.
If you're not sure what system to go with, you might be safest and best off implementing your project using CMIS (Content Management Interoperability Services). This provides a common way to talk to content repositories, allowing you to store/retrieve/browse/search/permissions/etc irrespective of what the underlying repo is. Alfresco provide some information on it, and Apache Chemistry provides open source client libraries for most common programming languages, which makes getting started very quick. There's also an excellent book on CMIS which I can very much recommend! And not only because the authors of that have been known to buy me beer too... ;-)
Related
I have a client who has been using WebOffice (from WebEx) for a variety of tasks within their small organization. The problem is that they only really need a small subset of the features WebOffice provides (Contact list, Database, and Document Storage).
They've asked me to develop a website focused on these three features with the rationalization that this should be more cost-effective, since they currently aren't using many of the features of WebOffice they pay for.
What are some open-source alternatives that I could implement for them? Sharepoint sounds like it would be too bloated and Google Apps may not be as collaborative as they would like.
We looked at sharepoint and went like "meh". Anything interesting you want to do with it requires prohibitive licensing, and if you expose any piece of it to the internet then the cost just blows any budget away.
We are piloting a deployment of Alfresco, with KnowledgeTree also being a very decent option, IMO. As for the main site, something like OpenAtrium looks like a pretty decent and flexible fit without much configuration needed. OpenAtrium is based on Drupal.
SharePoint sounds like a good match? Did whoever told you it was bloated also mention why?
You might only need WSS which is free (if you have Windows Server).
My company hosts LumiPortal (www.lumiportal.com) which is similar to WebOffice but with drive letters for storage. If you have inhouse technical expertise, then on the open source side we see Joomla and Drupal, which could be thought of as classic content management systems. If you have in-house technical expertise, you might look at Drupal and their document management component first.
Call WebOffice customer service and tell them. They will probably adjust your payment options to suit your needs.
There's a good roundup of online collaboration/office suites here although it is a bit dated now.
http://www.readwriteweb.com/archives/web_office_2007_year_in_review.php
Webex WebOffice hasn't been updated in 5 years and has been sunset by Webex with no migration path (confirmed in their forums) so I would get off it ASAP.
With the addition of Wave to Google Apps it would seem to be a much more cost effective and modern replacement.
What open source toolkit does fatwire compare to and are there some particular advantages to fatwire?
How hard is fatwire to export out of and move to a free alternative?
How stable is it as a platform to write java extensions on?
From a development persepective, FatWire can be unfriendly. Having worked on a number of sites using this application it can easy bloat, and become difficult to maintain.
From a user perspective there has been alot of effort in the UI and this has led to a highly functional tool.
From a client perspective all clients bar 1 (a large news agency) were happy with the end result. FatWire can slow when using complex logic to generate menus or breadcumbs for example or when you have a large amount of content. This is the main reason the one client was unhappy. The FatWire site regularily struggled under the load. It sometimes seen as a solution to all web needs.
As such FatWire succeeds in serving Static Content & Semi Dynamic content, but can flounder when forced to do fully dynamic sites (from my experience).
From the original press release:
FatWire Software announced the rollout
of FirstSite, which is a set of tools
and best practices that helps
companies using FatWire Content Server
get their first Web site or
application running quickly while
providing a foundation for future
expansion. FirstSite includes a
collection of standard templates and
site components that are common to
most sites, combined with
documentation, training, a rich
developer community, and best
practices methodology. FatWire and its
solution partners are using FirstSite
as the basis for developing
content-centric applications for
specific vertical markets. With only
minor, cosmetic alterations,
developers can use the code in
FirstSite to implement a first site,
while simultaneously learning how to
utilize Content Server's capabilities,
such as dynamic content delivery,
personalization, caching, and product
catalogs.
Firstsite is not a product, unless this has changed since 2004 (unfortunately I cannot look, since their developer site is down). Fatwire's Content Server does not compare to any Open Source CMS that I know. It's scope goes much further. I will answer your questions one by one:
Advantages - There are many (or nobody would buy it, and it is not cheap)
On the delivery side: scalability, fine-grained cache control, stateless servlet architecture, ....
On the back office side: virtually no limit to asset types, dynamic content attributes, find-grained security and access control, ...
On the development side: Intelligently architected API with good coding productivity, tag library, ...
Openness
You cannot easily expect to migrate content between any two CMS products, open source or not. While there are ways to extract contant from the database in XML and other forms, using product tools, or simply at the database level, I don't think that this can be an argument for or against using a particular CMS. Ever tried to migrate from Drupal to Joomla?
Stable
I worked on several Fatwire implementations from 2000 to 2004 (back then it was OpenMarket Content Server, then Divine Content Server). It was stable enough for the Washington Post, the New York Times, and the S&P sites, and I would expect stability not to be an issue today.
Fatwire is really unique concept from developer point of view. It builds everything on a very abstract, extremely flexible clever asset modeling framework which is stored in relational database.
Application logic is based on "templates" which actually are pieces of JSP code. This JSP code is not like conventional Java, but tags instead. It takes very long from a developer to learn these tags and Fatwire asset api. Expect even months before skilled develpers start to be productive.
Almost nothing useable samples ships along the product. There is advertized "FirstSite" but it is way too simple for the purpose this product is used normally (huge complex sites). So pretty much everything has to be built from scratch.
Cache control is advertized to be one powerful feature. Yes it is, but we had extremely long learning curve and it never worked exactly like one assumed.
Wysiwyg editing has been missed from this product even it is advertized. At least during 2009 it had serious conceptual problems which practically prevented using it in live environments. But it was cool feature for demos and marketing of course. Today it might be fixed.
As a summary and if I were a customer with limited budget, I'd select any open source alternative instead. Mostly because development costs with Fatwire are high due the uniqueness of the product, lack of good documentation and extremely long learing curve. Of course the product price tag is also thing to consider.
And to answer to questions: you have to start from scratch if you move from Fatwire 6.0 to any open source alternative. And it is stable to build Java extensions on.
Fatwire stores content in relation database and file system. Depending on what type of content (structured/unstructured), Fatwire can be evaluated.
At our company we are currenty trying to define the basic things our software architects have to know about SharePoint for them to architect and/or lead a SharePoint implementation project. Many architects in our company have a .NET developer background and know a lot about .NET development and the various framework components and tooling. However, they currently lack SharePoint knowledge. In fact they don't even want to know the nitty gritty details. They want to know just enough about it to make the right architectural decisions and apply proven patterns. If more specific knowledge is required they'll ask a SharePoint expert.
So What would is the basic set of SharePoint knowledge / skills that an architect would need to have?
Skills such as list, documents, workflow, permissions... are a bit too basic and are requirement for a SharePoint DEVELOPER.
I'd argue that perhaps site (and site structure) is an area that would fall under the architect's plate.
There are more areas that a SharePoint architect can help with:
Capacity planning - running multiple servers in a farm. Scalability and other magic words.
Knowing the capabilities and business scenarios of using SharePoint - this is a very common one.
The manager asks: what can SharePoint do for me?
The developer asks: well, what do you want it to do.
The manager then asks: well, I don't know what it can do for me so how do I know what do I want it to do?
Closely related to SharePoint capabilities are the various licensing costs related to each component.
As well as familiarity with development and customization costs. Take the same project time that would have taken in ASP.NET, then multiply it by a large coefficient, and then add an additional constant.
And closely related to what-can-it-do, and how-much-does-it-cost, is the all important question of Return-Of-Investment. All hail supreme ROI!
SharePoint deployment can be a massive issue and a lot of pain.
SharePoint upgrade from v2 (MOSS 2003) to v3 (MOSS 2007). We should be seeing a new version of SharePoint in 2010(?). Well soon after the next version of Office goes out the door. So past upgrade experiences may be useful.
Knowledge of 3rd party webparts. I believe a SharePoint architect should be able to give you at least 5 webparts that they've tried from CodePlex and tell you what they think about them. These are free and easy to grab and play at your own leisure.
Some knowledge of commercial webparts. Because they are still cheaper than writing your own.
Have at least 5 SharePoint blogs that they follow religiously (know the community). If not having their own SharePoint blog (give back to the community).
If they are on StackOverflow they must try to answer SharePoint questions (such as this one).
Attend local SharePoint usergroups. I think communities are a huge deal. Especially what you'd learn from talking with people directly and learning what they are doing with their SharePoint installation. You may just surprise yourself.
Experiences with SharePoint Integration - this comes in two equally important flavours - both from SharePoint accessing existing systems (business catalogs, webparts, etc), as well as other systems accessing SharePoint content via webservice or API.
In addition, SharePoint works with (or works well) with Office, OCS, reporting services, performance point, project server.
SharePoint hosting arrangements - Microsoft SharePoint online services can be a popular and cheaper option to start using SharePoint. It can be hosted inhouse, or with a 3rd party company. Knowing the options is always useful.
Must have read SharePoint code using reflector (and preferably still having hair).
I think it takes at least a couple of years to be a SharePoint architect (your mileage may differ). Your .NET architects need to want-to-be a SharePoint architect, otherwise I agree with other's summaries before me - find someone who already is a SharePoint architect.
An architect should have quite a good understanding of our a product works, from a functional and technical viewpoint.
So in my opinion, an architect should:
Have been involved in at least 2 Sharepoint deployments, from design to roll-out.
Have knowledge of our the major sharepoint components can be used using the API.
i.e. Sites, Lists, Documents & Workflow components.
As none of your architects have this knowledge, I would pair them with a Sharepoint expert in an existing Sharepoint project, so they get the knowledge they need.
Ideally SharePoint Architect Skills fall into the below mentioned categories
Infrastructure Level/Operational
Capacity Planning
Physical Architecture (Farm Setup, Network, OS, Licensing)
Application level (Functional and Non-Functional)\
Requirement and Feasibility Analysis (Custom Vs OOTB Development/Implementation)
Techno-functional Mapping of requirements
Information Architecture
Logical Architecture
Conceptual Architecture
Detailed Design
Database design (not in terms of traditional Database design), this is with respect to Number of content Databases for Site collections/web apps.
Deployment
Best way to go for deployment, first time and incremental
Some other activities that an architect will collaboratively work is the Project Manager in Planning, Estimation, Execution/Implementation, Risk Management (assessment, mitigation).
Apart from his daily tasks of working with technical teams, testers, User Interface professionals, Vendors, Clients (Business and IT teams).
Interacting with Enterprise Architect groups if any.
In my not so humble opinion I think the entire "Sharepoint Architect"/"Expert" thing is over-played.
Sharepoint is a tool to centralize an organizations digital resources for centralized collaboration or working together in a centralized way.
The best explanation of What Microsoft Sharepoint is and does
from the WROX book "Beginning Sharepoint 2010 - Building Business Solutions"
"Because computers play such an integral part in any business, not surprisingly, more and more
of the information that is created, consumed, and shared in an organization is digital. The more
business that you conduct and the more successful your business becomes, the more information you
have to manage. Usually, you have some form of document for just about every process and transaction
that plays out during the day-to-day operations of your company. From proposals to legal
documents, from sales receipts to human resources policies, the amount of information required for
a company to function is staggering.
To manage your information overload, SharePoint offers tools with which you can build business
applications to better store, share, and manage digital information. With it, you can create lists,
libraries, and websites for your various company teams to help run your business processes more
efficiently. By locating your organization’s important business data in a single location, it becomes
much easier and intuitive for users to find the right information when they need it rather than
searching through disparate locations such as email, computer hard drives, or file shares.
WHAT IS SHAREPOINT 2010?
SharePoint 2010 is an extensible and scalable web-based platform consisting of tools and technologies
that support the collaboration and sharing of information within teams, throughout the enterprise and
on the web. The total package is a platform on which you can build business applications to help you
better store, share, and manage digital information within your organization. Because you can build
with or without code, the package empowers the average business user to create, deploy, and manage
team websites, without depending on skilled resources, such as systems administrators or developers.
Using lists, libraries, and web parts, you can transform team websites into business applications built specifically around making your organization’s business processes more efficient."
Creating a schema for an organizations Sharepoint deployment is not rocket science. 1. Determine the structure of the organization 2. Determine what Sharepoint can do as far as centralizing the organizations digital resources. 3. Create a Sharepoint construction plan. 4. Build it, test it, refine it. 5. Maintain it, test it, refine it, add onto it. There! Not so tough.
Sharepoint can be a nasty beast to work with if you don't know the ins and outs of it (they should be experts with it to architect it). At a minimum, they should know how lists, sites, and permissions work. Ideally they should also know how all the web parts fit together on pages and how they are supposed to interact. Really if the architects don't want to learn about sharepoint, they are going to create a .net web application and force it to run on sharepoint. It won't really follow the paradigm of how a sharepoint app is supposed to work.
I would look at a company called Mind Sharp for guidence as to what they should learn.
My advice is look for a doer that doesn't just reads PowerPoint to much in the Sharepoint world is just based on what other people have said.
We have been having issues with crawling 500000 items in a Sharepoint farm and everyone gives another story how to get better speed... Normally people refer to not more than 2000 items in a folder, but that does not change the crawl speed....
So a good architecture is someone who is able to do POC proof of concepts himself of his design and not just refers to some vague stories.....
I have seen to many Sharepoint Architects that hasn't had experience from real life....
My company is a custom development shop for a number of projects, some larger and some smaller. Currently we handle all of our client communication through email. So we email a design doc, they mark it up and send it back. Then we roll out a beta version of their product and they email us with any bugs, new features, etc. And so on....
As I am working on implementing a new bug tracking system (it looks like it will be Mantis right now), I got to wondering how we could best allow our customers an interface with our development process that would provide better tracking of feature requests and client submitted bugs as well as communicate our responses back to the client.
If anyone is aware of a a bug tracking system that does this exceptionally well I'd be interested to hear of that. Otherwise I'm just looking for some general guidelines or good business practices that have allowed your companies to interface effectively and efficiently with your clients.
UPDATE: My company uses a LAMPP stack and as we are a small shop with a limited budget we tend to stick to tools that are open-source and free.
Do most people either use Team Foundation Server to handle this or emails back and forth?
I think the key is to have the dedicated tracking system there for bugs/requests, and to establish a set process for communication. With that at minimum you will start getting consistent feedback. From there you can tweak it to get your specific needs.
As an aside, rather than just using e-mail for your communication, I strongly recommend going to smething like BaseCamp for a project management tool. I find that it helps greatly with keeping messages, documentation, and timelines communicated to the client.
If you are using Team Foundation Server, I recommend you to install TeamPlain Web Access. They allow you to expose a web interface to your TFS project. The only things left to do, is give rights to your client and a username and a password.
Otherwise, there is some paying tools like FogBugz. Of course, the principal is having to bug reporting tools directly linked to your Source Control so that the developers can easily fix bugs.
Although I know of no specific tools (at least no open source ones), I suggest that you setup a system which will cover your overall requirements gathering and implementation process. Requirements could be tracked in the system, which would also contain the design documents (which could be "checked out from" and "committed to" the system). This way, you would tackle the problem of having multiple revisions of design documents around. Addionally, the design documents and the requirements could be tracked easily. If this system were linked to your source code management system, you would additionally ease your development process/requirements tracking.
Another possibility is to use two products in concert, here's our current setup with a team of 12:
osTicket for incoming requests from clients
Allows for issues to be handled by support staff and bugs to be verified
Status can be checked with just an email address and ticket ID
Typically users don't submit detailed enough bug reports so is a good first step
redmine for development tickets
Ticket created by QA or a developer if issue is a real bug
Provides solid enough project and release management
Is a solid step up from trac and mantis (and provides migration tools)
I am currently working on a project which requires migration of content from different content management Systems to SharePoint. Are there any good, preferably open source, tools that would help me do this? Also, what are the best practices that I would have to keep in mind when it comes to such projects. One more thing that i would like to factor here is reusablity, because we might have to work on similar migration projects, from other Content Management systems in future.
You can check http://www.codeplex.com/SPMigration (open source, project started by a Microsoft consultant).
This framework gives you an importer tool, as well as some exporter example (FileSystem for example). You'll problably have to code your own exporter.
This MSDN blog also goes into some detail about the Migration API and may be useful as its generally very had to do this sort of thing without getting your hands dirty
http://blogs.msdn.com/sharepointdeveloperdocs/archive/2007/11/30/content-migration-in-sharepoint.aspx
Also, IMHO you shouldn't dismiss proprietary products as although they can be expensive they may save you considerable time and therefore cost if you have a large conversion project.
http://www.tzunami.com/Pages/default.aspx
http://www.avepoint.com/products/sharepoint-migration
Tricks and tips -
http://www.parallelspace.net/portals/ALS305-mwherman-Content%20Migration-1-1-18-RC6_FINAL.ppt
We have had good mileage from going to the nearest university and grabbing some IT students to do a manual migration.
The students like the extra cash and it is sometimes easier when the Information Architectures of the site changes between systems.