Should any readers follow this blog in the future they should go to http://bogdanfreedom.wordpress.com
Why did I made the move? Simply because I wanted to use more free software, less proprietary (like blogger). This way presumably I will promote freedom software better.
Also I hope to use WordPress in my blogging efforts about my free software projects.
Sunday, June 1, 2008
Should any readers follow this blog in the future they should go to http://bogdanfreedom.wordpress.com
Monday, March 31, 2008
I believe the problem of communication is by far the biggest problem and obstacle in the adoption of free software. I believe we have solved all the major technical problems in the adoption of free software, and the ones that remain are either being worked on or in testing. What has yet kept us from becoming the dominant supplier of software is our way of communication and marketing. Oh, I hear my readers mumbling: “here comes another free software detractor”. Actually, this is my best attempt at gathering attention upon an issue I can not solve by myself.
Why can't I solve it alone, and then present my solution? Because that would be my solution to my version of the problem, as I see it. It would actually be of little help for others, as their issues are not even addressed. And failing to get their support to my initiative, it would fail itself, as many others did.
This problem needs be advertised by people with higher mind share on the public than my own, as there are still (many) people that negate its very existence.
Where do I see instances of this problem: in support forums in discussions between “gurus” and “newbies”, between developers and (experienced) users. Examples:
“Winning Hearts and Minds” by Angry Admin,
Problems between developers and users:
“A tale of two cultures” Daniel Robbins, Gentoo project initiator
“Why did I stopped reporting bugs on Ubuntu”,
“Why I quit: kernel developer Con Kolivas”,
Marketing problems (about the use of incomplete `truths` in our promotional messages):
Can we please stop fighting FUD with FUD? by Ryan Cartwright
Which can be solved with:
“A Free Software Manifesto For All Of Us" by Marco Fioretti,
These are all old participants in the free software world (or they claim so). Even if every one of this reports are false, this is still an issue that should be analyzed.
I have to give 2 examples and ask your opinion on it.
1) I believe there is an important distinction to be made between our campaigns to use free software and our answers in support forums.
Say an end-user shows up on a support forum saying “I am using your free software program X on some proprietary Operating system” or “in combination with other software that does not respect user's freedom”. In the current support forums the end user is likely to be greeted with a knee-jerk type of answer. For example: “Use Linux” or “read the guidelines” or worse - no answer at all.
I believe the right attitude of the 'support people' should be: “while we do not support your proprietary operating system, but here is the best advice we can provide you given the circumstances...”. The support community should provide end users with the best experience they can, so that users will come back when they are unencumbered by proprietary products.
End users have their own reasons for using their current products and could probably not give up on those products without costly transitions. Best thing to do should be to ensure a smooth transition - smooth by their terms - to free software. If their first contact is positive they are likely to come back. If we behave badly and rude and speak only technical language they will take their business elsewhere.
The fact that most applications of the KDE Desktop (less Kwin, Plasma) will run natively on most used proprietary operating systems is of great help. It will ensure users have a smooth ride to free software and that they do not have to switch applications all at once. It is also my hope that in the people supporting the KDE port on proprietary operating systems will also bring a new way of talking and behaving to the (technical support) free software world.
2) Another big mistake that we do is not explaining the free software philosophy in end users terms and with examples that affect them directly. Explaining artists the same freedoms as to programming coders is wrong: they care more about culture and telling them free software can smooth their ride in free culture is much more effective. By free culture I mean artwork developed collectively, just as our software, and distributed under a free (copylefted) art license.
It is right to present the four basic software freedoms, but for them free software is a means to achieving an end, free culture, and starting with the means to reach the end is wrong in my logic book. We should rather start with the end they care about and help them understand how Free Software can get them to that end. This is where we should rightly show them the four basic freedoms. This is also where I hope to turn them in free software advocates to others in their profession.
Yes I know I have another similar post here Communication in [an] overgrown community
Tuesday, January 22, 2008
Here I try to answer problems posted at Why I’ve stopped reporting bugs to Ubuntu. In this discussion we should assume that everyone involved in a free software project is benevolent. This may not be true in some particular cases, but greatly simplifies discussion.
I belive problems you are facing with Ubuntu developers are part of a larger communication problem within the free software development community. Namely the community has grown so large, that it becomes difficult to communicate with others involved. Actually there are two problems here: communication between project members and communication between different projects. Here I will limit to the first, which will still take a lengthy post.
Developers now hardly only scratch their own 'itch', as there are many requirements coming from all over the world. Experienced developers have more features to add, have more developers-wanna-bes to teach, so they spend less time teaching the beginning developers. Also beginning developers have more and more bugs to solve and less time to spend with them. They are likely to haste the closing of a bug as that could take them closer to being 'full' developers. They have a rather self imposed target of closing bugs and that is a normal desire for advancement. They may not even realize that their bug patch is not ready for 'prime time'. This is not to say that it is anyone's fault. Everyone is working just as before, only there is more work to be done, there are more people to talk to.
Let us take some examples:
On the developer side, I belive the SourceForge.net, has over 1.7 million members and 167,515 projects. Even assuming half or more of those accounts/projects are inactive, these are still staggering figures. Imagine a quarter of these projects are active need at least a maintainer to make them work in your favorite distro, that requires 40.000 maintainers per distro!
On the user side UbuntuForums.org has 483,921 users. How do you handle that many users asking what not and making a flurry of bug reports? Most Linux Distros/projects are expected to hit this wall sooner or later, depending on their how good are their best practices in communication. Please read what Daniel Robbins says about the Gentoo community(-ies) at A tale of two cultures
Let us go to large monolithic projects, where the kernel 'Linux' tops over all other projects with 2500 developers. Here is the perspective on the developer side Being a Moron on linux-kernel. On the user side, nobody really knows how many running kernels are in the world, but we can surely tell that the figure puts a big strain on the user support sites. Communications problems here lead to ugly situations like Kernel Developers vs. Mainstream Users Duel. Also, here is a quote from the APC interview with Con Kolivas:
If there is any one big problem with kernel development and Linux it is the complete disconnection of the development process from normal users. You know, the ones who constitute 99.9% of the Linux user base.
Here is my atempt at a plan to solve this issue:
- we need to raise awareness that we have a communication issue;
- once everyone knows we have this communication issue, we should try to define it more thoroughly;
- once it is defined we should try to find solutions.
There are several problems with this plan:
- it requires communication throughout the community
- we do not know precisely who is 'everyone' in the free software world.
But How do we talk to non-contributing users? We surely can not ignore them, they are part of the problem!
- How do we know when everyone knows enough about it? How do we know we have reached an agreement on defining this issue?
Let us not even discuss how can we solve it. It could lead us to solving problems of a group and ignoring everyone else's. That is no way good. Before introducing the "gate" system, Linux kernel developers had big problems like having no free time. Is the new system better? For developers it is, for users I'll let you, the reader, answer that question.
To end up on the positive side people should know this issue is being addressed at Linux_Foundation_Collaboration_Summit and here is where Mark Shuttleworth talks about some nice tools on improving collaboration: Ubuntu perspective.
These efforts are something that need be encouraged and extended. Also read my older posts at Better free software development and Standard for communication between project infrastructures
Posted by BogdanBiv at 3:14 PM
IF Microsoft or it's partners could do anything else to threaten us they would undoubtedly DO it right away and they would not let it linger. Also if this is the best they can do, then the rightful conclusion is that we are superior to them.
Read what Mahatma Gandhi said:
"First they ignore you, then they laugh at you, then they fight you, then you win." Wikiquote(This quote is also promoted by Red Hat.)How do Gandhi's words apply to Linux: In 1996 Microsoft ignored Linux, in 2001 they laughed at us, now Microsoft fights us: Google
search on NCSoft and Linux. Now they fear us as their most dreadful enemy. But how long can one company's greed and desire for domination can win against everybody's desire for freedom? Not indefinitely, that's for sure! And we're not going away!
See what Martin Luther King Jr. spoke about fighting for social change:
As the days unfolded, however, the Christian doctrine of love, operating through the Gandhian method of nonviolence, was one of the most potent weapons available to the Negro in his struggle for freedom. San
Like Gandhi and King, we also fight for social change: using Linux is ultimately a social activity,
helping others use Linux is also a social activity, developing Linux software is only more so.
Keep fighting, be civil, helpful on forums and never despair. Linux and free software was never in a better position than it is today. We fought a long way, there is a long way ahead of us and we have to keep it up! Do not be angry with Microsoft, relax and invite others join the Linux party, it's so much fun!
Posted by BogdanBiv at 3:08 PM
Wednesday, January 16, 2008
I read this blog post "
A free (as in “freedom”) exercise for your children"
which promotes free software as a tool for educating children. I belive this is a must read for any parent!
The idea presented helps children learn many things:
- collaborate with other children
- make something with a purpose
- being proud of what they have done
Posted by BogdanBiv at 2:20 PM
Sunday, January 6, 2008
I see the way forward as a Foundation Board (free to join as individual contributors, not permited for companies) that establishes community standards on all collaboration resources.
Such a standard should include what kind of information should be contained in a bug report, and this could in turn be implemented as a RDF resource. As far as I have seen LaunchPad already provides RDF resources for bugs. This way there would be an easy transition between different project infrastructures: maybe one will be able to take all the bugs (closed or open) her/his project has on Source Forge and have them automatically imported, as a batch, into LaunchPad or CollabNet.
For project infrastructure there are also tools like Maven, which ads the goodness of dependency management. We should check the effectiveness of Maven and similar tools, find their weakest spot and make a request to the responsible team to improve that feature.
I also think we need to research more thoroughly a free software development methodology. We do not like some Agile or XP programming ways of doing things, so we need our own methodology/-ies. There are some academic studies on our development model but they are scatterd across different web sites. The idea is that we do need a more structured, integrated documentation tool on how we do/should work.
This research is needed to prepare the infrastructure we will use 2,4,8 years from now, when both the number and the diversity of contributors to our community will grow immensely.
GPL is the license under which most free software is released.
Creative Commons are a set of licenses under which most free art is released.
Both licenses can be used for collaborative development.
There are many Creative Commons licenses and they have only one thing in common: their name. The actual terms of licensing can vary broadly from one license to another.
See the article Richard Stallman gave to the LinuxP2P.com (link to web.archive.org):
Some Creative Commons licenses are free licenses; most permit at least noncommercial verbatim copying. But some, such as the Sampling Licenses and Developing Countries Licenses, don't even permit that, which makes them unacceptable to use for any kind of work. All these licenses have in common is a label, but people regularly mistake that common label for something substantial.I agree some Creative Commons licenses have nothing to do with Free Culture, but why is no one promoting the GPL license for artwork?
I no longer endorse Creative Commons. I cannot endorse Creative Commons as a whole, because some of its licenses are unacceptable. It would be self-delusion to try to endorse just some of the Creative Commons licenses, because people lump them together; they will misconstrue any endorsement of some as a blanket endorsement of all. I therefore find myself constrained to reject Creative Commons entirely.
Here is what the Free Software Foundation publishes on their page on licensing:
Licenses for Works Besides Software and Documentation
- GNU General Public License
- GNU Free Documentation License
- Creative Commons Attribution 2.0 license (a.k.a. CC-BY)
- Creative Commons Attribution-Sharealike 2.0 license (a.k.a. CC-BY-SA)
- Design Science License (DSL)
- Free Art License
Posted by BogdanBiv at 7:05 AM