A similar question has been asked: MSDN subscriptions on the cheap?, but I am not interested in the solutions provided:
I am not developing a product for sale, I am starting up a consulting company, so Empower is not an option.
I have visited the links to MS regarding MSDN subscriptions and they do not point to a way to get an inexpensive copy.
I am not interested in suggestions that I become a MVP. Frankly, I'm desiring to focus on developing my company, not jumping through MS's hoops.
There are really only a few options available
Buy it at standard price
Become a Microsoft Certified Partner, and get a good discount (Actually much simpler than you would think, I did it in under 2 weeks for my business)
Find a MVP buddy that is willing to share a free giveaway
But in all reality, these are the ONLY legal options. You might also try calling Microsoft, you never know what might happen, they have many special programs that are not necessarily publicly advertised.
What you want is the Action Pack: https://partner.microsoft.com/US/40016455.
(Note, as an employee of Microsoft, I apologize that you have to LOG OUT of your LiveID to see this page if that LiveID is not already attached to a Registered Partner.)
You don't have to be certified to get access to this, just registered (there are three levels of partnership: 1. Registered, 2. Certified, 3. Gold Certified). You do have to pass a fairly simple assessment test, though.
See the pdf referenced at https://partner.microsoft.com/US/40082823 for an overview of the process.
One last thing - if you are a student (I suspect the OP is not), you can get many Microsoft tools free from http://www.dreamspark.com.
Surely your consultancy will need a website in ASP.NET and perhaps your clients would like a widget that talks directly to a web service on your site? There's your product.
Also, look into "Value added Services" amongst the Empower documentation.
I'm on the Empower program - there really aren't any barriers to entry, as such.
I used to go directly through MS, but nowadays, I always order mine through Xtras.net - they have good multi-year discounts and you manage the subscription online through Microsoft's site as normal.
Does Empower require that the 'main' use is developing a product?
You can always develop a product as well - doesn't have to be very sucessfull, perhaps something to display the time in a window?
Related
The team I'm part of manage a number of software projects - and most of the stuff we do is end to end, from requirements tracking, to project management to purchasing and setup - a big pain is tracking of financials as we have a whole process to go through for our financials. At the moment we use a spreadsheet and store all the invoices and purchase orders in a shared folder. Its difficult to capture expenses and relate them back to projects that are ongoing or completed. Anyone got better ideas? Hope this topic is relevant.
I'm just throwing this out there but Scrum seems like a methodology that might lend itself to tracking this kind of stuff easily.
I use the time tracking aspects of JIRA with a bunch of custom fields that let me note issues as having been billed for (complete with storing the invoice number details against the JIRA issue). It's easy to relate hours worked to time billed. Might not work if you're billing for functionality rather than hours, but for $/hr work it's perfect.
You're talking about bookkeeping. Your best bet is probably to talk to accountant who organised books for a software company before. Alternatively you could read up on bookkeeping basics.
This question is not strictly software development related, although software business has some traits that make it different, i.e. absence of raw materials.
Best of luck with your question, I personally find it interesting, but I don't believe it belongs on stackoverflow.
you could try http://projectsputnik.com This software combines project management and billing
If you are using Jira, you can try Clerk — Invoicing and Billing for Jira app. Jira has projects and time tracking feature and this add-on does the invoicing and billing on top of that. I hope that helps.
How about using a wiki, something like Confluence? And then you can export to a spreadsheet. and import back again...
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I have begun work on a personal project that may end up having some real-world applicability. I am beginning to entertain the idea of selling licenses. I am sure some others here have done this before, and I was wondering what successfully processes you've used to do so.
There are many questions on SO regarding licensing, legal implications, etc. However, I have looked around and could not find a duplicate question for this one. To be clear, I am not looking for information on what licensing strategy to use, how to advertise your software, and so forth, but rather, for a checklist of things that should be done to increase the probability of success, and any possible gotchas I have not thought of. If anyone has any personal success stories, they would be very welcome.
For a little background, I am set on the idea of licensing a closed-source, compiled .NET DLL.
A few things off the top of my head:
Strong documentation, because formal technical support is unlikely
Specifying licensing terms and formalizing them with an attorney
Code obfuscation
Exploring license enforcement (either using a commercial package or custom code)
Building a website around the product, including real-world code examples since this is a library
Possibly offering some type of beta period, for feedback and getting the name out a bit
Offering instant/automated purchases
Marketing (oh boy)
Is it necessary (or wise) to start a one-man company to do this?
I will keep this list updated as answers come in. Thanks all!
Some tips:
Obfuscation: Be wary of obfuscating everything. An alternative is to obfuscate just the critical bits (licensing, premium features). The problem with obfuscating everything is that stack traces from error reports are ineffective. When an unexpected exception is caught, you'll want to give the user the option of automatically reporting its details - this really helps with QC.
License enforcement: If it's a utility that can be easily pirated, people WILL pirate it. An activations-based licensing system is ideal - and if it's not too draconian people will be less motivated to circumvent it. For instance, allow at least 3 activations per user (home computer, work computer, laptop). If it's a control library, then an activation-based may not be required - baking the serial number into the library may be enough because customers are unlikely to build their own product on a stolen assembly.
Instant/automated purchases: writing a custom licensing server and web page for this is fairly easy - you need only about 3 tables. LINQ to SQL is ideal for this sort of thing. For the payment gateway, I use PayPal - it's very easy to set up, has the features you need for selling activation codes, and allows multiple currencies. If you use PayPal, enable both PDT and IPN so you can give customers their activation codes both on the screen and via e-mail.
Marketing: try LOTS of things simultaneously - because it's hard to predict the success of any campaign. Especially without experience! Making yourself known amongst the influential people in the field into which you're selling can work very well.
Advertising: advertise on StackOverflow - that's what I'm doing! Google ad words is also worth trying because it's so cheap to set up - you'll know after spending $10 whether it will be effective for you or not.
And good luck with it!
You have most of the practical things listed out, in terms of actually getting a product from you to the customer -
However, there are a couple of things I'd also recommend.
Figure out how you want to handle all of your accounting/purchasing/billing/etc.
Rethink formal technical support (for money), but not at the exclusion of documentation
Talk to a lawyer regarding all of your licensing decisions, agreements, etc., as well as company structure
Talk to your accountant (and/or find one who is good at working with small tech companies)
Some of this will cost some money up front, but save headaches later.
The last two bullets are crutial - there are MANY options for how to setup yourself from a tax perspective, each of which has potential advantages and disadvantages depending on your specific situation.
For example, if you're in the US, there are many advantages to incorporation prior to doing anything on your checklist. If you decide to incorporate, you may want to do it in your state, but there are also advantages to incorporating in Nevada or New Jersey (very pro-corporate states legally). If you're successful, doing this early can save a huge amount of work over time and have significant benefits.
Also, if you incorportate, you might want to consider S vs C corps (S Corps are great if you're a one or two man operation). If you don't incorporate, you can run as a sole proprietorship or an LLC, both of which have advnatages and disadvantages. A lot of this depends on your product (what it does), your expected returns, etc. - having a good lawyer and a good accountant is a huge blessing.
If you're aiming at software development teams as customers then the sort of thing they are likely to expect to see (in addition to the ones you listed) are:
A download service for any additional items and/or patches that the user might need.
Tight version control/configuration management processes so that it's easy to find out what version of the product they have, what they need and what the differences are between versions.
Email/online bug reporting.
A demo/trial version of the product.
A good set of tutorials.
Community support e.g. developer forums. This is a good 'value added' service that can also help with the fact that you have concerns (as a one man company) over being able to provide 'formal technical support'. Hand out a few badges and reputation scores and get a free technical support team ;) ... but if sales take off, seriously consider providing 'formal technical support', it can make a huge difference to the perception of the product.
... and make sure that the website, download service, license server, forums etc are all properly secured and done to a professional standard. If any of the peripheral services are less than 100% then it all reflects badly on the product, especially when yours is a technical one.
You might not want to provide formal technical support, but you could look for creative alternatives like some sort of moderated forum for issue resolution. Also, provide at least an email address for someone to contact you.
Another thing is to hire some sort of designer to make your product, documentation, website, etc look good. It is generally easy to tell programmers who attempt design.
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..
I have a Mailman managed list with years of history that I want to migrate into a web-based forum. Things it would be nice to do:
Keep the mailing list going for those who are used to and prefer it to a web interface, but have it integrate with the web-forum activity.
Take the web-based forum posts, and send them out to the mailing list.
I have run sites based on phpBB, Drupal, Simple Machines, etc., and am able to do a little bit of coding if that was what was required to integrate some package into Mailman, or replace it entirely. But I'm unaware of what is available, commercial, or open-source, that could accomplish this. I am also open to replacing Mailman, if the candidate package can perform its functions reasonably well and integrate well into its own forum.
Even if the phpBB/mail2forum option is using the older version, it is a nice option. OpenSceneGraph just implemented this for their long running mailing list, and it seems to work flawlessly. It's the only option I've seen that allows for forum posts and mailing list messages to work very seamlessly, and has the means to allow for tags to separate forum subjects from mailing list posts, etc.
Their v2 dev works with phpBB3, too - so if you're willing to live on the bleeding edge, that might be an option.
So far, here's what I've looked into:
Drupal, with its Mailmanager and Listmanager modules, though I've been having trouble turning on the IMAP feature so it can talk to my mail box (clients can access it fine), and the Drupal's forum module isn't really up to the feature level I'd like.
PhpBB, mail2forum, though it looks like currently it only works with the older phpBB version, so not really an alternative for me.
The only one that seems to really "work" is FUDforum and its maillist.php module, which integrates directly at the procmail level, nice. I can take all my Mailman archives and "formmail -ds" them directly into a chosen forum.
I've started a bounty for this issue, I'm looking for something, even commercial, that really integrates the email interface into the forum experience for the end users, particularly the handling of accounts. With FUDforum I'm still going to have to resolve the separation of the Mailman accounts from the FUDforum accounts.
I ran across this on the web: http://mail2forum.com/
I haven't used it but it looks promising and has both a 1.2 stable version and a 2.0 development version, so it's not a derelict SourceForge project with 1 developer and no commits, or anything :)
Theoretically my org may use it at some point in the next year or two, but we have to finish our own Listserv to Mailman transition first.
Well, based on what you've said (first, that you're able to do a bit of coding and second that FUDForum would work for you except for the issue of maintaining list membership, have you considered that:
Mailman stores its user information in a plain text file and
FUDForums stores its user information in a single sql table
The obvious solution would be to declare one of these master (probably FUDForum, since it looks as if it holds a proper superset of the Mailman info) and have a little script/cron job that copied changes from the master to the slave.
A passing note -- neither of these systems appears very secure (actually, they both look leaky as all get out) and combining them may well reduce the collective security even further. If you are doing anything even remotely confidential you should rethink your goals, and in any case you should take appropriate steps to protect your system from attack.
I know an SME which switched from the mailing list to phpBB!
If you want to keep your mailing list, you have also to maintrain it.
Finally the people I know diabled the mailing list service.
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).