Choosing a name for an open source library [closed] - language-agnostic

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 7 years ago.
Improve this question
How important it is that a Google search for the name will return no result?
If the library is written in Java and a search for 'java libname' returns 10,000s results, does it mean you should try harder and find a name that's availble?

That's not a very good criteria as Google will return all documents containing the word Java and your suggested name. Unless your name is a completely new word, it has likely been mentioned in the same document as the word Java at some point!
To have your project name rise to the top of Google, the important things are:
Pick a word that isn't too common - it doesn't need to be unique, but it needs to be a word that people aren't using on every single web page in the world.
Make sure it is prominent on all pages of your website, including in the title.
Get lots of people to link to your site (of course this is the tricky bit!) Open Source projects have a much better chance of getting to the top of Google for their name than websites on many other topics, simple because geeks generate a lot of links, esp. to sites hosting good, free, software.

It's popularly said: if you can't be found in google, you don't exist.
Jeff Atwood: If It's Not in Google, Does Your Website Really Exist?
Jeff Atwood: ... if every other search engine in the world shut down tomorrow, our website's traffic would be effectively unchanged...
Rob Watson: Without Google you don't exist
Bob Pearson, VP Communities & Conversations, Dell: ... The corporate homepage, dell.com, that's not the real homepage. The real homepage is Google...
JavaLobby: On any given day over 10,000 visitors arrive at Javalobby as a result of Google searches, and suddenly they stopped coming!... Suddenly we no longer existed in the eyes of Google, the world's largest search engine
Reputation Defender Blog: $400 million mall doesn't exist, because Google doesn't know about it
So while your name doesn't have to be absolutely unique, it does have to be distinctive enough for you to be found on Google...

Related

Confused on what license to choose [closed]

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 9 years ago.
Improve this question
I have worked with my friend on a project and made a website. This is the website: TOFSIS
It's more or less like an Educational CMS. Now the thing is, it's in its initial stage. We still have to prepare more modules for the site as instructed by the college.
So, my partner and I thought of making it open sourced so that people in college can build on it. We want to choose from a pool of eligible developers who are really interested and give the codes only to them under certain conditions so that they can prepare a particular module for the site or fix the existing bugs. And for things like GPA calculator, attendance calculator, you don't need the codes for the site.
I read completely about licenses and I don't think we can choose open source license as yet because we are not giving out the codes now. But what about Creative Commons? Just adding a CC badge like SO.
I see that on SO footer there is a CC stamp. SO is not open sourced to my knowledge. But I also heard CC is not meant for softwares or codes. So when does a developer use CC license? And is it fair in my case to use a GPL without giving out the code now but put some more additional custom conditions?
What should I do in my case? I want to put up a license. I don't want anyone to commercialise and I want people to share back things too.
Thank You
The AGPL is possibly the best license choice if you want to make the source code open for people to improve, but also want to force people to share back their improvements.
It doesn't explicitly prevent commercialisation, but anyone who makes a commercial derivative work would have to share all their changes under the AGPL. In practice, this means that a commercial entity would have to find some other way of creating value, e.g. providing value-added services.
Note: The Open Source Definition, require that a license has "No Discrimination Against Fields Of Endeavour". This means that you can't go adding clauses that prohibit commercial use if you want to be classified as open source. You have to let businesses use open source code fairly on the same terms, just like everyone else.
Before I answer, first a question: why not make the code widely available? Since you appear to have no intention of commercializing it, why go through the hassle of using a non-OSS licence (which will spark discussions with your contributors).
Anyway, a good licence could be the Microsoft Reference Source Licence, which will allow viewing rights, but not modification / redistribution. You can make a separate agreement to allow specific people to contribute, ask a lawyer since this goes into contract-law territory (you need permission from them to re-license their code).
But I also heard CC is not meant for softwares or codes. So when does a developer use CC license?
A software developer should never use a CC license for a software program.
Creative Common licenses are fitting for works like images, photos, music, video or the text of documents.
They are less fitting for software because a software program has two forms: object code and source code. The CC licenses do not work well with these two forms. E.g you can edit a photo or a music quite well, that does not work well with software if you don't have the source-code.
CC on stackoverflow btw. is used for the content. So you can edit my answer now and improve it ;)

Any benefit/disadvantages to open beta vs. closed beta for webapp [closed]

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 3 years ago.
Improve this question
This isn't a question about code, but it's programming related. We have a web app that's ready for beta testing. Has anyone noticed any difference between open beta vs. closed beta in terms of the quality or quantity of feedback the testers give or any other factors?
With a closed beta, you can limit the number of users
This might not seem like a big deal but, consider this...
Closed Beta:
the user base is selected by requiring them to write a proposal in how they expect to use the app
you release a highly anticipated app to 100 users with no extra invites for the first month
those users use the program on a regular basis and pick through most of the really common bugs that slipped through the pre-beta release QC.
those users feel privileged to use the app so they brag to everybody about how much they love it (tons of free PR) and are less inclined to trash it because it's still a 'closed beta for a reason'
most of the commonly occurring bugs are identified in the first month and a limited number of invites are given to the first set of beta testers to progress into step 2 of beta
or, there are still a nightmarish number of bugs in the app and further invites are postponed for review until the next release cycle.
Open Beta:
you feel like your app is sufficiently polished so you release it to the masses as a public beta
the more objective users start to find and report bugs
unfortunately, the sheer number of bug submissions bloats the bug tracker so finding bugs becomes sufficiently difficult
since it's hard to find bugs, duplicates start popping up and the bug tracker bloats even more
you spend x amount of effort wasted trying to keep the bug tracker clean while also trying to fix bugs in the code
the less objective users give the app a shot and discover that 'not everything' works perfectly or works in a the way they expected (intuitive)
the less objective users run off to their little blogs and start making posts like 'OMG WTF srsly, [appName] sucks for reason [x] and reason [y] and [z]
all the little 'buzz bloggers' trample all over the name of your app because it makes them feel 'empowered' to publicly rant about any/everything
google indexes all of the blog rants because they contain a lot of indicative keywords related to your product so the top 2 pages that come up when you enter your apps name in google usually involve something along the lines of '[appName] sucks'.
One of the biggest benefits of a 'closed beta' is, you have the ability to control your work load based on how many users you allow and what types of users you allow.
You need an army of 'objective' users to back you up against the 'subjective' users because the ladder group's main purpose in life is to troll the web looking for an app to trash and create a lot of sensational anti-hype over; all in the name of attracting more traffic to their blog.
If you want a really good example of how to successfully run a closed beta look to Google.
with gmail they had a strictly limited closed beta to start
they fixed any obvious bugs discovered by the first round of beta testers
more invites are given out
then they start collecting new ideas of features to implement in their webapp from the beta users
they incorporate features while simultaneously fixing bugs
they dole out more invites
continue tracking features requests and bug submissions
when it's sufficiently polished they release it to open beta
GMail remains in open beta for 3 years
Why? Google is smart. If some random obscure bug pops up 2 years into open beta nobody can really trash google for it because it's still 'beta'. It's like Google's little way of saying, it's good but we're not completely satisfied with just good. Even if they didn't touch the codebase for the last 2 years of the beta, it still gives the impression of 'they're still perfecting it'.
Which leads me to the single most import point of why you'd want to limit the beta...
Once created, you can't change people's perceptions about your product
Watch this, "How to Ignore Marketing and Become Irrelevant in Two Easy Steps" to see what I mean. It's easily one of the most intriguing presentations I have seen.
Note: I've personally participated in multiple 'closed' betas. Namely, GMail, Google Wave, Boxee, Songbird, and a few others.
With a closed beta the people generally want to be there. They've either waited patiently in line to get an invite after signing up, or they've forgotten about it by the time it starts.
With an open beta, you get more people but they tend to be the "hey, this website is neat, I think I'll... OOH SHINY! runs off after a piece of tin foil" type.

Software Critique: Open Source Software [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
Where can I find critical analysis of OpenSource projects?
ie: in-depth analysis of methods within the source, a comparison of projects with others, and performance metrics ...
I'd like to read something about existing projects that would give me an overview of its design, implementation, strengths and weaknesses, so I can choose something to get involved in. Hopefully, there would be more than one analyst per critique.
Ohloh will give you some information, but only what can be machine counted from source code repository data, i.e.:
Languages used, how much of each
Comment percentage
Developer base (i.e. expanding over time)
However, I don't know of any service/site that does automated method analysis at the code level. Ohloh might eventually convey something like "Mostly OOP", but that would be in the distant future.
Almost all reports like the type you mention are done by hand, in a lab and testing a very targeted group .. i.e. comparing performance and coding methods of various web servers. Almost all of the time, you'll find these types of reports on the Slashdot front page, as its data that many people would be interested in seeing.
Something like Ohloh could give you a good start of what you would want to compare yourself, but I know of nothing that will do it for you with any degree of reliability.
Patrick Smacchia (author of execellent tool NDepend) posts analysis of open source projects on his blog
Some posts I remeber
Lessons learned from the NUnit code base
Analysis of Paint.NET
I would recommend you do some searching around on ohloh.net. While it doesn't offer a analysis of architecture, it gives a lot of useful statistics (language, activity, location of members, user rating, license type, news, etc) about popular open source projects. You may find this a useful tool in looking for a project to contribute to.
As an example, here is the page for NUnit: http://www.ohloh.net/p/nunit
You can always search open source project hosting sites such as SourceForge, Google Code, and CodePlex as well, although the information isn't as in depth as with ohloh.
Main problem with open source software seems to be that there is no marketing department (usually) that makes the developers move in a more user - friendly direction.
Yeah, some Linux distributions look nice on the surface but the amount of half - finished, meh - code is incredible.
I have seen amazing stuff like unfinished text editors which gave a "feature not implemented yet" warning on every second click in some distributions, etc...
Not trying to sounds offensive but your question is completely backward. You should be asking what you can do for a specific open source project. Why anyone would analyse open source projects and compare them against each other, I have no idea. I can see some benefit in looking at performance metrics for the actual software but this would be genre specific and in no terms general.
Your best bet is to go to sites like freshmeat, look at the release history, source code and developers working on projects that are of specific interest to you and ones where you can make a difference
In short:
Software can be compared against other software
Projects cannot be compared against other projects. And to do so is ill-informed. What is considered the right method by some is often seen as wrong by others.

Handling paper documentation [closed]

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 4 years ago.
Improve this question
After every new program written a lot of paper documentation remains.
Apart from the usual scribble notes from the programmers there usually is a nice heap of papers containing physical model explanations, calculations and so on (equations, tables, graphs, little pictures describing variables ...)
We usually do numerically intensive calculations in console applications, which are not released to the public (remain in the house, only results go out). Before each project is finished all those papers have to be packed somehow with the application, so that one day, when someone will be reusing parts of it, has some idea what is what in there.
So far, we've been using the 'dirty' solution of just scanning all of it, and packing it up on the disc with the application.
So I was wondering ... for all science guys here in a similar situation ... how do you handle project documentation which is needed, but not released to the public ?
(the one that does, goes to the dtp laddies, and they make it nice and shiny - not our problem anymore :)
I use one of three options:
Keep everything in my lab notebooks, which I archive myself, for low-level stuff
Scan the paper document, and add to source control in pdf. It's ugly, but if someone needs it, it's there
Transcribe the equations, results, etc... in a clean format (usually Latex) for future reference, and again, add to source control. Official paper copy gets signed (I work in a highly regulated domain) and filed in a binder.
In the projects I've worked on we have done a lot of physics calculations in our programs and consequently we have a lot of whiteboard sessions with equations we are working on.
We keep a wiki for each major project and after each whiteboard session we physically photograph the whiteboard with a digital camera and upload/organize it within the wiki. We also scan in paper documents from developers notebooks if it is important and include it in the wiki as well.
Then, we back up the wiki on disc for storage. So our solution is pretty similar to yours, other than we use the project wiki for organization.
If it's important, it seems to me you should treat the internal documentation with the same care with which you treat the public docs.
I create UI paper prototypes when designing the UI of an application, which produces lots of A3-sized papers (in one project we had many desks covered with papers). When the design is ready or it needs to be mailed to somebody, I take pictures of it with a digital camera, so that I can produce a series of pictures showing how to perform some tasks on the UI, which serves as documentation of how the application is meant to work. This serves also as a backup, in case somebody steals/cleans away the original papers.
Here is some of the thoughts... Not so practical though :)
We can make it part of our Check-in notes. This may help the developers going to maintain the application.
Update the requirement document/Low level design document with these items

Place To get EULA and Other Legalese For Software? [closed]

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 was curious if anyone out there has experience getting the necessary legal documents (user agreements, privacy policies, disclaimers, etc.) for a small software business. For example if you just want to have a software 'company' that sells a few piece of software that you have written, are there cheap solutions for something small scale like that?
In Micro-ISV: From Vision to Reality, Bob suggests MegaDox.com and Soft14.com
Stationery stores will sell standard boiler plate contracts.
For software specific stuff most companies just copy the ones from bigger companies and change the name!
The suggestions by others in other answers are probably fine if you intend to stay small scale, but if your intent is grow, and particularly if you might want to have someone else invest money in the business, then it makes sense to invest in a lawyer, one who has experience in software. It doesn’t have to cost a lot if you can develop a relationship with someone interested in working with you for the long run and not running up fees on those basic documents.
By the way, either route you go, it makes sense to read the documents and make sure they fit what you’re actually doing. If you post a boilerplate privacy policy that says you do x, y and z with customer data, but in fact you do a, b and c instead, you’re creating more potential legal troubles than you’re solving.
I'm testing the waters for a crowd funded project to develop user-friendly EULAs. The EULAs themselves would be developed like open source. If a user encounters one of these "open" EULAs, then the user can feel better about agreeing it because
it's been reviewed by an open process, and
you might encounter this same EULA over and over, so you don't have to read it every time.
https://sites.google.com/a/x2xroads.com/nutshell/open-eula
I have recently been looking for the same info as the OP and found a great book which includes standard agreements for software companies which you may use as is or modify with the help of a lawyer.
The IT/Digital Legal Companion: A Comprehensive Business Guide to Software,
Internet, and IP Law Includes Contract and Web Forms
By: Gene K. Landy; Amy J. Mastrobattista
Publisher: Syngress
Print ISBN-10: 1-59749-256-6
Print ISBN-13: 978-1-59749-256-0
It also includes sections explaining issues that you need to consider for different aspects of you software business in regard to contracts, privacy and intellectual property.