What to think about when making a project open source? [closed] - version-control

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'm just about to publish a project as open source, and would really like some feedback on a couple of things:
The code is quite clean but the version control history isn't. Mistakes, debug code, perhaps inappropriate code, etc. Should I clear the history before publishing, or import it anyway to the public repository?
Should I prioritize making a tutorial, feature explanations or api documentation?
Other thoughts that makes a new project easy for people to get into?

In my very humble opinion:
1) If you're set on going open source, be proud of your code. We all know there are mistakes and bugs along the way. There are going to be more, too, so don't feel like you can't display those publically. You can!
2) Definitely. Probably in that, order, too, because that's the order that people using your product are going to read them. They'll have to use your software before they decide to work on it.
3) The best advice I can give is to have clear build instructions, hopefully with scripts to help people configure the environment. A common plague with open source software is requiring new developers to download tons of libraries and configure their box to work just right in order to be able to build the software. That, to me, is very frustrating and can put me off very quickly.
Good luck!

Totally your choice, unless you used copyrighted code for which you don't have distribution rights or if there is some issue involving redistribution, credit, whatever.
Hard to say without knowing what it is. What would you need in order to use it? What would you want to see first? (Probably the tutorial...)
Perhaps a start-to-finish example including installation. Perhaps you should go to the trouble of running it a virtual environment or on a new OS install, so you are sure your installation instructions deal with everything.

It should be easy enough to squash some commits together, and the effort will be worth it. Developers often look through the history to get an insight into how the project was designed ground-up.
Definitely. The least you can do is get some documentation engine like Doxygen to generate the documentation. Tutorial is probably unnecessary at this point; the community will write tutorials for you, provided the code is nicely documented.
Good packaging always helps. Generate pre-compiled binaries for more than one architecture, and if feasible, create RPMs and DEBs. This lowers the entry barrier greatly. Nobody contributes to software they don't use. You could additionally use a nice bug tracker like Bugzilla, or use an integrated solution like Launchpad or Trac. Also set up a mailing list and IRC channel. This will help build a community.

Related

How to protect unity assembly without compiling to IL2CPP? [duplicate]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I release a bunch of tools for free, but recently I have began to sell an application, that has private research, and people have been able to get my source code, and one person publically released my entire source. I spent a lot of time on this program, just to have someone crack it, and release my entire source.
How can I go about protecting my program? I have tried HWID, but people are still able to crack it. I know I am limited by C#, but it the most convenient to use. I just need a way to protect my programs from people trying to do this.
You could have a look at the many obfuscation tools that are out there, for example these:
http://gapotchenko.com/eazfuscator.net
http://orangeheap.blogspot.nl
http://confuser.codeplex.com (succeeded by https://yck1509.github.io/ConfuserEx/ and then again by https://github.com/XenocodeRCE/neo-ConfuserEx)
http://ntoolbox.com)
Well, the problem with languages like C#/Java is that they are generally much easier to de-obfuscate. The way to secure this is generally to put this stuff into a webservice, but you said you couldn't really do that. What about porting specific non-trivial functions over to a language like C, and obfuscate that. Your C# program could then use reflection to make calls to this external/unmanaged dll. It would increase the difficulty for de-obfuscating, but the problem is that if someone wants it bad enough, they can figure it out as it is client-side.
It may be that legal action is the only real solution here, but this is not a site for legal advice, and I am not qualified to give it if it were.
Additionally, this could be a business decision. Consider Making your software open-source and post a donation link. I am also not qualified to give business advice, but this is worth considering. It may actually increase your revenue, not to mention the other benefits that come with releasing open-source software.
There's Dotfuscator (http://www.preemptive.com/products/dotfuscator/overview). But the best solution in some cases is to offer what you do as a web site (Software as a Service).
Consider this tool for example to convert VB to C#: http://converter.telerik.com/
Or this tool to format JSON: http://jsonformatter.curiousconcept.com/
This may or may not work for you. I don't know what the nature of the software you're trying to protect is.
No, your code needs to contain the information needed to decrypt itself, its an impossible problem to solve.
Your best solution is to put your intellectual property on a server in the cloud that only you have access to. Give your customers a unique login, audit their access to check for abuse, off load as much grunt work onto your customers machines, but keep your algorithms locked into the cloud.

Choosing the correct framework [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 9 years ago.
Improve this question
When starting out on any project it could be seen as essential to pick an appropriate framework. I was wondering if you would point out any key questions that should be asked in order to aid the choice. I have looked at numerous sites and there doesn't seem to be any definative questions to ask before a choice is made.
I was wondering if, in any of your experience,s you have come across any key questions.
I gather one of the first is what are you developing? web app or desktop based
Any key questions would be a great help. This is a pretty general question as I am just looking for generic questions that would be asked before a choice is made.
Pick one you (or your team) already know.
Learning a new framework is a time consuming and expensive process that you don't want to be associated with a project. I would say the number one factor when selecting a framework/language is the existing knowledge base in your team.
[Obviously, this isn't very helpful if you don't currently know any, or the ones you do know aren't useful in the project's domain]
The best technology is the one you know. So ask a question - what technologies my team has experience in.
The main question you must ask is about stability. If you are developing an enterprise application wich sould be maintained for several years and should me stable, you should use mature and well tested frameworks. Something Java EE or .NET based for web applications. If your project is experimental, you can use experimental frameworks, technologies, languages etc.
Pick the one with good documentation. The quality of documentation gives you a clue how good the framework is.
A large user community is a plus, especially for opensource frameworks.
Ask yourself right from the start:
What are the things my application
will do, what are the ones it won't ever
do?
Choose a framework that makes it easy to accomplish the things you want from your application, care less for things that are extra. Don't worry, when you'll really need extra, you'll worry about looking then.
Who will use my application? What are
the numbers and needs of people that
will be the application's users?
You need a framework that scales well to the number of users you intend your app to handle and to their specific needs(collaboration, social interaction, ease of use, necessary tools, etc).
Is there a strong support
for the framework(from the developer or the community)?
Make sure you'll have who to turn to if you'll have questions or problems.
I usually try to find the framework that is the most popular. Have a look at a comparison of Javascript frameworks in Google Trends. It's pretty obvious that jQuery is the most popular by a large margin, so I'd lean towards using that.
It's not the only criteria, but more users means better documentation, testing, features, etc. Also, if you're new to an area of programming, then it usually pays to follow the wisdom of the crowd.
I would start by thinking about the pros and cons of frameworks in general. Based on those things that matter most in your situation, see which frameworks fit.
It's also helpful to think about the general features found in most frameworks of a platform (web application frameworks, for example). Decide which of those features are important to you, then investigate the frameworks that provide those features.

How to keep code and specs in sync? - are there good tools [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 5 years ago.
Improve this question
In my team we've got a great source control system and we have great specs. The problem I'd like to solve is how to keep the specs up-to-date with the code. Over time the specs tend to age and become out of date
The folks making the specs tend to dislike source control and the programmers tend to dislike sharepoint.
I'd love to hear what solutions others use? is there a happy middle somewhere?
Nope. There's no happy middle. They have different audiences and different purposes.
Here's what I've learned as an architect and spec writer: Specifications have little long-term value. Get over it.
The specs, while nice to get programming started, lose their value over time no matter what you do. The audience for the specification is a programmer who doesn't have much insight. Those programmers morph into deeply knowledgeable programmers who no longer need the specs.
Parts of the specification -- overviews in particular -- may have some long-term value.
If the rest of the spec had value, the programmers would keep them up to date.
What works well is to use comments embedded in the code and a tool to extract those comments and produce the current live documentation. Java does this with javadoc. Python does this with epydoc or Sphinx. C (and C++) use Doxygen. There are a lot of choices: http://en.wikipedia.org/wiki/Comparison_of_documentation_generators
The overviews should be taken out of the original specs and placed into the code.
A final document should be extracted. This document can replace the specifications by using the spec overviews and the code details.
When major overhauls are required, there will be new specifications. There may be a need to revisions to existing specifications. The jumping-off point is the auto-generated specification documents. The spec. authors can start with those and add/change/delete to their heart's content.
I think a non-Sharepoint wiki is good for keeping documentation up to date. Most non-technical people can understand how to use a wiki, and most programmers will be more than happy to use a good wiki. The wiki and documentation control systems in Sharepoint are clunky and frustrating to use, in my opinion.
Mediawiki is a good choice.
I really like wikis because they are by far the lowest pain to adopt and keep up. They give you automatic version control, and are usually very intuitive for everyone to use. A lot of companies will want to use Word, Excel, or other types of docs for this, but getting everything online and accessible from a common interface is key.
As much as possible the spec should be executable, via rspec, or doctest and similar frameworks. The spec of the code should be documented with unit tests and code that has well named methods and variables.
Then the spec documentation (preferably in a wiki) should give you the higher level overview of things - and that won't change much or get out of sync quickly.
Such an approach will certainly keep the spec and the code in sync and the tests will fail when they get out of sync.
That being said, on many projects the above is kind of pie-in-the-sky. In that case, S. Lott is right, get over it. They don't stay in sync. Look to the spec as the roadmap the developers were given, not a document of what they did.
If having a current spec is very important, then there should be specific time on the project allocated to write (or re-write) the spec after the code is written. Then it will be accurate (Until the code changes).
An alternative to all of this is to keep the spec and the code under source control and have check-ins reviewed to ensure that the spec changed along with the code. It will slow down the development process, but if it is really that important ...
One technique used to keep the documentation in sync with the code is literate programming. This keeps the code and the documentation in the same file and uses a preprocessor to generate the compilable code from the documentation. As far as I know this is one of the techniques Donald Knuth uses - and he's happy to pay people money if they find bugs in his code.
I don't know of any particularly good solution for precisely what you're describing; generally, the only solutions that I've seen that really keep this sort of stuff in sync are tools that generate documentation from the source code (doxygen, Javadoc).

Advantages & Disadvantages of DotNetNuke? [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 9 years ago.
Improve this question
If you have worked with DotNetNuke, what are advantages and disadvantages that you have come across? What are alternative Content Management Systems that you have used that you find are better or worst. I'm trying to get a feel of what Content Management System Frameworks people are using and the advantages and disadvantages of them.
Thanks,
XaiSoft
This post may help as it has covered some of this info!
DotNetNuke works well, and has a wide variety of addins that are available for purchase from various vendors. It is also open source which is nice, as it allows you to troubleshoot issues to a deeper level then if it was closed source.
We didn't spend a lot of time researching CMS systems but this past summer we couldn't find anything with the functionality of DotNetNuke which targets the .net framework. If your not tied to .net then there are a ton of options available.
DNN is very very dynamic in terms of functionality, features and security. There's is nothing like it. However there are a few drawbacks that i felt while using it.
The biggest drawback in my opinion is the response time of a DNN using sites. The code itself is very obsolete and you need to lock yourself and scour on each and every coding details before using DNN. One more is the URL dependency, if you need to change your domain name to another your old database will be of no use.
There are a lot of new promising CMS extension in Dot NET market and Sageframe, in my opinion, is the best of them. I have been using this extension for quite a time now and I am quite fascinated by its features though still in beta.
DotNetNuke is quite powerful. It's biggest advantage is the inline editing of site content, in my opinion. It's biggest disadvantage is that it is pretty resource intensive compared to other CMS systems.
Here's a comparison I wrote last month:
http://www.logicalvue.com/blog/2009/01/cms-shootout-dotnetnuke-vs-joomla-vs-wordpress/
The biggest disadvantage is the missing support for multiple languages.
Yes, you can install multiple languages but you can't write seperate content for each installed language...
It's not hard to write such a module yourself but the other problem is the URLs.
You can use the 'Human Friendly' option but yet again, this does not support multiple languages.
For instance /Products/tabid/57/language/en-US/Default.aspx becomes products.aspx but there isn't a possibility to include the language like this /en-US/products.aspx
I know there are 3th party tools like UrlMaster which covers this up but still I think this should be available in such a framework.
The biggest advantage is the ease of developing your own modules! If a functionality isn't available, you can write your own module without any problems!
.Net Nuke is not good for developing projects.
Microsoft is releasing lot of versiond and including lot of lauguages.
So how developers will learn all the things...
This is very bad for developers.....

Developing addins for World of Warcraft - Getting started? [closed]

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 6 years ago.
Improve this question
As a long time World of Warcraft player, and a passionate developer I have decided that I would like to combine the two and set about developing some addins. Not only to improve my gameplay experience but as a great opportunity to learn something new.
Does anyone have any advice on how to go about starting out?
Is there an IDE one can use? How does one go about testing? Are there any ready made libraries available? Or would I get a better learning experience by ignoring the libraries and building from scratch? How do I oneshot Hogger?
Would love to hear your advice, experiences and views.
This article explains how to start pretty well.
Your first bookmark is possibly the US Interface Forum, especially the Stickies for that:
http://us.battle.net/wow/en/forum/1011693/
Then, grab some simple addons to learn how XML and LUA interacts. The WoWWiki HOWTO List is a good point here as well.
One important thing to keep in mind: World of Warcraft is available in many languages. If you have a EU Account, you got an excellent testing bed by simply downloading the language Packs for Spanish, German and French. If you're an US Guy, check if you can get the Latin America version. That way, you can test it against another language version.
Once you made 1 or 2 really small and simple addons just to learn how to use it, have a look at the various frameworks. WowAce is a popular one, but there are others.
Just keep one thing in mind: Making an Addon is work. Maintaining one is even more work. With each new Patch, there may be breaking changes, and the next Addon will surely cause a big Exodus of Addons, just like Patch 2.0.1 did.
Another useful tools you might like is WarcraftAddOnStudio which lets you make plugins in the visual studio environment.
I learned the art of add-ons primarily by looking at the code of Blizzard's UI. You can see that code by extracting the default UI or finding a copy of the default UI online. Add-on developers sometimes like to over-engineer their pet projects (who doesn't?), while Blizzard's code is usually pretty no-nonsense and straightforward. In addition, Programming in Lua is a pretty useful (if slightly out-of-date) reference for the actual Lua language.
The best way to start is with the book World of Warcraft Programming. It covers LUA, XML, WarcraftAddOnStudio and the WoW API. The book also has sections on best practices and avoiding common mistakes.