Let's assume that you've created a SharePoint solution - a WebPart, a feature for a List Template, whatever - that you are planning to sell as a product.
How would you go about handling licensing of your solution?
I'm looking for some input in at least the following areas:
Code-wise:
1.1. Where do you keep the license itself? as a file somewhere? (then what happens in farms?) as a property in the property bag of the farm?
1.2. Do you implement "home-calling" - where your solution validate the license every now and then against your company's servers?
1.3. Any other best practice in this area will be welcome...
Business wise: How do you license - per user? per server? per instance (in case of WebParts or List Templates)?
Thanks.
I could tell you what we do:
We have a separate farm solution that handles trial/registration support for all our products
The license is eventually stored in the farm property bag (you have to support multiple servers)
We have a page to enter license key under the central admin solution's page
We license by front-end, you can know the number of front-end in the farm in code.
All products have a product name and the license key is a one-way encryption containing the product name. the trial support solution handles key validation.
1.1 You have to put in in the documentation and in the distribution files.
1.2 I would not do that for a sharepoint web part.
1.3 Invest in layout, documentation, support... Not just in the product itself.
Nobody will be able to answer that without knowing detailed information about your product, your market, your competitors, the alternatives, etc. Consider this book if you are serious about pricing.
Related
Is there a Kentico Small Business Edition for purchase?
https://www.kentico.com/download-demo/free-cms-for-asp-net/kentico_12_editions.pdf
You should email sales#kentico.com and ask them. Since what is available to purchase starts at Base on their site, this small business one might be a free one under special conditions or no longer offered.
The Kentico Small Business License was introduced in 2009 as something that is only available to Kentico partners. This was following feedback from existing partners that smaller clients who did not need the full features of Kentico CMS.
It is still available as far as I am aware, but you would need to be a partner to get access to it.
We have a custom solution made up of several screens that are packaged as a customization package. We'd like to be able to lock that down so that users need to purchase a license key to use these screens. I don't want to re-invent the wheel, so I'm wondering if there are standard examples (if this has been done before) on how to integrate this with Acumatica's license system.
It is not possible to integrate with the Acumatica licensing system. We implemented our own licensing and required the license when the Acumatica license has been applied. This is indicated by PXLicenseHelper.License.Licensed
I should point out I did spend a good amount of time on this very question before we implemented licensing for our product.
I am building a publicly facing website that does the following.
Users log in.
And then view a list of their customers.
They click on a customer to view their past purchases, order them, change them etc.
This is not a shopping site by the way.
It is a simple look up tool.
Note that none of the data accessed by the website is in anything other than a SQL database - no office documents. Also, the login does not use users Windows credentials on a VPN or something like that.
Typically I would build this using a standard ASP.NET MVC website.
However the client says they want to use Sharepoint.
As I understand it, Sharepoint is used for workflow and websites that are collaboration tools such as the components you can see here http://www.sharepointhosting.com/sharepoint-features.html
Here are my questions:
Would I be right in saying that WSS is completely inappropriate for this task as it comes with an overhead that provides no benefits?
If I had to use it, would I need WSS or MOSS?
If I had to use it, would I be right in saying the site would consist of :
List item
a) Web Parts
b) And a custom site layout. How do I create one of these?
Addendum:The book Professional SharePoint 2007 Web Content Management Development looks like a good start
1.) I agree that SharePoint would be quite inappropriate for this task. A few reasons:
It costs thousands of dollars to license SharePoint for use on the open Internet
SharePoint will use a lot of resources (SQL Server, IIS, Active Directory...) that are unnecessarily demanding for your task
SP will give you very little flexibility to develop a solution in your way -- it sounds like you would need to create a database-connected Web Part in ASP.NET anyway (so that could be entirely independent of SP)
SharePoint has it's place--it can be remarkably helpful as a company's internal document management, intranet, and workflow/approval system--but it is not well suited for custom code nor Internet use.
2.) I believe MOSS would be required for the Internet license (as in the link above).
3.) SP development is not like typical relation database systems (for example, it uses flat, unnormalized tables). If your SQL matched the SharePoint way of thinking, you might be able to connect to your database as an external List using SharePoint Designer. More likely you would need to use Visual Studio to create a custom Web Part in ASP.NET.
Hopefully this'll be a few reasonable arguments you can use to help the customer see how SharePoint is inappropriate for the task... In fact, I expect just the first point (the cost of licensing) will turn them.
You can technically use WSS for this task but MOSS has more features aimed at building public facing websites. The publishing infrastructure comes to mind. It has has the CQWP which enables you to build custom interfaces which perform well in SharePoint. With SharePoint there are potentially challenges around scalability. If you know the platform well then doing something like what you have suggested would be a pretty quick task. If you don't know SharePoint and the underlying system well you could face challenges.
You do not want to approach building the final application with SharePoint Designer. It has behavior which can cause major problems with scalability. You want to create a SharePoint Solution comprising a number of features which can be easily deployed to SharePoint. Going this route does not alleviate performance problems but you are going to be closer to the right solution. You can package up the custom user interface elements as CQWPs or write Web Parts. I personally prefer to write Web Parts.
You do the overall site design in a Master Page. Pages within a site are then inheriting from this. If you have MOSS then you can create what are called publishing pages which contain your Web Parts. These are not available in WSS which is why people recommend against it for public websites.
To decide whether SharePoint (any version) is worth it, you need to find out if they are going to use any of the core features. If everything is going to be custom and you are not going to make use of any workflow or document management features in your deployment then I would stay away. To see whether you want to go further with SharePoint from a development perspective, take a look at the WSS developer labs. I recently ran an intro course at my employer using the materials from that site. They are dated, and need more info on best practices but they provide a quick way for you to dip a toe in the water and decide whether you want to go any further.
1) For the core functionality as you describe it SharePoint isn't going to add anything, BUT if you build it on SharePoints premisses it allows your client to add a lot of functionality outside the core for "free" like:
They can add Content Editor WebParts to pages where they can add descriptions, and messages
They can add lists where the customers can enter requests/comments/... and automatically have new entries mailed to anyone in the organisation subscribing to changes
The functionality you develop can be reused on their intranet
Any future small "web apps" can be included in the same site
...
So all in all unless you have a better framework to use then use SharePoint
2) WSS is all you need for now
3) Your main deliverable for now would be:
a feature with some Site Pages and a few Web Parts
a feature with a custom masterpage and corresponding css
True. Well not inappropriate but it doesn't add anything either.. but maybe in the future?
WSS is enough
You'd need web parts to expose your data, yes. The custom site layout is not necessary. If you want your own look and feel a SharePoint Theme may suffice. Even if you want some real custom layout tweaks you probably don't need a site template but you can get away with using just SharePoint Designer to edit the pages or master page.
I work for a large organization and we have been utilizing SharePoint for document library. Yesterday my boss called me to his office and asked me:
"I heard that SharePoint is an ECM! So what can it do for us?".
"What kind of problem do you want us to solve utilizing SharePoint?", I replied.
"I want to know what it means when they say it is a ECM and how it can help us?", He said.
I told him it has Document Management, WorkFlow, Records Management, Search and some other stuff.
Anywho, He wants me to put togetter a list of things that SharePoint offers as an ECM.
You might find some useful info on the MS ECM team's blog.
Microsoft Office Sharepoint Server has a substantial content management system available. What was previously Microsoft Content Management Server was discontinued and that functionality was put under the Sharepoint umbrella. Usually this is referring to web content, but it can honestly be any kind of content relevant to an enterprise. It is intended to be a direct competitor to all the major WCMS out there, focused especially on the enterprise (governance, auditing, security model, etc).
That having been said, the current iteration of MOSS's EWCM pretty much blows. If you can develop your CM strategy to be parallel to MOSS, it can work out OK, otherwise it's much more pain than it's worth. Use SP for document management and use something else for content management.
Sharepoint is a collaboration platform restricted to a windows environment
Give Alfresco communities (labs) a go is my opinion here as it 'acts' as a Sharepoint server so Microsoft Office suite will not notice the difference but your wallet will...
Er... think the boss got a bit too much $$$ to spend. But really, an't we supposed to deploy a technical solution to solve a business problem.
The list of features can be found at
http://sharepoint.microsoft.com/product/capabilities/Pages/default.aspx
We are researching the various options that exist in our environment to create an Employee Directory. We have a SharePoint portal, AD and recently moved from Lotus Notes to Exchange. Our current employee search is a custom Notes DB that has since been retired.
Since moving to SharePoint an year ago, we've used a custom list using SharePoint Profiles that are updated from AD. But the simple list interface isn't very user friendly and is very slow. Sone of the requirements include type-ahead, pictures, and details of skills/certifications and other demographic information etc. We are considering building an ASP.NET or SilverLight application that can consume the information in the SharePoint list. With the introduction of Outlook and the Global Address List, we are now wondering if it might be easier to build something within Outlook.
Has anybody traveled a similar path and what would you advice us to do?
Microsoft has a huge set of offerings for Collaboration and Social Computing in Sharepoint.
See this document, pages 8 and 9 for information about features related to an employee directory, including details of skills/certifications and other demographic information.
A la carte availability of individual features (such as People Profiles and People Search) and pricing may be an issue, but you may want to look into buying something rather than building it (if you can get the pieces you want for a price you can afford).
Sharepoint can connect with Outlook to keep the lists synchronized if you want to use outlook. And there are definitely a lot of different ways to change the way the lists are presented in the Sharepoint portal to make them more user-friendly. Having those details on the portal will certainly be a boon when combined with the powerful search and indexing features in SharePoint so you can identify employees based on their profile details easily.
We use the people search for this pretty effectively. We populate data in AD, then connect profile properties to AD attributes. That's only if you have MOSS, though. If you're working with WSS, you'll have to build something more custom.
One gotcha, though, is that the People Search out of the box doesn't easily do partial searches (i.e. searching for "john" doesn't match "johnson"). That's a big downer in my mind. You can use Ramon Scott's approach of a Content Editor Webpart with a form and some Javascript to work around it, and you can also get there via the advanced search box (albeit indirectly), but it sure would be nice if it were easy to make the default search box do partial name searches.
I recently just discoverd a somewhat easy visual basic script that draws information from the active directory where you can specify which OU to draw from where it displays all user information in a simple .HTM page. it includes a search bar, recognizes patterns (address) (company telephone number) etc... If you would like i can post it for you. you only need to fill in a few sections (display name for directory, OU, OU display, and tags) and you can always change the way things look too.
This should be taken care of by using the My Site feature that's available within SharePoint. You will then be able to search SharePoint users by skills, certifications, projects, and educational qualification.
Please refer to the SharePoint Planning and Deployment material on TechNet for more info.
SH.