As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
A medical practice has approached us about using Filemaker as a fully-fledged EMR system with a HEAVY emphasis on using iPads to enter patient records, photos, digital signatures etc which can obviously be accessed on desktops as well. Ultimately they would like such a system to replace their current EMR and takeover all billing operations, patient scheduling and so forth. They only use Macs in their practice.
We have very little experience with Filemaker but found this discussing the Pros and Cons of it however it seems that Filemaker has come a long way since 2009 when that question was asked...
So overall I'm just trying to work out if Filemaker is suitable for such an application or what would be the pros and cons of using a combination of FMP12 and FM Go.
(Sorry if I've done anything wrong - first question...)
Thanks!
As a FileMaker Developer myself, I would say go for it. I agree with Mikhail - You WILL see results faster than any other platform. You can make changes yourself easily and live or you can get a FileMaker developer - just like you would need to get a developer for any application.
With an off-the-shelf application, they tend to be quite inflexible, however I am sure there are systems out there that allow some customisation.
FileMaker is a very capable product. We have written many applications for vertical markets, such as law firms and even a Harley Street plastic surgeon who gathers patient data on an iPad and even sketches the suggested surgery on a picture of the patient.
For those who think FileMaker is a baby, have a look at http://www.businessmancrm.com - this is a full ERP system used all over the world. This is not an advert, but a demonstration of what is possible with FileMaker.
Dollar for dollar, FileMaker will win hands down... and when it comes to time frames, there is no contest. We are open minded - We constantly look for other products to develop applications for ourselves and customers and we have not found anything more viable just yet.
Pros:
Extremely quick environment
Cross platform
Integrate other SQL data sources into application
ODBC Support
Remote Access
Can be run from a USB stick if needed!
Thousands of developers around the world
Large community
FileMaker Inc. have made a profit every single quarter since existence, therefore are stable and do have the backing of Apple!
Reasonable Cost
Make changes yourself
Easy to backup, supports incremental backup
Easy to secure and encrypt data on a network
Supports terminal server
FMGo is free
Cons
High level language (not low level with layout object control) - However does support plugins
Requires FileMaker client (unless a web application/interface is built in PHP or using IWP - Instant Web Publishing)
Proprietary Database (however can easily link into MySQL, MSSQL and Oracle)
Honestly, not worth it.
It's a very clunky front-end for a database.
If you do decide to pick it up your basically stuck with paying a Filemaker developer for the rest of its existence.
One of my clients at the moment has had it for the last ~6+? years after only being with them for the last 8 months i'm trying very hard to push them away from it and onto a newer system.
I can suggest looking at Mastercare EMR, Profile and MMEX.
FileMaker is perfectly capable of it, of course, and I expect you'll be getting first results much faster than with any other approach, especially with the iPad. There's quite a few EMRs out there written in FileMaker. There are downsides, of course; it was always targeted to end users so it ended up fairly inconventional from a common programmer's point of view. Many programmers dislike this. Being end-user it suffers from many simplifications (well, not exactly suffers, actually; this makes development faster as there's fewer choices), but people always want something special so there's a huge number of workarounds to overcome these simplifications. These workarounds vary from relatively harmless to very hairy ones.
For example, to sign documents on iPad you need to add a webviewer control pointed to a generated HTML page via the "data:" protocol. The page is going to have a JavaScript that captures user's touches, paints them on a canvas, and serializes this into a string. Later a script will capture the string, store it in a FileMaker field, and change the generated HTML to use this string so the JavaScript can redraw the signature. This one is relatively simple and since the functionality cannot be obtained in any other way, it's in wide use; there's even a commercial module for around $300. A complex app may consists of dozens of such workarounds; anyone who is not a FileMaker developer won't be able to understand why you need a webviewer to capture a signature or why you use a strange contraption of invisible tabs to display what looks like a simple pop-up list. I.e. it's not like you read a book and work from there; be ready to read quite a few blogs and frequent forums and mailing lists.
That said, it's a good product nonetheless with unique capabilities (that iPhone/iPad client, for one); paired with a good developer it can be very powerful.
Having developed an EMR system at a recent position for 3 years, I can tell you from experience that the requirements for a true EMR system may quickly outgrow the scope of what is easy to do in FileMaker. A few really big, important EMR features come to mind immediately:
Insurance Eligibility verification: is there going to be a way to hit all of the major payers' web services or a third party aggregator to verify insurance eligibility from the iPad?
Insurance Card OCR: sure you can snap a photo of an insurance card, but now you have back office staff typing that information in from an image. We implemented OCR of insurance cards in our EMR and it was a huge cost and time saver.
Security / Privacy concerns: HIPAA compliance is a big deal, and is FileMaker suitably transparent to be compliant? Is there any way to audit who looks at a record? How is the data transferred across the wire?
E-prescribing: All modern EMR's support electronic prescriptions, which carries a complex set of rules and implementation details along with it, I would want to be certain FileMaker could be integrated with an e-prescribing gateway before proceeding.
My main concern with using any off the shelf, cross platform tool to approach a problem as big and complex as an EMR would be getting painted into a corner down the road, having invested a bunch of time and money into a solution that may leave you unable to implement a feature or requirement, whereas paying the up front price of developing a native iOS app (and web apps and whatever else you need to integrate with) would eliminate that possibility, but obviously cost more.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
First off please have patience for this long winded post. I wanted to get all the pertinent information (as I see it) out to you.
I have a decision to make and would like your input. I have recently taken on the task of taking over my daughter's skating club's website. They have a custom site written in asp pages and don't have anyone to support it. I want to move their site to a CMS system so it doesn't take a developer to maintain or make changes to it. We also want to add some custom pieces to it like a registration form for the club and some other custom pieces around marking down scores and viewing stats and such.
I am a .Net developer and have been developing in SharePoint for some time, but don't feel that SharePoint is a very good fit for them. Our current web host is GoDaddy. I don't yet have the details of the contract with them yet so can't comment on the service we have with them.
I have been looking at three CMS's at the moment. DotNetNuke, Umbraco, and Orchard. All are good and all have pros and cons as far as I can see. I am currently leaning towards DotNetNuke for the following reasons:
Umbraco appears to be a "create from scratch" system with no templates to apply (I apologize if this is incorrect, but it is based on the information I received). I am not a guy to develop the visual aspects of a site, so would rely heavily on templates and such.
Orchard sounds like it might be a good fit, however I have never developed in MVC before. Most of my .NET has been straight ASPX. I am not opposed to learning MVC and have had it on my list for a while, but I don't know if I have the time to learn and port over the current site.
Orchard also appears to be a bit heavy for a normal user (explaining content types and such). I want something others can take up when I pass on the responsibility.
So I am wondering what you all think. Even with learning MVC would Orchard be the best platform for us based on the information I have provided? Should I stay with DotNetNuke as my choice? I would like to mention that I did consider Sitefinity and would have had it at the top of my list, except we are a non-profit and don't necassarily have the budget for a paid CMS.
Thanks again and I look forward to your thoughts.
Well, the ultimate choice will vary on your business need. They all do the same thing, but how they achieve the goal is quite different.
Umbraco - It utilizes the Model, View, Controller (MVC) methodology. This obviously presents an assortment of benefits. However, the methodology to build a product can be quite extensive and even the layout to modify data can be quite cumbersome.
DotNetNuke - Uses a more familiar technology, Web-Forms. This has an assortment of benefits that go a long with it. Including a market, documentation, permission, and ease.
I've never used Orchard so I can't comment- but I can comment on the other two. To show you how I came to my conclusion to use which Content Management System hopefully it will point you in the best direction.
My project that I worked on required a lot of non-technical people to utilize our new product. It has a lot of functionality and features that were required; the biggest however was ensuring the following:
Ease
Intuitive
Control
Speed
Those were our four primary categories. I'll attempt to outline what each area means-
One of the largest pitfall of a Content Management System is that they tend to do more then you require. So the question becomes which product will bend while maintaining my core goals be. For that reason our company chose DotNetNuke because by nature DotNetNuke isn't a Content Management System it is a very powerful Framework.
What this particular product does is focus on a lot of key aspects so a developer doesn't have to waste a lot of time in maintaining but rather in developing.
Ease - A non-technical user is able to view a page; then edit the content in place on that page. Which allows you to incorporate a What you see, is what you get mentality. For the non-developer they get the all familiar Email or Word Editor.
Intuitive - In DotNetNuke 7 they've modified the menu structure for editing. You can actually disable other users to make it actually show less, do less, and still maintain the highest level of control. The user won't get lost in editing the page.
Control - Now this is what is nice, you can regulate each and every control for your user. So you can allow certain content to be regulated and other data not to be.
Speed - It has a market, so you can implement other developer modules. But it also includes a lot of documentation- it may appear cumbersome at first but is quite easy to pick up. Which makes the initial start time relatively painless.
But what do all of those mean to you?
Simple, it means you can develop a beautiful elegant page quite quickly. But since you can restrict several tiers of access you can ensure the page content can be edited by someone other then you- But it won't jeopardize any of your development / content. As you control whom and what is modified.
If your familiar with Microsoft .Net then it will be quite easy to learn; I'm sure other products can accomplish those same goals. But DotNetNuke did it easier which met our goals. It allowed us to not worry about excessive issues or support to enter our company; as the user understood it in such a way that issues don't arise.
That is why we chose DotNetNuke it will boil down to your preference. My experience with the product, community, and marketplace have made me love this product and not chose another. As I can leverage the Core API when needed; so Development, Maintenance, Administration became a breeze for whatever my imagination may produce. But should a developer ever not be present the site and it's quality will not hinder when I leave.
There is a selection of starter kits available in the package repository on the community website and also a few of them can be applied directly during installation of Umbraco. Also in the package repository you will find a wide selection of other packages which you can use on your site to enhance and add additional functionality.
It is true that Umbraco does not come pre-installed with "themes" as such like some other CMS's but this is the beauty of Umbraco, you have a clean slate to work from if you choose. It enforces no requirements on your markup or styling so there is absolutely nothing to stop you using a free or purchased template from any one of the template libraries online such as Creative Market, Template Monster etc etc.
Umbraco has an incredibly friendly, helpful and active community on both the forums and Twitter.
I work with all three and would tell you to use DotNetNuke over the other 2. The primary reason is that if you are developer, Orchard and Umbraco are fine... but you may or may not be the final or future content manager in the future of the club and want to be able to hand the site off to someone. DotNetNuke has the larger community and would be easier for the future admins to learn as well as get support for.
DNN will give you the development options you want, but give the content editors the easier system to work work... and keep you from having to support the site if you ever move on.
don't forget that Sitefinity does have a free community edition: http://www.sitefinity.com/try-now/free-asp-net-cms
it does have limitations, but for simple sites like this it might be just what you need, plus if they ever get a budget someday they could upgrade to the Small Business Edition by just buying a license and get more features and less limitations on the content and page limits.
worth a look.
otherwise, in my opinion your choice depends on who is going to be maintaining the site. If that is you and you'll always be in charge, pick whatever platform works best for you as a developer.
If on the other hand you have to make it drop-dead easy, pick the platform that is best for end users, that based on your knowledge of the user, would require the least amount of training (Sitefinity CE has my vote on that one!)
I hope this is helpful!
I would highly recommend going with DotNetNuke for the sheer reason that the community and available modules for the platform far surpasses any of the other options.
If you want to do MVC style development, you can with DNN using the WebAPI approach for services, but if you don't want to, you can skip that altogether.
The amount of Free and Paid extensions for DNN grows on a daily basis, available in the Store or Forge. You can also search both of these locations right from within the product itself.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm currently a developer at my first job right out of college. I work for a large company, and the trend I notice with them is that they tend to go with more expensive, closed source software about 99% of the time, while there are perfectly good open source alternatives that are available, most of which are vastly superior to their closed-source counterparts. For example, we use this absolutely awful source control software that cost a ton of money, while there are quite a few open source and/or free options that in my experience, albiet limited, are much better and offer basically the exact same functionality.
I guess my question is: How would an experienced developer approach management about using more free software?
It appears there is another question very similar to this that did not show up when I made this one: How can I convince IT that F/OSS software isn't evil?
EDIT: Just come clarification. I'm not necessarily trying to change the company's procedure, I'm looking for advice on how to approach management about the subject.
Start using it in small utilities and things which are throwaway and don't need management buyin. This can prove the worth of an open source solution and put a crack in
the door for using it in other
projects.
Present articles from trade magazines showing that other people are using the open source solution.
Go with products which have commercial support options, such as MySQL, which enterprises seem to have an easier time swallowing.
Pick your battles carefully. Wait until they are suffering. If they are happy with what they have, they will not switch, no matter how much cheaper or superior the alternative is. You need to catch them while they're trying to think of ways to save money, or while they're disgusted with the problems of the current system.
Be very careful with what you refer to as free. There is a very large corpus of products that would be perfectly valid for a student to use without paying that an enterprise would have to pay for. Also never forget Total Cost of Ownership (TCO). A lot of relatively expensive software is expensive because you get things like configuration and help support for them whereas that may not be the case for free software.
I think you are not asking the right question. To me, the challenge is to have my Big Corp to buy the BEST softwares for me, be it free softwares or not.
Paying for Windows or paying for Linux is not important (what is 100 $ for a Big Corp ?).
But having things done better is really important.
I think that your request to your boss should not be : "Hey, it's free and it's as good as XYZ, why are we using XYZ ?"
Why you boss would risk something trying the product you told when XYZ seems to be ok ?
It would be much more better to ask : "Hey, here is what I cannot do with XYZ : (your list). With my product, I would be able to do that and much more so fast than I would have a lot of spare time to test our own software !".
Small money is usually not a show stopper. Being able to work faster in order to do much more testing (or any other things that could help your boss have a better image) is definitely an excellent argument !
Best wishes,
Sylvain.
I work in a big company that has recently moved into being more enthusiastic about open source solutions. There have been a few big hurdles:
Customer won't support it - we're defense contractors. We do almost nothing without customer say-so. As the customer's opinions have changed we've been able to change our architectures and tool usage. That said, there are still scenarios were open source is unacceptable and we don't use it.
No tech support = scary - in several cases, it's been possible to make the point that open source may not have a single point of company tech support, but it does have huge communities that will support questios for free, and that there are consultants available as needed for the really hard stuff. Plus many, many releases of new versions for bug fixes. And, several competing expensive products have not been able to service tech support needs. Being able to point to specific internal examples with long. well documented, histories of support problems, has been key.
Fear of security issues - we had to develop a process for scrutinizing and controlling every peice of open source introduced. We've managed to find criteria for what we deem risky, versus what we deem relatively benign based on info-sec policy.
Fear of lawsuit - Being large, and profitable, we fear lawsuits, we're great targets. We now have a process for the legal team to scrutinize every open source license. This has proved to be a win - since the legal team now has briefings on every major version of the typical open source licenses, and they can quickly review most stuff.
Version control - fear that if those wacky developers can just download anything they like the world will self destruct. OK, well, practically speaking, the concept of "how do we know what's in a given product" - being able to show a FOSS version control process that is managed internally has been important.
It was definitely a slow process - small projects proved profitable and customers started encouraging it in proposals. That made it useful for executive management. It's helped that those that support it have been williing to put in some extra time to making the business case in terms of efficiency/cost savings, and have been willing to negotiate repeatedly with various parts of the corporate infrastructure.
Making open source work has taken the effort of IT, the info security folks, the legal team, the procurement team, and technical management. Knowing that before you talk to your manager is probably a key to success.
There's also some political savy - for a first project, don't encroach on any sacred cows - ie, those projects that may not be successful, but are high profile and owned by someone with lots of political power. Instead, choose some wacky new thing that isn't available right now and prove the cost savings in a way that is unlikely to provoke a defensive reaction.
When you try to introduce open source software to a big company (or even a small one, in many cases), the biggest counter-argument you're going to hear is "There's no tech support." Companies tend to be wary of using software that's supported by the community, because there's no guarantee (or in some cases, service agreement) that questions about the software will be answered within a reasonable time frame, or at all. In many cases, you can find a company that will provide support for the open-source package you want to use (for example, Red Hat does this for its Linux distribution, even though the contents of the distribution is mainly open source). Showing management a business entity that can support the software will often go a long way.
The other counter-argument to using open source software that I've heard the most often is "Open source software is buggy." This is a tough one; this opinion is pretty ingrained in some corporate cultures. Two possible responses are "The open-source community fixes bugs quickly" and "Since we have the source code, our engineers can fix bugs"--but that's often not what managers want to hear.
So, in essence, it depends on the company, their attitudes, and how much they trust you to make business-critical recommendations. I've used all of the arguments above with different levels of success in different companies.
Of course, in these economic times, the "free" part may go a long way. :-)
"Free software" doesn't necessarily mean your company is going to get software for free. Many successful open-source projects are also offered with licenses and services that cost real money and are geared to organizations that want or need to be assured of good support. MySQL is an example
The reason for a lot of big companies using closed software is that they can call support and the vendor will issue a hotfix, patch or cumulative update
Changing a large company's habits are often like turning an Oil tanker around... it takes a long time and uses a lot of energy.
If the company were in the process of evaluating the purchase of new software for a specific task, Then I would make sure to write a concise opinion memo about why my choice is better.
If the software is something I would use personally and not a server product that multiple developers are forced to use, then I would just ask my manager to use it.
If the software is in place, does the job (even if I don't like the way it does it), i'd learn as much as I can about it to give it as much chance of work for me, or at least make my life easier. If it still sucks really bad, I probably wouldn't try to change it until it was time for the company to pay for an upgrade.
If the software works but is just annoying... I'd do as above, learning all there is to know about it just to make my life easier and then deal with it.
You're probably right that the system you'd recommend is better than the one currently in place. But like some other posters said, choose your battles, especially when this is your first job out in the real world. You may become expendable quickly.
It's not really so much a matter of what's better, even if your way IS better, it's a matter of the culture and the way things are done and the cost of switching. Even if, hypothetically, their system can be magically transported to your OSS system, with no loss of data, dates, records, or anything, you're still going to have people who say "I liked the old way better."
Remember: Experience is what you get when you don't get what you want. I know it may sound glamorous to be "the new guy who recommended a great new versioning system that everybody loved", but you also could just as easily become "that hotshot who insisted on a new versioning system that everybody hated." It's a much smarter career move to just play by the rules at least for a little while until you have some clout and can make some recommendations. In the meantime you may even learn why the old system is preferred, or learn to like it more the more you use it.
I know what you mean. It took us years to convince our managers that everything would be okay if we moved away from using Interbase (a commercial Relational DB) to it's opensource counterpart Firebird. Mostly it was fear of no support that blocked the move. I think the factors which changed their mind were:
tests showing better performance
that there are companies that provide and charge for supporting the OS alternative
constant pushing of the argument by passionate developers
I think cost savings would have played a part if our company were paying for the site licenses but in fact our customers were.
I look at this question like this. I work with the .NET framework. I could ask my employer to migrate to PHP. This is a disadvantage to me, as well as my company, for many reasons. Let's start with the obvious.
1.) I know PHP, but can do much more, and a lot faster, with .NET.
2.) Paying for a service, usually ensures a better experience. The Visual Studio IDE is second to NONE when developing an application.
3.) I can develop an application much faster in VS than hard-coding PHP.
4.) This is the most important one. If I work with a big company, I want my programmers to develop my app faster, and I expect it to run faster. PHP (an example Open Source language) is fast, and reliable, but if I can spend the money, I'll deploy ASP.NET.
Basically, big business, or even small business, wants to spend their money, as long as it's for a good reason. Your best bet is to say, 'Hey, if you want to deploy ASP.NET (or whatever), send me for some training. Then I'll be able to develop OUR application to my best ability'.
not to sound totally cynical, but:
an experienced developer probably would not approach management about something like this, unless he/she was already an expert with the open source package. Companies like to have a phone number to call and someone to blame when things don't work. Free open source packages do not provide this kind of 'accountability' (yes we know it's a joke, but management doesn't)
it is unlikely that management is going to listen to someone fresh out of college about any major purchasing or technology decision. You have to learn the business and earn everyone's respect first. [sorry!]
Same problem everywhere. Once an organization gets beyond a certain size (e.g., the Dunbar number) it starts to show a certain woodenheaded quality that will confound you. Lots of history, people, agendas that you aren't aware of. And getting everyone to agree on your solution is difficult.
Best to start locally. See if you can persuade your manager or PM to use SVN or CVS or GIT locally for a project and then get it to diffuse.
But that situation is true where I work as well. I use SVN locally for myself, but a commercial product for integrating with others.
Companies will use whatever will ultimately make them the most money. That means whatever software will make their employees more productive. If there is a particular piece of open source software you think they should use then when the time comes to purchase the software to do job X then as long as you can prove it will make the employees more productive and they are able to get reliable support just a phone call away as with commercial software then they will use it.
Big companies need to hire support staff for stuff like that. When they purchase software from a company, they are guaranteed support with the contract. Open source projects can die off a lot easier, whereas a large software vendor can be held responsible for much greater periods of time.
Every company has a culture, and fighting the culture can be something of an uphill battle. But if you're willing to try:
you'll likely have more luck getting BSD and BSD-like projects approved (MIT license, Apache, Boost, etc.); and it doesn't matter if most of the arguments against GPL and LGPL are mainly FUD
you should refer to the projects as "royalty-free"
you should make sure things are approved by somebody that can approve them (your direct manager) because putting the company in a bind -- especially when you're new -- (even if the "bind" is only in their head) is not conducive to long-term employment
you can probably go a long way by simply asking what the procedure is to choose a library or tool
From a configuration management perspective, having developers add free software stuff willy nilly whenever they feel like is a serious PITA to manage.
I've worked at companies where you were allowed to do it whenever you wanted and others where you could never do it.
There's definitely a balance to be found but if you're in a larger company with multiple projects, you do have to keep in mind that each time you add a new 'tool' it complicates the build process.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm thinking about adding some kind of copy protection to one of my tools.
Do you have any experience with that?
Have you developed your own protection techniques or did you buy 3rd party software?
Do you think it is a viable method to increase sales? (In a private and/or corporate environment)
What do you do to prevent hassling your paying customers? In most cases it's the paying customers who suffer from a bad copy protection, and I don't want this to happen to my customers. (Even if that means accepting some freeloaders)
I'm especially interested in techniques which allow a trial or freeware version of your software for private use but limit the usefulness in a corporate environment.
Related Question: How do you protect your software from illegal distribution
Related Question: Protect .NET code from reverse engineering.
Related Question: Prevent the circumvention of copy protection.
Whatever technique you use, your software will be copied. The actual aim of copy protection is to prevent honest customers from being tempted to be unfair.
The minimum copy protection technique is enough. The maximum is not worth the time spent.
Moreover, I've heard that some developers provide user support to any user who asks, customer or not. The idea is that happy users may become faithful customers.
On desktop apps I've been using a Clarion Template (3rdParty, http://www.capesoft.com/accessories/secwinsp.htm).
With web apps, pretty much just been using the simple fact that the User has to log in, and tracking the activity. If they have an account, it means they've paid.
Desktop is a lot harder to track. As has been said, very easy to crack. Very much a case of:
Make it annoying for the Hackers, but as unobtrusive as possible for the Users
"The hardware is the dongle"
That was what we always said at my old job, and to some extent, it's also true at my present one. Basically, we sold physical hardware to run our software, which we gave away for free. This probably isn't feasible for all businesses, but it's a nice feeling to know you don't have to worry about piracy, because people are invested in the hardware, not the software.
As mouviciel mentioned, nothing is perfect. Aim to gently encourage users who might buy your product to buy it, and forget about the people who never will.
Some general tips:
Don't bother implementing your own protection, unless you have experience doing so. This is an area where paying someone who's specialty is providing some type of licensing/protection is probably worthwhile (just keep in mind it won't be perfect).
Choose a license key system that is difficult to keygen. Again, picking a pre-built licensing system will likely suffice. Creating your own from scratch will likely not.
Take the time to properly integrate whatever licensing system you choose. If you just "protect/wrap" your executable(s), the protection will quickly be removed. Most licensing/protection products offer easy integration tools/macros that make automated cracking much more difficult.
For corporate software, the best thing you can do is make it easy for administrators to ensure they are within the license boundaries (# of instances/installs, etc.). Provide a central place for them to verify this, and gently remind them if they go slightly over, before you take any more drastic actions. In a large network environment, software licensing can get very complex for the IT dept. Make their job easier and they'll thank you.
"The technical support is the dongle"
This doesn't apply to all applications, but for complex applications with higher price and lower sell volume, providing excellent support to your customers is the best way to be sure all your users are paying.
I know this post was submitted quite some time ago, but everyone always seems so negative when this subject is discussed. For obvious reasons I prefer not to say where I work but we use CodeMeter by Wibu-Systems US. We chose this as hackers didn't manage to hack this during a hacker competition.
Regarding all the questions you ask, it is really flexible and they offer a free SDK, which is how we tested before we purchased.
For some products we (have to) use hardware dongles. Although they give a prety good copy protection, they are a real hassle for our customers.
All other software is protected by a software key. And yes you can copy those. But we have very good experience that customers don't do that.
Without a key a program works normal, only you can't calculate the model and some print functions are disabled.
You do need to employ copy-protection for your software, but as others have said, make it as hassle-free as possible for your customers. Your aim should be to keep honest customers honest, and not make them go through hoops before they can finally use your software.
I would also advice against spending your time on coming up with your own licensing scheme, instead spend that time focusing on your actual product.
Consider using CryptoLicensing - it provides licensing, copy-protection, activations, machine-locking, trials, and other features.
DISCLAIMER: I work for LogicNP Software, the developer of CryptoLicensing.
Good software doesn't need a protection. Your software will ever be copied, no mather what protection you choose.
So the best way to avoid illegal copies would be to make your software user-friendly, so that your customers are happy and satisfied with your product.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I currently maintain 3 websites all revolving around the same concept. 2 of them are WinForms applications where the website gives a few basic details, and download links. The third is a web application to query data. I also have a forum (SMF/TinyPortal) that has been serving as a tech support/news hub for the three sites. The download traffic is decent, but I don't get a lot of hits on the support forums
I want to consolidate these three entities so that I don't have to duplicate announcements, upload data library updates to multiple locations, and also provide a unified look to the sites.
Fortunately my hosting account has both .NET and PHP support, so I've been looking into Drupal, Graffiti, DotNetNuke, Joomla, Community Server, and more. However, it has been hard for me to discern between what features included, supported, or just not part of the framework whatsoever.
Does anybody have a good evaluation of these projects (and others too) and can evaluate them for features/expandability/customization/etc.? I'm not necessarily looking for a "what's your favorite" but more of a feature set / target end user type evaluation.
If you want to quickly compare features on CMS's, then take a look at CMS Matrix - has practically every cms known to man on there.
Edit
To be a little more precise, from the site
CMSMatrix is the number one content management system comparison site on the Internet. It allows users to evaluate over 950 content management systems in 135+ different categories.
Go with N2 if you want to get up and running in no time with a couple of nice features packed. Also, it is really targetted against extensibility and clean code.
http://www.n2cms.com
"Open Source cms" has tons of them, and running demos with admin logins
DotNetNuke:
very flexible
lots of community around it
community tends to be fairly technical and can be hard to find useful end-user support
can be difficult to upgrade and to keep current versions available
fairly easy to program basic modules for
100s of available modules (free and pay)
documentation can be difficult to find and sparse in detail
easy to skin so your sites can have a unified look
1000s of pre made skins available.
hopefully this is along the lines of what you are looking for.
I've found that CMS Matrix (refer:iAn) can sometimes be a bit out of date but it is definitely a good starting place. Open Source CMS is a good resource (refer:mrinject). I'd lean towards something you can tinker with - closed source could back you into a corner.
If you're looking into .NET then MojoPortal is another option, as is umbracco etc. Search here on DNN and these others. I've found Drupal to be be more intimidating to approach. Also, it's forums are pretty basic. Joomla tends to want money for add-ins, as does DNN although there are freebies for both. Apparently the freebies fro Joomla can vary in quality - I never looked into it too closely.
I think the pick of the PHP crowd is Drupal - if you can invest the headspace for learning it. Drupal tends to be more developer-friendly than end-user friendly so if you're not a developer it is harder to grasp than something like Joomla. Apparently its codebase is better than Joomla.
Have a browse through the communities - you'll spend some time there so make sure they are to your liking.
If the site is quite simple then perhaps WordPress will suffice as it has a plethora of plugins and there are lots of template available for free or
I've been meandering down this path for a while now. My advice is to set up some test installs and roughly configure them to something that has what you want and then try using and and - important - try to break it. Installing them together on the same server is a good way to test the relative speed differences too.
Test drive them - it's the only way to tell which one works for you.
DotNetNuke out of the box contains a lot of features, content management, link management, documents list modules, forum modules, and items of that nature. There is also a very good third-party module and skin market out there for getting the enhancements needed to really get a full solution implemented.
With a little bit of time DNN can serve as a great foundation for a collection of websites. It also supports a multi-portal system that allows you to host more than one site off of the same code base which is very helpful.
The best part of all is that it is Free!
As you mentioned, there are plenty of options available, most of them have all the basic features. If you are looking for a simple setup, most may even be overkill for what you are trying to achieve. Which CMS you choose, may best depend on your preference for the programming language the CMS is using.
For some websites I maintain, I have used Typo3 (http://www.typo3.com/). The reason for my choice was the flexibility of Typo3, with its many (many!) plugins for all sorts of features, and for the ability to develop plugins yourself.
HTH,
J.
Assuming you're going open source, strong considerations are:
An active and knowledgeable community. <-- You don't want to be the only person able to support this CMS in 10 years time.
regular and simple updating techniques.
Your skill sets.
As a vendor, I find CMS matrix to be daunting. Its basically a list of every CMS under the sun, with a few generic ratings and reviews. Before selecting a CMS, I'd commit to a model first, then I'd investigate the various options that are available.
Open Source...has lots of user generated support, but often requires the assistance of outside developers for software maintenance and add-on installation.
Private installed solutions...can be easier to work with, but lock you in to one vendor for maintenance.
SaaS Model...still locks in to one vendor, but all updates are included and initial costs are minimal.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Does your work environment use Harvest SCM? I've used this now at two different locations and find it appalling. In one situation I wrote a conversion script so I could use CVS locally and then daily import changes to the Harvest system while I was sleeping. The corp was fanatic about using Harvest, despite 80% of the programmers crying for something different. It was needlessly complicated, slow and heavy. It is now a job requirement for me that Harvest is not in use where I work.
Has anyone else used Harvest before? What's your experience? As bad as mine? Did you employ other, different workarounds? Why is this product still purchased today?
I had the benefit of using Harvest at a bank and you'll never find a more wretched hive of scum and villainy, backwards triple-forking undocumented check-in gauntlets that require 15 steps to make one simple change. Nevermind that they weren't even using branching. This is an evil tool don't let it get you in its clutches.
Chances are, your company has some sort of contract with CA - are you using a lot of other CA software in-house?
Edit: Guess so!
OK I'm going to answer this in a couple of episodes because its late here and Harvest is a big topic.
Firstly CA Harvest (which is what version 7 of the product is called, version 5 is CCC which I cant recall the expansion, version 12 is called CA SCM) is a lot more than just a SCM tool - in the same way ClearCase is a lot more than an SCM tool. SVN, CVS, git, hg are all base-standard SCM and little more.
What you get with Harvest is SCM + Policy. It gives you a place to store and version your code and wrap it all in a policy of how that code matures though your organization from dev to prod. Do you have a policy in your organization that a Lead Developer needs to sign off on the code before its released to QA ? Harvest allows you define the signoff as a policy, and enforces it - you cant migrate the code from the "Dev" state to the "QA" state until one of the people in the project designated as a Lead Dev does exactly that. Do you have a policy that any SQL code needs signoff by a DBA before it progresses ? Harvest allows you to define that policy, and enforces it - so you might need both Lead Dev and DBA signoff before code migrates.
Harvest is by no means a tool for most software organizations - it is typically used in the finance industry, or in business' where a very strong regulatory framework governs what they can do. Banks need to comply with Sarbannes-Oxley, which has very strong auditing requirements. Harvest provides the ability to define all kinds of controls and process around how changes to the Banks assets move through their lifecycle. I know large public transport organizations that are responsible for the safety and punctuality of millions of people every day, that need the tightly defined control mechanisms that a tool like Harvest provides. I also have seen Harvest used in environments where 1000's of developers use it everyday - yes, I'm not exaggerating, literally 1000's of devs in one organization, writing code for a worldwide retailer, pushing IT solutions out their door everyday to the stores around the world.
Harvest is not perfect, thought version 12 is much better. It has too many "that's just stupid"-moments, it does per-file versioning ala CVS, and CVS-like branching and directory versioning (or lack thereof), with all the fun we've come to know and fear. Once you know it and accept it though, its isn't inherently slower than any other SCM I've used. It just has a bigger job to do than just version your code.
Another big win, and its even bigger with version 12, is its integration with other CA tool (and ability to integrate with non-CA tools, but not many at the moment) - defect tracking with Quality Centre, trouble ticketing with Unicentre Service Desk, software deployment to the desktop with SDM. You can define bridges between these apps that result in a lot tighter integration of these concerns, with the usually positive effects on accuracy and timeliness.
If your dealing with getting software out to a worldwide enterprise, with thousands of desktops and servers, mainfame/midrange/middleware systems, iron-clad change control processes, complexity, regulations, contracts, auditors, just a whole bunch of complexity, Harvest is just one tool in a whole suite of tools your going to need. If you just want a simple SCM for a team of 10 devs supporting a few hundred customers, its not a great way to go.
I'll try to add something about how Harvest actually works next time - repositories, projects, views, packages, forms, processes etc. That might help explain why some organizations use it, and why its not for everyone.
I used Harvest during a short gig in the banking industry a few years ago. I agree that it was practically unusable, but the people in charge of QA seemed to love it.
I worked for a company that had two choices; ClearCase or Harvest. Subversion hadn't ever been considered, and the reason was that ClearCase (IBM) and Harvest (CA) both had longstanding mainframe contracts already.
We've used Harvest for about ten years (2000-2010) and even though we are now looking at replacing it I believe it has served us very well.
Harvest (let's stick with that name even though it's no longer it's official name), was the first major tool we implemented to support us in R&D and at the time none uf us knew much about the many aspects of application lifecycle (versioning of code, branching, automated testing, regression testing, quality assurance, deployment to numerous runtime environments and production, rollback, ememrgency fixes, maintenance updates etc.); today we know a lot more and our development processes serve us very well (not that there is not room for many improvements).
We do not have a very hierarchical organisation (we don't have a lot of inspectors that need to approve changes) but it's very helpful to have support for "checkpoints" - points in the development process where something need to happen (e.g. functional testing or integration testing).
The drawback (for us) with Harvest in regards to usability has been "what a programmer need to do to change x lines of code". Today (out there) there are a lot of easier and more efficient ways than Harvest to get write access to source code files, make your updates and then return the files again / move them to another aspect of the development process (testing,deployment etc.). Another drawback is the price tag; it's expensive.
Gain we've had with Harvest:
It support workflow and therefore we've been able to have a single system to manage code versioning, workflow and process automation. If possible it's easier to maintain and improve a single system than many.
In addition to providing cmd line access to internal processes (making it possible to script special solutions when so required by your processes) Harvest also is easily configured by graphic interface.
It has the concept of "Package" which makes it easy to attach plenty of meta data to code changes and to handle the changes independently of other changes (versioning on file level rather than change sets containing the complete code mass). This is helpful to handle indpendent emergency and maintenance changes.
If a developer is only a programmer and only think on the coding aspect of software development then I imagen he/she would might get very frustrated with Harvest.
If a developer is a developer and understand that software development is a lot more than coding and that the coding is only the very begining of a the lifecycle of software then I belive he would see a lot of benefits with Harvest.
I have been using HARVEST for the last 4 years and i love it. The kind of support it gives you to control the code movement is really fantastic. We use HARVEST to deploy applications on to Websphere. It also do an amazing work in deploying the plugins into the web server along with the application. When you want to have a process in place for moving the code in a big enterprise environment, i don't think any other tool can even come closer to HARVEST.