Tag Info

Hot answers tagged

54

I believe on the contrary that you should release an open source software as soon as possible. There is no "too soon" for that (but it should compile). Or at least publish the source code very early and continuously (e.g. by frequent pushes on github), without making formal releases. However, it is very important to flag it as alpha or beta stage, and if ...


28

TL;DR: Release Early. Release Often. Personal anecdote: I was really excited about the project I was working on. Like, really excited. I couldn't sleep at night excited. So, I pushed my co-dev into releasing v1.0 faster than he wanted to. It was terrible. Nothing worked the way it was supposed to. There were bugs at every turn, but we logged them and ...


27

I haven't had this situation yet, but that's what I would try: Try contacting the owner Maybe they really lost interest, but are willing to transfer the project to somebody else, in particular someone who has already shown considerate commitment. But perhaps they are just occupied with something else (work, vacations, illness, other projects) and didn't ...


13

If the owner of the original repo is not found anywhere and absent for a considerable, I would publish my own repository as a different version of the project. With this, you take over the lead of development of the library, and don't leave it to die in a corner without being updated ever again. If the original owner ever closes the repo, the world still ...


10

It is the same as with closed source software. Communication is important. Inform users what the state of the software is and why it is available for download. Software will always lead to customer issues, no matter if it is fully tested or not. Most customers do accept that fact, and some customers never do. But if the software will lead to more issues ...


7

Personally I believe the best option would be to out-source the work (perhaps on Freelancer or something along those lines) so that you personally have the features you desire. Thereafter you can offer the patch back to the community, and it'll be their decision whether or not to adopt it. At the end of the day, this solution will be functional for you as ...


6

If you want to remain free in which license to choose for your own parts of the application, you can use libraries with any license that doesn't try to extend its scope to the entire program, but is limited to the library in question. So, the licenses that you must avoid are strong copyleft licenses, such as GPL and AGPL. If you want to use a library with ...


6

There is no moral responsibility whatsoever. No one is being forced to use your half-baked software. The only thing to be concerned about would be your credibility.


3

My experience is that there's a balance to be achieved. Right now, I'm working (in the sense of answering questions and providing development suggestions, without seeing any code) with a developer who's producing what looks to be a very exciting FOSS project that utilizes code I've written. The public release has been repeatedly delayed by realizations of ...


3

Let's invert the logic here, to keep in the spirit of Demorgan's law: Would you want "programmers" to contribute to your project even though they have problems with elementary logic? Is that a net benefit to you? Or will they be time wastes? Does your project have enough volunteers to review their code?


2

Assuming you are the copyright holder for all the code, then yes you can do this. But as I understand things, no other entity will be able to compliantly create a derived work and distribute it because of the incompatibility of the licenses for the code and the "resources". This problem doesn't apply to you since you're the owner of the code and hence ...


2

The Creative Commons Attribution license is a "open" license. It gives you the right to use and modify the data in any way you see fit, as long as you give proper attribution to the source of the data. Migrating the data to a different database engine would be fine. For the other data sources, you need to check on a case-by-case basis if their license ...


2

The goals of most companies is to increase the value of their shares, not to make the whole world better by contributing to open source projects and to help other developers by publishing tutorials. What you are doing at work should go in the same direction as the goals of your company. When you: Work on your project, Teach your colleagues, Improve the ...


2

There's no such major license, as FOSS licenses' primary goal is to maintain the "four freedoms" (or a part thereof for permissive licenses). Any restrictions on possible future functionality (apart from the odious DRM that Stallman banned in GPLv3, asserting it has no place in the future1) are seen as highly undesirable and are gonna condemn a license as ...


1

I don't think either of those two is really more complex or more difficult than he other. I'd choose the one without the unnecessary pass branch, because that's an unnecessary branch. If you consider all the things that keep people from contributing to Open Source (it needs time, some programming ability, motivation, getting a Github account, making sense ...


1

You have to buy a "Code Signing Certificate". Vendors include Comodo or Godaddy, it costs about $150 to $200. You can make installation packages with it for 1 year. The installation package itself has no expiration date (also look up timestamp option). Some famous freeware products don't have certificates, but they are allowed through because lots of people ...


1

TL;DR Canonical build or test files should always be included in the repository. Files that are expected to be customized by each developer should be included in a minimalist way within the repository, often in the form of example files. Reasons to Include a Baseline Guardfile Verbatim Files which are required to build or test your code base should be ...



Only top voted, non community-wiki answers of a minimum length are eligible