Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I learned about Microsoft BizSpark the other day and started the sign up process. Has anyone else heard about it or had success with it?
I can't speak for BizSpark specifically (it's so new), but Microsoft has had the similar Empower program in place for 5 or so years. When our company was originally getting started, we joined the program (and participated for two years) and it was an excellent program.
The main benefit, of course, is that you get access to MSDN Subscriptions at such a low cost. Aside from that, though, it put us in touch with the local Microsoft office and gave us a clear path to working toward the typical ISV Partner relationship. You also get some technical support incidents, which are handy when/if you need to escalate an issue you're running into.
The requirements for Empower were/are pretty straightforward... basically commit to releasing a commercial software product based on the current Microsoft stack within two years.
Hope that helps... I look forward to hearing more about how BizSpark is different - or if it's simply the next evolution of Empower.
Well I have just signed up... yes of course there is an "end game" amount to pay.. but if you were going to use Microsoft technologies anyway.. then it's an awesome deal.. I have the software now (today), and there is everything I need to develop the project I am working on... Open source is excellent, don't get me wrong.. but you have to decide for the right reasons...
I think it is a great initiative, they are giving away the highest (most expensive) licenses of Visual Studio and VS Team System. With Empower you get Visual Studio Professional Edition with MSDN.
It is important to point out that this is NOT intended for consultatnts, there is a seperate program called Microsoft Action Pack Subscription that is more geared toward that audience. The Bizspark program is for software vendors, I suppouse it will have some kind of requirement similar to what Empower had, where you have to release commercial software within certain time period.
Let us know how your enrollment goes...
I joined it and empower recently. I think it is a great deal. I had an old MSDN set of software I was using and wasn't relishing the thought of spending all that money for my startup that has no current revenue.
Apparently MS really wants to get back to enticing developers to its platform.
One of the downsides I could see (or upsides depending on your view) [and this requires a health cynicism] is that MS uses this program to
identify potential markets for it to jump into and trounce the competition
identify startups it wants to purchase.
It has all your information in its database - the type of business, etc.
I still joined - no big deal, but for those who already think MS if the big bad wolf this might rub them the wrong way.
I think BizSpark is a great opportunity for startups which either
know they will use Microsoft technology
doesn't know what technology to use
The ones who doesn't know which software tools or programming language to use can test the Microsoft ones along with Open Source or other freely or inexpensive alternatives.
This way they can choose the technologies which suit them best - also when it comes to expenses for licenses - and remember to calculate the time you use to manage the licenses too.
The most enjoyable greetings
Claus Agerskov, SALDI - the Danish Open Source ERP
My $0.02 is that it's a trap. MS knows that many startups, especially the ones without venture capital (which in my book makes them "real" startups), are flocking to open source technologies both because of the cost savings and the control over your destiny -- the ability to fix bugs, modify things, and prevent vendor lockin that are the best parts of open source. MS is trying to trick them into becoming locked in. I'd steer clear. But I'd also steer clear of venture capital for similar reasons. IMHO, a startup that is going to actually go places (more than just being acquired and becoming a money sink like most bubble companies) is founded by a small group of knowledgeable people and funded out of those people's own pockets. Doing what you love because you want to, not because you're getting rich at it is why they have the drive to succeed and innovate that bigger companies don't have.
Related
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 2 years ago.
Improve this question
I work on developer tools for a particular product. There is a competing set of tools for the same product produced by a different company. The user-base is split roughly 50-50 between us.
Recently, the other company has introduced scripting to make their own tools extensible by end-users. This is a feature that we have had planned for our tools for a while, but it is only now that we are able to start implementing it.
My question is: should we try as much as possible to collaborate with the developers of competing product so that end-user scripts can be shared between users on the different products? We would obviously require different implementations, but share the same syntax. This would obviously be better for the community as a whole since there would be more interoperability.
The downside of collaborating like this is that the competing product's scripting language is slightly tailored towards their own implementation. We would have to jump through a few hoops to create an implementation for their scripts on our platform. Or, we would have to somehow convince our competitor to modify their scripts so that they are platform agnostic.
So, to rephrase my question: should we try to collaborate, thus making our community happier, or should we produce a competing scripting language that is more appropriate for our platform?
I realize that this is a very general question with no single right or wrong answer. What I am looking for is a good explanation of the pros and cons of each approach.
I would write something that is specifically tailored towards my own system (don't compromise your technical quality) and then release and fully support a compatibility layer that allows my competitors scripts to run on my system (make it easy for users to migrate).
I'd stay away from doing things that will try to lock people in and cripple them if they move. These tactics worked once upon a time but in this day and age don't really cut it any more. I'd even go so far as to actually (unofficially on fora etc.) help people who are having trouble porting scripts running on my system to my competitors.
Another way to ask the question (and to answer) is to wonder WHAT KIND of script language is DESIRABLE FOR USERS.
If your competitor went a lock-in route with a proprietary scripted language, then please your users (and get a competitive edge) by using a STANDARD scripted language.
Doing so will immensely increase the value of your tool as many persons ALREADY know the scripted language.
Nobody wants to learn a new language.
Would building a unified scripting language harm your customer-base or give the competitor the competitive edge?
Obviously if you want to lock in customers, go solo which will prevent your customers from easily switching over to the competitor's product (sounds a little like Microsoft tactics) or if you know your product is superior, a collaboration will allow you to get customers from the competitor in which case customers will have the choice to choose which business model suits their needs, make a choice based on the quality of the product as a whole as well as which features they really need instead of being locked into an invisible contract due to the choice they made initially.
Going the collaboration route will also put your company in a position where developers will respect your company (for not being a greedy monopoly monster) instead of boycotting it due to their "moral" beliefs in open standards.
I would say that if possible make it compatible, not so much to cooperate but to compete. Making an incompatible solution would lock you customers in to some degree (you don't have any yet with a lot of scripts - so not much gain), but making a compatible solution keeps the door open for customers of your competition to migrate (they might have some scripts by the time you ship yours).
Just my 2cents
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I work in a small company (2-4 software developers) where software is "only" a part of the main product (specialized measurement instruments). So far the software has been built from start to end with no formal process at all, but as we're steadily growing in both in number of products and people involved, it's evident that we need to adopt some kind of methodology for the whole thing (designing, building, testing, maintaining) to avoid blowing into a mess
The problem is that none of us has much real-world experience on such processes. Wikipedia's software development methodology and software development process entries list lots of practices, and I'm aware of the modern buzzwords (agile, extreme, etc.), but we're still lost on how and from where to start all this.
What should we do to get started, given that currently we have no formal process, and the goal would be to have a light process that helps us keep things under control without slowing us down? Is there some:
Essential de facto literature that we should read first?
Essential tools? (We do have a SCM, but should we start using something like FogBugz?)
Practical "do this and this" guidelines?
Any guidelines are welcome, as long as they're not 1000+ page books! I want to avoid both the religious hype and the dull academicity that seem to surround this field, and find out what to do in practice.
Highly recommended reading includes : The Agile Manifesto and The Pragmatic Programmer. Subsequently, you'll probably want to get familiar with Scrum software development, or Test-Driven Development. At the very least you should have:
Source Control repository
Bug tracking system
Standard set of tools
for communication (A wiki tends to be
popular for documentation, these
days),
IDE
Testing framework
A lot of things will depend on the skills of your team and the application domain that you're seeking to go into. Get yourselves familiar with some methodologies, then practice them. Have 15 minute standing meetings at the start of the day. Develop code incrementally with a write a failing test, make it pass, repeat mindset. Etc etc.
I would suggest to try Scrum for start. As lightweight project management framework it should suite your small team needs.
To do that less painful I would also suggest temporary hiring someone familiar with scrum (certified scrum master maybe), after 3-4 months you should be able to keep it running by yourself. Really investing in few months of experienced team member should pay off. And I don't mean analytic, consultant or whatever you call person that comes, analyzes, makes presentation, takes money and goes while you stay with a problem. I mean Team member that will work with you but also introduce scrum to you via daily practice.
You could also just read some books instead, or send one or two team members to a training, but I think that having someone to incorporate Scrum into your daily work and start learning by examples is the best.
Good description detailed description (based on daily work) would be Scrum and XP from the Trenches (alternative source).
Subscribing rigidly to someone else's view of the development process isn't going to work for everyone. Start with the real basics
Get the basics of the development process right - see The Joel Test.
Track everything. Use a system like JIRA, FogBugz or so on to track all issues, features and bugs that are ever reported. Track how long you spend on each task; the information you have the better prepared you'll be.
Triage - Work with stakeholders to make sure what you are doing is actually important, rather than just what you think is important. In my experience, developers and customers often have wildly differing views!
I'm a huge fan of the recent Lean literature by the forerunners of the movement, Mary and Tom Poppendieck:
Lean Toolkit
Implementing Lean Software Development: From Concept to Cash
Leading Lean Software Development
These are very practical books that look at the whole business value chain from a software team's viewpoint, instead of being head-down in software land and ignoring business goals.
i know nothing about medical records but im sure there's great opportunity in it now.
im planning to either find software that manages records or build my own.
if i do build my own, can someone recommend a platform to use? i prefer vb.net. is there anything better for this?
if you do not recommend me to build my own medical records keeping software, please recommend something that is already existent. is that opensource openEMR any good?
i am planning to start some kind of system as a DEMO for a small doctor's office.
I work in the medical industry as an EDI developer. If you "know nothing about it" as you say, I would recommend strongly against trying to create your own. Even beginning to understand all the nuances surrounding the medical field, all the related laws at local, state and federal levels, the variations between how the exact same "standards" are applied across the various segments of the industry and so forth, can take years or longer.
For instance, there are defined standards, but every state government has their own set of "variations" and exceptions and custom rules, and even across segments in the same state things are not handled the same way (i.e. Medicaid, Medicare, HMOs, TPAs, MCOs and so forth can all have different, and often contradictory, regulations that they have to follow within the same state.
Add to that the fact that regulations change on an ongoing basis and, if the federal government gets its way, things are going to change drastically across the board in coming years.
For a developer, the medical field can be one of the most complex
If you want to pursue this, I would recommend taking on a couple of partners, specifically people with extensive skills and backgrounds as business systems analysts in the medical field to guide you and making extensive use of existing tools as a base and, at least at first, focusing on a very specific segment to start with to build up your experience and background.
As for tools, any of the .NET tools are excellent, though I would recommend C# over VB if you can. There's a broader support for C# in third party tools and apps. In addition to some of the tools others have mentioned, I would also add that you will need mapping software, such as Altova's MapForce. This will aid substantially in your ability to transfer records between entities and between formats and mapforce includes the ability to export the map you design as a C# based .dll you can add to your own home grown apps.
There are existing standards (for example, HL7), which vary somewhat from continent to continent (e.g. North America not necessarily using the same standards as Europe), and vendors' implementations of those standards.
If you want a sledgehammer, the the US Veterans Administrations software is open source, and I thought well regarded (or so I read years ago).
You might want to tell us what scale you are looking for, a one doc office, or a hospital chain?
http://en.wikipedia.org/wiki/VistA
http://en.wikipedia.org/wiki/MUMPS
If you're pretty new to this, and don't know too much about it, building your own would not be a good idea. As BBlake said, it can take years to learn everything you'd need to know. There are a few different types of software you can use. One such medical software is AdvancedMD. You may want to try them or just look around elsewhere. Good luck!
Also see the Practice Fusion tool.
I read about them a bit ago here: http://healthcare.zdnet.com/?p=2522
There may be better opportunities in supporting an existing open source medical services app than in creating a new one.
In Canada, OSCAR is a well-regarded open source medical admin application. You can find a list of other such programs, mainly American, at Sourceforge.
There are about 2000 medical record vendors. I do not know a lot about costs, markups price points in the market but I will say that the software is usually phenomenally expensive. It seems to be based on "what the market can bear". Almost every package I have used looks completely amateur compared to software in almost any other category I have used. It maybe that the market is quite small when it is divided by 2000 vendors.
Most database software and general business software would do the job quite well but there are peculiarities to medicine such as HIPAA.
One of the most intelligent pieces of medical software that I have seen (at least for documenting evaluation and management encoutners) is Praxis. You have to be a doctor who is in practice to realize how genius it is. Disclaimer: I have not used it but wish I could.
Penultimately, for medical software to work the patient has to have a portal into it so that they can update, or bring attention to, mistakes.
Finally, all medical software is fantastic when demonstrated. One only knows its flaws when one uses it on every patient for about 6 weeks.
surely build your own software
i work with vb.net and i started developing my own healthcare applications since 2006
it was hard in the beginning, but now, man.. the sky is the limit
building your own apps will help you add or modify features with extreme ease
good luck
if you need any help just comment on my answer and ask your question, i will respond asap
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.
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.
As a long time Microsoft developer, I find MSDN to be an invaluable resource.
However, when tinkering at home I am not able to play with the best latest technologies and the different offerings coming from Microsoft as I cannot justify paying such a hefty price for what is essentially a pastime.
The Express editions are great, but fall flat when trying to use the more advanced feature I am used to from the versions I use at work. I cannot get the latest betas and play with the new offerings, not legally, anyway.
Apart from getting an MVP, how would one go about getting an MSDN subscription for an acceptable price for a non-professional environment?
I am aware of the Empower program, but I thought it was geared towards getting commercial software to market. If this is not the case, it appears like the way for me to go. Thanks!
MSDN subscriptions are per user rather than per device so as long as you're the only person using them I think you should be free to use them at home. I'm not aware of any differentiation being applied to the workplace, unless of course your workplace itself lays down such a rule.
From http://msdn.microsoft.com/en-gb/subscriptions/aa948867.aspx:
MSDN Subscriptions are licensed to
individuals who may install the
provided software without restriction.
Software provided through MSDN
Subscriptions is licensed for design,
development, test and demonstration of
your applications.
See also http://msdn.microsoft.com/en-gb/subscriptions/aa948864.aspx.
There is an Empower program that Microsoft has available. It gives you several Premium subscriptions for cheap, with the catch that you have to be an ISV working towards an actual product.
This (Not available anymore - broken link) gives you all the software you'll need for development, and even a few "real world" licenses for certain apps (like Office)
After a couple of years, you have to pay full price though. The logic being that you should have a product on the market, and can afford it.
+1 Luke's comment about using work MSDN license at home. I think that's the best answer for the OP.
Also consider
DreamSpark (for students): http://www.dreamspark.com
BizSpark (for startups building "next gen web apps"): http://www.bizspark.com
Empower (for ISVs wanting to partner with Microsoft): http://www.empowerforisv.com
(Note there is some overlap between BizSpark and Empower ... many ISVs will find them both useful)
And finally ... don't overlook trial versions and VHD's. Most Microsoft software is available for trial (30-360 days). Many are available via the "VHD Test Drive"
VHD Test Drive: http://microsoft.com/vhd
Check out the Microsoft Action Pack Development and Design subscription. It is designed to replace the Empower program and gives you access to some MS products at a great price point.
https://partner.microsoft.com/global/40132997
In agreement with comments already made - get an Empower subscription, it's geared up towards people like yourself. As I recall, you have 2 years to bring a product/solution to market (where market is very loosely defined) that uses some element of MS technology (again, where this is quite loosely defined). In return for quite a modest outlay, you get MSDN, a bunch of OS licenses and access to development tools and end-user application programs (XP, Vista, Office being obvious examples).
For instance, I develop in Delphi but write code to run on SQL Express 2005 and full-blown SQL Server 2005+, and this entitles me to purchase an Empower agreement. I get all the goodies, plus things like Visual Studio, SQL Server, Office and OS licenses. If you don't bring a solution to market in the time allocated, you can pay to extend your agreement or... well, I must admit I'm not sure. It's hard to see what bad thing can befall you if you try to produce something but ultimately fail - it's the American dream, right? You have to stop using the software at the end of the period, etc. :-)
If you want to develop for desktop Windows you really need some level of MSDN access, or a good broadband connection and some patience while you access the online materials. Empower is a fairly pain-free method of getting your hands on all the best tools for very little outlay indeed - you end up with a large pile of DVDs and CDs, and a few updates during the year. I'd say it was an essential purchase - particularly if this is viewed as a career investment, or some element of training or progression. It's not a lot of money at all (I speak as an ISV - everything I have to pay out truly comes from my pocket!).
You may want to talk to your boss about your opportunities to join MSDN for free. I work at a company using all Microsoft Software, and I get a free subscription, which comes with access to almost all of microsoft's software.
If you have an MSDN subscription at work, odds are good that your subscription license has a provision for you to be able to install things at home as well.
I know with our subscriptions here I'm allowed to install copies of operating systems and development tools at home since I obviously can't use the copies at work and at home at the same time.
Edit: I'm assuming that since you said you were a longtime MSDN developer that you are currently employed doing development on Microsoft platforms.
Even with just one licence you can get MSDN Under a Volume Licence. This is cheaper and (depending on exactly which VL program) can allow the cost to be spread across the VL period (once fully paid the licences become permanent).
Also means you get the VL builds and keys for Office/Windows rather than just the retail.
Many MVP's have gift subscriptions that they can give away, so it pays off to be visible in the community.
Speak at your local user group, start (or participate) in an open source project, start a blog... just generally get your name out there.
Eventually you'll get one (or an MVP :)).
What I've found is that if you pay attention there are plenty of opportunities to snag a free copy of Office or Visual Studio at local Microsoft events.
Good luck!