Related
Should developers be limited to certain applications for development use?
For most, the answer would be as long as the development team agrees it shouldn't matter.
For a company that is audited for security certifications, is there a method that balances the risk of the company and the flexibility, performance of the developers?
Scope
coding/development software
build system software
3rd party software included with distribution (libraries, utilities)
(Additional) Remaining software on workstation
Possible solutions
Create white-list of approved software where developer must ask for approval for desired software before he/she can use it. Approval would be based on business purpose/security risk.
Create black-list for software. Developers list all software used. Review board periodically goes over list.
Has anyone had to work at a company that restricted developer tools beyond the team setting? How did they handle the situation?
Edit
Cleaned up question. Attempted to make less argumentative.
Limiting the software that developers can use on their work machines is a fantastic idea. This way, all the developers will quit, and then the company won't have to spend as much money on salaries and equipment, resulting in higher profits.
Real answer: NO!!!
No, developers should not be limited in the software they use, because it prevents them from successfully doing their jobs. Think about how much you are paying your team of developers, - do you really want all that money to go spiraling down the drain because you've artificially prevented them from solving problems?
1) Company locks down the pc and treats the developer as competent as a secretary
What happens when the developer needs to do something with administrative permissions? EG: Register a COM object, restart IIS, or install the product they're building? You've just shut them down.
2) Create a white-list of approved software...
This is also impractical due to the sheer amount of software. As a .NET developer I regularly (at least once per week) use upwards of 50 distinct applications, and am constantly evaluating newer upgrades/alternatives for many of these applications. If everything must go through a whitelist, your "approval" staff are going to be utterly swamped by just one or 2 developers, let alone a team of them.
If you take either of these actions, you'll achieve the following:
You'll burn giant piles of time and money as the developers sit on their thumbs waiting for your approval team, or doing things the long slow tedious way because they weren't allowed to install a helpful tool
You'll make yourself the enemy of the development department (not good if you want your devs to actually do what you ask them to do)
You'll depress team morale substantially. Nobody enjoys feeling like they're locked in a cage, and every time they think "This would be finished 5 hours ago if only I could install grep", they'll be unhappy.
A more acceptable answer is to create a blacklist for "problem" software (and websites) such as Pidgin, MSN messenger, etc if you have problems with developers slacking off. Some developers will also rail against this, but many will be OK with it, provided you are sensible in what you blacklist and don't go overboard.
I think developers should have total control on applications that they use as long as they can do their job with them. Developers' productivity is directly related to working environment and no one will like being restricted and everyone likes to use software they like themselves.
Of course there should be some standards in terms of version control, document format, etc., but generally developers should have right to use any programs they want.
And security should be developer's concern - company admins should care about setting up proper firewall to protect against any kinds of attacks.
A better solution would to create a secure independent environment for the developers. An environment that if compromised won't put the rest of the company at risk.
The very nature of the development is to create crafty ingenuous pithy solutions. To achieve this, failures must happen.
Whatever they do, don't take away the Internet in general. Google = Coding Help 101 :)
Or maybe just leave www.stackoverflow.com allowed haha.
I'd say this depends on quite a list of factors.
One is team size. If you have a team of half a dozen developers, this can be negotiated whenever a need for some application pops up. If you have a team of 100 developers, some policy is probably in order.
Another factor is what those developers do. If they compile C code using a proprietary compiler for an embedded platform, things are very different from a team producing distributed web or PC software in a constantly shifting environment.
The software you produce and the target customers are important, too. If you're porting the Linux kernel to some new platform, whether code leaks probably doesn't matter all that bad. OTOH, there are a lot of cases where this is very different.
There are more factors, but in the end it all boils down to two conflicting goals:
You want to give your developers as much freedom as possible, because that stimulates their creativity.
You want to restrict them as much as possible, as this reduces risks. (I'm talking of security risks as well as the risk to ship non-functioning software etc.)
You'll have to find a middle ground that doesn't hurt creativity while allowing enough guarantees to not to hurt the company.
Of course! If you want a repeatable build process, you don't want it contaminated by whatever random bit of junk a programmer happens to use as a tool to generate part of the code. Since whatever application you are building lasts much longer than anyone expects, you also want to ensure that the tools you use to build it are available for roughly the same duration; random tools from the internet don't provide any such gaurantee.
Your team should say "The following tools are allowed for build steps and nothing else" and attempt to make that list short.
Obviously, it shouldn't matter what a programmer looks at to decide what to do, so the entire Internet is just fine as long as its just-look. Nor does it matter if he produces code by magic (or random tool) as long as your team doesn't mind accepting just that tool's output as though it were written by hand.
Do you think Microsoft's RAP program worth the money you pay ?
Any suggestions ?
Thanks
I would have to say that it depends on a number of factors. First how knowledgeable are you at configuring and maintaining the specific versions of SQL Server that they would be looking at? Then why are you doing the SQL RAP? Is it to really get a good risk assessment, to demonstrate to management that things are being done correctly, or to learn where you are coming up short in an effort to correct things and find areas to learn more about the product, or is it none of the above?
I had a SQL RAP done at the end of last year, and I can tell you from personal experience, you will only get as much from it as you are open to learning. If you have a cluster, be prepared to have your eyes opened to areas you never thought to look at. The SQL RAP visit has four different phases, or at least mine did. First they collect the data from your SQL Servers using pssdiag and a bunch of other neat tools that they leave copies of most with you. Then they go into analysis, where they take the data and perform a very thorough analysis of it and generate reports and recommendations. Then they sit down with you and management if you so chose and go over everything, what was good, what was iffy, and what was bad. Then the last part they sit down with you as a DBA and teach you how to use the tools they used and that they can leave copies of with you. They go over the PAL Tool, SQL Nexus, and some others and make sure that you know how to use these tools to do self analysis. Best of all, they leave you these really detailed reports that you can use as a self check for setting up new environments in the future.
Is it worth it? You probably can't tell that until you are done with it. For me, I'd recommend it to anyone who wants to know more about running a "Best Practice" implementation of SQL Server, and who'd like some one on one learning time with a Senior Microsoft Field Engineer.
Oh boy, is that all they does with this much hyped RAP.
Pssdiag is already done.
We did the PAL and Nexus and they too did it before.
They took around 20 Gigs of size trace files to analyse.
Now, wanted to do RAP. Holy cRAP, if this is the same thing to do again, what that's for.
I expect much more than this level of analysis without which I think this is useless and waste of money.
I've been a part of 2 RAPs for SharePoint (finished my second 2 weeks ago). I am unsure as to how much it costs (the company I work for gets 3 RAPs a year with MS) but it is most definitely worth it.
Starting 2010, the PFE will leave the RAP tool installed on the data collection machine. This means that for up to a year, you can rerun the full RAP as many times as you want and analyze the results.
The RAP tool (for SharePoint) runs a bunch of tests that are categorized as below:
SQL Configuration (24)
Server Health (4)
Server Configuration (7)
MOSS Configuration (2)
Each test produces a list of issues with detailed recommendations on how to resolve them.
Additionally, a competent PFE (and they are) will help troubleshoot any outstanding issues you have in your environment and give you the opportunity to listen and learn.
I would recommend the MS RAP to all SharePoint (and SQL) Admins.
If you have never had one, then I think you will have benefit from going through it at least one time. I warn you that it can be quite humbling.
There are a couple of questions on Stackoverflow asking whether x (Ruby / Drupal) technology is 'enterprise ready'.
I would like to ask how is 'enterprise ready' defined.
Has anyone created their own checklist?
Does anyone have a benchmark that they test against?
"Enterprise Ready" for the most part means can we run it reliably and effectively within a large organisation.
There are several factors involved:
Is it reliable?
Can our current staff support it, or do we need specialists?
Can it fit in with our established security model?
Can deployments be done with our automated tools?
How easy is it to administer? Can the business users do it or do we need a specialist?
If it uses a database, is it our standard DB, or do we need to train up more specialists?
Depending on how important the system is to the business the following question might also apply:
Can it be made highly available?
Can it be load balanced?
Is it secure enough?
Open Source projects often do not pay enough attention to the difficulties of deploying and running software within a large organisation. e.g. Most OS projects default to MySql as the database, which is a good and sensible choice for most small projects, however, if your Enterprise has an ORACLE site license and a team of highly skilled ORACLE DBAs in place the MySql option looks distinctly unattractive.
To be short:
"Enterprise ready" means: If it crashes, the enterprises using it will possibly sue you.
Most of the time the "test", if it may really be called as such, is that some enterprise (=large business), has deployed a successful and stable product using it. So its more like saying its proven its worth on the battlefield, or something like that. In other words the framework has been used successfully, or not in the real world, you can't just follow some checklist and load tests and say its enterprise ready.
Like Robert Gould says in his answer, it's "Enterprise-ready" when it's been proven by some other huge project. I'd put it this way: if somebody out there has made millions of dollars with it and gotten written up by venture capitalist magazines as the year's (some year, not necessarily this one) hottest new thing, then it's Enterprise-ready. :)
Another way to look at the question is that a tech is Enterprise-ready when a non-tech boss or business owner won't worry about whether or not they've chosen a good platform to run their business on. In this sense Enterprise-ready is a measure of brand recognition rather than technological maturity.
Having built a couple "Enterprise" applications...
Enterprise outside of development means, that if it breaks, someone can fix it. I've worked with employers/contractors that stick with quite possibly the worst managing hosting providers, data vendors, or such because they will fix problems when they crop up, even if they crop up a lot it, and have someone to call when they break.
So to restate it another way, Enterprise software is Enterprisey because it has support options available. A simple example: jQuery isn't enterprisey while ExtJS is, because ExtJS has a corporate support structure to it. (Yes I know these two frameworks is like comparing a toolset to a factory manufactured home kit ).
As my day job is all about enterprise architecture, I believe that the word enterprise isn't nowadays about size nor scale but refers more to how a software product is sold.
For example, Ruby on Rails isn't enterprise because there is no vendor that will come into your shop and do Powerpoint presentations repeatedly for the developer community. Ruby on Rails doesn't have a sales executive that takes me out to the golf course or my favorite restaurant for lunch. Ruby on Rails also isn't deeply covered by industry analyst firms such as Gartner.
Ruby on Rails will never be considered "enterprise" until these things occur...
From my experience, "Enterprise ready" label is an indicator of the fear of managers to adopt an open-source technology, possibly balanced with a desire not to stay follower in that technology.
This may objectively argued with considerations such as support from a third party company or integration in existing development tools.
I suppose an application could be considered "enterprise ready" when it is stable enough that a large company would use it. It would also imply some level of support, so when it does inevitable break.
Wether or not something is "enterprise ready" is entirely subjective, and undefined, and rather "buzz word'y".. Basically, you can't have a test_isEnterpriseReady() - just make your application as reliable and efficient as it can be..
It seems to me that if you are writing in an interpreted language that it must be difficult to sell software, because anyone who buys it can edit it/change it/resell it without much difficulty.
How do you get around this? I have a couple of PHP apps that I'm reluctant to sell to people as it seems that it's too simple for them to change/read/edit/sell what I've produced.
Hardly anyone sells code. We sell the ability to create, edit, support and understand the code.
As a potential buyer of your application, I might find these features attractive:
The ability to change the code to suit my needs
The ability to read the code to better understand what it's doing
... and yes ...
The ability to sell my modifications
All three of those are features.
The third one might be a feature you can't afford to give me. Fix that through legal measures, not technical measures. That's what licensing is for. You could also sell more expensive licenses which do allow resale.
There are things you could do to remove the first two features, but bear in mind that in doing so you are reducing the overall value of your product to some people, and therefore its sale price.
For many people the primary reason for using Open Source software is not that it costs nothing -- it's that you get the source code.
People sell the service of creating web sites all the time. Also, even a compiled language can be altered, it`s just more difficult.
Most of the time the user base does not understand how to make the changes or what to do with the scripts so you are really selling your knowledge of how to install and change the scripts.
Don't sell the software, sell "licences".
I'll try to explain better, build the web app but provide hosting for it. this way your client will never get to "hold" the source code.
If you really must deliver the source code, Obfuscating is the way to go ;)
Possible routes to go:
Translate to a bytecode, binary or an obfuscated format
For instance, Splunk is written mostly in Python, and distribute bytecode. The EVE online client uses Stackless Python to compile to an executable binary.
Host the solution yourself
Put up a website, charge for use.
License the software
They get the source, but cannot legally modify or redistribute the source.
Open source the solution
Anyone can change the code, but you are the de-facto authority on it, and you can earn money by selling support, consultancy and customization services.
You could also consider a combination of approaches. E.g., partition your solution into several stand alone packages, and then open source some of them, and sell bytecode versions of other parts. What you then sell is the complete solution, as well as other services, and some people may benefit and enhance other parts of the solution.
Plenty of companies make money off of applications in interpreted languages and happily distribute the source code with them. Don't take this personally, but your program probably isn't going to be popular enough to have a large following of pirates. And anybody who would pirate your software probably isn't going to buy it in the first place. If they can't pirate it, they'll pirate somebody elses.
Whatever you do, please don't obfuscate your code. It's not an effective means of preventing infringement and it won't do anything other than make life miserable for you and your customers.
Protecting your secret bits is getting more and more difficult.
IMHO, your solution really depends on your target market. If you are targeting business, just give them the code with a good license, and possibly some type of defect so you can determine who gave your code away if that ever happens. Businesses will mostly pay for your app just to stay compliant; it's not worth the legal hassles. And if an individual gets your app for free, that's probably a good thing, since they will try to convince their current and future employers to buy it.
If you are targeting individuals, and can do it as a web app (which you obviously are with PHP), do it as a hosted service, and either sell a monthly subscription or allow free access and find another way to monetize it.
If you definitely need to or want to distribute it to individuals for whatever reason, you can give it away for free, and try to monetize customizations, add-ins, & other support features.
This is a problem that's been discussed a lot, and a few hours’ worth of really focused googling should reveal all the current philosophies on this.
I hope this helps.
Obfuscation may be a good way to go
With PHP you have the option of using the Zend Guard for PHP. I believe it compiles the source code in a way similar to what the php interpreter does,
so it should also increase performance. Of course the price of $ 600 may be too much for your liking ;-)
Anyway, I see no reason why you shouldn't distribute your code with an open source license (see the Open Source Initiative for a list of licenses available). You can find one that prohibits your customer from redistributing your app.
EDIT:
As Novelocrat points out in his comment, a license that prohibits distribution is per definitionem not an Open Source license, the term Open Source refers to a lot more than just the availability of the source code. (See also the answers to this related question for further discussion).
Assume your .NET-based development team is already using the following set of tools in its processes:
Subversion / TortoiseSVN / VisualSVN (source control)
NUnit (unit testing)
An open source Wiki
A proprietary bug-tracking system that is paid for
You are happy with Subversion and NUnit, but dislike the Wiki and bug-tracking system. You also would like to add some lightweight project-management software (like Fogbugz/Trac) - it does not have to be free, but obviously cheaper is better.
Can you make a compelling argument for adopting VSTS, either to add missing features and replace disliked software or to handle everything (including the source control)? Is the integration of all these features greater than the sum of the parts, or would it simply be better to acquire and replace the parts that you either do not like or do not have?
I remember looking into VSTS a few years ago and thought it was terribly expensive and not really better than many of the free options, but I assume Microsoft has continued to work on it?
VSTS is great, if you do everything in it. Unfortunately the price has not become better over the years. :( The CAL's are still ludicrously expensive. The only improvement is that if a person uses only the work item system, and works only with his/her own work items (no peeking at other person's work items!) then there is no need for a CAL. This makes it a bit easier to use it as an external bugreport system. Still it leaves a lot to be desired in this area.
There is one way to alleviate the cost - become Microsoft Certified Partner. If you are a simple partner, you get 5 VS/TFS licenses for free; if you are a Gold Certifiend Partner, you get 25 (if memory fails me not). That should be enough for most companies. But getting the Gold status might be tricky, depending on what you do.
If you only dislike those two parts, then perhaps it's better just to find a replacement for them instead for everything? There are many wiki systems out there, some should be to your liking. The same goes for bugtracking too.
We are extremely happy with not only the tools, but the integration that Team Foundation Server, and the various Team Editions have given us. We previously used Borland's StarTeam for source control and issue tracking with a 3rd party wiki, the name of which escapes me at the moment.
It came time for us to extend our licensing and support agreement with Borland, only to learn that the cost of adding users to our license and upgrading the product would cost us as much (a little more, actually) than biting the bullet and making the switch. One thing to consider is that you would normally pay for the development tools to begin with, so the cost is partially absorbed by our budget.
We also did not feel the need for getting Team Suite for every person. You might want to consider it for the developers, but other disciplines don't really have a benefit in using all of the tools in most companies.
We were able to get the appropriate team editions for twelve people, enough CALs for 50 users (for Team Explorer, Teamprise, Team Project Portals, Team Web Access), Teamprise for the five Mac Users that we have, and the Team Foundation Server software itself for under six figures. Considering that includes the developer tools that we normally would be buying, it was a good deal.
The upfront cost on new licensing also covered two years, so we could split the budget between the 2008 and 2009 fiscal years. The very important thing is to make sure not to let the licenses lapse, as the renewals on licenses cost a fraction of the initial cost and also include version upgrades.
As to the features, we are in the process of rolling out. About half of our department completed training, and I have already started migrating projects over. The development team absolutely loves the features and tight integration with their workflow. Version control is a snap, and work items (and their related reporting artifacts) are extensible to the nth degree. The fact that TFS relies heavily on bringing sanity to workflow management helps to tie in all of the processes to a level that you just can not get with multiple vendors.
My absolute favorite thing, though, is the extensibility model. Using the Team Foundation Server API, you can easily write check-in policies, write tools to interface with the system, develop plug-ins, and more. We are already seeing gains in productivity and the quality of our products through a minimal implementation.
Still on the horizon, though, is integrating Team Build. I have yet to set up a build project, but it seems to be seamless and painless. Time will tell... :-)
Edit - I forgot to mention that our migration to TFS includes licensing for the Test Load Agent. The load testing functionality within Team Test is one of, if not the absolute best that I have seen.
Where I'm at, we've settled on the following:
SVN for source control
Redmine for bug-tracking and wiki
NUnit for unit testing
CruiseControl.NET for our build server
Redmine is an open source Ruby on Rails application that supports multiple projects much better than Trac and seems to be much easier to administer. It's definitely worth checking out.
VSTS seems to be way too much money compared to other products. As an additional benefit, you also get the souce with open source solutions, which allows you to modify things to fit your need if the capability isn't there yet.
I'd stick with SVN and use trac or bugzilla or fogbugz. You could also do a trial of team server. In my opinion it is not worth the money. MS had their chance with version control and they screwed it up a long time ago. Too late to the party if you ask me and frankly I am not impressed with how they try to control all your development experience in the IDE with "integration" to the source control. I prefer the perforce/SVN and separate defect tracking solution.
With all that said, you probably can't go wrong with any of the following:
bugzilla or trac or fogbugz AND SVN
MS team thingamabob