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 7 years ago.
Improve this question
I want to start an open source project, but my favourite project name was already used for a framework with the same goal. This project was never popular, there is nothing to download or executable, the project had only two active days with commits at Google Code and is dead since four years. In other words: the project is irrelevant but the name is in use at Google Code and ohloh (the same dead project). The .org domain would be available.
Would it be ok to reuse this project name?
4 years, just 2 active days? Get it and make it better then old dead one ;)
I would advise against it, even if it is clearly dead. Recycling old names can cause a great deal of confusion. Moreover, if the old project has been indexed, then searches for your project or for documentation for your project could accidentally turn up information related to the previous project. There are plenty of good names out there that haven't been taken. Better to brainstorm now than cause confusion later.
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 5 years ago.
Improve this question
I've been developing a small database for my summer internship and I need to write a manual/documentation for it aimed at both users and developers for future use. Thing is...I have no idea where to start or what information to include. Many people I work with have no idea what databases can do so I need to keep it as simple as possible. The database is implemented in Access and I experimented with the database documenter but I think that is overkill. Is there some kind of documentation standard that I can follow or anything of that nature?
As a starter for ten, I'd have thought that the user documentation should be task orientated.
(i.e: How to achieve 'X'.)
In terms of the developer documentation, defining the meaning of any non-obvious fields in your schemas, how they're used and the relationships between different tables, etc. would be a good start. (I'm presuming your VBA code is well commented, etc.) You may also want to examine the existing "Documenting Visual Basic with Doxygen" question/answer.
Just straightforward english if you are explaining a process.
If you have a series of Macros do a document highlighting to code used in each macro and the order it should be employed. This could aid someone down the line if they are trying to automate the process.
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 7 years ago.
Improve this question
I am involved in a project which is meant to eventually become open-source and have a code contributor community. Is there any "right" way of doing this and what should/can I expect?
Thanks
There's a pretty good book on this topic, Producing Open Source Software by Karl Fogel, which is available for free online or in dead tree form if you prefer to read it that way. It would be hard to expand much on it in a single answer. Every project will, of course, be different, so I'd recommend reading that book, and then asking more specific questions about your particular project; answers will depend on the language and platform you use, how active an open source community there already is in your area, what your business model is, and many other factors.
I would recommand using Github or Google Project Hosting (subversion/mercurial), and of course use social media network to promote the project helps too.
You can start something like this - http://wxwidgets.org/develop/
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 9 years ago.
Improve this question
You can see lots of briliant ideas in Open source projects. How authors found these ideas whey they don't exist yet?
Should I learn software dynamics, history and trends(Nothing new under the sun?) for that?
I don't want to start another github project called "API to xyz". What should I do??
Scratch an itch. Find something that you feel is a problem or annoying and write some code to solve that problem. Chances are you aren't the only person who is affected by that particular problem.
I believe a lot of software projects, open source or not, start as someone identifying a demand and working to supply it.
Think you're not satisfied with wherever photo management apps you found. Starting (or forking an existing one) with your needs in mind is an option.
What kind of software you would like to use but can find one that suits you? If yours needs are more or less supplied by already existing applications, why not working on improving one you like most?
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 7 years ago.
Improve this question
Declining commit graph at ohloh.net:
http://www.ohloh.net/languages/compare?commit=Update&l0=c&l10=lisp&l11=csharp&l12=-1&l1=html&l2=java&l3=php&l4=perl&l5=python&l6=haskell&l7=clojure&l8=scala&l9=ruby&measure=commits
Maybe the recession has caused people to focus more on work that pays, instead of their hobbies.
Ohloh stopped automatically discovering new open source projects from code.google.com, sourceforge.net and other forges in January of 2010.
Also a large number of open source projects have since moved to github.com and many new ones start there. Ohloh has never automatically discovered new projects on github.com
So the substantial decline of the graph is due to a data problem on Ohloh's side.
This year, Ohloh has plans to start scraping automatically again.
They plan on covering code.google.com, sourceforge.net, github.com and other forges
Since Ohloh's data is based on commit history from source control, the graphs will retroactively correct themselves and all will be right again in the world.
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 7 years ago.
Improve this question
When I browse github I have a hard time differentiating high quality code from half-finished crap without taking a serious look at the code. What are some good ways to quickly size up a project? Rubyforge allows people to designate a "Development Status". SourceForge has a "recommend" feature. Is there some feature that I've overlooked? I just look at the number of forks and watchers. Is there a better way? I don't see a checkout count, or any other measure of popularity.
I would check for documentation. Well advanced code should have associated documentation, while fledgling projects are too busy getting their code and architecture done to create documentation, which will probably have to change by the time they release anyway. Basically, writing documentation says to me that you think the code is stable and functional enough for users to be able to benefit from it.
Recent activity is a big one. If the project does not have recent developer commits or there are open bugs, tickets, issues, questions, etc without developer responses then move on.