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.
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 8 years ago.
Improve this question
A year ago I was a big fan of .NET. I was developing custom applications on demand and it was not hard to understand how you can live by doing this kind of job - the customer asks you to make a custom application, you arrange the price, do the job and earn money.
Now I hear more and more people talking about open source projects and collective intelligence which seems a great concept to contribute something to the innovation. But of course as a full-time employee it is hard to find time to work for free and I don't understand what are other benefits of contributing to open source projects beside personal satisfaction.
I would be very thankful if you could explain how the contribution to the open source project could be paid off.
Thanks.
There are a few benefits to working on open source projects. I'll be brief here and allow you to work out the detail as you go.
Experience. You'll get to use some stuff you probably won't get to use in your day job.
Fun. It will be a project you've chosen, so you can enjoy it a bit more.
Freedom. There will probably be less rules about what you can use and how funky you can make things (within reason)
You Need It! You'll probably choose a product that you have some need for but you want to contribute to the features.
Just because something is open source, doesn't mean it isn't "commercially viable". For example, you might charge for the service of installing, configuring and guiding a client who uses the application and the fact that the software is open source is a big selling point. You don't make money from license fees, you make money from consultancy.
As far as employability is concern? Street cred.
Peer-interviewers often take (varying degrees of) stock in a fellow programmer's contribution to open source projects, especially if you're at a junior level. It shows self-motivation, proactive-ness, ability to work in distributed teams, proof that you've actually used some sort of version control, etc.
One other reason: Suppose you use version 1.4 of an open source product and want a feature added to it. You add it on your own copy and do not contribute back to the open source version. When version 1.5 is released with a lot of other goodies that you would love to have, you will again need to patch up 1.5 with your required feature. If you had contributed back and it went into the open source version, you will not have this maintenance problem.
For me to work as in open source projects has the following advantages:
Make you learn more
Shows to the world your development skills
Make you a reference in a specific subject or for a group of people
Give a good impression about you that you work with development because you love it. Love enough to spend your free time on a free project
It can become a product in the future or with a "key module" or plugins that a user must pay for it
One more time: make you learn more, specially if you are doing a project without relation with your "daily job"
For personal use, many people want to contribute to the open source because they use so much themselves. And the only way they can use open source is if people contribute to it. Also if people want a feature added, they can help others by giving it away.
For many companies, creating open source software means they can benefit largely from additions made by other people, while still getting the software they need.
Also there is the great amount of personal experience, and a good item on your CV that helps.
However, in the end, most open source projects are run/created by people that do it make the software they work on better, to help others.
Contributing to open source shows that you like software development, not just the salary - that can make you more interesting to a prospective employer.
Here's my reasons:
Why I spend so much time working on an Opensource project
And my views about the differences between paid jobs and working on open source projects might also be interesting here.
You might also ask, what are the benefits of giving or volunteering for a charity?
In terms of getting paid, some companies employ people to work on open source projects, full time. But the vast majority of minor contributions will see no direct monetary payback, apart from knowing that the software has been improved for everyone using it. Of course, things such as reputation can be built, you learn more skills and potential employers can see your work, but these in themselves will not necessary equal a monetary payback.
If you write you own software and open-source is you can still sell it, and sell support services for it (e.g. helplines, support, paper manuals, custom programming) This is a common business model for open source companies.
Help to improve code
You can get all updates to you software. You can find out pitfalls and defects in your code if someone else edited some functionality in your code.
Added functionality
Any one can add functionality to your software. By this you will be aware of what all things you missed in the design and can contribute to your future software development.
You might like to try reading The Cathedral and the Bazaar, by Eric S Raymond (a big open source contributor). It's a very good overview of the history of the open source movement, how it works and where it might be going, written in an informal and approachable style. I'm pretty familiar with the ins and outs of open source (my husband's last two jobs have been in open source based companies) but I still learnt a lot from it.
you will be listed as contributors in the project website (if any) and this is great because you can tell your clients that you are the contributor of that open source product. It would add value to you.
it would be good for your portofolio/resume if you are involved in open source project in the past / present.
for fun. you help eagerly to make a better software for yourself and others. it also fun to see your open source project grows and being used by many companies.
experience that you would have for being work together as team. also you can learn from others how to code.
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 8 years ago.
Improve this question
The producing open-source software book is a gold mine of information on starting open-source projects. Yet I am hoping to learn more from the experience of stackoverflow users and was wondering what are the mistakes you made when starting a new open-source project (or difficulties you encountered when attempting to contribute to a new project), and how would you avoid these traps to become a successful project*?
**Successful loosely defined as a project that is used, and attracts active contributors.*
My two biggest mistakes are:
I expect the world to fall in love with my project as soon as I post it anywhere. If I don't get immediate feedback how great I am, I quickly lose interest.
When I get quick feedback, I often don't respond on a timely basis because I have so many projects.
"Eat Your Own Dog Food."
Be your first user. This is good:
to know what you're doing
to motivate yourself
to get early feedback
I think it's nearly impossible to write open source software you're not using yourself.
"Eat Your Own Dog Food" tries to break out of the vicious circle: Nobody uses the software because it is not useable; it is not useable because there is no user feedback. Try to develop something that is useful for you and see if it sticks and gains some traction.
Besides using the software yourself “Release Often, Release Early”. With release I do not mean publishing some source zip somewhere but a real end to end release.
Choosing the wrong license (for different values of 'wrong') is a common pitfall. Two examples:
1.) If you're using a license that does not allow for relicensing under different terms and you accept contributors code, you need to keep in mind that the code suddenly is not yours anymore. This is fine for some hobby project, but might limit your commercial options later. Of course, it also limits other's commercial options too.
An example for this is the GPL. Include contributed code under this license and you're bound to the GPL yourself and can't decide to dual-license later (unless you nail this down for every contributor). Even a simple change of the license to a similar OpenSource license is impossible: See the linux kernel - it's bound to GPL V2 and can't be updated to GPL V3.
2.) If you're using a permissive license (e. g. Apache, MIT, BSD) you need to keep in mind that not only you can go commercial and close the code later, but anybody else can do so too.
Don't get me wrong: I like the GPL, I'm happily contributing to GPL projects and am glad that these projects exist. I also like BSD, Apache, MIT (the permissive ones) and am contributing to projects that others exploit commercially, e.g. through "Enterprise Editions" of the software that I'm getting OpenSource. It's all fair game - you just have to be sure what options you want to have later. None is better, they're just different.
The first pitfall is to start a new project when there are already plenty of existing projects that are planning to do the same thing.
Currently I am starting a blog based on a talk that I have given on the FrOSCon here in germany.
First article: There shall be light – things to keep in mind when starting a project
Maybe this helps. I don't know how long it will take to write the following 19 blog posts.
I'll answer clinton here:
Not so obvious stuff for new users is:
For User focused software:
getting started guide (Get the software to run quickly)
screenshots! Users love screenshots and too few projects provide them
For developer centric software:
getting started guide ("get to code quickly" for example by explaining dependencies, structure, compile and start process)
code of conduct
I'll think a little bit more about it and add it here.
Positively super great documentation is a must.
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 8 years ago.
Improve this question
I have a problem to solve that I think will take 4 days, but if I had a feature request sorted and a snapshot release then I reckon I could have it done in one. Superficially this creates a budget of 3 x my daily rate to get it the feature-request actioned.
So my questions are, have you ever paid an O/S project member to fix something for you? Did it work out OK? How did you sell the idea to your manager / colleagues and where did the money come from?
Most importantly how did you go about asking nicely? Is there an etiquette for these things? Are the project leaders likely to be receptive to the idea?
In case it matters, the software with the the missing feature is a JBoss project - the home of professional open source - and I'm able to claim expenses as I'm a contractor.
At work, we've had good luck hiring open source maintainers to enhance libraries that we use.
Here are some projects we've done in the past:
We needed to integrate Quake 2 with wxWidgets. We hired Vadim Zeitlin, a major contributor to wxWidgets. In less than 4 days, he built a wxQuake2 widget by adapting the Windows version of Quake 2.
Later on, we needed portable access to raw bitmaps. So we hired Vadim again, and worked with him to produce a new raw bitmap API. This involved a substantial bit of design work, but we really liked the resulting API, and we use it to this day.
At a later date, we hired another one of the core contributors to improve wxWidgets accessibility support. As it turned out, we ended up not using this code right away, for various technical reasons. But other people have been enhancing this code since then, and we hope to use it some day.
In other words, hiring open source maintainers is a lot like hiring any other kind of contractor. But some things are a bit different, too. Here's some advice based on our experiences:
You'll have the most luck if you want to enhance an existing project and release the changes as open source.
In general, you want to hire members of the core team. They have the best track records, they're the most productive, and they have the best chance of getting your changes merged upstream.
You want to get your changes merged upstream. If you don't, you'll be maintaining a local fork, which is a headache.
Before hiring, do some research. Who works on the features you care about? Are they somebody you'd enjoy working with? Read the mailing lists and glance at the version control history, and pick out a few people to approach.
During the design phase, there may be a bit of give-and-take. The developers are looking at the larger health of the project, and you're looking at the needs of a specific business. This has occasionally made negotiations a bit more complicated for us, but the final result has typically been a better design than we would have chosen on our own.
And most importantly, don't be shy. In any sufficiently large open source project, several members of the core team will already run consulting businesses. In smaller open source projects, you'll generally find several contributors who want to run consulting businesses.
And if you're still hesitant to approach somebody, you can always ask, "Do you know anybody who'd be interested in getting paid to work on $FEATURE?" If they're not interested, you haven't put them on the spot, and they may tell you who to ask.
On the whole, we've been impressed with the professionalism and productivity of open source maintainers, and I would recommend this route for others.
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 7 years ago.
Improve this question
The company I'm working for is facing some difficulties and our future is, let's say, uncertain. Over the last years, we have developed a framework to build community apps and social networks. We believe that this initiative should not be totally lost, and that it may be useful for the community, so we decided to open source it.
I have some questions regarding this process:
How to choose the most suitable license knowing that the original authors could still contribute and/or do some consulting ?
What are the necessary modifications we have to do in the codebase ?
Do you have some pointers to some existing docs / books which would cover this wide topic ?
I know that those questions are quite open and that there is no simple answer, but I would like to hear from some people with similar experiences.
Thanks in advance !
For the license, you have to ask what your goals are for the license. Is your goal to build a community of people who contribute code back, and not let anyone else create a proprietary fork of your code? Then the GPL would be a good license to choose. Is your goal to allow you to retain copyright, distribute it as open source, but offer an alternative license for people who want to link it to proprietary software? Again, the GPL might be a good choice, though in this case you'll need to make sure you set up copyright assignments from any other contributors that send changes back to you so that you can re-license their contributions.
It sounds like your code might be server-side software, in which case you may want to look into the AGPL; the AGPL is like the GPL, but also requires people to distribute the source to changes if they run it on their own server (which the GPL doesn't require, as it only ever requires anything when you distribute it).
If you want people to be able to build off of it while writing proprietary software, but still contribue changes back to your software itself, the LGPL is pretty good. If you don't care about proprietary forks, and want something that's simply permissive, then the MIT license is a good choice.
The only modifications that are necessary are those that remove any code you are not legally able to release. If you own the copyright on all of the code, then it should be all good, but be careful of any cryptographic code, and talk to a lawyer if there is any in your program. Export restrictions can be a pain to deal with, though they do have provisions that make the process simpler for open source software.
Beyond the necessary modifications, it is good to make sure your code is easy to build and run on as many systems as possible. For instance, you should check which of your dependencies are required, and which ones can be made optional. Some good documentation on how to build and install your software is also good, as well as all the usual things you want in any software development (not just open source), like an easy to build system, unit and regression tests, etc.
A few other things to think about are:
How will other people get their changes to you? Patches on a mailing list? Patches attached to bug reports? Forks on GitHub?
What revision control system will you use? I generally advocate for a distributed revision control system like Git or Mercurial, but Subversion is also very popular and should do the job.
Make sure you make it obvious how the community is supposed to work; a web page describing how to get the software and how to contribute, pointers to your mailing list or IRC channel or whatever medium you want it to be discussed on. If you are going to have a core group of committers or something, document how the process of choosing committers works.
I could go on listing more and details, but I'd probably be repeating things that have already been said. If you want more information, I'd recommend reading Producing Open Source Software by Karl Fogel.
If you're looking for ways to incorporate the open sourcing of this software into a strategy to make money for your company, Joel Spolsky's take is one of the most clearheaded I've read.
If you only read one book on the subject of open source licenses, then it would be hard to do better than Open Source Licensing by Lawrence Rosen.
We've done the same process last weeks. We choose Mercurial as version control system, which works like a charm. Bitbucket is a hosting company, which provides Open source projects with free hosting. You also need more documentation, because people from outside the world will hopefully join your project - this is something different from explaining things to your collegue next door.
One important thing is also that you have to keep in mind, that you now have an audience which you dont want to annoy. With internal development you often change your API, the database schema or something like that. With open source you have to keep in mind, that there should be compatibility between minor versions and clear migration paths if necessary.
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 7 years ago.
Improve this question
I've used a WordPress blog and a Screwturn Wiki (at two separate jobs) to store private, company-specific KB info, but I'm looking for something that was created to be a knowledge base. Specifically, I'd like to see:
Free/low cost
Simple method for users to subscribe to KB (or just sections) to get updates
Ability to do page versioning/audit changes
Limit access to certain pages for certain users
Very simple method of posting/editing articles
Very simple method of adding images to articles
Excellent (fast, accurate) searching abilities
Ability to rate and comment on articles
I liked using the Wordpress blog because it allowed me to use Live Writer to add/edit articles and images, but it didn't have page versioning (that I could see).
I like using Screwturn wiki because of it's ability to track article versions, and I like it's clean look, but some non-technical people balk at the input and editing.
I second Luke's answer.
I can Recommend Confluence and here is why:
I tested extensively many commercial and free Wiki based solutions. Not a single one is a winner on all accounts, including confluence. Let me try to make your quest a little shorter by summarizing what I have learned to be a pain and what is important:
WYSIWYG is a most have feature for the Enterprise. A wiki without it, skip it
Saying that, in reality, WYSIWYG doesn't work perfectly. It is more of a feature you must have to get the casual users not be afraid of the monster, and start using it. But you and anyone that wants to seriously create content, will very quickly get used to the wiki markup. it is faster and more reliable.
You need good permissions controls (who can see, edit etc' a page). confluence has good, but I have my complaints (to complicated to be put here)
You will want a good export feature. Most will give you a single page "PDF" export, but you need much more. For example, lets say you have an FAQ, you want to export the entire FAQ right? will that work?
Macros: you want a community creating macros. You asked for example about the ability to rate pages, here is a link to a Macro for Confluence that lets you do that
Structure: you want to be able to say that a page is a child of a different page, and be able to browse the data. The wikipedia model, of orphaned pages with no sturcture will not work in the Enterprise. (think FAQ, you want to have a hierarchy no?)
Ability to easily attache picture to be embedded in the body of the page/article. In confluence, you need to upload the image and then can embed it, it could be a little better (CTR+V) but I guess this is easy enough for 80% of the users.
At the end of the day, remember that a Wiki will be valuable to you the more flexible it is. It needs to be a "blank" canvas, and your imagination is then used to "build" the application. In Confluence, I found 3 different "best practices" on how to create a FAQ. That means I can implement MANY things.
Some examples (I use my Wiki for)
FAQ: any error, problem is logged. Used by PS and ENG. reduced internal support time dramatically
Track account status: I implemetned sophisticated "dashboard" that you can see at a glance which customer is at what state, the software version they have, who in the company 'owns" the custoemr etc'
Product: all documentation, installation instructions, the "what's new" etc
Technical documentation, DB structure and what the tables mean
HR: contact list, Document repository
My runner up (15 month ago) was free Deki_Wiki, time has passed, so I don't know if this would be still my runner up.
good luck!
I've also been investigating wiki software for use as a KB, but it is tricky to find something that is easy to use for non-technical people. There are many wikis that attempt to provide WYSIWYG editing, but most of the software I've found generates nasty inefficient html markup from the WYSIWYG editor.
One notable exception to this is Confluence which generates wiki syntax from a WYSIWYG editor. This still isn't perfect (show me a WYSIWYG editor that is) but is a pretty good compromise between retaining simple wiki syntax for those who like it and allowing non-technical users to contribute content. The only problem is that Confluence isn't free ($1,200 for 25 user license).
Edit: I also tried DekiWiki and while the UI is nice it doesn't seem to be quite ready for primetime (suffers terribly from the bad WYSIWYG output disease mentioned above). Also seems like they lack direction as there are so many different ways of accomplishing the same task.
Cerberus - it's more a full featured Help Desk/Issue Tracking system but it has a nice KB solution built in. It can be free but they do have a low cost pay version that is also very good.
Personally I use MediaWiki for this purpose. I've tried a number of other free and paid wikis (including Confluence) and have always been impressed with MediaWiki's simplicity and ease of use.
I have MediaWiki installed on a thumb drive (using XAMPP from PortableApps), which I use mostly as a personal knowledge base/code snippet repository. I can take it with me wherever I go, and view/edit it from any computer I'm using.
I think Drupal is a very possible choice. It has a lot of built-in support for book-type information capturing.
And there is a rich collection of user generated modules which you can use to enhance the features.
I think it has almost all the features you ask for out of the box.
Drupal CMS Benefits
We've been using a combination of
TWiki
OpenGrok for the codebase
usenet
LotusNotes based system
As long as there is a google search appliance pointed at these things I think it's ok to have any or many versions as long as people use them