What would you change about the FB ecosystem?
-
- Posts: 453
- Joined: Dec 24, 2005 2:32
- Location: WA - USA
- Contact:
FYI:
Just giving an open source project a new set of clothes doesn't mean you will see more contributions from the community. I put a huge effort into the BCX project to give it a professional / functional look and it didn't do much to attract new developers and users. Maybe your effort will have a different outcome.
Just giving an open source project a new set of clothes doesn't mean you will see more contributions from the community. I put a huge effort into the BCX project to give it a professional / functional look and it didn't do much to attract new developers and users. Maybe your effort will have a different outcome.
John Spikowski, I think having the front-page of the site easier to navigate is a plus, no matter the side-effects. That said, existing users probably have all the important stuff bookmarked, so that kind of change would likely only affect new users to the site. Perhaps your site was already sufficiently professional-looking/functional as to not have an impact on incoming users, but I can definitely see some small room for improvements here.
-
- Posts: 453
- Joined: Dec 24, 2005 2:32
- Location: WA - USA
- Contact:
I have to disagree that changes would be only superficial in nature.
How many times have you wanted to download a library, but found that FB's header/import library was for a previous version of the library, and the one you downloaded wouldn't work?
Not to mention header clashes, translating new headers and chasing these libraries is something that the core maintainers simply can't get done.
However, setting up a project repository we could start projects for library headers, SWIG, fb-ext, FB edit, etc. We could have multiple contributors on any of these projects (it's something the project leaders would determine) andthen we can have all these things happen in parallel. It would be much easier for our small team to vet and test library implementations before we consider them for inclusion in the main package.
Either way, how hard would it be for someone to go to freebasic.net/projects/sdl to get the SDL bindings, and not even distribute them with the release? Food for thought.
Also, an as yet unmentioned but HUGE advantage would be not only to keep libraries up to date like SDL, but to have a project release system that could make multiple past versions enabled, so not only would we allow people to use the latest libraries, we could allow them to still interface with the older binaries they may not want to get rid of.
EDIT: A totally sweet iea, that of course would require some work: Allow people from the Win32 installer to select libraries, and then use REST to pull them down from the fb.net project repositories at install-time. :)
How many times have you wanted to download a library, but found that FB's header/import library was for a previous version of the library, and the one you downloaded wouldn't work?
Not to mention header clashes, translating new headers and chasing these libraries is something that the core maintainers simply can't get done.
However, setting up a project repository we could start projects for library headers, SWIG, fb-ext, FB edit, etc. We could have multiple contributors on any of these projects (it's something the project leaders would determine) andthen we can have all these things happen in parallel. It would be much easier for our small team to vet and test library implementations before we consider them for inclusion in the main package.
Either way, how hard would it be for someone to go to freebasic.net/projects/sdl to get the SDL bindings, and not even distribute them with the release? Food for thought.
Also, an as yet unmentioned but HUGE advantage would be not only to keep libraries up to date like SDL, but to have a project release system that could make multiple past versions enabled, so not only would we allow people to use the latest libraries, we could allow them to still interface with the older binaries they may not want to get rid of.
EDIT: A totally sweet iea, that of course would require some work: Allow people from the Win32 installer to select libraries, and then use REST to pull them down from the fb.net project repositories at install-time. :)
This is what we were talking about on IRC. Version control when it comes to libraries can be a real pain in the tail. Some libraries' headers do not get along with each other, as noted in the bass.bi/freeimage.bi conflict, as one example. It would be much better to have individual maintainers for these libraries, as it would most certainly free the core team from having to maintain them themselves. And of course, in the case of DLLs, trying to track down the specific version to match the import library is often a vain struggle. Each library has its own license, and it's simply too much work for the core team to keep up to date with the libs. So having additional people maintaining the lib pool is a very smart idea.
This isn't even something that really needs discussion...it's something that simply needs to be done, and right away.
This isn't even something that really needs discussion...it's something that simply needs to be done, and right away.
The color of hyperlinks are dark blue with regular text being black.Sebastian wrote:Hyperlinks in forum postings should show up in a different color or formatting (maybe underlined?) than normal text. :) This posting can be taken as an example. If you don't test the entire text if there's a mouseover/hover effect you won't notice the wiki links. ;-)
You might just not have the normal density of rods in your eyes or else the settings for your display are incorrect.
Someone should make hyperlinks a brighter shade of blue in the forums.
@Keal: I think TheMG revealed the problem. ;)
TheMG wrote:Sebastian: I've found the same thing, but it's a bit of an illusion. Previously visited links are displayed in black (like normal text), but new links are blue. As a poster, of course we've visited our own links. But yeah, although it's less of a problem, I'd still like it to be fixed.
It is important, but only one factor, and the effect is quite long term (and must be sustained for a while)John Spikowski wrote: Just giving an open source project a new set of clothes doesn't mean you will see more contributions from the community.
The factors can be summarized as everything that helps on the path of getting involved in development.
And since developers are mostly recruited from say "active" users (users that track development, use snapshots etc), it applies to increasing the size of that group too.
Think
- easily usable releases
- documentation on development practices
- daily snapshots
- interactive bugreporting (*)
- a maillist/forum culture that coaches these crucial groups (active users/potential developers)
(*) using a tracker like mantis really improved bugreport related feedback compared to older solutions based on emailing forms.
other factors (imho)
In the end, an open source project wants more devels, not more users, and this can achieved in multiple ways. One can assume that more "general" users automatically lead to more devels entering the process and go in that direction (trying to be more visible) OR you can try to change the conversion-rates from "ordinary users" to "active users" and from "active user" to "developer", with targeted developer info and infrastructure.
In my opinion the latter is ultimately easier and more successful than the former. Just "getting more users" is somehow always disappointing wrt amount of new developers you pick up.
-
- Posts: 453
- Joined: Dec 24, 2005 2:32
- Location: WA - USA
- Contact:
We always just followed the regular scheduled updates of the distro, and were fine. We had more problems with wiki and forum PHP software (securitywise) than with mantis. Of all PHP packages it has been the least bad one.John Spikowski wrote:I was using Mantis for the ScriptBasic project till it became the source of a hack to use the server in DOS attack. I wasn't too vigilant about keeping the package updated and the problem may have been fix by now.using a tracker like mantis
Longer ago (say >5 years) we did have serious problems with the email module though. It was synchronous, and would send mails to all users for all modifications (which are thousands, since the tracker is been in use for a decade). We had to hack the email stuff which made updating harder. But it was solved by a later version, at least 4 years ago.
I see that a lot of member (including me) have gotten a little text under their names. I think that even such minor changes should be anounced somewhere (probably on forums). This is not a big deal, but it whould be nice to know what's going on "under the hood", even if that doesn't directly corelate to FBC.
At long last, I'm happy to announce that we managed to bring up SVN daily builds of FreeBASIC again. :) The packages are generated and uploaded automatically every day. Currently, we provide SVN builds for Windows and Linux.
Here's the download page: http://www.freebasic-portal.de/download ... ailybuilds
(Unfortunately, there isn't an English description yet. But actually the long German text at the top of the page only explains what you mean by "SVN daily builds" and their pros and cons, mainly.)
As our build system is still in testing phase, you're asked to report any problems, bugs or suggestions. :)
Thank you for any feedback.
Here's the download page: http://www.freebasic-portal.de/download ... ailybuilds
(Unfortunately, there isn't an English description yet. But actually the long German text at the top of the page only explains what you mean by "SVN daily builds" and their pros and cons, mainly.)
As our build system is still in testing phase, you're asked to report any problems, bugs or suggestions. :)
Thank you for any feedback.